ChatGPT解决这个技术问题 Extra ChatGPT

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.

The extra folder in the "invalid" project is probably something that got created during a build. It will have no effect on TFS unless you "Add" it to your project, (which will in turn "Add" it to TFS). The caveat is: If it is part of your project, but not in TFS, then you need to add it to TFS. :)
I had an invalid source control binding. I discovered a $tf1 folder kept getting created in my project (dated currently). I already had a $tf folder dated months ago. I tried unbinding and rebinding, didn't fix the problem. Once I deleted $tf1, and then renamed $tf to $tf1 my binding worked! And my pending changes were preserved as I needed.

R
Ralph Willgoss

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.


That is so well hidden...it would be very handy to have it in a right-click submenu or something...
I tried doing this but when I clock "Bind", it pops up with the SourceSafe dialog - but I need to bind it to TFS? Can anybody help?
@NewStart You should really ask that as a separate question, but my first thought is that your Tools->Options->Source Control plug-in is set to SourceSafe and not TFS.
Note that in Visual Studio 2013 it's in File->Source Control->Advanced->Change Source Control
If you re-organize your projects within a solution (e.g. TFS Move command), then you may have invalid references. As a result, ProjectA will have a binding status of Invalid. For example: [1] the C++ project Filter in ProjectA contains a file that is no longer at the old location, OR [2] ProjectA contains a reference to ProjectB that is no longer at the old location. See: ProjectA -> Properties -> Common Properties -> References
C
Cyril Mestrom

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

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

Works for me all the time...


by this way, the TFS consider all project files as newly added files to the solution...
This has worked for me on 2020, and nowadays 'unload-project' is already available on the project context menu
I've used this answer twice now and it worked.
J
Jonathan Nixon

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.


+1 for manual editing of solution files. Hope you never have to do it, but know how just in case.
Editing the .sln ended up being what I had to do, but it worked! Thanks!!
u
user1725145

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.


a
adospace

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.


How odd, this solved it for me for one of my reference only projects in VS 2019 16.9.3. I was planning on adding the extra files anyway (they were dlls that don't auto add).
S
Spacemonkey

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.


M
MunsterMan

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

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


This appears to be aimed at "TFS scheduled build doesn't anymore." rather than "My solution/project isn't connected with TFS at all.".
N
Nico Timmerman

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


D
Didaxis

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.


S
SafwanMZ

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