Trouble with Visual Studio integration

[Kevin]

Hello,

I am using Visual Studio SCC integration with Vault. I can add Solutions to Vault no problem using the "Add to Source Control command" in Visual Studio, after which the integration seems to work fine.

However, when another team member gets the newly checked in Solution and tries to open it, they get an error message saying:

"The solution appears to be under source control, but its binding information cannot be found. It is possible that the MSSCCPRJ.SCC file or another item that holds the source control settings for the solution, has been deleted. Because it is not possible to recover this missing information automatically, the projects whose bindings are missing will be treated as not under source control."

I also get the same error when opening if I delete my working directory and get a fresh copy. I am able to re-bind the solution manually, which regenerates the MSSCCPRJ.SCC file, but once that file is deleted, the problem returns. Visual Studio should be able to generate this file automatically. Any ideas what the problem could be?

Thanks.

[Ken]

It sounds like you are using the Valult GUI client to retrieve the solution on the unbound developer's computer. What you should do is use the Visual Studio IDE and select "File > Source Control > Open from Source Control". After logging in you select the Vault folder where your solution resides. If you do not have a Working directory for this folder you will be required to select one. Visual Studio will automatically get any .sln and .*proj files and Ask you what you would like to open. At this point you select the solution and Visual Studio will create the MSSCCPRJ.SCC file.

[Kevin]

Hi Ken,

Yes, you are correct about using the Valult GUI client to retrieve the solution. Thanks for pointing out the "Open from Source Control" command. I tried that, and it did in fact work as you described.

However, I've used Visual Source Safe for quite a while, and it never required me to "Open from Source Control" in order to generate the MSSCCPRJ.SCC file. i.e., with VSS, we were always able to do a fresh Get Latest to an empty working directory from the GUI client and just double-click on the solution file, and it connected to source control no problem. Anyone know how (or if it's possible) to make this work with Vault?

Thanks again,
Kevin

[dan]

Hmm. Were you using the same version of Visual Studio when integrating with VSS vs Vault?

[Kevin]

Yes, same version of Visual Studio, but different machines.

Kevin

[JeffKryzer]

I totally agree with Kevin. This was done simply by doing a GetLatest in VSS. I could do a GetLatest at the root of 30 projects, then open any project directly in Visual Studio without going through any solution (by double-click on a .csproj file). After doing that I could check out any file right away - Visual Studio knew that project was under source control.

Now with Vault, I have to always load every solution and project through the menu of Visual Studio? Has there been a fix for this? Are you at least acknowledging that there SHOULD be fixed in a future patch? If not, I can give a bunch more reasons why doing a GetLatest from the client is waaaay better than using the menu in VS.

Curious what the status is. Thanks.
Jeff

[dan]

It is possible to make our GUI client "IDE-aware", so after an initial Get on a folder it will look for project and solutions files and try to map the associations between those files and their locations in Vault. We'll add this to the feature request list.

However, I can't guarantee this feature will recieve a high priority. Doing "Open From Source Control" is the standard method for getting a project that is using IDE integration, and you only have to invoke that command on the first open to a working folder - after that Gets work fine from either client.

But, I am curious to know the reasons for wanting to do the Get from the GUI client, as I am probably missing something. If you are using IDE SCC integration for a project, why wouldn't you want to use the IDE commands to do source control?

[GregM]

Dan, I can think of several reasons, just from my own experiences.

The first is that not all of the files in the tree are under IDE source control.

The second is that it requires that you start the IDE, which isn't necessary if you're going to be building from the command line, which our buildmaster machine does. On occasion, we delete the buildmaster's tree, and let the nightly build get a new one. When we need to build manually on the machine from the IDE, we shouldn't have to do a "Get from source control" when the files are already there.

The third is that there are many projects in the workspace/solution, which share files, and many individual files. There are also a lot of generated files in the workspace, and the IDE doesn't know on a file-by-file basis that they're not in source control. In short, it's just faster to just get the entire tree than to tell the IDE to request each file individually.