Follow POI 5.x repository directory structure

[9rnsr]

Current NPOI repository directory structure follows old POI (3.x?). It actually causes some difficulties during port from POI code.

I'm started working to fix issues, and I found some build process issues before change directory structures.

• [x] Scattering of npoi.snk file. (#1028)
• [x] Outdated packages.config files. (#1028)
• [x] Outdated build targets for older .NET Framework versions. (#1031)
• [x] Test cases are not runnable for net472 with VS2022. (#1032)
• [x] Inconsistent NuGet package versions between projects and target frameworks. (#1032)
• [x] Troublesome manual .runsettings file specification for testing. (#1037) It's not automatically detected so we cannot run test cases immediately after NPOI.Test.sln or NPOI.Test.Core.sln open.
• [x] Migrate csproj for net472 to SDK style. (#1037)
• [ ] Revive scratchpad projects.

My current plan of directory tree changes:

current	new	assembly name
/main	/npoi/main	NPOI.dll (keep)
/testcases/main	/npoi/test
/ooxml	/npoi-ooxml/main	NPOI.OOXML.dll (name is unchanged, but will contain additional classes from /openxml4Net)
/openxml4Net	/npoi-ooxml/main/openxml4Net	NPOI.OpenXml4Net.dll (removed)
/testcases/ooxml	/npoi-ooxml/test
/OpenXmlFormats	/OpenXmlFormats/main	NPOI.OpenXmlFormats.dll (keep) (or rename to NPOI.OOXML.Full.dll ?)
/testcases/openxml4net	/OpenXmlFormats/test
/scratchpad	/npoi-scratchpad/main	combine three csprojs into one
/testcases/scratchpad	/npoi-scratchpad/test
/testcases/test-data	/test-data

[tonyqus]

Changing directory tree is a bit dangerous because we may lose git history for existing files. You have to reconsider it.

[mycroes]

The proposed directory structure feels a lot more natural to me. I do prefer src over main, which is a lot more common in C# source trees (see for instance AspNetCore), I'm not sure how limiting that would be with regards to directory structure compatibility with the POI project.

Also, I think renaming DLL's is fine, anyone using modern NuGet won't need to manage the DLL references. Not sure if the OpenXmlFormats namespace is used by consumers a lot (I've personally never used it), renaming that might have more impact (not sure if that's intended work as well though, just saying).

[9rnsr]

@tonyqus Git can track file moving when its content is unchanged. So I'll add two commits for one project migration 1. move files 2. modify files to fix project build errors.

[9rnsr]

I added information about each assembly names in above table.

[9rnsr]

@mycroes POI 5.x has has following directory tree in the repository. (Focus on [!])

/
  poi/           [!]
    src/
      main/      [!]
        java/org/apache/poi/
          (source files for 'poi' artifact)
      test/      [!]
        java/org/apache/poi/
          (test files for 'poi' artifact)

  poi-ooxml/     [!]
    src/
      main/      [!]
        java/org/apache/poi/
          (source files for 'poi' artifact)
      test/      [!]
        java/org/apache/poi/
          (test files for 'poi' artifact)　

  ...

Typical java project has main and test pairs under src, so I'd argue to follow the names to increase code port-ability from POI.

Next, my plan will remove assembly file NPOI.OpenXml4Net.dll (but its contents will be just moved into NPOI.OOXML.dll). But it will never the namespace change (NPOI, NPOI.OOXML, NPOI.OpenXml4Net, and NPOI.OpenXmlFormats), so NPOI users will not get code breaking. Remain three assembly names will be consistent with their containing namespaces, so I'd like to keep these names.

[tonyqus]

any update on this ticket?