Visual Source Safe Get

[martys]

I have a source safe repository, and several steps to get files from the repository (separated so I can choose which ones to get). If I don't specify a destination directory, I would expect it to go to the current working folder for that project... but it seems to be going to the Current Directory instead. Is there a way to get it to go to the current working folder for the project without setting each output directory for each step?

[kinook]

http://msdn2.microsoft.com/en-us/lib...6t(VS.80).aspx

[martys]

Well, I've fixed one problem and run into another. I'm not sure whose problem this is, but I'll just outline the process and see if anybody has any suggestions.

I have a build that gets files from sourcesafe using user bldadm with no password. It generates the command line:

"C:\Program Files\Microsoft Visual Studio\Common\VSS\win32\ss.exe" Get $/Path/ -GWR -GTM -GCD -NL -I-N -Ybldadm, -W-

which works just fine when run directly from the GUI. When I run the command from a command line, it prompts for the password. Pressing enter, it says "User "bldadm" not found".

This isn't too bad of a problem, because I don't plan on running it from the command line. However, I don't plan on running it from the GUI either. I've written an ASP script to run it from a website. The build pauses indefinitely when it reaches the first SourceSafe step. My suspicion is that the same problem is occurring; it's prompting for the bldadm password.

I'm using bld.SyncBuildEx, and passing in the same username/password as the local user I'm logged in as when running the build from the GUI, but it doesn't work. I've tried running with no user/pass, but that causes the step to fail.

[kinook]

The SourceSafe action also sets the SSDIR environment variable to point to the database specified in the Database field. You'll need to do that manually from a command line.

Regarding hanging when building from an ASP page, enable file logging for the project and send or post:
1) The info from Help | About | Install Info
2) The .bld file
3) The build log file

Thanks.

[martys]

Install Info:

Visual Build Professional 6.4
Registered to: Softbrands (2-computer license)
Windows Version: 5.2.3790.2.0
Install path: C:\Program Files\VisBuildPro6
SftTree_IX86_U_50.dll version 5.06
unins000.exe version 51.46.0.0
VisBuildCmd.exe version 6.4.0.2
VisBuildPro.exe version 6.4.0.2
VisBuildBld.dll version 6.4.0.3
VisBuildBurn.dll version 6.4.0.2
VisBuildCore.dll version 6.4.0.2
VisBuildDotNET.dll version 6.4.0.0
VisBuildExt.dll version 6.4.0.3
VisBuildLog.dll version 6.4.0.2
VisBuildMisc.dll version 6.4.0.3
VisBuildMS.dll version 6.4.0.2
VisBuildMS2.dll version 6.4.0.2
VisBuildNet.dll version 6.4.0.3
VisBuildSvr.dll version 6.4.0.2
VisBuildSvr.Interop.dll version 1.0.0.0
VisBuildVCS.dll version 6.4.0.4

Log:

<?xml version='1.0' encoding='utf-8'?>
<log version='1'>
<build context='Automation' start='7/26/2007 10:43:10 AM'>
<name>C:\Documents and Settings\nt\Local Settings\Temp\1\tmp12.tmp</name>
<step action='Group' type='0' start='7/26/2007 10:43:10 AM'>
<name>Get files from SourceSafe</name>
<status code='0'>Completed</status>
</step>
<step action='SourceSafe' type='0' start='7/26/2007 10:43:10 AM'>
<name>Animator</name>

Build is attached (generated on the fly based on inputs from the webpage)

[kinook]

I'm not exactly sure what the problem is, probably some sort of security or identity issue. SourceSafe actions work ok in our tests w/ the WebLauncher sample and ASP.NET 2.0.

[martys]

Is there any way to see full output of what Visual Build is doing? Maybe I can diagnose the problem if I better see how it's running SS.exe

[martys]

I set the environment variables SSUSER and SSPATH to the values I'm using externally, and this fixed the problem.

I'm not sure exactly what the problem was, but it seems like SS.exe wasn't picking up the SSPATH variable that Visual Build was setting, and was therefore showing similar output to what I saw when I ran the command manually (without setting the environment variable). I couldn't verify this entirely, because it wasn't showing a command window, of course, but in a process manager, I saw that SS.exe wasn't using any CPU, and was not accessing any files at any time, so it was obviously not hanging as in an infinite loop, but rather, as in waiting for user input. So perhaps it is being run in a different environment than the environment variables are being set in, in my configuration. I can't imagine why, but setting the variables permanently fixed the problem.