The following directory structures should be supported by NMaven
1. Multi-module project with a parent pom containing modules, then a subdirectory for each module, which equates to a VS "project". The .sln file sits beside the parent pom, and each subdirectory contains a .csproj, pom.xml and source code. Source code is not typically put in a subdirectory under the module, but it might be. NUnit test code may be within each module in a directory named "Tests", or it may be in a separate module.
2. Flat structure with pom.xml, .sln, .csproj and source code all in the same directory. Source code is not typically put in a subdirectory under the module, but it might be. If present, NUnit test code should be in a directory named "Tests", which is not packaged in the main artifact. See note below about "nested" projects. The "flat" structure is only supported as a single project with no sub-modules, for projects of type 'library' (dll) and 'exe'.
3. Visual Studio "Web Site" (File > New -> Web Site) project with .sln file copied into the project directory and modified to normalize paths. NMaven will build a zip file containing the aspx files and compiled dlls (in a bin/ directory). There is an issue with building this type of project twice in a row- you must 'mvn clean' before building again.
4. Visual Studio "ASP.NET Web Application" (File -> New -> Project, "ASP.NET Web Application"). Structure is similar to (1). Should build a .zip file as in (3) containing pages and dlls.
Note: Some versions of NMaven have limited support for a "nested" project-within-project structure with source code in the parent directory. This structure will have a .sln and .vbproj file at the top, then directories for additional modules beneath, each containing a .vbproj file. This structure is NOT RECOMMENDED and not likely to be fully supported by Maven tools such as the Release plugin.
TODO: ASP.NET Web Service Application
TODO: ADO.NET project structure
NOTE: In the examples, .vbproj and .csproj are interchangeable, each structure should work for any language, and a solution may be composed of different modules using different languages. In addition, tests within a module may be written in a different language than the main artifact.