How to use Vault w/o binding info in .sln and .proj files?

[daflookie]

I'm new to Vault, but not source control in general. In other products such as SVN, Git and Mercurial I never had to have binding information stored in the Visual Studio .sln and .vbproj/.csproj file.

Our team of ~15 developers has about 60 sw solutions (mostly 1 solution w/ just 1 project). They have avoided branching like the plague in the past b/c of binding issues, errors, prompts, etc. I'm trying to transition the team out of this and more into feature/release branches so we can manage the code better.

Is there a way with this product to not have binding information embedded in these Visual Studio files? It seems like using a MSSCCPRJ.scc is the way to go, but Vault inconsistently uses it depending on how I open my project, estabslish my working folder, etc (based on my limited testing). I've read some of the MSDN docs on MSSCCPRJ.scc but it's unclear how to *always* use this in Vault instead of embedded bindings.

We are using:
- Vault Professional 5.1.2 (19283)
- Visual Studio 2010 (lots of older projects though that we want upgraded though)
- Vault Professional Classic Client (for Visual Studio)
- The repo is currently configured with exclusive lock & check-in/out (another subject I'm looking to address but first things first)

Thanks for your time.

Steve

[Beth]

All that needs to happen is to have the binding information removed and then users can manage their files using the Vault GUI client and edit in Visual Studio.

There are two ways you can accomplish this.

1) Open the solution in Visual Studio.
2) Go to File - Source Control - Change Source Control.
3) Unbind all the lines listed and click OK. Save everything and close VS.
4) Open the Vault GUI client and check in the .sln and project files.
5) Have other users perform a Get to retrieve the changes.

The other option is to delete the MSSCCPRJ.scc and any .vssscc files. Then find in the .sln file and the project files lines that relate to the SCC provider (you will probably need to use notepad for this change). They should be toward the beginning of the file and will clearly say SCC. Remove those lines and check in the changes using the Vault GUI client.

[daflookie]

Beth thanks for your help.

I tested this, and what you are suggesting is not having any integration scenario with SC while in Visual Studio correct?

Is there a way to do this where developers still get integration while in Visual Studio? Otherwise they don't have the status lights of what is checked out, right-click context menus for getting the latest or DIFF'ing a file, etc.

Is there a way to have the Visual Studio plug-in work w/o keeping binding information in the Visual Studio .sln and .proj file? I was thinking the MSSCCPRJ.scc file was a good thing as this isn't kept in source control but still allows integration while working in the IDE. When I look at developer's working copies I don't see this file in most of their projects b/c VS is cued in via embedded bindings in the .sln and .vbproj files.

Thanks,
Steve

[Beth]

The binding is what makes the other features possible. Nothing in the integration works without the binding.

[daflookie]

Beth I apologize if I'm seeming dense here.

It is my understanding we have two different options for getting the Visual Studio integration story to work well:

A. Embed binding info in .sln and .proj files
B. Let Visual Studio manage binding information via a user-specific file called MSSCCPRJ.scc that never makes it's way to the remote repository.

There are references on the web that state binding in the .sln file is not optimal, and you should let Visual Studio use a MSSCCPRJ.scc file dynamically. Here is an example of such recommendation:

http://thetweaker.wordpress.com/2011/08 ... -location/

What isn't clear to me is Vault sometimes uses the MSSCCPRJ.scc and sometimes embeds it in our source code. Can Vault exclusively work with the MSSCCPRJ.scc file alone or must it put bindings in source code files?

My assumption all along is we are just procedurally going about working with our projects the wrong way, not it being a limitation in the product. I'm looking for clarification.

Thanks

[Beth]

No matter which style of binding you use, there will be some sort of SCC entry in the .sln and .proj files. This is for both the Vault Classic Client and Vault Enhanced Client. The Vault Classic Client also makes use of the .scc files you see. The Vault Enhanced Client does not. Any source code control provider that uses the Microsoft MSSCCI will make use of the .scc files.

It is possible in some cases to not have the .sln file bound, but it's not possible to not have the .proj files bound and still have source control.

[daflookie]

Ok Beth thanks for the clarification.

[Beth]

You're welcome.

[AjarnMark]

daflookie, if your main concern is with branching and whether you'll have to rebind your solution files, then from another Vault user's perspective, let me tell you that this is one of the areas that I am most impressed with how Vault works. We use VS 2010 and the Vault Pro Enhanced Client. As long as we include the solution file in our source code repository, and we create our branch at the folder level that contains the solution file and everything else is within that folder or its subfolders, and we have set our working folder setting at a higher level (I always set at the $/ level and let everything inherit) then after we branch, we just open up the Solution file and start working and everything is properly maintained. I think in large part this works so well because of the relative path referencing and the fact that our working folder hierarchy has not been disrupted.

I hav struggled with other source control systems to get bindings set properly and reset after branching, and so on, but with the above setup, we consistently have success without any effor to rebind.

[Beth]

Thanks for providing your input.