Project structure best practices

The .NET Framework is designed to allow tight integration with development tools, and Visual Studio .NET has many features that work closely with the Framework to ease the application development process. In addition, Visual Studio .NET default settings encourage implementation of best practice recommendations. Even with the defaults, there are things that you should know before you start a team project, or any production project for that matter. This article from InformIT's .NET Reference Guide outlines a set of best practices for structuring development projects.

There are several different ways that you can structure your solutions and projects. The most common method is a single solution that contains multiple projects. This model works well for small and medium-large systems that consist of one or more project assemblies. It allows each member of your development team access to all of the projects in the solution, allowing them to build and deploy the entire solution on their local workstations. The single-solution has the following primary advantages and disadvantages:

• When you need to reference another assembly generated by a separate project, you can use a project reference. Project references are the preferred way to establish references to other assemblies and they are guaranteed to work on all development workstations in a team environment. In addition, because project references are sensitive to changes in the configuration of the referenced project, you can automatically switch from Debug and Release builds across projects without having to reset references.
• Assembly versioning issues are avoided, because Visual Studio .NET detects when a client of a referenced assembly needs to be rebuilt.
• The system build process and build script is much simpler.
• The model scales only so far. If you want to work on a single project within the solution, you are forced to acquire all of the source code for all projects within the solution.
• Due to project dependencies, even minor (non-breaking) changes to a single source file within a single project can result in a rebuild of many projects within the solution. If an assembly's interface changes within a referenced project, you want the client project to be rebuilt. However, unnecessary rebuilds can be very time consuming, especially for solutions containing many projects.

Note that with the last two, there is no hard and fast rule as to how big is "too big." In general, you should be able to comfortably work with a single solution that contains 10 to 20 projects. The maximum number of workable projects in a single solution is hard to define, because it depends on your build server and workstation specifications, the size and number of source files in individual projects, and the dependencies between your projects. There are two other common solution structures. The partitioned single solution is recommended for projects that are too large to comfortably fit within a single solution model. This model breaks a master solution into multiple sub-solutions so that they are easier to work with. In this model, projects often are members of multiple solutions. This model requires more maintenance and care in order to ensure that new projects are added to the appropriate sub-solutions and references are updated appropriately. This model also can be difficult to maintain in source control.

With the multi-solution model, you create individual solutions to group projects in logical or functional areas, and no project is contained in more than one solution. This model allows you to avoid the additional overhead of adding projects to multiple solutions, but forces you to use file references rather than the preferred project references. In addition, assembly versioning becomes an issue when a project references an assembly that is in a different solution.

Whatever model you choose for your particular application, you should ensure that all team members create identical directory structures on their development machines. Define a single root directory for all projects and create a sub-folder for each solution. Projects become child folders of the solution folder. This allows all developers all developers to quickly and easily locate the solution's files in VSS and on each other's development machines. Life in a team environment is difficult enough without adding unnecessary hunting for things.

The most important thing to remember about source control is always to use Visual Studio .NET to create and manipulate your projects and solutions in VSS. Visual Studio .NET ensures that only the appropriate files are placed under source control, and that files are updated with the proper VSS-specific information whenever they are checked in, checked out, or copied. Manipulating your solution with the VSS Explorer is a recipe for disaster. When you place a solution or project under source control, Visual Studio .NET adds the following file types to VSS:

• Solution files (*.sln)
• Project files (*.csproj, *.vbproj, etc)
• Application configuration files (Web.config or App.config)
• Source files (*.cs, *.vb, *.aspx, *.asax, *.resx, etc.)

Visual Studio .NET creates many other types of files on developer workstations and on the build server. These include solution user options, project user options, webinfo files, and project build outputs. These files are not placed under source control.