CODEWITHSUNDEEP
visual-studiovisual-studio-2012tfsvisual-studio-2013
Mark Bailey
Mark Bailey

Reputation: 1131

Persistent TFS workspace binding will not go away

I have a folder in my workspace that insists on being mapped to a different location. I only mapped the root folder of my TFS project. The entire folder structure comes down to that location without exception when I get source... until today. I was troubleshooting the state of a web project and among other things, removed the entire solution folder (renamed to another location) and forced a get of the solution fresh from TFS. Now when I get latest, everything comes down correctly, but as soon as I open the solution, I get several messages that say Replacing (moved from ). One folder of the solution is moved and workspace working folder mapping shows up mapping that folder to the new location.

History:
My version of the web project had been upgraded from a website to a web app, and we needed to get it in a state consistent with the rest of the team. We removed some sites from IIS, deleted the solution directory, rebooted, and got the latest source code again. The website/web app problem was fixed, but now I have this persistent workspace change that acts like malware.

What I've tried so far:
Deleted TFS cache at Appdata\Local\Microsoft\Team Foundation
Deleted TFS temp files at Appdata\Local\Temp\TFSTemp
Removed the workspace mapping, deleted the solution folder again, restarted Visual Studio, got latest source again. The source is downloaded correctly, but when I run the solution, the working folders are mapped again, and the folder is moved again.
Checked the type of workspace. It is a server workspace (legacy).
Performed a Repair install on Visual Studio 2012.
Installed Visual Studio 2013.
Removed the workspace mapping and allowed Visual Studio to perform another get. This restores the solution structure, but the problem returns if I 1)Close and reopen the solution, or 2)Get latest on the solution (without forcing overwrite).

Upvotes: 1

Views: 327

Answers (1)

Mark Bailey
Mark Bailey

Reputation: 1131

We did finally get a resolution for this in my case. Although I had asked the rest of the team if they had seen this behavior, and got no affirmative responses, when I investigated in detail, I found that many members of my team simply were not aware of their workspace much at all, and did not see that these mappings were being added. Not all members of my team had this issue. I believe everyone that was on a Server workspace did have the issue.

Once we realized that the problem was not unique to me, we found that the solution file was compromised. When we looked into the solution file (.sln) with a text editor, we could see the unwanted mappings represented there. We removed from the solution everything that was being remapped, and then added them back in. After double-checking that the unwanted mappings were no longer written in the solution file, we checked that in, and as each developer removed the added mappings, and then got latest again, the problem was resolved.

Upvotes: 3

Related Questions