Team Development with Visual Studio .NET and Visual SourceSafe

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

 

Working with Visual SourceSafe™

Microsoft Corporation

January 2002

Summary: This chapter provides a series of step by step procedures that walk you through common development tasks such as how to add solutions and projects to Visual SourceSafe, how to retrieve solutions from VSS, and how to check files in and out on a daily basis. This chapter gets you up to speed quickly on the essential tasks.

This is Chapter 6 of the Team Development with Visual Studio® .NET and Visual SourceSafe™ guide. Start here to get the full picture.

This chapter will help you work with the integrated source control features provided by Microsoft® Visual Studio® .NET in order to perform the following development tasks:

• Creating solutions and projects
• Working on existing solutions and projects
• Adding a new project to an existing solution
• Checking source files into Microsoft Visual SourceSafe™ (VSS)
• Renaming and deleting projects, files and folders

This chapter presents a series of mini-walk through procedures that guide you through a set of common tasks that you are likely to perform on a daily basis.

Note   This chapter describes procedures that apply to Visual SourceSafe version 6.0c.

Visual Studio .NET provides fully integrated VSS support. It's essential that you use Visual Studio .NET when checking projects and files in and out of VSS on a daily basis because Visual Studio .NET is aware of the various file types that constitute different types of .NET projects. It automatically places the appropriate files under source control, while leaving user-specific files untouched. The Visual Studio .NET source control functionality also adds its own specific information to both Visual Studio .NET solution and project files. If you use the VSS Explorer directly, this functionality is bypassed.

Figure 6.1 illustrates a high level overview of the development process and shows four common tasks that you will need to perform when interacting with VSS:

Figure 6.1. Interacting with VSS

As illustrated in Figure 6.1, there are four basic tasks that you regularly perform as a developer: You need to:

• Create a new solution and project and add these to VSS.
• Work on an existing solution for the first time.
• Work on an existing solution that you have worked on before.
• Add a new project to an existing solution.

This chapter explains how you must perform each of these tasks together with some other tasks that you may occasionally need to perform, such as renaming projects, files and folders within source controlled VSS projects and using VSS in a multiple checkout mode.

Creating a New Solution and Project

In this scenario, you want to create a brand new solution that initially contains a single project and then add the solution and project to VSS. The process of creating both Web and non-Web project types and adopting the recommended folder structure is described in Chapter 3, "Structuring Solutions and Projects." The following procedures assume you have created solutions and projects in accordance with the prescribed structure.

Note   Each project file contains a Globally Unique Identifier (GUID) to uniquely identify that project within a solution. Therefore, you should never copy and rename an existing project file to create a new project, as both will share the same GUID and cannot be distinguished from one another by Visual Studio.NET. Problems will ensue if you include both projects in the same solution.

How to Check In a New Solution to VSS

After you use Visual Studio .NET to create a new solution and project file, and after some initial development, you must check in the solution and project to VSS.

To add a new solution to source control

1. On the File menu, point to SourceControl, and then click Add Solution to Source Control. If you are adding an ASP.NET Web application to VSS, the following Source Control message box appears.

   

2. Select the Don't show this dialog box again check box, and then click Continue to close this dialog box.

3. You may then be prompted with the VSS login dialog box. This happens only if your VSS administrator has not configured VSS to use automatic network user login. Enter your VSS user name, and then click the Browse button to locate the VSS database on the VSS server. Select the Srcsafe.ini file that identifies your development database on your VSS server's file share.

   Note: If automatic network user login is configured, you do not see the VSS login dialog box. In this event, if you want to change VSS database, run the VSS Explorer, and then click Open SourceSafe Database on the File menu. Then browse to the appropriate Srcsafe.ini file.

4. You can then enter a meaningful name for the database—one that represents the name of the system that you are currently working on. Click Open, and then click OK to connect to the database.

5. In the Add to SourceSafe Project dialog box, expand Projects, and then select your system name.

6. Click the Create button. This creates a VSS project folder specifically for your solution file. The VSS folder has the same name as your Visual Studio .NET solution.

7. Click OK.

8. Important: If you are adding an ASP.NET Web application to VSS, you are prompted to add each Visual Studio .NET project to VSS. For Web applications only (the following two steps are not required for non-Web applications):

   1. Expand Projects, expand your system name, and then click your solution name. Click OK.
   2. You are prompted to create a new VSS folder to contain the project. Click Yes to create the new folder. This process repeats for all Web projects in the solution.

Your solution, project, and source files are now placed under source control within VSS. Notice that a padlock symbol is displayed in the Solution Explorer window next to all of the files that have been added to VSS. This indicates that they are currently locked within VSS. Your local working files have been assigned the read-only attribute to prevent you from working with them until you check out the files from VSS.

Check Out on Edit

If you subsequently start to edit a locked file, Visual Studio .NET has an automatic check out on edit feature that prompts you to check out the file. If you decide you want to continue and edit the file, click the CheckOut button in the Check Out For Edit dialog box. The file will be automatically checked out for you. You can subsequently right-click the file within Solution Explorer and click CheckIn, to check in the file to VSS.

Working on an Existing Solution for the First Time

In this scenario, another team member has created a solution and added it to VSS. You now need to obtain the solution for the first time in order to work on one of the projects contained within that solution.

To obtain an existing solution from VSS

1. Start Visual Studio .NET.
2. On the File menu, point to SourceControl, and then click Open From Source Control. You are prompted with the VSS login dialog box.
3. Enter your VSS user name, and then click the Browse button to locate the VSS database on the VSS server. Select the Srcsafe.ini file that identifies your development database on your VSS server's file share. If you have previously connected to this database and selected Open this database the next time I run Visual SourceSafe, the database will be pre-selected.
4. Click OK to connect to the database. The Create local project from SourceSafe dialog box displays.
5. Expand Projects, expand your system name folder, and then click the solution you want to obtain. In the Create a new project in the folder edit box, enter \Projects\SystemName\SolutionName, where SolutionName is the name of your particular solution. This ensures that you have the correct local file system structure.
6. Click OK. If the local solution folder doesn't exist, you will be prompted to create it. Click Yes to All to create the solution folder. For non-Web applications, this also creates the project subfolders.
7. For ASP.NET Web applications, you are prompted by the Set Project Location dialog box to enter a working location for the Web application. This allows you to specify a URL which identifies the path to the Web application's virtual root. By default, Visual Studio .NET assumes https://localhost/<projectname>. If you click OK to accept the default location, the new virtual root is created beneath your default Web site (typically \Inetpub\wwwroot). This is not the recommended location when you are in a team environment, although you do want to create the application locally. To create a virtual root in a project subfolder beneath the solution folder, perform the following steps before you click OK to accept the Set Project Location dialog box:

   1. Use Microsoft Windows Explorer to create a project subfolder beneath the solution folder which has been created for you at \Projects\SystemName\SolutionName. Use the project name to name this subfolder.

   2. Use Windows Explorer or Microsoft Internet Information Services (IIS) to set this folder as an IIS virtual root.

   3. Return to Visual Studio .NET and enter https://localhost/projectname/ as the working location.

      Important: You must overtype and change the existing Uniform Resource Locator (URL) or the dialog box assumes the address still maps to a folder beneath \inetpub\wwwroot).

   4. Click OK to close the Set Project Location dialog box. This places the project and Web application files in the virtual root, which maps to a subfolder one level beneath your solution folder.

8. The solution, project, and source files are now downloaded to your hard disk. However, note that they remain locked in VSS. The padlock symbol next to each file in Solution Explorer confirms this.
9. You can now either select one or more of the files within Solution Explorer, right-click, and click CheckOut, or simply start editing the source files because the check out on edit feature of Visual Studio automatically prompts you when a file needs to be checked out.
10. After you complete your local development, you can either check in each file individually or use the Pending Checkins window within the integrated development environment (IDE). You may need to click PendingCheckins from the View menu to display this window.

Note   If you exit the solution without checking in the files, you are not prompted. The files remain checked out in your name.

Working on an Existing Solution for a Subsequent Time

In this scenario, you want to work on an existing source controlled solution that you have worked on at least once before. As a result, your local file system contains a solution and project folder with read-only solution and project files.

To obtain an existing solution from VSS

1. Start Visual Studio .NET.
2. If the required solution is displayed on the start page, click the solution. Otherwise, open the solution by browsing to the solution (.sln) file on your local file system.
3. To ensure you have the most up-to-date set of project files, you can select the solution within Solution Explorer, right-click it, and then click Get Latest Version (Recursive).

Important   When working on an existing solution that you have previously obtained from VSS, you should open the local solution file. Do not use the OpenFromSourceControl menu item in this scenario. If you do so, Visual Studio .NET detects the presence of local solution and project files and you are prompted to overwrite these files. Also, if you have one or more of these files checked out, you are prompted to either replace the local files with versions from VSS, or to leave the local versions untouched. Opening the local solution file is a simpler and less error prone approach.

Adding a New Project to an Existing Solution

In this scenario, you want to add a new project to an existing solution. The following procedure assumes that you have obtained the solution from VSS as described earlier.

To add a new project and add it to VSS

1. On the File menu, point to AddProject, and then click New Project.
2. Select the appropriate project type and template, and then enter a name for the project.
3. For ASP.NET Web projects, you must manually create a project subfolder beneath the solution folder and mark it as an IIS virtual root. For non-Web applications, the new project folder defaults to a location one level beneath the solution folder.
4. Click OK. Visual Studio .NET automatically prompts you to check out the solution file (if you haven't already got it checked out) because it needs to add the new project details to that file.
5. Click CheckOut. The new project is added to the solution and appears in Solution Explorer. Notice that each file in the new project has a tick symbol displayed next to it. This indicates that the files are not locked and are available for edit.
6. After you complete your initial development work with the new project files, they must be checked in to VSS. To add the entire solution (with the new project) back into VSS, right-click the solution in Solution Explorer, and then click CheckIn.
7. The CheckIn dialog box displays all the files currently checked out. This includes the new project file and source files. To check in all the files, click CheckIn.

Checking In Source Files to VSS

After your solution and project are in VSS, you need to check-in only those files that you have updated. To do this you can right-click an individual file within Solution Explorer and click CheckIn. Alternatively, you can see a list of all files that need to be checked in by using the PendingCheckins page that is displayed at the bottom of the IDE. You can easily check in multiple files using this page.

Only Check In Files When They Are Ready to Build

Generally, you should check in projects and files to VSS only when you are confident that they are fully unit tested and are unlikely to cause integration problems when built alongside other project updates made by fellow team members.

Important   This may mean that some files are not checked in to VSS for several days. As a result, make sure you have adequate daily backup procedures in place for all of your development workstations.

Note   If you work with a change management system that natively supports the concept of promotion levels, you may prefer to check in files at regular intervals, regardless of their current state of completeness. Change management systems that support promotion levels usually provide an initial "Development" level specifically for this purpose. The build process never extracts source files from this level. Instead, it operates with source files associated with a higher promotion level such as "Integration." Developers or the build coordinator promote files to this level only when they are ready to be integrated with the overall system build.

Renaming and Deleting Files and Folders

On occasion, you may need to rename and/or delete individual files or folders that are within source controlled VSS projects. Rename or deletions that are performed with the Visual Studio .NET IDE are not automatically propagated to VSS and vice-versa. As a result you must use VSS Explorer in conjunction with Visual Studio .NET.

Renaming a File

The following procedure describes how to rename a file in a Visual Studio .NET project.

To rename an existing file contained within a Visual Studio .NET project

1. Use VSS Explorer to ensure that the file you want to rename is not checked out.
2. Use VSS Explorer to rename the file.
3. Use Visual Studio .NET to open the solution that contains the project with the file to rename. The file that you have renamed within VSS appears checked out within Solution Explorer. If you already have the project loaded within Visual Studio .NET, select the project file within Solution Explorer, right-click it, and then click Get Latest Version (Recursive).
4. Select the file within Solution Explorer, right-click it, and then click Rename. Rename the file to match the new name within VSS.
5. You will be prompted to check out the project file because it contains a file inventory. In the Check Out For Edit dialog box, click Check Out.
6. In the Source Control message box, click Continue with Change.
7. The file now appears locked within Solution Explorer. Check in the project file to VSS.

Renaming a Project

When you rename a project you should rename the following items to retain a consistent naming convention, as described in Carefully Consider Naming Conventions in Chapter 3, "Structuring Solutions and Projects":

• The Visual Studio .NET project file
• The local file system folder that contains the project file
• The VSS project folder
• The output assembly name
• The root namespace used for the project

To rename a project

1. Ensure that the following files are not checked out: the project file, the solution file that contains the project file, or any file within the project.
2. Check out the solution file. Select the solution within the Visual Studio .NET Solution Explorer, right-click it, and then click Check Out. Make sure that only the solution file (and no project files) is selected in the CheckOut dialog box, and then click Check Out.
3. You must now unbind the project from the VSS database. Within Visual Studio .NET, point to SourceControl on the File menu, and then click Change Source Control.
4. Select the project you want to rename (this may also automatically select the solution) and then click the Unbind button. In the resulting SourceControl message box, click Unbind.
5. Click OK to close the Change Source Control dialog box. The project file (and possibly the solution file) is now no longer bound to the VSS database.
6. Within Solution Explorer, right-click the project you want to rename, and then click Rename. Type the new project name.
7. On the File menu, click SaveAll to ensure the local solution file is updated.
8. You must now temporarily remove the project from the solution to allow you to rename the local project folder. Right-click the renamed project within Solution Explorer and select Remove. In the resulting MicrosoftDevelopmentEnvironment message box, click OK.
9. Use Windows Explorer to rename the local file system project folder to match the renamed project file name.
10. If you are renaming a Web application, use Windows Explorer or IIS to establish the renamed folder as an IIS virtual root. Also, use Notepad to edit the .webinfo file within the project folder and set the URLPath attribute to point to the project's new virtual root folder.
11. Return to Visual Studio .NET. Right-click the solution file within Solution Explorer, point to Add, and then click Existing Project. Browse to the renamed local project folder, select the renamed project file, and then click Open.
12. Use VSS Explorer to rename the VSS project folder to match the renamed project.
13. You can now rebind the project to the VSS database. Return to Visual Studio .NET, point to SourceControl on the File menu, and then click Change Source Control.
14. If the solution file is currently unbound, select it within the ChangeSourceControl dialog box, and then click Bind. You may need to log into VSS at this point. Navigate to the solution folder within VSS, select it, and then click OK.
15. Select the renamed project within the ChangeSourceControl dialog box, and then click Bind. Log into VSS if required.
16. Navigate to the renamed project folder within VSS, select it, and then click OK.
17. Click OK to close the Change Source Control dialog box. In the resulting SourceControl message box, click OK.
18. Use the PendingCheckins window to check in the solution and renamed project file to VSS.
19. You should now check out the relevant source files and update the root namespace to match the project name.
20. You should also check out the project file and update project properties, including the Assembly Name which controls the name of the output dynamic-link library (DLL) or executable file. Also, for C# projects, update the Default Namespace and for Microsoft Visual Basic® .NET projects, the Root Namespace, because these govern the default namespaces into which new types are added.

To tidy up the old project files

The old project file, the associated source control metadata file and for Web applications, the Web service dynamic discovery file remain in the renamed VSS project folder and also within the renamed project folder on your local file system. You should tidy up these items by deleting them:

1. Use VSS Explorer to delete the old project file (*.csproj.proj), the old Visual Studio Source Control Project Metadata file (*.csproj.vspcc) and for Web applications, the old Web service dynamic discovery file (*.vsdisco) from the renamed project folder. You may need to refresh the view within VSS Explorer to see the new project files.
2. Use Windows Explorer to delete the old Visual Studio Source Control Project Metadata file (*.csproj.vspcc) and for Web applications, the old Web service dynamic discovery file (*.vsdicso) from the locally renamed file system project folder. Note that these files are read-only on your local file system.
3. For Web applications, use IIS to remove the old virtual root that has now been renamed.

Deleting a File from VSS

This procedure assumes that you have opened a solution from VSS that contains at least one project and the file you want to delete is contained within a project.

To delete the file

1. Ensure that the file you want to delete is not checked out.
2. In Solution Explorer, right-click the file you want to delete, and then click Check Out.
3. In the Check Out confirmation dialog box, click Check Out. If the file is already checked out by someone else, you must wait until the file is available exclusively to you.
4. In Solution Explorer, right-click the file, and then click Delete.
5. In the resulting MicrosoftDevelopmentEnvironment message box that confirms you want the file to be deleted permanently, click OK.
6. You will be prompted to check out the project file because it contains a file inventory. In the Check Out For Edit dialog box, click Check Out.
7. Check in the project file to VSS.
8. Use VSS Explorer to delete the file (which appears checked out) from the VSS database. In the resulting MicrosoftVisualSourceSafe message boxes, click Yes to confirm that the file should be deleted.

Deleting a Project from VSS

The following procedure describes how to delete a project from VSS.

To delete a project from VSS

1. In Solution Explorer, right-click the project you want to delete, and then click Remove.
2. In the MicrosoftDevelopmentEnvironment confirmation message box, click OK.
3. You will be prompted to check out the solution file because it contains a project list. In the Check Out for Edit dialog box, click Check Out.
4. Check in the solution to VSS.
5. Use VSS Explorer to delete the project from the VSS database.
6. Delete the project folder from your local hard disk and for a Web application, use IIS to remove the corresponding virtual root.

Deleting a Solution from VSS

The following procedure describes how to delete a solution from VSS.

To delete a solution (and all contained projects) from VSS

1. In VSS Explorer, make sure none of the following files are checked out: the solution file, any subproject, or the project file.
2. Use VSS Explorer to delete the solution from VSS.
3. Delete the solution from your local hard disk.

Note   You should communicate the fact that you are about to delete a solution to other team members to allow them to unload the solution if they currently have it loaded within Visual Studio .NET. If any team member has the solution loaded (not checked out) when you delete it, they will receive VSS errors if they subsequently attempt to check out a file that is contained within the solution.

Multiple Checkout

Usually, only one user at a time is allowed to check out a file from VSS. However, you can use the VSS Administration tool to configure VSS to allow multiple users to check out the same file simultaneously.

This can be useful in a team environment because it can help to relieve contention on commonly accessed files such as project files. However, if you use this feature, it requires careful coordination between individual team members, and you must be careful to merge changes correctly when you check in the file to VSS.

To work with a file in multiple checkout mode

1. Use Solution Explorer to check out the required file. Visual Studio .NET warns you that the file is checked out by another user. In the resulting Microsoft Visual SourceSafe message box, click Yes.
2. Make changes to your copy of the file and then compile and unit test your project.
3. Before you check in the file, you should merge any changes made by other developers and locally test those changes in conjunction with your own. To do this, right-click the file in Solution Explorer, and then click Get Latest Version. In the resulting Microsoft Visual SourceSafe message box, click Merge. VSS automatically merges the version from VSS with your local working copy. You can now compile and test the merged file.
4. When your tests are complete, use Visual Studio .NET to check in the file to VSS. If the file has been merged, VSS prompts you to check whether all conflicts have been properly resolved. Click Yes in response to the prompt and the file is checked back into VSS.

Checking Out Solution Files

Solution files are particularly difficult to check out simultaneously because they contain a project count which can make the merge process difficult and prone to error. You should generally avoid checking out solution files if another developer already has the file checked out.

Instead, aim to check out a solution file (for example, to add new projects) for short periods at a time to reduce contention on the file. Coordinate with other developers if contention arises and wait for the solution file to become exclusively available before checking it out.

This is Chapter 6 of the Team Development with Visual Studio .NET and Visual SourceSafe guide. To read the next chapter, please see Chapter 7, "Setting up and Maintaining the Team Environment."

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

© Microsoft Corporation. All rights reserved.