与 VS 和 TFS 共享项目
我在使用 VS 2010 和 TFS 2010 的解决方案之间共享项目时遇到了很多问题。
第一个问题是每个人都以不同的方式设置自己的计算机，并以不同的方式创建工作区。有些对所有项目使用一个工作区。有些为每个项目使用不同的工作区。当您将两个不同的项目从树的不同部分放入解决方案时，它们不一定映射到 TFS 树结构（通常也不会）。
因此，一个人可能有：
C:\Users\User\Documents\Projects\Project1
C:\Users\User\Documents\Projects\Project2
另一个人可能有
C:\Users\User\Documents\Projects\Project1
C:\Users\User\Documents\SharedProjects\Project2
另一个人甚至有
C:\SharedProjects\Project2
C:\Projects\Project1
问题在于，该解决方案保留了物理项目位置，每次用户获取最新版本时，他们都会争吵并产生有关项目位置的冲突。
我知道，简单的解决方案是强制使用单一结构，但这在这里行不通。
第二个问题：
我们有一些共享库，这些项目包含在我们树中的不同解决方案中。其中一些项目具有不同的构建配置。一种可能有开发、测试、阶段、生产，另一种可能有调试、发布、生产。
这会导致问题，因为构建配置存储在项目文件中。如果一个项目尝试使用共享项目，并且共享项目不包含与解决方案相匹配的构建配置，则 VS 会锁定并导致各种奇怪的行为。
有人有解决这些问题的办法吗？有没有办法为不影响所有用户的位置创建本地覆盖？ （类似于为每个用户设置 Web 服务器配置的方式）
似乎这些问题现在应该已经解决了。
I'm running into a lot of problems sharing projects between solutions with VS 2010 and TFS 2010.
First issue is that everyone sets up their machine different, and create workspaces differently. Some use a single workspace for all projects. Some use a different workspace for each project. When you put two different projects into a solution from different parts of the tree, they don't necessarily map to the TFS tree structure (and generally don't).
So one person might have:
C:\Users\User\Documents\Projects\Project1
C:\Users\User\Documents\Projects\Project2
Another might have
C:\Users\User\Documents\Projects\Project1
C:\Users\User\Documents\SharedProjects\Project2
Another even does
C:\SharedProjects\Project2
C:\Projects\Project1
The problem is that the solution holds physical project locations, and everytime users get latest, they fight and create conflicts about project location.
I know, the easy solution is to mandate a single structure, but that's not going to work here.
Second problem:
We have some shared libraries that are the projects are included in different solutions across our tree. Some of these projects have different build configurations. One might have Dev, Test, Stage, Prod and another has Debug, Release, Prod.
This causes problems because the build configurations are stored in the project files. If a project tries to use a shared project, and the shared project does not contain a build configuration to match the solution, then VS locks up and causes all kinds of weird behavior.
Does anyone have any solutions to these problems? Is there any way to create local overrides for locations that do not affect all users? (Similar to the way you can set web server configurations on a per user basis)
Seems like these problems should have been figured out by now.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
建议 1 - 将解决方案文件与实际构建系统分开使用...阅读下面的 MSBuild 最佳实践文档的“构建大型源树”部分
http://msdn.microsoft.com/en-us/magazine/dd483291.aspx
建议 2 - 严格执行您所说的不能执行的操作...强制执行某种表面上的一致性。提供 TFS 工作区模板和/或说明“构建批准”配置。在某些时候，人们必须购买这些东西，否则它就行不通。
Recommendation 1 - seperate usage of solution files from your actual build system... Read the "Building Large Source Trees" section of this MSBuild Best Practices document below
http://msdn.microsoft.com/en-us/magazine/dd483291.aspx
Recommendation 2 - Do exactly what you said you couldn't do... Enforce some semblance of uniformity. Provide a TFS workspace template and/or state the 'build-approved' configurations. At some point people have to buy into this stuff or it's just not going to work.
我有同样的问题。建设这些项目花了很长时间。我创建了主解决方案，它托管所有 Web 应用程序和类库，只是为了构建，并且使用它确实改进了构建时间。
你可以参考这篇文章，也许对你有帮助。
大型项目的 TFS 构建策略
I had the same issue. It was taking so long to build the projects. I created master solution that hosts all web app and class library just for build and build time is really improved using that.
You can refer this post it might helps you.
TFS Build strategies for large projects