A while back I had a working folder on a "D:\ drive". That drive is now gone and I have my working folder on another drive, u:\.

When I got the new drive I deleted my workspace and created a new one and have mapped my project working folder to my new folder on the new drive. My project has dozens of subprojects and the directory structure on my new local drive mirrors that of the TFS folder.

However whenever I attempt to work with a folder for the first time (since I got the new drive), I am constantly told that my "D:\blah\blah\blah" folder is invalid. To top it off, after I get the error I typically give up and do a get specific version with the force get check boxes checked.

Then TFS does one of two things. It either syncs the folder up (sometimes giving the same error a couple of times on other files or subfolders), or I get a "Microsoft Visual Studio has encountered a problem and needs to close." dialog box. The debug report shows an access violation in dpprj.dll and then devenv closes down and restarts on me.

Sometimes (if I don't crash) after I get the error a couple of times it quits occurring for a project. Also when opening a project I can get dialog boxes telling me there is a discrepancy between the solution's source control info about some project(s) and the info in the project files. I am only allowed to ok or hit help on that dialog. I sure the heck would like to be able to see a diff at this point since these projects are shared by lots of team mates and I wonder what is being stored in these files that appears to be specific to an individual user. So for instance, I just went thru all this again (I dreaded it but I had to open a project for the first time since getting my new drive). Now after the crash and restart I have the following files checked out to me:

.sln .vcproj .vcproj.vspscc .vssscc .vcproj .vcproj.vspscc

Yes that is correct, some files are checked out twice. Some to my local folder as defined in my workspace mapping but the first 4 are in c:\temp\ under a folder with the same name as the folder my project is in (fully qualified path).

If I now do a diff with the vcproj and vcproj.fspscc files in my local folder (not c:\temp...), there are no differences. So TFS forces me to check out files because of "differences" but when it is done, there are no differences in the files.

If I go to the c:\temp\... files and pick the .sln file and do a compare, I get a dialog box telling me "The character encodings on these files are different ..." I can answer yes to treat the files as being the same and the diff window shows nothing in the right hand side other than a title of "[no file]".

So, How do I force TFS to give up on my "D drive". I have tried deleting my workspace and starting over but that does not work.

I have VS 2005 SP1 on XP Pro 64 bit Edition OS. All my software is up to date.

Oh, and when I try to "undo" all these checked out files, I get the same "There appears to be a discrepancy between the solution's source control info about some project(s) and the info in the project(s) files. box again.

I am guessing that for some reason TFS is storing that "D:\..." in the database and when I deleted my workspace and created a new one, TFS is not cleaning up after itself.

Re: Team Foundation Server - Version Control Working folder fiasco

Chandru R - MSFT

How did you delete your workspace Did you use the tf workspace /delete command to notify the server that the workspace has been deleted.

Re: Team Foundation Server - Version Control Working folder fiasco


Well I was unaware of the workspace/delete command. What I did was click the source control explorer's "Workspace:" dropdown arrow. Then I pick the "Workspaces" entry. At that point a "Manage Workspaces" dialog appears. I click the workspace I wanted to remove and then click the "Remove" button on that dialog.

So it sounds like I need to find the workspace/delete command and run it too Hopefully when I find the delete command my original workspace will still be in the list.

Man, I hate to appear so inept but I simply cannot find the workspace/delete command. I dont' see it in the source control explorer window. I tried the Visual Studio file/source control menu but see nothing like a workspace/delete command. There is a workspaces command but that brings up the same dialog with the "remove" button.

Where is this delete comand hidden

Re: Team Foundation Server - Version Control Working folder fiasco

Richard Berg MSFT

tf workspace /delete is documented here: http://msdn2.microsoft.com/en-us/library/y901w7se(VS.80).aspx

You shouldn't need to run it though. Removing the workspace from the Manage Workspaces dialog does the same thing. It sounds like a problem with Solution Explorer integration, specifically with the Deployment Project project system (dpprj.dll). I would try unbinding & rebinding this project.

Re: Team Foundation Server - Version Control Working folder fiasco


Boy I feel dumb. I cannot find the unbind command. I followed your link and could not find it listed there either. I hit the "sync to contents" icon while in your link and that does not put me anywhere in the index list either so I don't see what other "hidden" command line commands (good thing that dos window still exists) are available.

Plus the MSDN window that I live in now does not allow me to open in a new tab nor does navigate backwards bring me back to this page complete with text. So I typed the above in twice. But that's ok. I am used to this new MSDN container app (MS Document Explorer) losing my data. Heck, everytime I have to login, such as when I hit "check on a question status", the login page comes up and puts me in the password field and as I start to type, focus is switched from the pwd field to, well to somewhere but not the pwd field and I end up with one or two "dots" that obfuscate my pwd and then nothing until I manually place the cursor back in the field and click to manually set focus.

Perhaps I type too fast.

If I find the rebind command, I hope it doesn't start deleting files from my disk (someone's ears are burning in Redmon for that nifty "feature").

Re: Team Foundation Server - Version Control Working folder fiasco

Re: Team Foundation Server - Version Control Working folder fiasco


Thanks. That was useful. A project I have been working in mysteriously lost the auto-checkout capability after I pulled a new dev platform a week or so ago. When I ran brought up the change source control dialog I saw that the "Solution: controls.sln" binding was complete but there is also a "Controls" entry for one of the projects in the solution that did not have a binding. Running bind filled out its entry and now when I edit a file, it is checked out automatically. All the other projects in the solution were bound.

I am not sure just what changed but the bind command checked out the .sln file and when I do a compare, for once there is a difference (.sln and .vcproj files get checked out often with no diffs). I don't know how this fixed auto-checkout (perhaps the sln file is not the only file involved for that feature) since the compare shows that the only difference in the local and server .sln file is that the order of the projects has changed


SccProjectUniqueName1 = Controls.vcproj
SccLocalPath1 = .
SccProjectUniqueName2 = SEListCtrlX\\SEListCtrlX.vcproj
SccProjectName2 = SEListCtrlX
SccLocalPath2 = SEListCtrlX
SccProjectUniqueName3 = controlsres.vcproj
SccLocalPath3 = .


SccProjectUniqueName1 = SEListCtrlX\\SEListCtrlX.vcproj
SccProjectName1 = SEListCtrlX
SccLocalPath1 = SEListCtrlX
SccProjectUniqueName2 = controlsres.vcproj
SccLocalPath2 = .
SccProjectUniqueName3 = Controls.vcproj
SccLocalPath3 = .

Since the above is simply a reordering (unless I miss something), the magic must be in the vcproj file where there is this diff. The first and last line were in both but the new file has the "SAK" entries.




I looked at the history of the proj file and found a co-worker had checked in changes (added new files) a while back and that is when the above entries were removed. I asked him about it and it turns out he had taken his USB drive home to work one weekend and he got tired of VSS bringing up the dialog that says the source code provider cannot be found and should he permanently remove the binding or temporarilty work off-line. He clicked OK so that appears to be why this was removed.

The next time I open a project I have not been in and it tells me it cannot find my "D:\..." (local folder that no longer exists) I'll run the bind and see if it helps. I'm not sure if it will since the binding dialog doesn't really show me any local folders but if I lose auto-checkout again, I'll know what to do!