0

我在使用 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 服务器配置的方式)

看来这些问题现在应该已经解决了。

4

2 回答 2

1

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

建议 2 - 做你说你不能做的事... 强制执行一些表面上的统一性。提供 TFS 工作区模板和/或说明“已批准构建”配置。在某些时候,人们必须购买这些东西,否则它就是行不通的。

于 2011-09-28T22:58:22.953 回答
0

我遇到过同样的问题。建造这些项目花了很长时间。我创建了托管所有 Web 应用程序和类库的主解决方案,仅用于构建和构建时间使用它确实得到了改进。

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

大型项目的 TFS 构建策略

于 2012-04-03T20:09:52.257 回答