How can I rebind my project in TFS?

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

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