1

我有 3 个 TFS 构建（2 个开发和 1 个证书）。

我想对构建进行模块化，因此每次更改公共项目时都不必编辑 3 个文件。

我遇到的问题是只有构建文件夹中的项目（在 TeamBuildTypes 下）由 Team Build 自动检索。我可以在构建过程中输入代码来获取其他文件，但到那时为时已晚。

这是我的情况。我为常见任务创建了一个“通用”位置。然后我去对该文件进行了更改。因为文件在我的构建过程告诉它下载之前不会下载，所以它检索得太晚了（导入已经发生并且 MSBuild 过程已经在内存中构建了构建目标）。

我考虑将它添加到构建的工作区，但随后它将在 Get Sources 目标中检索（这也为时已晚）。

我看不到不会让我复制文件或不使用源代码控制的解决方案......

有任何想法吗？

4

2 回答 2

4

在 Team Build 2008 中没有针对此问题的“理想”解决方案，您最好的选择是将常见的东西放在$(MSBuildExtensionsPath)解析到的构建机器上C:\Program Files\MSBuild，然后从那里引用它们。

如果您的构建配置非常相似，您可以：

  1. 将所有构建定义指向一个配置文件夹。
  2. 将通用构建逻辑放入TFSBuild.proj.
  3. 在 TFSBuild.proj 的底部添加<Import Project="TFSBuild.$(BuildDefinitionName).proj" />.
  4. 在 TFSBuild 中添加因构建定义而异的配置。<BuildDefinitionName>.proj.
于 2009-06-11T03:47:24.973 回答
3

您最好的选择是将构建机器上的常见内容放在 $(MSBuildExtensionsPath) 中，解析为 C:\Program Files\MSBuild

我不喜欢依赖“神奇”位置的想法。您最终需要第二次部署 + QA 流程，以保持您的构建脚本同步......

只有构建文件夹中的项目（在 TeamBuildTypes 下）由 Team Build 自动检索。

诚然，有点蹩脚，但我还没有发现它是实践中的主要限制。这是我的 TeamBuild 文件夹的简化视图：

$/TeamProject
   |- Dev
       |- Module1
       |- Module2
       ...
       Solution1.sln
       Solution2.sln
       |- TeamBuild
            |- 3rdparty
                MSBuild.Community.Tasks.dll
                MSBuild.Community.Tasks.targets
                RandomScriptOffTheWeb1.targets
                ...
            |- SrcSrv                
                srcsrv.ini
                ...
            |- SymStor
                dbghelp.dll
                ...
            Common.targets
            TFSBuild.proj
            TFSBuild.Common.targets
            TFSBuild.Config1.targets
            ...
            UtilityScript1.ps1
            ...
   |- Main           
       ...
       |- TeamBuild
       ...
   |- Release
       ...

Common.targets 由所有 *.csproj (etc) 文件导入。它导入我所有的 3rd 方任务，初始化各种全局属性/项目，并设置参考路径。

TFSBuild.proj 导入 Common.targets，然后是 TFSBuild.proj，然后是通过调节 $(BuildDefinition) 的配置文件之一。这样，更具体的总是根据需要从不太具体的文件中覆盖任务/属性/等。尽管如此，这个短文件是我确实感到有限的一个地方：以编程方式将构建名称映射到文件名会更好，但 MSBuild 不会让我使 [declarative] 导入依赖于 [runtime] 目标中设置的属性，例如.

TFSBuild.Config*.targets 文件大部分只设置属性；没有“真正的”工作。这些包括我想要参数化的 Team Build 属性，以及控制我的自定义目标（在其他地方实现）如何工作的其他属性。

TFSBuild.Common.targets 是一个数量级的最长文件。在这里，我使用良好的默认值配置所有 Team Build 属性，覆盖 AfterDropBuild 等目标，并定义许多我自己的自定义目标，这些目标根据 Config* 文件中的设置有条件地执行。

注意：我显然启用了递归下载选项，但这不是严格要求的。将构建依赖项分离到子文件夹中更符合美学要求。

于 2009-06-12T05:24:06.243 回答