Software Configuration and Management Using Visual SourceSafe and VS .NET (Cont.) 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: - D:\Projects\InsuranceApp
- $/Projects/InsuranceApp
- D:\Projects\EmployeeBenefitsApp
- $/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.
Managing Dependencies 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. File References and Isolated Development You must handle file reference dependencies yourself by making those references from within each project that requires file references. A file reference is an external DLL that you reference from within a project in your solution. This DLL most likely resides in a folder other than your project folder. When you are forced to reference "outer assemblies," you have the following two choices: - You can reference an assembly on the build server by using either a virtual drive letter or Universal Naming Convention (UNC) path.
- You can copy the set of assemblies that are generated by the build process from the build server to your local development workstation and then establish a local reference with a virtual path. We recommend that you use this approach.
Here is an approach for setting references to outer assemblies within your solution. - For "outer assemblies" copy from a shared server or VSS to a common drive and folder that is the same for all developers on the project.
- Establish a common drive (for example, drive D) so that all developers reference assemblies with the same path.
- Set references to the local assemblies by using this drive letter and path.
- Periodically check for new build output on the build server and manually copy it locally at your convenience (with VSS, "get latest").
Debugging Issues and Assemblies One issue you may encounter referencing "release" assemblies is that you are unable to debug and step into the assembly. If you need to debug a referenced assembly contained within a separate solution: - Copy the solution to your development workstation.
- Rebuild a debug version of the assembly.
- Set the reference path within the client project to point to the debug output folder of the referenced assembly.
- Rebuild and run the client project.
These steps allow you to debug the local version of the referenced assembly being copied to the client's project output folder. You can then debug and step into the referenced assembly. When you finish debugging and you want to revert back to referencing the assembly from its usual location, remove the reference path entry and set the path back to the normal "release" version of the assembly. Checking Out Project Files You cannot simultaneously check out solution and project files because they contain a project count and references to all files in the project. The Project Manager is responsible for creating the necessary forms that he/she believes will be required for the whole project during the prototyping phase. By doing this they will reduce the need to check out project files. If you need to check out a project file to add, rename, or delete a file, do it quickly then immediately check the project file back into VSS. Otherwise, if someone else needs to add a new file to a project they will be unable to since the project file is checked out to someone else. This holds true with solution files as well. If someone has the solution file checked out, you cannot add new project files. When to Check In Files Only check in bug free files. You don't have to finish coding all the functionality, but you want to ensure that if anyone does a "get latest" at any time from VSS on the project that they can run the project with no errors. If you are not completely done with a file and you know it still has bugs, comment out the lines that cause the error, do a build to ensure that your file is error free, then check the file in. You should check all files in each night. This allows your system to back up all files related to the project. Resources on VSS The Internet is your best resource for more information on software configuration management, Visual SourceSafe, and Visual Studio .NET. We found two particularly good resources that we used when we developed this article. MSDN http://msdn.microsoft.com/msdnmag/issues/02/09/SecurityTips/ default.aspx MSDN Article http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspp/html/vssstarttofinish.asp Summary It takes a lot more than code to manage a project. You must take the complete software development lifecycle into account including analysis, design, prototyping, estimating, data modeling, coding, testing, and building your project. Using good software configuration management tools will help you ensure that you maintain all the artifacts for the project in one location. All developers should use VSS or a similar tool whether they are working on a team or not. We've found that VSS makes going back to a previous version of a file very easy, whereas not using a tool like VSS makes going back to a previous version almost impossible. Paul Sheriff |