FinalBuilder 8 and Visual Sourcesafe

FinalBuilder Bugs
1

We have upgraded from FinalBuilder 7.0.0.3450 to FinalBuilder 8.0.0.2797
We run on a Windows Server 2012 R2.

When FinalBuilder 8 tries to run VisualSourceSafe commands, as:

“VSS Label Files(s)”, “VSS Check out File(s)” and “VSS Check In Files”

the command hangs and never finishes, with no messages indicating anything wrong. I have to “Terminate Current Action” to stop the command. Here is an excerpt from the log:

Executing external process: C:\Program Files (x86)\Microsoft Visual Studio\VSS\win32\ss.exe
Parameters: label $/Proj/Rel7.5 -I-Y -Y"****" "-L7.5.6.17" -C-
Output from C:\Program Files (x86)\Microsoft Visual Studio\VSS\win32\ss.exe
Username: vssuser
Terminating...
Password:

I’m only able to terminate the command if it has been hanging for a long time. If I rerun the command, I only have the “Stop Build” available and have to close FinalBuilder to end.

This worked without issue in FinalBuilder 7.

We use Visual Sourcesafe version 6.0c, and the user accessing Visual SourceSafe has a blank password (no password).

2

Hi Stein

I had a look at our version control for these actions, and the only changes that were made between FB7 and FB8 (and since) were some minor changes due to internal api changes, nothing at all that would affect the behaviour of the actions.

If you run the command from the windows command line, what happens? My guess is that a dialog or messagebox is being shown by sourcesafe, which is why it appears as though FB has hung.

3

I have to ask, why are you still using source safe, and a version from 1998 at that?

Source safe 6.0c had lots of major bugs and these days there are plenty of very good alternatives (git, mercurial, subversion).

4

Hi Vincent,

This is strange. What I can say for certain is that it’s the same FB-command running on both versions of FB. It’s essentially the same project, only upgraded for FB8. In FB7 the command runs without delay, in FB8 it hangs.

FB uses the command line ss.exe to access the base, so there should not be any dialog to wait for. Although I do see that the log shows that the option -Y”****” is used when running ss.exe. This should provide the username (potentially username and password), but the log only shows it as four stars. Is there a problem sending the username defined to ss.exe?

And we are aware of the risks and potential problems running software from 1998. Upgrade is planned, but resources are not available at the moment.

5

The -Y**** is just FB intentionally not showing credentials in the log output. It’s not masked when passed to the ss command line. I did check the code and it does deal correctly with blank passwords.

Did you try running the command from the dos prompt, just to confirm it’s not showing a message box or prompting for input. SS was notorious for doing this, even when run from the command line.

6

Hi Vincent,

Running the command on the command line works without problem:

C:\>set SSDIR=\\*****\***\********\****\

C:\>"c:\Program Files (x86)\Microsoft Visual Studio\VSS\win32\SS.EXE" label $/********/Rel9.0 -I-Y -Y"******" "-L9.0.6.17" -C-
Rel9.0

(The output from the command is the last line).

Inspecting the VSS-base shows me that the label has been set on the project by the user specified with the -Y option.

On FB7 the log shows the exact same command being run (as in FB8 and the command line above), and the log of the command shows the same output from the command line I tried above.

But the output in FB8 is not the same as in FB7. In FB8 the command prompts for a username. This does not happen in FB7 (or the command line).

7

We don’t have ss 6 installed, but were able to test today with 2005, and it worked as expected. One thing we found was it did hang when an incorrect password was supplied. Are you sure your password field is blank?

8

Hi Vincent,

Yes, the password is definitely blank. I would not have been able to run the command line otherwise.

I can get the same behavior from the command line if I supply a password to the user I’m trying to use. If I do this:

C:\>"c:\Program Files (x86)\Microsoft Visual Studio\VSS\win32\SS.EXE" label $/********/Rel9.0 -I-Y -Y"<username>" "-L9.0.6.17" -C-

The command completes without issue. If I do this:

C:\>"c:\Program Files (x86)\Microsoft Visual Studio\VSS\win32\SS.EXE" label $/********/Rel9.0 -I-Y -Y"<username>,<password>" "-L9.0.6.17" -C-

I get a dialog asking for the password. But only if I provide a password (any string, actually).

It seems like FB8 is actually sending -Y"<username>,<password>" even if there is no password. And the password string being sent is a valid string (not whitespace). Is there a default password string in FB8?

Editing the FB-action and removing the password does not help. I even double checked the default password for Visual SourceSafe in the FB-Options.

9

Some more information:

This occurs when the FB SourceSafe action is using “Override global settings”. Earlier steps where this option is not enabled works as expected.

10

Can you send your FB project to support @ finalbuilder.com so we can make sure we are testing with the same settings. We have not been able to reproduce the problem here.

Another option would be to try upgrading to VSS 2005 if you have access to it (it’s available via msdn/visual studio subscriptions).

11

Hi Vincent,

I have sent you an email with the project.

I really do not see how an upgrade of VSS to 2005 would fix anything. VSS is working as it should in FB7 and on the command line.

12

This turned out to be a bug in the actions which was a side effect of the FB8 file format optimisation (avoids serializing default property values).

This build has the fix :

https://downloads.finalbuilder.com/downloads/finalbuilder/800/FB800_2809.exe