Question

I have read this post thoroughly: How does Visual Studio's source control integration work with Perforce? and found it very informative. However, I have a specific issue that is blocking my use of Perforce in VS.

For the most part, I have no complaints about the plug-in (I’m still using the P4VSCC plug-in because the new plug-in requires conversion by the entire team which can’t happen at this time). Once I understood the idiosyncracies, I’ve had only one problem working with the plug-in.

Our solutions contains many projects that are built into a single deployment package. As such, each assembly is versioned the same. To accomodate this, and other common aspects, we have defined a common “SharedVersionInfo.cs” file which contains the AssemblyVersion and AssemblyFileVersion attributes typically found in the AssemblyInfo.cs file. This file is stored in an Assets folder beneath the solution folder and added to each project’s Properties folder as a linked file. This works great from a version management perspective as we only have to change the version in one place and all assemblies are updated. However, Perforce has a problem with this when a new developer first opens the solution or when a new project is added. The only remedy we have currently is to remove all of the linked files (there are 3 per project in this solution), bind the project to source control, then re-add the linked files.

This isn’t such a big deal when we add a new project but the solution contains 80 projects (and counting), so this isn’t a viable remedy for a new developer!

My understanding is that the problem has to do with where VS thinks the binding root for each project is. After some research, I was led to find where the MSSCCPRJ.SCC files are for the projects. I found there are numerous SCC files scattered throughout the solution structure. So…

First question: Why are there multiple MSSCCPRJ.SCC files in my solution structure?

We also have several shared/common projects that we use in our solutions. This leads to the following folder structure:

/Source
    /CommonTools
        /ProjectA
            ProjectA.csproj
        /ProjectB
            ProjectB.csproj
    /MySolution
        /Assets
            SharedVersionInfo.cs
        /Project1
            Project1.csproj
        /Project2
            Project2.csproj
        :
        /ProjectZ
            ProjectZ.csproj
        MySolution.sln

Where both ProjectA and ProjectB are part of MySolution.sln

Second Question: How can I setup the bindings so the /Source folder is considered the root? This would ensure that all projects included in the solution are under the same binding root. Perforce considers this folder to be the root, how do I get VS and the plug-in to do the same?

Answer 1

Since no one else has offered up a solution, I thought I’d follow-up with my own findings for anyone else that comes across the thread.

First, I still have no idea why Visual Studio creates multiple MSSCCPRJ.SCC files but these are the key to establishing the “binding root” for a solution. It is critical that this file exist at the highest level necessary so that ALL of the projects in the solution are in sub-folders relative to the location of this file. In my example above, the MSSCCPRJ.SCC needed to be located in the /Source folder. Having it in the /MySolution folder caused the original problem when adding projects from /CommonTools into the solution.

That said, resolving the issue was no easy task. I had to manually edit the .sln and all of the .csproj files in Notepad. What I found was that some of the .csproj files had the following elements identifying the source control settings:

<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>

I don’t know what SAK stands for, but my understanding is this tells Visual Studio to use the binding information contained in the .sln file.

I had to change these to:

<SccProjectName>Perforce Project</SccProjectName>
<SccLocalPath>..\..</SccLocalPath>
<SccAuxPath />
<SccProvider>MSSCCI:Perforce SCM</SccProvider>

where the SccLocalPath value is the relative path from the .csproj file to the MSSCCPRJ.SCC file.

I also had to change the SccLocalPathX and SccProjectFilePathRelativizedFromConnectionX statements for each project in the .sln file. The SccLocalPathX value should be the relative path from the .sln file to the MSSCCPRJ.SCC file – a dot (.) if in the same folder. SccProjectFilePathRelativizedFromConnectionX should be the relative path from the binding root to the .csproj file.

I wish I could say that having that in place, I never had to repeat these steps. Unfortunately, I still have to go in and make corrections every time I added a new project to the solution. Visual Studio still wants to use SAK for the elements in the .csproj file and sometimes the values in the .sln file aren’t quite right.

But, at least I know what to look for and what needs to be done to achieve my goals. If anyone else has a better solution or a way to configure VS and/or Perforce so these settings are created correctly up-front, I’ll gladly give credit.

Hope that helps…