Visual Studio .NET VSS Integration Works Great
You should always use Visual Studio .NET for all source control operations with VSS. Use VSS's client IDE for operations relating to assemblies, third-party controls, and other ancillary project files. You should perform all project creation, retrieval, and file manipulation by using the integrated VSS support menus from within Visual Studio .NET. This holds especially true for Web-based applications since VSS and Visual Studio .NET will automatically create a virtual directory for new developers just getting started on the project.
The Visual Studio .NET VSS commands guarantee that only the appropriate files are added to source control. It also ensures that your Visual Studio .NET project and solution files are updated with appropriate VSS-specific details.
Use a Consistent Folder Structure for Solutions and Projects
You'll make the lives of your development team a whole lot easier if you use a common file and folder structure for storing Visual Studio .NET solutions and projects within VSS as well as on your hard drive. To keep things symmetrical (and as a result, simpler), set up a folder structure within VSS that matches your local file system structure.
Define a common root folder for your VSS library and your hard drive:
- D:\Projects on your file system
- $/Projects within VSS
Beneath the common root folder, create an application root folder for each of your applications:
- $/Projects/ EmployeeBenefitsApp
You may want to add additional VSS folders under this application folder using the VSS client interface (not Visual Studio .NET's IDE) to store:
- MSI packages
- ZIP files
- External assemblies (EXEs, DLLs)
- Documents including specifications, estimates, drawings, planning spreadsheets, and Microsoft Project files.
Within the software development life cycle you must understand how to manage dependencies and references between projects and solutions, and how to work with dependencies in .NET assemblies, Web services, databases, serviced components, and COM Interop libraries.
As we have expressed throughout this article, you need a consistent and maintainable approach to managing dependencies in a team environment. Dependencies inevitably change over time and as a result they impact the build process and the build order. Also, we have recommended the isolated model of development. Dependencies are much easier to manage under this model rather than using a file share to store assemblies for testing.
Visual Studio .NET supports two types of references:
- Project references
- File references
Visual Studio .NET handles all issues with project references automatically since they are all included in the solution. Visual Studio .NET places a project's Globally Unique Identifier (GUID) in the project file to uniquely identify the referenced project in the context of the current solution. Visual Studio .NET tracks project dependencies and determines the correct project build order. This avoids the potential for referenced assemblies to be missing on a particular computer.
Each time you build your local project, the build system compares the date and time of the referenced assembly file with the working copy on your development workstation. If the referenced assembly is more recent, Visual Studio .NET copies the new version to the local folder.
One of the benefits of this approach is that a project reference established by a developer does not lock the assembly dynamic-link library (DLL) on the file server and does not interfere in any way with the build process.