2011-09-28 59 views
0

我遇到了很多的问题,VS 2010和TFS共享解决方案之间的项目共享项目2010年与VS和TFS

第一个问题是,每个人都建立了自己的机器不同,不同的创建工作。有些为所有项目使用单个工作区。有些人为每个项目使用不同的工作区。当你将两个不同的项目放入树中不同部分的解决方案中时,它们不一定映射到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服务器配置的方式)

似乎这些问题现在应该已经弄清楚了。

回答

1

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

建议2 - 究竟你说过你做不到的事情......强调一致性。提供TFS工作空间模板和/或说明“构建批准”配置。在某些时候,人们不得不购买这些东西,否则它就无法工作。

0

我有同样的问题。建设项目花费了很长时间。我创建了主控解决方案,其中托管所有的Web应用程序和类库,仅用于构建,而构建时间使用该方法得到了很大改善

你可以参考这篇文章,它可能会帮助你。

TFS Build strategies for large projects