Fog Creek Software
Discussion Board




Problems setting up VSS integration

I've been working on trying to set-up FogBugz w/VSS integration and I've run into a few snags. In the vss_fbupdate.wsf script, there is a problem with the code. There are cases where sPrevVersion is empty, which means the INSERT will fail (you need to pass empty string delimiters, not just an empty string). I ran into this with an item that had a version # of 2. 

eg. the INSERT VALUES end up looking like:

VALUES(ixBug, sFile,,2)

instead of:

VALUES(ixBug, sFile,"",2)

Another issue:

ShowVSSDiff.ASP assumes that the DB path doesn't end in a backslash (see the function OpenVSSDatabase). If you add one, then you'll end up with two backslashes as the path.

I am also getting an error:

SourceSafe error '8004d117'

The SourceSafe database path fogbugz does not exist. Please select another database.

/bugs/showVSSdiff.asp, line 195

The path, user, and password are correct. Any ideas on the cause of this?

Paul Mrozowski
Friday, February 28, 2003

Perhaps its a permissions issue?

You must make sure that the FogBUGZ user or whoever you installed FogBUGZ to run as has READ access on all your VSS folders and all subfolders.  The user must also have FULL CONTROL on the names.dat and the rights.dat files, and the LoggedIn directory.

I'll fix those other problems you mentioned.

Michael H. Pryor
Friday, February 28, 2003

>Perhaps its a permissions issue?

A VSS permissions issue or network permissions? I made sure the VSS user has full access to the projects. I also made sure that the logged in user on the webserver has access to the directories/files you listed. For testing, I'm running the import script manually.

(a little later) OK, I've gotten it to work. I thought about it some more and realized that you were launching the SourceSafe object under the default ASP permissions (eg. under the IUSR security context). I created a new COM+ package and set the user to a user that would have access to SourceSafe. Then I added the SSAPI.DLL into the COM+ component. That fixed it. This is probably a better solution that adding permission to allow the IUSR account access to VSS (which, in my case, wouldn't work since my VSS database isn't on an NT server).

I'd suggest adding this info to your instructions. I'm sure I'm not the only one who's going to run into this.

Also, I noticed that you're removing the journal.txt file after processing it. I understand why, but realize that this might cause problems if the user is running any other applications that depend on it (eg. SourceVizor). Maybe you could "daisy-chain" the log file. That is, once you're done processing it, append it to another log file that can be used by other applications. Then it should be safe to remove your copy of it.

Paul Mrozowski
Monday, March 03, 2003

Did you upgrade from 2.0?  If you just installed 3.0 then it shouldn't be the IUSR_ account that is running the script.  If you look in the directory security tab for the FogBUGZ virtual directory, it should be set to anonymous access only and the account should be FogBUGZ.  If that's set to IUSR_ then I understand why this happened, if not, I don't understand...

Michael H. Pryor
Monday, March 03, 2003

>Did you upgrade from 2.0? 

Yes, we upgraded from 2.0

>If you look in the directory security tab for the FogBUGZ virtual directory, it should be set to anonymous access only and the account should be FogBUGZ.  If that's set to IUSR_ then I understand why this happened, if not, I don't understand...

It's set to IUSR_.

Paul Mrozowski
Monday, March 03, 2003

Ok, that makes sense to me then.

If you upgraded from 2.0 we don't mess around with the user in IIS (for 3.0 we set it to FogBUGZ).  So it was still set to IUSR_ for you, but you could safely change it to the FogBUGZ user and then take away the IUSR_ priveleges you granted on the VSS dbase.

Customer Service
Monday, March 03, 2003

*  Recent Topics

*  Fog Creek Home