Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Software Configuration and Management Using Visual SourceSafe and VS .NET : Page 7

Good software development is a combination of many things that are outside of just writing great code. Turning the art of software development into the science that makes for controllable, predictable, managed software projects makes your business more productive.


advertisement
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: 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. Clear Case
Merant
SourceGear
BitKeeper



Paul D. Sheriff is President of PDSA, Inc., which provides .NET consulting, products, and services, including an SDLC document and architectural framework. Paul is a Microsoft Regional Director for Southern California. His .NET books include "ASP.NET Developer's Jumpstart" (Addison-Wesley) and several eBooks listed on PDSA's Web site.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date