This article talks about how you can use Visual Studio and Clearcase in combination in order to provide more effective team integration and operation. Visual Studio has 2 important features that facilitate this:

1. Grouping project configuration with the project.
2. The ability to split the configuration of the IDE between team settings and personal settings.

One of the great things about integrating with a source controller is that the more configuration you put into it the easier it will be for everyone who uses it. Shared files can be added to the source controller instead of being placed on network resources because you want them to change as the projects move along. Project configuration Variables can be used in the project definition file to point to various places e.g. for header files or pre-compiled libraries:

IncludePath=c:\include;$(SUPLIB)\include AdditionalLibraries=c:\lib;$(SUPLIB)\lib

If you have a set of variables that map to the latest versions of a supporting package you would expect those variables to change as the code base moves forward. If you looked at a version from last year you would like those variables to point to what they pointed to a year ago. I currently work for a company that uses normal environment variables in order to get around this problem. As far as I can work out there are no advantages of doing this and several disadvantages:

1. Every user needs to set up all the variables on their PC, or their new PC, or the dedicated PC they are using as a build machine.
2. Every user has to keep track of when these variables are modified or new ones are created.
3. Once an environment variable is set up you can’t have a different definition, for that environment variable, per project.
4. You need a master document to hold all these configuration options, so that when you are trying to use a new machine you don’t miss anything out.
5. Don’t know about you, but I use ten’s of supporting libraries, and so the more you have the longer it takes to configure a machine and the more error prone this process can be.

As a consequence of not being able to change what an environment variable points to, per project, it has meant that they needed to set up an environment variable for each version of each supporting library:

SUPLIB_1_2=z:\lib1.2 SUPLIB_2_0=z:\lib2.0

So when someone updates the support library:

1. They must get every developer to add a new environment variable SUPLIB_3_0=z:\lib3.0 to their machine.
2. They must also update a master document containing all the configuration items that must be configured to do a build.
3. All the projects that use this supporting library must have their project files changed to use this new location to pick up the latest libraries.

Visual Studio has a solution file and one or more project files. The solution file is just a container for project files, their inter-dependencies and what kind of build you would like to do (Debug/Release). Project files hold all the settings required to build the project including locations of header files, supporting libraries, etc. A single project may appear in many solutions, so you may need to be careful about what you add because it will be applied to all solutions that use that project. This is ok because you want all the projects to move forward at the same time. It’s a developer’s nightmare to have to support many different supporting library versions; particularly when it comes to finding bugs. Irrespective of whether you use snapshot views or dynamic views these supporting library locations can change significantly. A good trick is to use relative references to the supporting libraries but thanks to Microsoft that doesn’t work if you want to change to a different drive letter. The best way to share project information across the source is to use user defined macros. This is quite simple to set up.

1. Firstly navigate to the location of the solution file ending .sln.
2. Create a file called SolutionProperties.vsprops in your favourite editor.
3. Enter the following definitions. You can see that ZDRIVE is defined as the first macro and it is used in subsequent macros. Under Clearcase (and every other source controller) everything is relative to the root. It’s just that the root can change its location.

   <?xml version="1.0" encoding="Windows-1252"?>
   <VisualStudioPropertySheet
       ProjectType="Visual C++"
       Version="8.00"
       Name="ClearCaseDrive"
       >
       <UserMacro
       	Name="ZDRIVE"
       	Value="z:"
       	PerformEnvironmentSet="true"
       />
   	
       <UserMacro
       	Name="CUDA"
       	Value="$(ZDRIVE)\CUDA\cuda-4.0"
       	PerformEnvironmentSet="true"
       />
       
       <UserMacro
       	Name="INTEL_IPP"
       	Value="$(ZDRIVE)\Intel_IPP"
       	PerformEnvironmentSet="true"
       />
   
   </VisualStudioPropertySheet>
   

4. Check in the SolutionProperties.vsprops
5. For each project file:
   1. Load the solution/project into Visual Studio.
   2. Right click on the project and select Properties.
   3. Under Configuration Properties, click General.
   4. In the right hand configuration panel change Inherited Project Property Sheets to:
      $(SolutionDir)\SolutionProperties.vsprops
   5. Save project configuration file.
   6. Check the project files into the source controller.

The $(SolutionDir)\SolutionProperties.vsprops’s location is defined using a standard Visual Studio macro and so it becomes independent of file system paths. There is a precedence order to the configuration files, newer variables overwrite predefined variables. Now instead of having a multitude of variables defining all the versions of a supporting library, you just need one to be defined in the SolutionProperties.vsprops. The project needs to be updated to change the SUPLIB_3_0 to SUPLIB, but once that is done there shouldn’t be any other need to update the project file again. When you need to update the supporting library the person in charge of doing it can update their local copy of SolutionProperties.vsprops, build and test the new library. When they are happy they check in their local copy of SolutionProperties.vsprops. The change to the new library is reflected in all the other developers views without them needing to know or care. They have been decoupled. Team configuration in the IDE There are many options that should be set up in a team configuration file. These settings should apply to everything and everyone. The best example of this is TABs or spaces. If you checkout a file with spaces making up the indentation and your IDE is set to use TABs then when you check it in, every line (or the line you have edited (depending on the preference)) will be different to the last version which makes spotting differences between files that bit more difficult. You may have a code formatter that needs to be allied to code before it’s checked-in, or want extra warning flagged switched on (warning free code - is good code!). Unlike library and header locations there will be a lot of personal preferences that will have to be contended with. You will have to arbitrate between what you consider team settings and personal preferences. The easiest thing to do is:

1. Set up a Visual Studio installation the way you want.
2. From the menu bar select Tools -> Options
3. From the Options panel, select Environment -> Import and Export Settings
4. The Automatically save my settings to this file option will point to your current settings file.
5. Copy the current settings file to the solution directory of the source controller and call it TeamSettings.vssettings
6. Edit it, only keep the settings that apply to the team and remove everything else.
7. Check in the team file.
8. Send notification to your developers. Each developer must:
   1. Inside Visual Studio, click the Tools -> Options
   2. From the Options panel, select Environment -> Import and Export Settings
   3. Check the Use team settings file
   4. Unfortunately macros are not supported here, although they maybe in the future. Edit the location box to point to the team settings file.
   5. Click OK

Like projects, there is a precedence to these settings so they may be overwritten by a user setting. If everyone is overwriting a team setting then it’s a really good candidate for updating the team settings file so everyone doesn’t have to do it. The next time you colleague launches Visual Studio it will pick up the new team settings and you will have saved them a bit of time.