Structuring Solutions and Projects
Let's look at how you should organize and structure Visual Studio .NET solutions and projects. We'll suggest a folder structure that you can use to store projects locally and within Visual SourceSafe (VSS). To ensure that your development and build processes work effectively in a team environment, it's essential to start with a correct project structure that is consistent across all of your development workstations and your build server.
Visual Studio .NET uses project files as containers for all of the build and configuration settings required to generate a .NET assembly. Project files have either a .csproj
file extension, depending upon the project's language.
Visual Studio .NET supports many different projects types but basically they come in two flavors: Web and non-Web projects. You can create a Web project with a Hypertext Transfer Protocol (HTTP) location (for example, http://localhost/MyWebProject). Web projects include ASP.NET Web Applications used to deliver content to Web browsers, or ASP.NET Web services used primarily for data integration over the Internet.
You create non-Web or Windows Forms projects with a file system location (for example, D:\Projects\MySolution\MyWinProject). Common local project types include Windows applications, class libraries, and others including services, console applications, database projects, and so on.
Solution files (with a .SLN file extension) group related projects together to control the build process. You can use solutions to control build dependency issues and the precise order in which contained projects are built. You can include a project in one or more solutions, but you cannot include solutions within other solutions.
The solution file contains project dependency information used by the build process. For example, assume the dependency information indicates that Project A depends upon Project B and Project B depends upon Project C. As a result, the build order must be Project C, then Project B, and then Project A. When project references are used within a single solution, Visual Studio .NET ensures the correct build order is followed.
Files Subject to Source Control
Visual Studio .NET and VSS are tightly integrated, and one benefit of this integration is that important file types are automatically added to VSS when you add a solution to source control from within Visual Studio .NET.
- Solution files (*.sln) maintain a list of projects that make up the complete application, dependency information, build configuration details, and source control provider details.
- Project files (*.csproj or *.vbproj) include assembly build settings, referenced assemblies (by name and path), global imports (.VB projects only), and a list of the files that make up the project.
- Application configuration files (.config) use Extensible Markup Language (XML) to control various aspects of your project's runtime behavior.
Additionally, Visual Studio .NET automatically adds source files with the following file extensions into Visual SourceSafe: *.cs
, and any other files referenced by your VS .NET project file.
Files Not Subject to Source Control
There are several files that are part of your Visual Studio .NET projects and solutions that you do not need to add to VSS since they are unique for each programmer on your team.
Wrapping up a Project
- Solution user option files (*.suo) contain information about the solution. These are stored in a binary format and are not made to be modified by you. You can delete these files at any time with no harm to your project.
- Project user option files (*.user) contain personalized customizations made to the IDE by you. These options indicate which mode you were in (Debug or Release), the last files you had open in the IDE, and other information about your specific project. You can delete these files at any time with no harm to your project.
- WebInfo files (*.csproj.webinfo or *.vbproj.webinfo) keep track of a project's virtual root location. This allows you to specify different virtual roots for your own working copy of your project. Use a consistent (local) virtual root location when you develop Web applications to allow development across multiple programmers to continue smoothly. You can delete these files at any time with no harm to your project.
- Build outputs (.dll, .pdb, .exe) are not included automatically within VSS, and really they shouldn't be. As you run and test your application, Visual Studio .NET constantly creates these .dll and .exe files. You only need to place the final builds into VSS.
Once your team completes the development of an application, the project manager can make a build. A "completed" application means that all programmers have checked in all the project files and they have completed all testing. We recommend the following steps for the project manager to create a build.
Create a clean Build machine. This machine has never been used for development of this application. If you do not have a Build machine, follow these steps:
- Totally clean your hard drive of any virtual directories relating to this project.
- Totally clean your hard drive of any source code.
- Totally clean your hard drive of any other unnecessary files.
- Delete the VSWebCache folder.
- Wipe out all subdirectories within the Temporary ASP.NET Files folder under C:\Windows\Microsoft.NET\<VersionNo.>.
Now your hard drive should look as if you never worked on this project before.
- Launch Visual Studio .NET and open your project from within Visual Studio .NET by selecting the File menu, choose Source Control, and then choose Open from Source Control.
- Locate the Solution Configurations drop down list and select the Release option. By selecting Release, the build will not contain any debugging information.
- Now build your solution by selecting Build and then choose Rebuild Solution.
Now you have created an EXE and/or one or more DLLs depending on the application type.
Your application is now ready for final testing and production. You should now place the final build assemblies into VSS yourself using the VSS client IDE. I know we said not to use the VSS client before, but this is the one exception as there is no other way to get these assemblies into VSS without using it. You should place the following files into VSS:
- All assemblies that are not projects within your solution (known as "outer system" assemblies).
- Any external executable files or third-party controls that you have purchased.
Be sure to add any additional documents that you have created as a part of your project, and, of course, you should back up the schema of your database into VSS as well. There is no need to store your data, but you definitely need all the schema objects including table definitions, stored procedures, views, triggers, etc.