Question

我遇到了很多问题，在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

问题在于解决方案包含物理项目位置，每次用户获得最新信息时，他们都会对项目位置进行斗争并产生冲突。

我知道，简单的解决方案是强制要求一个单一的结构，但这不会起作用。

第二个问题：

我们有一些共享库，这些项目包含在我们树中的不同解决方案中。其中一些项目具有不同的构建配置。一个可能有Dev，Test，Stage，Prod和另一个有Debug，Release，Prod。

这会导致问题，因为构建配置存储在项目文件中。如果项目试图使用共享项目，并且共享项目不包含与解决方案匹配的构建配置，则VS会锁定并导致各种奇怪的行为。

有没有人对这些问题有任何解决方案？有没有办法为不影响所有用户的位置创建本地覆盖？（类似于基于每个用户设置Web服务器配置的方式）

似乎这些问题应该已经解决了。

Answer 1

建议1 - 从实际构建系统中单独使用解决方案文件...阅读下面的MSBuild最佳实践文档的“构建大型源树”部分
http://msdn.microsoft.com/en-us/magazine/dd483291.aspx

建议2 - 完全按照你所说的做不到的事情......强化一些相似性。提供TFS工作区模板和/或说明“构建批准”配置。在某些时候，人们不得不购买这些东西，或者它不会起作用。

Answer 2

我有同样的问题。建造这些项目需要很长时间。我创建了主要解决方案，托管所有Web应用程序和类库只是为了构建和构建时间真的改善使用它。

你可以参考这篇文章，它可能对你有帮助。