如何在 TFS 中重新绑定我的项目? [英] How can I rebind my project in TFS?

问题描述

尝试将新机器重新附加到我的项目具有的所有依赖项，我当前的障碍是 TFS 绑定.我看到了:

...当我选择文件 |源代码管理 |更改源代码管理...，但单元格中的值是只读的.当我捣碎绑定"按钮时，我被骂找不到解决方案的映射".是的，我知道，这就是我想重新绑定它们的原因.怎么样?

更新

选择文件 |源代码管理 |工作区，我得到了一个工作区列表(但只有在我选中显示远程工作区"复选框之后)，我目前感兴趣的那个对我来说很好:

...所以这有什么问题?我假设$\tlog"已连接到远程源；并且我本地机器上的源是本地"单元格指示的位置，所以...有什么问题?为什么不让我重新介绍一下?

更新 2

重新启动时，我收到未安装或无法初始化关联的源代码控制插件.此错误的常见原因包括服务器不可用和/或工作区映射不正确."并基于此处的答案:

...但还是不行——没有变化；有效的仍然有效，无效的仍然无效.

我本可以在这个 TFS 废话所花费的时间内重写所有代码！

不是真的，但它仍然很令人沮丧.

更新 7

有关我尝试过的和正在发生的事情的更多细节，请参阅 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

更新 8

在我看来，TFS 应该做的是允许您为它提供本地文件夹结构，或者更好的是没有子文件夹，只是起点"，然后 TFS 应该根据以下内容填写文件夹结构存储库的结构，并用最新的代码填充它.

如果是它是如何工作的，或者可以工作......gr8！但我还没有找到如何做到这一点......

更新 9

这是我认为它应该工作的方式:

1) 在 Windows 资源管理器中，您创建一个本地文件夹，并根据您的解决方案为其适当命名

2) 打开 Visual Studio，然后在 Visual Studio 起始页上选择连接到 TFS"

3) 您选择文件 |源代码管理 |工作区... |编辑...

4) 在编辑工作区"对话框的工作文件夹"部分的记录/行上，单击进入本地文件夹"条目以便能够对其进行编辑

5) 您混搭省略号按钮以显示文件夹对话框.

6) 然后选择您在步骤 1 中创建的文件夹并混合确定"按钮.

您现在在工作文件夹:"部分有一条记录，如下所示

状态源控制文件夹本地文件夹==================================活动 $/Whatever C:\Whatever

7) 你现在混搭这个OK"按钮

注意:当我执行此操作时，会出现一个对话框，内容为:

工作区已修改版本控制中的一个或多个工作文件夹已更改.你想要从版本控制中获取最新文件以更新您的本地工作区?"

我把是"捣碎，然后看到:

获取进度C:\Whatever\\\..."

...并且进度条不断更新的文本似乎表明它正在做我所期望的(将存储库文件复制到本地文件夹，根据需要创建子文件夹).

8) 您在编辑工作区"对话框中混搭关闭"按钮

9) 然后在 Visual Studio 起始页上选择打开项目..."，并导航到 C:\Whatever

10) 太阳出来了，蓝鸟开始唱歌，海豚开始在中距离跳出水面，以精心编排的欢乐表演.

但是，在我的情况下，Windows 资源管理器说我想要的对象 (Whatever.sln) 在两个本地文件夹中找到，但是单击这些文件夹显示没有这样的文件.有一个，但它不是 Windows 资源管理器所说的位置......它是下面的另一个文件夹.当我选择要打开的项目时，我得到:

Web 项目当前配置为使用 URL 'http://localhost/'.Web 服务器将此 URL 映射到不同的文件夹 'C:\Project\ccr\TLog\Development\Development\Externals\CommonLogin.'是否要重新映射此 URL 以指向此 Web 项目的文件夹?"

我说是"

我收到另一个项目的相同消息，然后再次选择是"按钮.

项目加载.它似乎是解决方案中正确的项目集合.

也许这一次它真的奏效了(在一种时尚之后).我的意思是，当我编译解决方案时，Visual Studio 告诉我有 11251 个错误......也许这是添加引用之类的问题.我确实得到了这个:解决方案中的一个或多个项目未正确加载.有关详细信息，请参阅输出窗口."

无论如何，不​​是晒着太阳听幸福的青鸟，而是湖边的莎草枯萎了，没有鸟儿歌唱.

更新 10

我终于按照杰森威廉姆斯的回答让它工作了；但是，由于引用损坏，我仍然有 11,257 条错误消息.有没有办法自动修复这些问题，或者我必须一次通过一个程序集(我知道有些会修复 1 个以上的错误信息，但仍然......)

更新 11

这就是昔日的萨克拉门托国王所说的:获取特定版本"(见他回答后的评论):

解决方案

您的更新 9 听起来基本正确.您可以跳过第 1 步.

但是，听起来在第 5 步中，请注意不要使用映射创建双文件夹(例如，如果您有一个名为 $/Whatever 的 TeamProject 并且它有一个名为 Whatever 的根文件夹，那么您实际上有一个路径 $/Whatever/Whatever，或者您可以将 $/映射到 D:\Code\Whatever - 无论哪种方式，您都可能以 D:\Code\Whatever\Whatever 结束).这可能不是问题，但创建源代码的人可能没有考虑过使用相对路径引用使其可重定位，在这种情况下，您可能需要确保它以正确的绝对路径结束，否则可能不会正确编译.

创建工作区后，它会询问(步骤 7)您是否希望使用更改更新工作区.这是正确的计划，但我不相信它 - TFS 会记住它认为您在工作区的每个文件夹中有什么，所以如果它被您过去做过的任何事情弄糊涂了，它可能会决定您有一些的源代码已经而不是更新它.因此，为了在此步骤中防弹，单击否"，然后手动转到源代码管理资源管理器，右键单击根文件夹并执行获取特定版本".然后勾选这两个复选框以使其获取所有文件(即使它认为您拥有它们)并强行覆盖所有内容(甚至可写文件)，您将确保获得源代码的完整副本.

在 (9) 处，您需要从映射的工作区(本地驱动器)打开解决方案.转到 File > Source Control > Change Source Control 并检查解决方案是否已绑定.如果没有，请选择所有内容并单击绑定.这是解决所有问题的神奇按钮，宇宙中没有人了解这个用户界面，为什么它在那里，为什么它如此复杂，以及为什么对话框上的其他选项从不用于任何事情时都不存在.绑定所做的一切就是写下您在本地磁盘上获得解决方案的位置，这样您就会有一种空虚的感觉，并暗示这应该可以正常工作，而您不必在对话框中像这样搞砸如果您正在使用源代码管理中的某些内容并且处于在线"模式，那么做一些应该自动发生的事情是没有意义的.

此绑定过程应该意味着您现在所做的任何编辑都会自动检出受影响的文件.(如果没有发生这种情况，请检查工具 > 选项 > 源代码管理以确保您的设置正常)

现在，如果您在编译时遇到错误，可能的嫌疑人是:

• 服务器上的代码未构建.例如有人忘记检查所有依赖项等.
• 服务器上的代码很好，但是您将它映射到 PC 上与原作者不同的位置(例如，您使用了 D:\ 而他使用了 C:)，并且他没有将其设置为可重定位.如果是这样，最快的解决方法是找出他的映射是如何工作的，然后在您的 PC 上准确复制它(提示:您可以在工作区编辑器中查看其他人的映射，然后将它们复制并粘贴到您自己的映射中).真正的解决方案当然是追踪每个损坏的(绝对)文件引用，并使其相对，使解决方案可重新定位.
• 服务器上的代码没问题，但您的工作区映射与您设置 Web 服务器的方式不匹配，然后当 Visual Studio 发现两者不匹配时，您单击了是"(不知道这意味着是的，请为我搞砸一切")而不是不"(我的源代码控制映射中一定有错误，我想我会回去仔细检查一下，谢谢").在这种情况下，仔细检查您的源代码控制映射会将代码放在 Web 服务器认为它会找到的位置，并且(在删除批次、修复映射并执行获取特定版本以强制 TFS 获取一个干净的副本在正确的地方)可能你的很多问题都会消失.
• 服务器上的代码很好，但 Visual Studio 糟糕的参考系统破坏了一些参考.本质上，如果它无法在您告诉它查看的确切位置找到引用的程序集，而不是说错误:它不存在"，而是通过您的 PC 进行一次发现之旅，并选择具有相似名称的其他程序集并说应该这样做".在一小部分情况下 (99%) 把事情完全搞砸了，而在剩下的 1% 中，他们只是完全破坏了它们.查看错误列表的位置通常位于底部 - 最后一个错误通常是失败的引用，而前面的 1000 个错误只是副作用.此外，请检查每个项目的参考文献是否有黄色感叹号图标 - 这些是缺少的参考文献.最后，如果您引用了导致莫名其妙的构建错误的 MyAssembly.dll 或MyAssembly"项目，请在您的硬盘驱动器中搜索MyAssembly.dll".当您在整个构建项目中发现该 dll 的 3,245 个副本时，删除除正确"之外的所有副本，然后查看您的构建成功率是否有所提高.除此之外，您只需阅读错误并一一解决.

恐怕要从这么远的地方得到准确的答案并不容易，但希望这至少可以确认您的基本想法是正确的，并且可能会给您一些线索来帮助您诊断您的痛苦.我的钱会花在工作区映射上，这与所有东西只需点击到位所需的魔法设置略有不同，让你惊呆了，想知道为什么你只需要花 3 天时间来解决这样一个噩梦般的问题却发现你从来没有超过 3 个字符，距离迷宫中心只有一个斜线.

从您的第 9 步中的线索来看，它可能类似于

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

而不是

$/TLog ->C:\TLog

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):

解决方案

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

这篇关于如何在 TFS 中重新绑定我的项目?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！