VSS Configuration Example

For Visual Source Safe you must specify the executable, project, username and password. You may also specify the SSDIR. If SSDIR is not set the default or the SSDIR environment variable will be used.

Minimal configuration example:

<sourcecontrol type="vss" />

Full configuration example:

<sourcecontrol type="vss">
   <executable>C:\Program Files\Microsoft Visual Studio\VSS\win32\SS.EXE</executable>
   <project>$/CCNET</project>
   <username>buildguy</username>
   <password>buildguypw</password>
   <ssdir>c:\repos\</ssdir>
   <applyLabel>false</applyLabel>
   <autoGetSource>true</autoGetSource>
   <alwaysGetLatest>false</alwaysGetLatest>
   <workingDirectory>c:\myBuild</workingDirectory>
   <culture>fr-FR</culture>
   <cleanCopy>false</cleanCopy>
   <timeout units="minutes">10</timeout>
</sourcecontrol>

Configuration Elements:

Getting the latest source with VSS

VSS does not automatically remove files from the local workspace that have been deleted from the VSS database. This does not cause a problem if you are using the <solution> task or the Visual Studio Task to compile your project. However, if you are packaging the source for deployment or if you are using the <csc> task to produce a custom build, you may end up compiling these deleted files in your assembly. To be on the safe side, it might be a good idea to clear the contents of the local workspace after each build.

Using a US English VSS in a non-English culture

If you use an English VSS with machines configured to use a non-English culture, it may happen that CCNet will not detect any modifications after you check-in some code. The reason for this behaviour is that CCNet uses the selected culture on the build server to determine the language it expects VSS will output for parsing. For example, with fr-CA, CCNet looks for French keywords in the VSS output. Hence, if your VSS installation does not use the same language, CCNET will not be able to detect any modification.

If you're using a US VSS installation, the first step in solving this problem is to include a configuration block set to the US english culture (<culture>en-US</culture>). This will make CCNet look for English VSS keywords, and eventually detect modifications.

VSS Issues

CCNet periodically reports the following error when connecting to VSS: "Unable to open user login file \SourceSafe\Vss60\data\loggedin\<userid>.log." What gives?

If you have set CCNet up to manage multiple projects that all connect to the VSS repository using the same user id then you may sporadically receive this failure. Our analysis suggests that the root of the problem is caused by the fact that VSS will create the <userid>.log file when a user logs into VSS and delete it when the user logs out again. If a second build is using the repository concurrently with the same user, when that second build logs out it looks for <userid>.log, but it's gone. Hence the error.

There are three approaches that you can take to deal with this:

• Log into VSS using different users for each CCNet project.
• You can keep CCNet from publishing exceptions , so this exception will just get logged into the ccnet.log file.
• Leave the VSS GUI open on the integration server. This will mean the userid.log file never gets deleted.

If you're using a labeller that returns a label equal to one already applied in the repository, the old label will be deleted when the new one is added.

This is because of a quirk in how VSS deals with labels of the same name; it should not be a problem with the default labeller.

This problem usually occurs when someone is using a custom labeller (a class that implements ILabeller) and that custom labeller returns a constant value.

Workaround: If you use a custom labeller, make sure each label is unique.

When I try to connect to use the <vss> NAntContrib tasks from ccservice I get this error: Failed to open database \\someserver\someshare\vssrep\srcsafe.ini

There are a number of known issues with SourceSafe 6.0c. Make sure that you upgrade to the 6.0d version.

When I try connecting to VSS when using ccservice I get the error: No VSS database (srcsafe.ini) found. Use the SSDIR environment variable or run netsetup.

Make sure that you are running ccservice using an account that has the necessary permissions to access the network share where your VSS database is set up. By default ccservice will run as the LocalSystem account, which does not have the necessary priviledges to access other machines.

When using VSS with a Filtered Source Control Block, newly added or removed files don't show up as modifications

VSS does not output the paths for added or deleted files. As a result, the modifications returned by CCNet do not have any specified path information. If a Filtered Source Control Block is used with a path filter then these modifications are likely to be filtered out. This is an outstanding issue.

Useful Links:

• Visual SourceSafe Best Practices Guide
• Using VSS With Multiple Timezones
• OLE Automation interface Get method behaves differently with VSSVersion and with VSSItem

Reasons why you might want to consider a different version control system:

• Visual SourceSafe: Microsoft's Source Destruction System
• Visual SourceSafe Version Control: Unsafe at any Speed?
• Look here for a comparison list of alternatives