How can I rebind my project in TFS?

Question

Trying to reattach a new machine to all of the dependencies my project has, my current hurdle is the TFS bindings. I see this:

...when I select File | Source Control | Change Source Control..., but the values in the cells are read-only. When I mash the "Bind" button, I'm scolded with, "The mappings for the solution could not be found". Yeah, I know, that's why I want to rebind them. How?

UPDATE

Selecting File | Source Control | Workspaces, I get a list of workspaces (but only after I select the "show remote workspaces" checkbox), and the one I'm currently interested in looks fine to me:

...so what's wrong with this? I'm assuming the "$\tlog" is connected to the remote source; and the source on my local machine is where the "local" cell indicates, so...what's the problem? Why won't it let me re-introduce the pair to each other?

UPDATE 2

On restarting, I was getting, "The associated source control plug-in is not installed or could not be initialized. Common causes for this error include server unavailability and/or incorrect workspace mappings." and based on an answer here: How do I get Visual Studio Team Foundation Server to see I moved code to a different folder?, I allowed it to "permanently unbind." But when I look in the Workspaces, the setup is exactly the same as it was: the connections are exactly the same as before (it's true, they don't work, but I would think permanently unbinding would remove them from Workspaces).

UPDATE 3

Another restart of Visual Studio, and the bindings do appear to be severed - no more err msg. However, they still show as being connected in Workspaces!?!

UPDATE 4

I can now edit the "Change" dialog, but even though the connections seem accurate, it's telling me the status is invalid:

I know the local path is correct, and I can't do anything (AFAIK) about the server path (and I'm sure that hasn't changed), so why is it invalid? Gotta love this "productivity" software.

UPDATE 5

I tried that. I removed everything from the "GlobalSection(TeamFoundationVersionControl)" section, selected File | Source Control | Change Source Control..., then with the first of the projects in the solution highlighted, selected the "Bind" button. It went from this:

...to this after mashing the "Bind" button:

IOW, still no joy in Mudville (Casey has struck out). It says it has connected, but that it's invalid. It would be nice if it would explain why - what is invalid about it? Give me a clue, TFS!

UPDATE 6

Well, I did get a little further and got some of the projects to bind:

Yet nine remained incalcitrant. I tried to fix those bindings by altering the .sln file. As mentioned, nine projects in the solution had a status of "Invalid" and the rest (over twice the number) were "Valid"

So I compared the valid with the in-, and I saw that all the "invalid"s had additional path "descriptions" such as "../../" and "..\" etc. So, I stripped all those out, replaced the .sln with that, and ... nothing. The invalids stayed invalid.

I then took the "nuclear option" suggested by DaveShaw here: TFS Issue: No source control options (get latest, check-out, check-in) for Solution

...but still no go - no change; the valid remained valid, the invalid remained invalid.

I could have rewritten all the code in the time this TFS nonsense is taking!

Not really, but it's still quite frustrating.

UPDATE 7

For more specifics on just what I've tried and what is happening, see http://social.msdn.microsoft.com/Forums/vstudio/en-US/08d3e956-62a8-4874-8468-f178d12ac67c/why-is-the-requested-url-and-physical-path-the-browser-is-trying-to-use-different-from-the-actual?prof=required

UPDATE 8

It seems to me that what TFS should do is allow you to provide it with a local folder structure, or better yet one that has no subfolders, just the "starting point" and then TFS should fill out the folder structure based on the repository's structure, and populate that with the latest code.

If that is how it works, or can work...gr8! But I haven't been able to find out how to do that yet...

UPDATE 9

Here's the way I think it should work:

1) In Windows Explorer, you create a local folder, naming it appropriately for your solution

2) You open Visual Studio, and select "Connect to TFS" on the Visual Studio Start Page

3) You select File | Source Control | Workspaces... | Edit...

4) On the record/row in the Working folders part of the "Edit Workspace " dialog, you click into the "Local Folder" entry so as to be able to edit it

5) You mash the ellipsis button to bring up the Folder dialog.

6) You then select the folder you created in step 1 and mash the "Ok" button.

You now have a record in the "Working folders:" section that looks like this

Status  Source Control Folder   Local Folder
=====   ==================  ==========
Active  $/Whatever      C:\Whatever

7) You now mash this "OK" button

Note: When I do this, I get a dialog that says:

"Workspace Modified One or more working folders in version control have changed. Do you want to get the latest files from version control to update your local workspace?"

I mashed "Yes" and saw:

"Get Progress C:\Whatever\\\..."

...and the progress bar's continually updated text seemed to indicate that it was doing what I would expect (copying the repository files to the local folder, creating subfolders as necessary).

8) You mash the "Close" button on the "Edit Workspace " dialog

9) You then select "Open Project..." on the Visual Studio Start Page, and navigate to C:\Whatever

10) The sun comes out, bluebirds begin to sing, and dolphins begin jumping out of the water in the middle distance in a choreographed display of delight.

However, in my case what happens is that Windows Explorer says the object of my desire (Whatever.sln) is found in two local folders, but clicking on those folders shows no such file. There is one, but it's not where Windows Explorer says it is...it's another folder below that. And when I select that project to open, I get:

"The Web project is currently configured to use the URL 'http://localhost/<different one>'. the Web server has this URL mapped to a different folder 'C:\Project\ccr\TLog\Development\Development\Externals\CommonLogin.' Would you like to remap this URL to point to this Web project's folder?"

I say "Yes"

I get the same message for another project, and again select the "Yes" button.

The project loads. It seems to be the right collection of projects in the solution.

Perhaps it really has worked this time (after a fashion). What I mean by that qualification is that, when I compile the solution, Visual Studio tells me there are 11251 Errors... perhaps it's a matter of adding references and whatnot. I did get this: "One or more projects in the solution were not loaded correctly. Please see the Output Window for details."

At any rate, instead of basking in the sun listening to the bluebird of happiness, the sedge has withered from the lake, and no birds sing.

UPDATE 10

I finally got it to work, by following Jason Williams' answer; however, I still have 11,257 error messages due to broken references. Is there a way to automate the process of fixing these, or must I slog through them one assembly at a time (I know some will fix more than 1 err msg, but still...)

UPDATE 11

Here's what the erstwhile Sacramento King was talking about re: "Get Specific Version" (see the comments following his answer):

Davis

Try my answer here: #17447445 – Amimia

Didn't work for me. I'm updating again with the specifics (Update 5 shows what I see/saw). – Purposeless

Answer 1

Your update 9 sounds essentially correct. You can skip step 1.

However, it sounds like in step 5 take care that you aren't creating a double folder with your mapping (e.g. if you have a TeamProject called $/Whatever and it has a root folder called Whatever, then you actually have a path $/Whatever/Whatever, or you could map $/ to D:\Code\Whatever - either way you may end up with D:\Code\Whatever\Whatever). This may not be a problem but it's possible that whoever created your source code may not have thought about making it relocatable by using relative path references in which case you may need to be sure that it ends up in the correct absolute path or it may not compile correctly.

Once you have the workspace created, it asks (step 7) if you wish to update the workspace with the changes. This is the right plan, but I wouldn't trust it - TFS remembers what it thinks you have in each folder of your workspace, so if it gets confused by anything you've ever done in the past, it may decide you have some of the source code already and not update it. So to be bullet-proof on this step, click "No" and then manually go to the source control explorer, right click on the root folder and do a "Get Specific Version". Then tick both the checkboxes to make it get all files (even if it thinks you have them) and to forcibly overwrite everything (even writable files) and you'll be sure to get a complete copy of the source code.

At (9) you need to open a solution from your mapped workspace (local drive). Go to File > Source Control > Change Source Control and check that the solution is bound. If not, select everything and click Bind. This is the magic button that fixes everything and nobody in the universe understands this user interface, why it is there, why it is so complex, and why none of the other options on the dialog are there when they are never used for anything ever. All that binding does is write down where you've got the solutions on your local disk so you will be left with an empty feeling and the hint of an idea that this should just work without you having to mess about like this in dialogs that make no sense to do something that should just happen automatically if you are using something from within source control and you're in "online" mode.

This binding process should mean that any edits you now make will cause the affected files to be checked out automatically. (If this doesn't happen, check Tools > Options > Source Control to be sure you have sane settings)

Now, if you get errors when compiling, the likely suspects will be:

• The code on the server doesn't build. e.g. someone's forgotten to check in all the dependencies, etc.
• The code on the server is fine, but you have mapped it to a different location on your PC than the original author had it at (e.g. you used D:\ and he used C:), and he's not made it relocatable. If so, the quickest fix is to find out how his mapping works and duplicate it exactly on your PC (hint: You can view other people's mappings in your workspace editor and copy and paste them into your own mapping). the real solution is of course to track down every broken (absolute) file reference and make it relative to make the solution relocatable.
• The code on the server is fine, but your workspace mapping doesn't match how you've set up your web server, and then when Visual Studio notices that the two don't match, you've clicked "yes" (not knowing that it means "yes, please screw everything up for me") rather than "no" ("I must have a mistake in my source control mapping, I think I'll go back and double check it first thanks"). In this case, double check your source control mapping will drop the code in the place where the web server thinks it will find it, and (after deleting the lot, fixing the mapping, and doing a Get Specific Version to force TFS to get a clean copy in the right place) probably a lot of your issues will vanish.
• The code on the server is fine, but Visual Studio's awful reference system has broken some of the references. Essentially, if it can't find a referenced assembly exactly where you tell it to look, instead of saying "error: it's not there", it instead goes on a journey of discovery through your PC, and picks something else with a similar name and says "that ought to do". Which in a small percentage of cases (99%) f**ks things up completely, and in the remaining 1% just breaks them totally. The place to look in your list of errors is usually at the bottom - helpfully the last error is often the failed reference, and the preceeding 1000 errors are just side effects. Also, check in each project's references for yellow exclamation mark icons - these are missing references. Finally, if you have a reference to a MyAssembly.dll or "MyAssembly" project that causes inexplicable build errors, then search your hard drive for "MyAssembly.dll". When you discover 3,245 copies of that dll all through your build projects, delete all of them except the "right" one and see if your build success improves. Beyond that, you'll just have to read the errors and resolve them one by one.

I'm afraid an exact answer isn't easy from this far away, but hopefully that will at least confirm that you've got the essential ideas right, and maybe give you some clues that will help you diagnose your affliction. My money would be on the workspace mapping being a teeny tiny bit different from the magic setting it needs to be for everything to just click into place, leaving you stunned and wondering why you've just had to spend 3 days solving such a nightmarish problem only to find out that you were never more than 3 characters and a slash away from the centre of the maze.

From clues in your step 9, it may be something like

$/TLog  -> C:\Project\ccr\TLog

rather than

$/TLog -> C:\TLog

Homeo

Thanks a million; for the time you spent, the information, and the confirmation that TFS is a nefarious and foul-smelling beast. – Purposeless

To me, TFS is just like every other source control system, in that the ui is very poor, and semingly simple or obvious actions can get you into a lot of trouble if you don't know exactly what you are doing. One day someone will realise that we need about 20% of the functionality and 500% of the user interface support that we have at the moment, and the world will become a better place. – Homeo

Agreed; I've used CVS, VSS, Tortoise/Subervsion, and now TFS (and perhaps one or two I'm disremembering at the moment), and I don't care much for any of them. – Purposeless

By "manually go to the source control explorer, right click on the root folder and do a "Get Specific Version"" do you mean the dialog that says "Edit Workspace <Computer Name>"? Right-clicking there does not give me an option to "Get Specific Version"... Or do you mean the "Open from Source Control" dialog? In that case, also, highlighting and right-clicking does not give me any such context menu option... – Purposeless

No - go to the "Source Control Explorer" view (available from the Team Explorer, or from the View main menu item), then right-click on the source control folder (or the whole Team Project) that you want to get. In the context menu you'll find a "Get specific version" (exactly where in the menu depends on your version of Visual Studio) – Homeo

Oh, I see - you have to 2-click <TFS team project name> | Source Control. Why did MS hide that functionality in the pressed rat and warthog's den? – Purposeless

Answer 2

There is already a great answer for this issue, but I want to share my steps since they might help:

1. Check your current Workspaces, In my case I had two of them and this was causing my problem (the image is for reference since I took it after I solve it)

2. Since I did not needed any of both workspaces I deleted them using the window that appears in the previous step, watch out to not delete other workspaces that you might need

3. Then you need to connect to the TFS like it is the first time, and when that happend VS will ask for a mapping of the workspace (server to local path), then I click MAP & GET

4. After the GET of all the sourcecode is finish open the solution and it asked if I wanted to bind it to the server and clicked YES

That solved the problem

Schaub