Visual Studio / TFS 2010 / 获取最新版本 / 某些编译失败，但其他编译失败，并出现引用错误
设置：
<块引用>
- 所有开发均在虚拟服务器 (Win Server 2003) 上完成
- 所有编译均在 VS 2010 中完成
- 所有代码均已签入 TFS 2010
我们正在将解决方案从 VS 2008 迁移到 VS 2010。我创建了一个 MAIN 分支文件夹来包含转换后的 VS 2010 项目。然后我开始进行分支工作，从 2008 年开始迁移项目。编译（最终）成功了。另一位开发人员正在同一分支上处理其他项目。
然后，我们也通过 TFS Build 2010 编译所有这些项目。
这是我们的主分支。然后，另一位开发人员创建了一个 DEV 分支文件夹，并将所有解决方案从 MAIN 分支分支到 DEV 分支以进行持续开发。
令我们惊讶的是，我们发现，虽然如果我们在 MAIN 分支上执行 getlatest 操作，我们就可以编译代码，但当我们在 DEV 分支上执行 getlatest 操作时（假设是相同的代码），一些我们（我们称他们为不幸的开发人员）遇到了大量与解决方案中包含的项目引用有关的错误。但是两个开发人员（幸运的）编译得很好。当两个不幸的开发人员编译单个项目（导致引用错误的那个）时，它构建得很好，但是当我们构建解决方案或引用时项目，它因引用该项目而失败。
我们尝试清理我们的工作区并重新编写代码 - 但没有什么乐趣。
创建分支的幸运者也做了同样的事情（删除了他们的工作区，获取了最新版本并运行了编译）并且它仍然可以编译。然后，我们让一位未参与迁移的开发人员获取最新版本并运行编译。他们的编译也运行得很好！这使我们相信它一定是计算机。
然后，我们让一位不幸的开发人员登录到一位幸运的开发人员的虚拟环境，并使用他们自己的工作区执行获取最新版本和构建操作。这也失败了。因此，该虚拟环境在一个用户下有一个工作区成功，而在另一用户下有一个工作区无法编译相同代码的最新版本。
然后...我们将工作工作区与幸运开发人员的虚拟工作区和附加到它的不幸开发人员之一分离（没有获取，只需编译那里的内容）。编译得很好。
所以感觉我们这些不幸的开发者身上可能有某种特征，导致我们的 Gets 有所不同。我刚刚意识到的一个区别是，我们两个不幸的人在 2008 版本的 TFS 中保存了搁置集（但在 TFS 2010 下）。
好吧，然后...同一个不幸的开发人员通过删除文件来清除幸运者的工作区，然后执行获取特定/最新/两个强制覆盖开关打开。这样就编译成功了！！
然后他又回到原来的虚拟机。他删除了工作区中的文件，并打开了“获取特定/最新/两个强制覆盖”开关。 这次编译再次失败！
我们已经没有想法了...
setup:
- all development being done on virtual servers (Win Server 2003)
- all compiles being done in VS 2010
- all code checked into TFS 2010
We are migrating our solutions from VS 2008 to VS 2010. I created a MAIN branch folder for containing our converted VS 2010 projects. I then branched over and worked through getting projects migrated from 2008. The compiles were (eventually) successful. Another developer was working through other projects on the same branch.
We then got all of these projects compiling also through TFS Build 2010.
This is our MAIN branch. Another developer then created a DEV branch folder and branched all of the solutions from the MAIN branch to the DEV branch for ongoing development.
Much to our surprise, we found that though we could compile the code if we did a get latest on the MAIN branch, when we did a get latest on the DEV branch (supposedly the same code), some of us (we'll call them the unlucky developers) got a slew of errors having to do with a reference to a project contained in the solution. But two developers (lucky) had it compile just fine. When the two unlucky ones compile the individual project (the one causing the reference error) it builds fine, but when we build the solution or the referencing project, it fails with the reference to that project.
We tried wiping out our workspace and doing a get on the code fresh - no joy.
The lucky person who created the branch did the same (deleted their workspace, did get latest and ran a compile) and it still compiles. We then had a developer that hadn't been involved in the migration do a get latest and run a compile. Their compile ran just fine too! This led us to believe that it must be the computer.
So then we had one of the unlucky developers log into one of the lucky developer's virtuals and perform a get latest and build using their own workspace. This also failed. So this virtual has one workspace under one user that succeeds, and one under another user that fails to compile for the same get latest on the same code.
Then... we detached the working workspace from the lucky developer's virtual and one of the unlucky devs attached to it (no get, just compile what's there). That compiled fine.
So it feels like we may have some sort of characteristic attached to us unlucky devs that are causing our Gets to be different. One difference I just realized is that we two unlucky ones have shelvesets that we saved in TFS in the 2008 versions (but under TFS 2010).
OK, Then... the same unlucky developer wiped out the lucky one's workspace by deleting the files and then performed a get specific / latest / both force overwrite switches turned on. This compiled successfully!!
Then he went back to his original virtual machine. He deleted the files in his workspace, and did a get specific / latest / both force overwrite switches turned on. This compile again failed!
We're running out of ideas...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
听起来（不幸的）开发人员可能有自定义工作区映射（确定 TFS 中的哪些文件夹在硬盘上的哪个位置检出）。
查看->团队资源管理器 ->源代码控制 ->单击“工作空间”上的下拉列表，然后选择“工作空间...”
删除其中的所有工作空间（或至少验证它们）。
创建一个新的工作区并在根级别签出（以保持项目引用完整）
Sounds like the (unlucky) developers may have custom workspace mappings (determines which folders in TFS are checkedout where on the hard disk).
View -> Team Explorer -> Source Control -> Click the dropdown on Workspace and select Workspaces...
Delete all the workspaces there (or at least verify them).
Create a single new workspace and checkout at the root level (to keep project references intact)
好吧，我们又被咬了。 这个问题与源代码的路径长度有关。当然，实际错误中没有表明这一点。这可能是我第 8 次遇到这种情况。当试图保持名称空间有意义时，必须不断修剪这些路径，这是令人沮丧的。
我们已经排除了这种可能性，因为能够编译代码的开发人员的名称比不能编译代码的两个开发人员的名称更长，并且这些名称按设计位于工作区的路径中，以便多个开发人员可以在同一文件上工作根据需要使用虚拟机。
我相信我找到了原因。我将编译设置为“混合平台”，可以编译的设置为“任何 CPU”，也许这在路径中。
解决方案是（再一次 - 这已经变得非常旧）将项目移到几个文件夹中，而不是将其包含在我们希望的位置。这减少了路径中的字符数，编译运行得很好。啊。
Well we got bit once again. The issue had to do with the length of the path to the source code. Of course there is no indication of this in the actual error. This is probably the 8th time I have run into this. It is frustrating while trying to keep namespaces meaningful to constantly have to trim these paths.
We had dismissed this possibility, because the names of the developers who were able to compile the code were longer than the two who couldn't, and the names are in the path of the workspace by design so that multiple developers can work on the same virtual machine as needed.
I believe I found out why. I had my compile set to "Mixed Platforms" and the ones who could compile were set to "Any CPU" Maybe this was in the path.
The solution was (once again - this is getting really old) to move the project down a few folders instead of containing it where we had hoped to. This reduced the number of characters in the path and the compile ran just fine. Ugh.