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.

Version¶

Available from version 1.0

Examples¶

Minimal example

1<sourcecontrol type="vss" />

Full example

 1<sourcecontrol type="vss">
 2  <executable>C:\Program Files\Microsoft Visual Studio\VSS\win32\SS.EXE</executable>
 3  <project>$/CCNET</project>
 4  <username>buildguy</username>
 5  <password>buildguypw</password>
 6  <ssdir>c:\repos\</ssdir>
 7  <applyLabel>false</applyLabel>
 8  <autoGetSource>true</autoGetSource>
 9  <alwaysGetLatest>false</alwaysGetLatest>
10  <workingDirectory>c:\myBuild</workingDirectory>
11  <culture>fr-FR</culture>
12  <cleanCopy>false</cleanCopy>
13  <timeout units="minutes">10</timeout>
14</sourcecontrol>

Configuration Elements¶

Element	Description	Type	Required	Default	Version
type	The type of source control block.	String - must be vss	Yes	n/a	1.0
alwaysGetLatest	Specifies whether the most recent version of the source should be retrieved from VSS. If not, CCNet will obtain the source as of the time the build began.	Boolean	No	false	1.0
applyLabel	Specifies whether the current CCNet label should be applied to all source files under the current project in VSS. The specified VSS username must have write access to the repository.	Boolean	No	false	1.0
autoGetSource	Specifies whether the current version of the source should be retrieved from VSS.	Boolean	No	true	1.0
cleanCopy	Controls whether or not VSS gets a clean copy (overwrites modified files) when getting the latest source.	Boolean	No	true	1.0
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	No	The culture of the VSS installation	1.0
dynamicValues	The dynamic values to use for the source control block.	Dynamic Values array	No	None	1.5
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	No	None	1.0
issueUrlBuilder	Converts the comment (or parts from it) into an url pointing to the issue for this build. See IssueUrlBuilder for more details.	IssueUrlBuilder	No	None	1.4
password	Password for the VSS user ID.	PrivateString	No	None	1.0
project	The project in the repository to be monitored.	String	No	$/	1.0
ssdir	The directory containing SRCSAFE.INI. If this SSDIR environment variable is already set then this property may be omitted.	String	No	None	1.0
timeout	Sets the timeout period for the source control operation. See Timeout Configuration for details.	Timeout Configuration	No	10 minutes	1.0
username	VSS user ID that CCNet should use to authenticate. If the username is unspecified, the VSS client will attempt to authenticate using the NT user.	String	No	None	1.0
workingDirectory	The folder into which the source should be retrived from VSS. If this folder does not exist, it will be automatically created.	String	No	Project Working Directory	1.0

Notes¶

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.

p.

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 The Server Service Application 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 The Server Service Application 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 - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvss/html/vssbest.asp
* Using VSS With Multiple Timezones - http://support.microsoft.com/default.aspx?scid=kb;en-us;248240&Product=vss
* OLE Automation interface Get method behaves differently with VSSVersion and with VSSItem - http://support.microsoft.com/default.aspx?scid=kb;en-us;837417

Automatically Generated¶

Documentation generated on Monday, 26 May 2014 at 7:18:03 AM