Solving the “Some projects have been bound to server locations that may be incorrect.” in Visual Studio 2010 when using Team Foundation System 2010 #VS2010 #TFS2010
Posted by jpluimers on 2012/08/23
A while ago, I inherited a bunch of C# and VB.NET projects. One of them always generated the below error when including it in Team Foundation System (yes, the original projects were salvaged from Visual Source Shredder version 6.0c):
[Source Control]
Some projects have been bound to server locations that may be incorrect.
A location may be incorrect either because it does not contain the majority of the projects' files or because those files are not in the correct location relative to the specified server folder.
You should probably fix all the bindings in the solution. However, you may continue and bind these projects to the specified locations even when some may be incorrect.
[Fix server bindings] [Continue with these bindings] [Help]
First I tried the Help button: it links to a Help page on MSDN explaining the error can be cause with some statistics on projects not being in the source control system. Since all projects were, there, I looked for more information.
I tried finding a “Fix Server Bindings” or a 2010 “Some projects have been bound to server locations that may be incorrect” link that fitted my use case (getting projects from VSS into TFS), but the solutions I tried eventually all led to the same issue.
Fixing the server bindings would always fail: the solution (which itself is also a project) would get the status Invalid.
The next steps were these:
- add an empty solution in the same directory as the original one,
- add that solution to TFS
- add the projects from the original solution to this solution one by one
- check after each addition of the bindings were still OK using the “File”, “Source Control”, “Change Source Control” sequence on the right.
(note that you don’t always see “Change Source Control”, if you don’t select the solution in the Solution Explorer before going to the File menu). - text compare both .SLN solution files
- observe that “Solution Items” actually is a project just like the others:
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Solution Items", "Solution Items", "{8D9964D4-6129-4B8F-9238-F9161A02B968}"
ProjectSection(SolutionItems) = preProject
...
Framework\Config.dll = Framework\Config.dll
...
EndProjectSection
EndProject - add the existing solution item from the original solution to this solution one by one, check
- check after each addition of the bindings were still OK using the “File”, “Source Control”, “Change Source Control” sequence on the right.
(note that you don’t always see “Change Source Control”, if you don’t select the solution in the Solution Explorer before going to the File menu). - copy the non-existing solution items to the solution one by one using the text compare tool (yes, a lot of the projects are dirty and contain references to files that are not in the version control system)
save after every copy, then reload the project in Visual Studio - check after each addition of the bindings were still OK using the “File”, “Source Control”, “Change Source Control” sequence on the right.
(note that you don’t always see “Change Source Control”, if you don’t select the solution in the Solution Explorer before going to the File menu). - after a few files, suddenly the “Invalid” appeared, so the issue has to do with missing files.
Reading the Help more carefully, with in the back of my mind keeping “Solution Items” all as projects, I finally got the cause:
When some percentage of Solution Items cannot be found locally, and are not in the version control system, Visual Studio marks the solution binding to the version control system as “Invalid”.
The temporary solution is to ignore the error, until I have found all the missing files (they are scattered around some network shares), or made sure they are not needed at all.
There are many of those (you recognize them from the missing padlock icon in the Solution Explorer).
Version control rot is just like link rot, that’s why one of the high priority action items is to introduce for build automation at this client, then deploy those as clean builds into the Develop and Test stages of the DTAP, then verify if the solutions still work).
–jeroen
The Wiert Corner - irregular stream of stuff 
Leave a Reply