Interesting support case – Visual Studio solution prompts for entire SCC check-out on open

  • Article

Today we hear from Brett Keown about an interesting support case he had recently, with some great details about CSPROJ file structures, etc. Enjoy!

Trevor

+++++++++++++++++++++++++++++

I had some questions yesterday from a customer about an issue in which every time they opened a solution file locally or from their TFS Server, they were prompted to check-out the entire code tree.  It turns out that the resolution is fairly straight forward though finding it was a bit tough (thank you JH!  You know who you are :-) )!  It turns out that my customer’s csproj files had been modified either manually or by a tool to add values that should not have been there.

In project files there are four values that we use to control this behavior.  They are SccProjectName, SccLocalPath, SccAuxPath and SccProvider.  The value for each of these "should" be "SAK" (with the quotation marks). If you take a look in a project file (in my case, csproj) you will see an SCC section that looks like this:

        SccProjectName = "SAK"
        SccLocalPath = "SAK"
        SccAuxPath = "SAK"
        SccProvider = "SAK"

The settings in the project files override the settings in MSSCCPRJ.SCC which is created by MSSCCI compliant source code control providers.  The SAK essentially says… “Ignore me and go look at the MSSCCPRJ.SCC file for this information”.  Here is what my customer had.  Ouch!

<SccProjectName>%24/BLAH111/GreatProject/Dev/Feature1/Desktop</SccProjectName>
<SccLocalPath>..\..</SccLocalPath>
<SccAuxPath>CoolTFSServer:8080</SccAuxPath>
<SccProvider>{4DB58AB2-18RA-4F8K-95U4-32PDF27L184R}</SccProvider>

The MSSCCI portion of the Visual Studio Development Environment will read these settings and never get the info contained in MSSCCPRJ.SCC.   Because we can't find the information that TFS (or VSS) is expecting to see, MSSCCI believes that it has to rebind the solution and its dependent files back to the correct location so we are prompted to checkout / checkin on every edit, get, or history of the files.

The fix for this issue was to use REGEX (regular expression editor) to walk all the csproj files and replace the incorrect values with “SAK” for each line.  MSSCCI will then ignore the project file settings and go look for the information in the MSSCCPRJ.SCC file.

Those of you that have used Visual SourceSafe for a while most likely know the name "Alin Constantin".  He's been working with this community in a very transparent manner for years leveraging his experience as one of the product’s (Visual SourceSafe) developers (he's a heck of a nice guy to boot!).  Alin has written a great document which discusses MSSCCPRJ.SCC and all the other version control files here:

<alinconstantin.members.winisp.net/webdocs/scc/SccFiles.htm>

I'd like to restate what Alin says very clearly... this is important now...

DO NOT DELETE THESE FILES!

Here' is Alin's description of the MSSCCPRJ.SCC file:

MSSCCPRJ.SCC - This file is created by MSSCCI-compliant source control providers

This file is created by source control providers like Visual SourceSafe if they can track the location of certain files in the database. A provider creates this file if it can store the AuxPath and ProjectName bindings for a file.

To help the source control integration in Visual Studio, a source control provider needs to track the location of solution and project files. When the provider is able to track the source control location of a project file, the source control bindings of that project will not be written in the project and solution file (dummy 'SAK' strings will be used instead as a signature in this case). This helps scenarios like Branching, when the project will automatically be bound to the branched location without the user having to use the File/SourceControl/ChangeSourceControl dialog to retarget the new branch. Also, creating mssccprj.scc may help keeping the source control integration working even when the users don't use source control integration properly (when they Get projects using VSS standalone instead of using the integration commands OpenFromSourceControl)

In SourceSafe the list of files that will be tracked can be configured using SourceSafe Explorer in Tools/Options/FileTypes/CreateSCCFile.

Here is an example of a mssccprj.scc file content:

      SCC = This is a Source Code Control file

      [ClassLibrary1.vbproj]

      SCC_Aux_Path = "D:\Program Files\Microsoft Visual SourceSafe 6.0"

      SCC_Project_Name = "$/Solution1/SubFolder/Solution1/ClassLibrary1", PBAAAAAA

For a description of mssccPrj.scc file format you can consult the most recent MSSCCI specification found here:

<alinconstantin.members.winisp.net/webdocs/scc/MSSCCI.htm>