Can you keep Visual Studio source control binding info out of .sln and .csproj files?

Question

My Visual Studio 2005 is storing the info about which projects and solutions go with which source control repositories in the .sln and .csproj files. Is it possible to make it store that binding information in some external file instead?

The reason I wish the info were stored outside the solution/project files is to facilitate experimenting with the AnknSVN plugin. Right now we have all our stuff in VSS 6, but I want to maintain an experimental copy of the repository of SVN and then manually sync the two using the ideas described here:

http://www.dotnet6.com/blogs/jeroen/archive/2008/04/05/using-subversion-in-a-vss-only-shop.aspx

Unfortunately, having bindings stored in the .sln file (for example) throws a wrench in this. To illustrate, let's say I copy my whole VSS repository into a parallel SVN instance. Now I open up the main solution from SVN in Visual Studio using AnknSvn; in this process, AnkhSvn will change the source control binding info in the .sln file to point to SVN. Next let's say I add a new project P1 to the solution. This will cause Visual Studio to modify the .sln file a second time, noting the existence of P1. Say at this point I want to sync the changes I've made in the SVN copy back to the VSS repository. If source control binding weren't stored in the .sln file, that wouldn't be too bad. However, the .sln file now has two different changes in it, and I want to propagate the project-add change back to VSS, but I don't want to propagate the source control binding change back to VSS, because that would break the build for all the VSS users! I don't think there's a way to propagate the one change without the other manual intervention. If Visual Studio would just stored the binding info outside the .sln file, in contrast, then I would indeed want to propagate all .sln file changes back to VSS, and that would be ok.

Answer 1

VisualSVN does not use the native source control ecosystem plugin (SCC) so thus does not pollute your solution or project file. It is commercial licensed but very reasonable < $50. Thus allowing you to continue to use the nasty VSS (although ideally exclude .svn directories)

Answer 2

A coworker wrote this NAnt task for removing bindings

http://www.atalasoft.com/cs/blogs/jake/archive/2008/05/21/2custom-nant-task-for-removing-tfs-bindings.aspx

You could probably adapt into a custom build step or other script to help you.

Answer 3

IIRC both AnkhSVN, and VSS implements version-control binding strictly by .sln / .csproj files (the version control plugin interface of VS facilitate this kind of storage). Therefore, the short answer is no.

However, you can still use subversion as an outside version-control solution, which, in terms of security, and stability, would be much better, that VSS, using either the command line (the book is your friend), or TortoiseSVN.

Answer 4

AnkhSVN 2.0 has two modes of operation.

• Connected (recommended). This stores binding information in the .sln and optionally project files.
• Disconnected. This does not store the binding.

You can connect and disconnect the solution and individual projects in File->Subversion->Change Source Control.

The advantages of connecting are:

• Automatic switching between SCC providers on opening the solution (E.g. between VSS, TFS and AnkhSVN)
• Compatible with all project types that implement SCC support.
• (2.1+) Automatic handling projects outside the primary working copy. (E.g. websites in c:\inetpub)

Note: If you previously used AnkhSVN 1.X on a solution you should manually remove your Ankh.load files. When AnkhSVN 2.0 sees an Ankh.load file it automatically connects your solution.

[Follow up:]
An easy way to use AnkhSVN next to another SCC implementation is to just create an extra .sln file. AnkhSVN doesn't use the actual values in the individual project's SCC fields. (It just has to insert them to enable the project for full SCC management)