Visual Studio bindings - bound and unbound sc in different solutions
I have a development team that is divided into the mentality of using visual bindings to manage studio source code. Half would like to integrate, and half would not. Is there a way to add a bind-only solution so that each team can use a different solution based on their preference?
source to share
There is nothing painless solution to this problem. This is because Microsoft made a monumental poor decision to embed raw control information into the .NET solution and project files.
Let's say Dick wants to use the SCC plugin but Jane doesn't. Dick adds the project to version control via a plugin, and information like this will be written to the solution file:
GlobalSection(SourceCodeControl) = preSolution
SccNumberOfProjects = 2
SccLocalPath0 = .
SccProjectUniqueName1 = someApp\\someApp.csproj
SccLocalPath1 = someApp
EndGlobalSection
and some garbage like this will be added to the project files:
<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>
In addition, some files will be scattered across the project folder tree (MSSCCPRJ.SCC files in solution and project folders, * .vssscc in solution folder, and * .vspscc in project folders).
Additional files are not a problem as long as Dick does not check them against the original control (although the plugin will always want to check those .vssscc and .vspscc files). However, the raw management information that is written to the solution and project files will always annoy Jane. Whenever she opens a solution, she will be enforced with this message:
and then this one:
If she chooses Permanently Remove Source Control Association Bindings, the source control information is removed from the solution and project files, and she is happy again. However, the Dick SCC plugin will no longer work and it will probably put projects back in original control and the office mess will start.
To summarize, you can share a .NET project between those who use the SCC plugin and those who don't, but one or more parties will have to endure some trouble because Microsoft decided to add source control information for .NET project files (such a bad solution, this is not a problem in Visual Studio 6).
source to share
I'm not really sure if I called you. My guess is that half of your team wants to use the Visual Studio plugin to access Perforce and the other half doesn't.
It is possible. You have to make sure never check in the MSSCCPRJ.SCC file generated by the plugin. This is local binding information and will not work on all workstations.
On the other hand, * .vssscc files can and should go into Perforce.
Using a plugin has one big advantage: the plugin knows which files to check in and which to skip. Especially when adding new projects, it is a common mistake to forget to check in the newly created files when using the visual Perforce client instead of a plugin.
source to share