I usually stick to the same base folder structure for my .NET applications. This one works well for both my open source projects and enterprise projects at work:
| Branch name (usually ‘trunk’) | This root folder contains the solution file.
|
| | All the projects of the application goes here. Each project in it’s own subfolder.
|
| | I keep all build related stuff here, like: - The signing key for the application
- A C# project holding the main MSBuild script file and any custom MSBuild tasks
|
| | Usually not much here, except always a SolutionInfo.cs file.
|
| | All developer-related documents of the project are kept here. This way a developer can easily get the latest version of a document without leaving Visual Studio.
If the project contains auto-generated documentation (for instance using Sandcastle), these generator-projects are kept here as well.
|
| | All installer projects are kept here (Setup projects, WIX projects). Each project in it’s own subfolder.
|
| | This folder contains all the external assemblies used by the project.
All Visual Studio projects reference the needed dll’s directly from this folder.
|
| | Contains all test projects, usually divided in unit tests, integration tests and test helpers. Each project in it’s own subfolder.
|
Note that the above is the physical folder structure. I always make sure that the version control has the excact same folder structure. Never try to build this folder structure from within Visual Studio. Instead build it by hand and add it to source control by hand.
In the main Visual Studio solution file however, I alter the structure slightly by putting the contents of the Application folder directly in the solution root, and mimic the rest of the folders using solution folders:
- Solution root
- All projects of the Application folder
- Build
- Common
- Documentation
- Installers
- Lib
- Tests
Now, with everything being nicely structured, it’s time to do some coding.
Subscribe