CruiseControl.NET : Visual Source Safe Source Control Block
This page last changed on Jun 14, 2005 by orogers.

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.

<sourcecontrol type="vss" autoGetSource="true" applyLabel="true">
   <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>
   <workingDirectory>c:\myBuild</workingDirectory>
   <culture>fr-FR</culture>
   <cleanCopy>false</cleanCopy>
</sourcecontrol>

Configuration Elements:

Node Description Type Default Required
project The project in the repository to be monitored. If the project contains a space, enclose the text in double quotes (") string N/A true
username VSS user ID that CCNet should use to authenticate string N/A true
password Password for the VSS user ID string N/A true
ssdir The directory containing SRCSAFE.INI. If this SSDIR environment variable is already set then this property may be omitted. string N/A false
executable The location of SS.EXE. If VSS is installed on the integration server, the location of VSS will be read from the registry and this element may be omitted. string value from registry false
autoGetSource Specifies whether the current version of the source should be retrieved from VSS bool false false
applyLabel Specifies whether the current CCNet label should be applied to all source files under the current project in VSS. Note: the specified VSS username must have write access to the repository. bool false false
workingDirectory The folder into which the source should be retrived from VSS. If this folder does not exist, it will be automatically created string N/A false
timeout How long (in milliseconds) the VSS operation will be permitted to run before timing out int 10 minutes false
culture The culture under which VSS is running. This value must match the culture of the VSS installation for CCNet to work with VSS. Most of the time the default is OK and you may omit this item. If you are using the US version of VSS on a machine that is not set to the US culture, you should include the configuration block <culture>en-US</culture>. string the culture of the VSS installation false
cleanCopy Controls whether or not VSS gets a clean copy (overwrites modified files) when getting the latest source. bool true false

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.

If the project name contains spaces then the VSS command-line will fail.
Wrap the text in the <project> element in double quotes: eg. <project>"My Project"</project>
  • 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.

Useful Links:
Document generated by Confluence on Jun 26, 2005 17:23