Integration with visual studio

If you are having a problem using Vault, post a message here.

Moderator: SourceGear

Post Reply
Hans Olav Nymand
Posts: 55
Joined: Wed Sep 29, 2004 8:09 am
Location: Denmark, Copenhagen
Contact:

Integration with visual studio

Post by Hans Olav Nymand » Fri Mar 11, 2005 8:46 am

Hi,

[using version 3.0.5]

I am afraid this is a rather general "complaint" so I should say that for now it is mostly intended as information to you, but of course if you have some best practice, guidelines or workarounds that we can go by, I would be gratefull. Maybe I have missed something in the documentation.

It's all about the intagration with Visual Studio.Net 2003 (but is possibly valid also for earlier versions of VS)

The first problem is ab out the MSSCCPRJ.SCC file. We don't want to check in this file because it refers machine specific info (the profile name) as well as an absolute path into vault. The latter cause some problems when you do shares (and branches). We have see some examples where people would constently check out this file in two different shares to fix the path to match their particular share (and we have a lot of shares).

But in general we dont like absolute paths in checked-in files.

Not having checked in MSSCCPRJ.SCC on the other hand cause problems any time you take the code to a new empty directory (get a new pc, get a new man on the job, start to work on a new project, clear old code to make sure you have the right stuff and so on). When MSSCCPRJ.SCC is missing, it is understandable that the Vault component gets confused - but it starts asking for changed bindings and so on, when in reality it should just ask for the servername and repository (path into vault is in the vcproj file or at least can be deduced from this file). Again we see people checking out and checking in files to fix this "error in the file" when in reality they just need to create the MSSCCPRJ.SCC files. I usually check out, bind and undo checkout - it works fine, but is messy.

Another issue seems to be that the Vault component does not always put "SAK" in the vcproj file when it should; it seems to prefer putting an absolute path here as well. Not good.

Are we doing something wrong?
Can we create default MSSCCPRJ.SCC that contain only the server and repository?



Regards,
Hans Olav

dan
Posts: 2448
Joined: Wed Dec 17, 2003 5:03 pm
Location: SourceGear
Contact:

Post by dan » Fri Mar 11, 2005 9:54 am

In order to get a project going on a separate machine or in a new working folder, you need to first invoke "Open From Source Control" from within Visual Studio, and choose the project in Vault and also choose the new location. This will automatically create the bindings and create the MSSCCPRJ.SCC file with the right contents for that working folder.

Yes, you definitely never want to checkin the MSSCCPRJ.SCC file, because it is specific to the local working folder. Any absolute path that gets created should be as a result of opening from source control - copying files from one place to another will always confuse Visual Studio if the file is under source control.

alexis_michel

Post by alexis_michel » Wed Jul 13, 2005 8:49 am

It sounds to me that this means I never will be able to automate daily builds, because I cannot do "Open from source Control" via Visual Studio automation, and if I just open the solution then I get those dialogs asking me server name, login password blablabla.

Is there any other way to fully automate the following sequence of events : "Get a clean latest version of a project in an empty directory, do something magic, open the solution in Visual Studio (without nasty dialogs appearing all over the place), build solution." ?

lbauer
Posts: 9736
Joined: Tue Dec 16, 2003 1:25 pm
Location: SourceGear

Post by lbauer » Wed Jul 13, 2005 9:14 am

You could automate the build by doing a get latest with the Vault Command Line Client, which will automatically login and retrieve the code. Then you can just open the project normally with VS.NET.

Opening the project from Source Control creates source control bindings, which you don't need if you're going to use the code for a build.

I noticed you posted to the SOS forum, too, so I'm not sure which product you're using, but this applies to SourceOffSite as well.
Linda Bauer
SourceGear
Technical Support Manager

Post Reply