Binding in vbproj files not cleared when following KB advice

arbitrarily · Post by **arbitrarily** » Thu Feb 23, 2006 6:31 pm

I'm using SOS 4.1.2, VSS 6.0d and VS.NET 2003.

We have a mixed team working with SOS and VSS.

I am trying to fix up the solution and project bindings as described in http://support.sourcegear.com/viewtopic.php?t=1149. I am following these instructions exactly, however the source control lines still appear in the vbproj files after checking in the modified files. The sln file is fine.

The lines in the vbproj file are:

SccProjectName = "$/ProjectPath"
SccLocalPath = ".."
SccProvider = "MSSCCI:SourceOffSite"

When somone using VSS tries to open the solution after me, they get messages asking whether to change the bindings, and are then asked to check out the project. If they follow the instructions in the KB article, the vbproj ends up with these lines:

SccProjectName = '"$/ProjectPath", COFAAAAA'
SccLocalPath = "..\.."
SccProvider = "MSSCCI:Microsoft Visual SourceSafe"

So we end up going backwards and forwards changing these files. How can I set it up so we only need to update the bindings once and have them work for everyone?

Post by **Tonya** » Mon Feb 27, 2006 10:28 am

I think the problem may be that you are opening the project from source control every time you need to access the project. My first suggestion to resolve the problem is to have each user clear out their working folder and then open the project from source control. From this point on, the user no longer needs to open the project from source control because the files already exist on their local machine. They would simply use File - Open.

Please let me know if this doesn't resolve the problem.

Thanks,

Tonya Nunn
SourceGear

arbitrarily · Post by **arbitrarily** » Mon Feb 27, 2006 2:35 pm

This did not solve the problem. We were not opening from source control after the first time to create the files. We've spent a few days trying many options to sort this problem out and we are close to giving up. We work on a large number of solutions and cannot afford to be continually fixing binding problems.

Are mssccprj.scc files supposed to be created for the projects as well as the solutions? We only get one created for the solution, and nothing for the projects.

Post by **Tonya** » Mon Feb 27, 2006 3:25 pm

Are mssccprj.scc files supposed to be created for the projects as well as the solutions? We only get one created for the solution, and nothing for the projects.

Yes, there should be a mssccproj.scc file for each project. It seems like your SourceOffSite is behaving as an older version. Could you confirm that every user has SourceOffSite 4.1.2 and the SOS Server is also 4.1.2?

Tonya

arbitrarily · Post by **arbitrarily** » Mon Feb 27, 2006 5:16 pm

In our current trial, we only have two SOS users, and we are both using version 4.1.2. The server is also 4.1.2. This was a fresh install on recently re-imaged machines, so there should be no upgrade issues. All other users are using VSS 6.0d.

I've currently switched my VS integration back to SourceSafe, but still have SOS installed. When I re-did the bindings for one solution, it appeared to work correctly and creating a mssccprj.scc file for the single project in the solution, but in this case following lines were already in the vbproj file

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

This narrows down the problem to clearing the SCC from the vbproj files. I don't know how to make this happen consistently for both VSS and SOS users.

Post by **Tonya** » Tue Feb 28, 2006 10:00 am

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

This is correct and is what your mssccprj files should look like. By any chance are you using the GUI client "get latest" command to get some of the files instead of the IDE?

I'm not really sure what's going on, we have users that use VSS and SOS for integrated projects. Clearing the working folder and performing an "open from source control" should create the new mssccprj file in the "SAK" format as listed above.

Tonya

arbitrarily · Post by **arbitrarily** » Tue Feb 28, 2006 3:24 pm

I think we're almost getting somewhere. If the project file has been bound such that it is in SAK format, using the Get from sournce control method will create the mssccprj.scc files. The problem I have is that I cannot get most of my project files to change to the SAK format. I am using the procedure described in the KB article. When I unbind, all SCC fields are removed from th .vbproj file. But when I bind again the Scc fields go back in the server specific format.

I have one case of a solution with 8 projects. 4 are code projects are 4 are unit test projects. When all 8 projects are bound to the solution, the 4 unit test projects end up in SAK format, while the 4 code projects end up with SccProvider specific bindings. Therefore we cannot use this solution with both SOS and VSS.

Can you recommend a way of forcing all 8 projects into SAK format?

Post by **Tonya** » Tue Feb 28, 2006 3:56 pm

Out of the eight projects, are the four projects that aren't ending up in the "SAK" format web projects?

Tonya

arbitrarily · Post by **arbitrarily** » Tue Feb 28, 2006 4:25 pm

No. We don't work with any web projects.

However there is one difference I've noticed between the 4 that work and the 4 that dont. In the <Files> section of the .vbproj file, we link to a file that is in the solution root directory.

Code: Select all

                <File
                    RelPath = "AssemblyInfoCommon.vb"
                    Link = "..\..\AssemblyInfoCommon.vb"
                    SubType = "Code"
                    BuildAction = "Compile"
                />

This is a common file that we use for our versioning. All projects link to the same file because we want them to have the same version. We use NAnt to increment the version when we build. Could this be causing the problem with binding?

Post by **Tonya** » Thu Mar 02, 2006 1:57 pm

I'm not sure if the problem is related to the file that is linked. Could you perform the following test scenario and let me know the outcome?

Create a new project that links to a file in the root directory, add the project to scc using VSS. Check the MSSCCPRJ file and see what the SccProvider is set to. If it looks correct, open the project from source control using SOS and let me know if the MSSCCPRJ file is altered.

Thanks,

Tonya

arbitrarily · Post by **arbitrarily** » Thu Mar 02, 2006 2:40 pm

When I do as you suggested for a new solution with a file linked in the root directory it behaves like my other projects. The mssccprj.scc is correct, as follows

Code: Select all

SCC = This is a Source Code Control file

[TestClassLibrary.vbproj]
SCC_Aux_Path = "\\melfp04\ssafe$\GKN.NET"
SCC_Project_Name = "$/Scratch/{SOS Test Solution}/TestClassLibrary", GDKAAAAA

But the SCC information is also in the .vbproj file

Code: Select all

    <VisualBasic
        ProjectType = "Local"
        ProductVersion = "7.10.3077"
        SchemaVersion = "2.0"
        ProjectGuid = "{570B76B1-E032-4333-A509-B737B99ED3ED}"
        SccProjectName = '"$/Scratch/{SOS Test Solution}", DDKAAAAA'
        SccLocalPath = ".."
        SccProvider = "MSSCCI:Microsoft Visual SourceSafe"
    >

If I do exactly the same process but do not have the linked file, the mssccprj.scc file is identical, but the .vbproj file is in the SAK format.

Code: Select all

    <VisualBasic
        ProjectType = "Local"
        ProductVersion = "7.10.3077"
        SchemaVersion = "2.0"
        ProjectGuid = "{C88AD881-BC58-49C7-A810-5EBFC3AA9F1A}"
        SccProjectName = "SAK"
        SccLocalPath = "SAK"
        SccAuxPath = "SAK"
        SccProvider = "SAK"
    >

Post by **Tonya** » Thu Mar 02, 2006 3:03 pm

Are you able to successfully open the second project (the one without the linked file) using SOS? It appears as if the linked file, may be the cause of the problem.

Can you give me more information in regards to the linked file that you are referring to? I'm not familiar with "linked files" in VS.Net and I need to attempt to reproduce this issue.

Thanks,

Tonya

arbitrarily · Post by **arbitrarily** » Thu Mar 02, 2006 3:25 pm

When I open the solution without the linked file from source control with SOS it opens with no error messages.

When I open the solution with the linked file from source control with SOS I get this message.

"The source control bindings for project TestClassLibrary differ from those stored in the solution file. Both sets of bindings must be the same.

Which bindings would you like to use?"

I then have the options "Solution's bindings" or "Dont change anything". However with both of these options it requires me to check out the project file and it changes the bindings in the file to this:

Code: Select all

    <VisualBasic
        ProjectType = "Local"
        ProductVersion = "7.10.3077"
        SchemaVersion = "2.0"
        ProjectGuid = "{570B76B1-E032-4333-A509-B737B99ED3ED}"
        SccProjectName = "$/Scratch/{SOS Test Solution}"
        SccLocalPath = ".."
        SccProvider = "MSSCCI:SourceOffSite"
    >

To add a linked file in VS.NET, right click on the project and go to Add->Add Existing Item... then browse to the file in the root directory (it has to already be there). Select the file and then click the drop down arrow next to the open button. There are three options - Open, Open With... and Link File. Choose link file.

The file then appears in the solution explorer under the project, but has a little arrow on the icon to show it's a linked file.

Post by **Tonya** » Thu Mar 02, 2006 3:34 pm

I spoke to our SOS developer about this issue. Because Visual Studio behaves the way it does (inputting the incorrect scc information in the .vbproj file) there is nothing that SourceGear can do to resolve the problem as we have no control over it.

I am very sorry that we have no resolution other then not to use "linked files".

Tonya

arbitrarily · Post by **arbitrarily** » Thu Mar 02, 2006 3:38 pm

Thanks for your help. We will have to look a rearranging our source if we decide to go ahead with SOS.

Can I suggest that this issue with linked files be added to the KB article on clearing the bindings for using SOS and VSS together.