Every company has some form of Software Development Lifecycle (SDLC) process - whether it is formal or informal.

An SDLC includes people, processes, and tools that span the design, build, and support of your information systems. Some components of an SDLC are requirements gathering, analysis, prototyping, software construction, estimating, time tracking, project management, ongoing support, standards, best practices, and software configuration management. Typically, companies that we have engaged in our consulting practice have very weak SDLC implementations and in particular, even weaker software configuration management implementations. Our article will help you get a handle on what software configuration management is, why you need to have it, and how best to apply its principles to help you manage and develop your organization's software.

What Is Software Configuration Management?

Software Configuration Management (SCM) is the collection of processes and tools that are used to effectively manage the development, maintenance, and build processes of software. Tools alone will never get the job done. It is important to note that processes or "best practices" are a critical element in the total success of SCM for your organization.

As a best practice, your SCM should contain all project artifacts in the SCM library for easy access, sharing, and version control.

Software Configuration Management Tools

There are many SCM tools on the market today and their capabilities and prices range significantly. Low end tools begin with open-source products that are simple version-control tools. High end tools offer a great array of features and are highly configurable. Based on your company's needs, you will need to find the right one to do the job. We didn't write this article to help you choose which tool to use. We wrote this article to convince you of the importance of picking an SCM tool and we want to offer some SCM best practices.

If you don't already have an SCM tool, Table 1 offers a starting point if you would like to do further research. Your SCM practice must use some tool. The entry point can be very low cost and more than pay for itself.

The Software Configuration Management Process

At some companies we've worked with, the SCM process is literally source code on the programmer's hard drive, or maybe a shared drive. Imagine a significant software project that doesn't let you keep track of the following:

  • No product or process to keep track of who is working on which modules of code
  • Nothing differentiates versions of software releases
  • No ability to recreate a previous build or version
  • No mechanism to easily compare lines of code

And the list goes on. The power and capability of your SCM tool will dictate what other additional management processes you will need to complete your implementation of SCM. Experienced, successful IT managers and leaders are wholehearted adopters of SCM implementations.

Benefits of Using SCM

The most important benefit of using an SCM is that you will be able to sleep better at night! Basically, you want to know the entire lifecycle of every line of code. You want to track who wrote it, what version it is of the larger product, and you must have the ability to recreate any build. As a software professional, you should strive to move software development from an art to a science. You want to imbed tools and processes into your SDLC process that will result in a more predictable software development and release cycle. Doing so will ensure a higher quality software product and reduce overall operating costs.

An SCM allows you to automate repetitive development tasks and manage the concurrent development process of multiple developers on the same project. SCMs enable you to develop software in a distributed environment regardless of the geographical location of your developers. Using an SCM helps you to create a more bug-free product, manage changes, manage bug fixes, and continue to build the next software release. Developer and manager productivity will increase when you use an SCM.

What Does an SCM Tool Do?

From a simplistic perspective, an SCM product is a central library of software source code. A good SCM lets you store any stream of bits such as project plans, estimate documents, specification documents, or any other artifact of your project. As a best practice, your SCM should contain all project artifacts in the SCM library for easy access, sharing, and version control.

Some SCM products allow multiple developers to check out the same file. Do NOT ever choose to allow developers to check out the same file simultaneously.

As in any library, you must "check out" a file to use or make changes to it. As a best practice, ensure that only ONE person can ever have a file checked out. In our research for this article, we reviewed some white papers that offered scenarios for using SCMs that recommended allowing multiple users to check out the same file. Good SCM software can merge all changes back together. In our opinion, however, this practice has several drawbacks:

  • It takes longer to check items back in.
  • It could lead to someone having to manually check conflicts in the merge process.
  • Merging does not generally work with binary artifacts such as database schemas, Word documents, etc.
  • The multiple merge scenario does not always reflect the accurate history of who updated what and when.

SCMs allow you to designate one person as administrator of the library to define its access control. Your administrator gives users access IDs and passwords, plus access rights. Access rights may be as simple as read or read/write capabilities, or as complicated as functional rights. A functional right may include the ability to make a build or delete files, for example.

Knowing what has happened to each and every file (source code, project plans, requirements, etc.) through its lifecycle is a very important feature. SCMs keep a history of all activity, such as when someone created a file, each revision to that file, notes or comments about that file, and other information that helps you track the lifecycle of that file.

Features mentioned above and many more allow you to effectively manage the development, build, and maintenance process in a structured, well-managed approach.

SCM Tools Are Not All Alike

SCM tools are as different as each user in the way they approach their SCM implementation. Some are more powerful, useful, and flexible than others. Some SCM tools look sophisticated because they have nice interfaces, but their GUIs are the most sophisticated thing about them. Some SCM tools fit into any process flow, while others force users to adapt their flow to fit the tool. For your organization, you need to determine your SCM implementation criteria and measure your criteria against the SCM products in the market. Where your SCM tool is inadequate you must "fill in" that gap with processes to ensure that your SCM satisfies your requirements.

We will not compare and contrast different SCM products or processes in this article. Instead, we'll show you how to use one SCM tool as an example, we'll recommend best practices, and we encourage you to use our example as a way to judge which SCM features and practices are best for your company. Our example will use Microsoft Visual SourceSafe (VSS for short) with Visual Studio .NET and we'll recommend best practices to make them all work well together.

SCM Best Practices with Visual Studio .NET and VSS

Before we begin to offer a prescriptive approach to SCM implementation, we'll first define some common terms. Table 2 discusses many of the common terms and products that you will learn about in this article.

You can include a project in one or more solutions, but you cannot include solutions within other solutions.

Visual SourceSafe Projects

A VSS project is a collection of logically related files typically stored in a central folder on a network share. A VSS project is similar to an operating system folder. Do not confuse the VSS term "project" with a Visual Studio .NET project. When compiled, a Visual Studio .NET project results in an assembly (DLL or EXE). A VSS "project" is simply a folder that contains files. VSS project files may include a Visual Studio .NET project of source files and a collection of Word documents and other "stuff". As a best practice, a Visual Studio .NET project should map into a VSS project folder. You will have additional VSS project folders containing other system files such as documents or binary files.

Develop and Build

Successful team-based software development projects combine many elements, processes, and roles. The two core processes are the development process and the build process. It's essential to develop working practices and project structures that work well for both processes to work in tandem.

Development Architecture

For your development process to be successful, everyone on the team will need basic tools. You should configure all developer workstations in a common, standard way in your development group (and if you can, in your whole company). Standardized workstations improve productivity by reducing installation and setup time, and if issues arise they are much easier to resolve since everyone has the same configurations. Your developers will require at a minimum:

  • Windows 2000, Windows XP Professional, or Windows Server 2003. It is a good idea (if practical) to develop your applications on the same OS as the target production operating system.
  • Visual Studio .NET IDE (including, of course, the Visual Studio .NET Framework).
  • Visual SourceSafe 6.0c (client) or another SCM product.
  • Access to a database server, either locally on each development machine or on a shared remote server.
  • Test database servers. This is the Windows server that will run Microsoft SQL Server or another database management system. In general, you'll have developers and a quality assurance team to test your software, but you may encounter times when testing could harm the database or inhibit others from testing. Developers can import the database from the test database server and continue testing (or experimenting) locally.
  • Access to a Visual SourceSafe (VSS) server. The VSS server houses your source library. You can have as many VSS libraries as you want, but you may want to keep the number to just two or three. It can become confusing to have too many.
  • Test application servers. For an n-tier application you may also need an additional server running the middle tier (business objects).
  • Test Web servers. For Web applications you will need a test Web server (IIS server). Typically, your Web server also hosts the middle tier.
  • Backup server. Do not forget this important element. Always test your restore process. Just because you can back something up does not mean you can restore it.

Hardware Requirements for Developers

Hardware prices keep dropping, so get as much as you can afford for each developer. Our minimum requirements include: 1 GB memory, 1 GHz CPU, and 40 GB hard drive.

Drive Layouts

Within an organization you want your developers to have a common drive. Project leaders often overlook this important topic. A consistent machine environment reduces new developer training, reduces overall development issues with file and assembly references, and allows programmers to move from one machine to another with no effort. Our best practice suggestions for drive layout include:

  • The C drive contains just system software. This means just the operating system, Visual Studio .NET, and all the other application software you require.
  • The D drive contains all of your project data and application data. When you retrieve data from your SCM tool, it should always go onto this drive and not the C drive. Keeping data on only this drive allows you to back up just your data without having to back up all of your application software.
  • The E drive should be a backup image of your C drive. Use Drive Image from PowerQuest or Norton Ghost to create an image of your application software and operating system.
  • Map your DVD or CD ROM drive to X: or Z: right after you install your operating system.

You may have additional drives or different letters, but you get the idea.

Layout of the "Data" Drive

Since your developers will retrieve all data from VSS, everyone's D drive will look similar. A developer's D drive will, in fact, "mirror" the VSS project layout (or a subset of a VSS project). Of course, you may have other things on the D drive, but you should map any folder in VSS that the developer needs to a folder on their D drive.

This approach has some good benefits. A common Drive D layout enables developer's to move between machines that will be very familiar. Try this approach in your shop and you will find that your developer productivity will increase. This approach lets you more easily train new hires since everyone does things the same way.

Visual SourceSafe (VSS) Server

The Visual SourceSafe server is a central file server that hosts one or more Visual SourceSafe (VSS) libraries. You can, of course, locate VSS libraries on different file servers. Use the VSS library to provide versioned, controlled access to project source files. Developers interact with VSS on a daily basis as you check project files in and out through Visual Studio .NET's Interactive Development Environment (IDE). Though you can use the VSS client program to check files in and out, we strongly recommend that you manage your source code through .NET's IDE when developing .NET applications. For other files like project plans, specification documents, and the like, use the VSS client program to manage and use those files.

Use the isolated development model for best source code control.

VSS is a "file management system" and not a database server (like SQL Server). A VSS instance "lives" on a Windows file share and therefore, your system administrator can use basic file share security to ensure that only authorized people can use the VSS library.

You can assign each VSS library to a different administrator or the same administrator could manage multiple VSS libraries. VSS requires very little administration. The administrator would initially create one or more libraries on the appropriate Windows shares and set up the access control lists. The administrator would add the necessary user IDs and passwords for the developers. Unfortunately VSS does not yet offer integration between Windows authentication and VSS library authentication. And, in fact, you will need to add IDs and passwords for each VSS library that you create.

The administrator sets up a Windows share and puts the VSS client installation folder there with read access. In that way your developers can easily install the VSS 6.0c client software. VSS's Netsetup.exe program lets your administrator perform a client setup over a network. Netsetup.exe does not require you to have an installation disc at your computer.

Team Development Roles

There are several instrumental roles when developing software. A role is a function or duty performed by a person. A role does not imply a full time effort, and a role may require three people to perform. Based on your own organization, you'll staff roles as appropriate to get your job done. Here are some of the various roles you might create within your organization.

  • A Systems Analyst develops the functional specification document, the prototype, and possibly the initial data model. We have seen the analyst role vary widely from company to company. A good analyst has a broad range of skills including customer interface, interviewing, documenting, prototyping, and data modeling.
  • A Developer writes software and performs unit testing for all the tasks assigned to them. Also, a developer may do some database modeling, they may need to use SQL and stored procedures, and they need to do software design.
  • A System Integrator or Project Manager is the overall project manager of the development effort, supplying the necessary resources. Key tasks are the customer interface, software integration across the developers, managing the software build, and ensuring a quality product.
  • A Quality Assurance role is involved in the final integrated testing for the application. Many times the developer will assist in this role, but there should be a dedicated team devoted to ensuring the quality of all applications prior to going into production.
  • A Database Administrator (DBA) is responsible for implementing the data model created by the systems analyst. A DBA will ensure that all the data objects are created and that good referential integrity is maintained within the database. In addition, the DBA will most likely generate many of the stored procedures for the application this database will support. Additionally, the DBA performs routine maintenance on the database including backup and restore functions. Finally, the DBA should tune the database for performance.

VSS and the Development Process

Just how should your development team interact with VSS? We strongly recommended an isolated development model. With this model, you completely isolate the developer (edit, debug, and run capabilities) on their own development workstation. This applies to desktop or Web applications. In the case of Web applications, the developer is using the instance of IIS (or other Web server) on their workstation for unit testing. Let's work through a scenario.

  1. The Project Manager or lead developer initially builds a Visual Studio .NET application (Web, desktop, etc.) on their workstation. Visual Studio .NET creates the appropriate VS projects, defines references, and adds other initial solution elements (Web pages, Windows Forms, etc.) to the project.
  2. The Project Manager or lead developer adds this solution to the VSS library through Visual Studio .NET-?NOT from the VSS client program. This is a good habit to get used to. In the case of Web applications, VSS will not work very well without adding and getting projects through the Visual Studio .NET interface.
  3. Now hold a team meeting is with all the roles present and let your Project Manager lead this meeting. The Project Manager assigns each Developer their portion of the project. For example, one developer may get ten screens and another may have to build five screens and five reports.
  4. Each developer returns to their workstation and launches Visual Studio .NET. They then load the solution from the VSS library from within Visual Studio .NET. This, in essence, is called a "get latest" from the VSS library.

Now each developer has their own copy of the entire solution and projects on their workstation, but their copy of the solution is READ ONLY. This is important: Each and every developer should always have an entire instance of the application they are working on. This provides an excellent form of incremental testing. When a developer needs to create or edit an existing source code file, the developer "checks out" the file(s). When a developer has checked out a file, only that developer can edit that file.

After the developer codes and tests his or her program, then and only then should they check it back in. A good rule of thumb is to check in only those files that are fully debugged so that when other developers perform a "get latest" on the solution, they will not be impeded by another developer's bugs.

Approaches to SCM within a Team Environment

You can choose from a couple of different models when you develop Web applications in a team environment. The first approach, non-isolated, lets every developer create and modify all files on a central server. Non-isolated development uses one IIS server on a centrally shared computer and all the files for your application reside within a virtual directory on that server. All developers will check out files from VSS and place those files onto the central IIS server. Each developer will then edit and debug those files on that central IIS server.

The isolated approach to Web development lets each developer create a virtual directory within the IIS server running on their own development computer. The isolated approach makes each developer retrieve or check out files from the central VSS library and store the checked out files on their local machine. The developer will edit, debug, and test everything on their local machine, and once everything works, they check the file(s) back into the central location for other developers to retrieve.

Each of these two types of development has their pros and cons. Let's examine the advantages and the disadvantages of each of these different approaches.

Advantages of Non-Isolated Development

  1. Developers do not have to have IIS running on their local computer.

Disadvantages of Non-Isolated Development

  1. All the source code is in one location, not spread out on different developer's computers. If you lose that one computer and have not checked the changes into Visual SourceSafe, you could potentially lose those changes.
  2. It is very easy to inadvertently affect another developer.
  3. When one developer runs an application with debugging, it locks the process so other developers cannot debug their application at the same time.
  4. If two developers work on the same file, then the "last check-in" wins.
  5. Offers limited source control capabilities.
  6. If a developer modifies some code that causes the code not to work, nobody else will be able to run that part of the project.

Advantages of Isolated Development

  1. You can both develop and debug the application without inadvertently interfering with other developers.
  2. You can test out changes locally without affecting other developers.
  3. It provides superior support for source-code control.
  4. Developers can move the project to another machine and take it with them to show users without requiring a network connection.

Disadvantages of Isolated Development

  1. Each developer must set up IIS on their local computer for developing Web applications.
  2. Each developer must remember to check all their files back in prior to leaving for the evening to ensure that the files are backed up. This assumes the VSS library is part of a backup process (which it should be).

Which Model to Choose

We recommend the isolated model for development. Each user must have IIS on their machine, which in some organizations you may need to restrict, but it is by far the best model for the most flexible source code control.

Visual Studio .NET Settings for Isolated Development

Be sure you set the right options in Visual Studio .NET so you can use the isolated model. From within Visual Studio .NET, go to the Tools menu, choose Options, and click "File share" but do not choose the option for Front Page Extensions. You would choose FrontPage Extensions if you want to use a non-isolated approach with all files located on a central server.

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 or .vbproj 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, *.vb, *.aspx, *.asax, *.resx, *.vsdisco, *.css, 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.

  • 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.

Wrapping up a Project

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.

  1. 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 5 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.

  1. 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.
  2. Locate the Solution Configurations drop down list and select the Release option. By selecting Release, the build will not contain any debugging information.
  3. 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.

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:

  • 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.


http://msdn.microsoft.com/msdnmag/issues/02/09/SecurityTips/ default.aspx

MSDN Article



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.