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.
Debugging Issues and Assemblies
- 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").
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: http://msdn.microsoft.com/msdnmag/issues/02/09/SecurityTips/default.aspx, and http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspp/html/vssstarttofinish.asp.
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.