Re-establish TFS source control bindings

I have about a dozen Visual Studio 2010 projects I've been working on that are versioned in a TFS repository. Recently I went on a vacation and upgraded my computer's OS to Windows 7 64 bit.

I've reinstalled Visual Studio, and I can connect to my Team Foundation Server and see my projects...only my bindings aren't working correctly. Most of the time none of my files seem to be under source control, but in a couple of projects my source control bindings are OK in the root folder, but not working in subfolders off the project root.

I've tried undoing the binding, opening from source control, and deleting the folder and doing a get latest version. None of these has fixed the problem.

Any thoughts on restoring my bindings?

UPDATE

After poking around I can see there seems to be an extra folder in the path of my "invalid" projects...I've got no idea how it got in there, but this seems to be throwing off my mappings.

You say you've tried undoing the binding, but have you tried rebinding back to source control?

In Visual Studio:

• Open a solution with the problem
• Choose the solution in Solution Explorer
• Pick File->Source Control->Change Source Control
  Visual Studio 2013/2015: File->Source Control->Advanced->Change Source Control
• Unbind any projects that are bound but not working correctly.
• Bind all projects that are now unbound.

When you have an invalid binding and unbinding/binding a project doesn't work, try the following:

1. Unbind project in Change Source Control
2. Unload project in Solution Explorer (For a website-project 'unload project' is not in the context-menu but in the 'Website' menu)
3. Reload project in Solution Explorer

Works for me all the time...

I agree with Joel - usually unbinding and rebinding fixes it.

However, if rebinding doesn't work, you might try editing the solution files directly. I have seen instances where TFS bindings are in the solution file twice and appear to be inaccurate for whatever reason - They may have the wrong number of projects and projects that are set to nothing but still listed in the solution file.

When this happens (pretty rare) I edit the files and make them the way that they should be. For example, I will delete out the 2nd set of TFS bindings (GlobalSection(TeamFoundationVersionControl) or fix any other discrepancies that I see. Then I reload the solution and that normally fixes the problem. I would definitely only use that fix as a last resort though.

I saw this problem the first time I opened an existing (and previously working) solution in a newly installed Visual Studio, with a newly made Workspace.

Unbinding and rebinding didn't fix the problem for me. But it went away when I did a Get Latest Version. TFS showed the files as conflicted, and I resolved the conflicts by overriding the local copy. The previously invalid bindings were then shown as valid.

If your're still fighting with TFS binding invalid status I report here a "gem" I've found in an old (2005) MSDN forum (https://social.msdn.microsoft.com/Forums/en-US/801b2490-776d-43a8-afef-adcedd78f02d/vsts-change-source-control-status-invalid?forum=tfsgeneral):

> This is due to a heuristic used in the validation code for binding. The heuristic does an existence check for all of the files in the project and will only return "valid", if at least half of the files are present in the source control repository. Since web projects have no project file, any file residing in the web project folder is considered "part of the project". Apparently you had enough uncontrolled files to tilt the percentage of controlled project files to under 50%, thus causing an invalid status.

In other words, if you have a project that has many files uncontrolled (this is especially true when you opt-out check-in for folders like node_modules or public in a web project) and the number of these files are more than 50% of the total files in the folder, TFS binding status are invalid whatever you do.

I could verify this rule just removing the correct number of files until the binding status became invalid and just adding a new one (uncontrolled) get the invalid status.

This behavior is still present in VS 2019 6.3 (Azure DevOps).

I don't know if there is a way to disable this heuristic, but I'm pretty sure that it's a fake Invalid status, i.e. tfs binding is actually working correctly and that is just an erroneous message.

I'm going to add this here because I ran into a variant of this and had to find a solution on my own.

The TLDR::
1) Make sure the project is unbound.
2) Manually select all files of the project and add them to sourcecontrol (not the project itself) - this should create the problematic project's root folder under TFS
3) In source control explorer, navigate to the root folder of the problematic project and manually add its .csproj to source control

And the full story of how/why I got there:

IF all answers above don't work (*adospace's answer may be related to this - but I didn't quite understand it :P )

I had 2 projects out of 9 in my solution that were purely Resource projects. When I brought the whole thing into tfs and mapped it to source control they would resolutely remain with invalid bindings (just the two resource projects), nothing I did fixed it. When I finally tried adding manually the project individual files to tfs (the .resx), TFS threw warning about the files being ignored, just like .exes, something it had never done once when adding - remapping - fixing my solution. The warning allowed me to add the files to TFS anyway and at the same time it created the full project folder structure while the projects themselves remained resolutely unbound. But from there I was able to add manually each .csproj to TFS and magically the projects are now properly bound and under source control. I'm not sure why those file types were getting ignored from being added to source control, it might be some default settings in TFS or VS.

When I renamed my solution, I ran into this error as well. I tried all of the above and it did not resolve the situation.

Actual Solution for me was to edit the Build Definition with the new Solution Name

1. My Builds > Right Click the Build Definition > Edit my Build Definition > Process
2. Note that "1. Required > Solution to build" is referencing the old Soluton name.
3. Click the "..." beside the "Solution to Build",
4. Find your new solution. Click it
5. Save the Build Definition
6. Rebuild

Had exactly the same issue but then within visual studio 2017.

Unbinding and rebinding didn't work for me. In then end I solved it by unbinding all the projects in the soluting + the solution file itself and thereafter doing a 'Get Latest Version' for the entire branch. This resulted in a series of conflicts: 'A non version controlled file or writable file by the same name already exists locally'. Resolved those errors by choosing the 'Overwrite Local Filer or Folder Option' Finally this solved it for me

I see numerous answers providing different solutions here. I've had this happen a few times in the past, and usually unbinding/rebinding did the trick. However I just fought this issue recently, and NOTHING seemed to work.

So, I simply deleted the solution directories on my machine, and then got latest from source. Worked like a charm. However, all of my changes were checked-in, so I didn't have to worry about losing anything. YMMV.

Make sure that you solution is already added to source control: File > Source Control > Add Solution to Source Control.