C＃，TeamCity - 避免在TeamCity服务器上发布后期构建事件

Question

我有许多项目，我已经在我的开发环境中输出到DLL的中央存储库。 这是通过将XCopy命令添加到项目的Post-build事件命令行来实现的。

XCOPY $(TargetDir)$(TargetFileName) C:\DEV\library /I /R /Y

我希望这在dev模式下发生，但是当在TeamCity服务器上时，我想避免脚本被执行。 这样做的最佳方式是什么？ 我将搜索谷歌和文档，但希望其他人以类似的方式使用TeamCity，并可以建议如何实现。

谢谢。

编辑：

XCopy应该将dll复制到一个中央文件夹（C：\\ DEV \\ library），依赖于它们的外围项目可以访问。 事实上，我已经从项目中删除了xcopy，因为我觉得它更像是一个黑客而不是帮助它使用它。 感觉就像我正在把一个方形钉子压成一个圆孔。

Answer 1

您可以在构建配置或构建代理程序配置中定义环境变量，并仅在未设置变量时触发复制命令，如下所述： 抑制构建后事件

Answer 2

据我所知，您使用XCopy将构建输出复制到外部文件夹，以便依赖解决方案可以将输出用作程序集引用。 你已经正确地发现使用post build事件和XCopy是错误的，因为它开始让你感到痛苦。 我们在API解决方案中有类似的目标，我将尝试描述我们对我们的处理方式，但请记住，没有银弹，有时仍需要妥协。

项目结构

项目结构不是Visual Studio中的结构，而是如何组织项目所需的源，库和其他外部项，此模式可以应用于大多数语言。 项目结构应清晰，易于理解并在所有项目之间保持一致。 我使用的结构与许多开源项目一致，通常由以下内容组成。

- root
|-- bin
|-- build
|-- lib
|-- src
|-- tools

• root - 根应包含尽可能少的项目。
• bin - bin是构建输出的位置。 这可能仅在您有多个输出时才有意义，如果您只有一个输出，例如Web项目，它可以保持原样。 我没有找到使用子文件夹进行调试和发布版本的理由。
• build - 包含构建文件，如MSBuild或NAnt脚本，用于构建源代码，运行测试，代码覆盖率，代码分析，文档等。
• lib - 包含项目输出所依赖的所有第三方库（外部或内部）。 我通常为每个库使用子文件夹，但我不确定我是否真的需要。
• src - 包含在您选择的IDE中打开项目，编辑，构建和运行所需的所有文件。 尽量保持这里的结构尽可能平坦，没有必要试图让它太复杂，因为其他开发人员不太可能像你一样有条不紊，你最终会在错误的文件夹中找到项目。 我所做的最多的是为所有测试创建一个测试文件夹，但即便这样也不是必需的。
• tools - 它包含构建所依赖的所有应用程序，程序集和外部文件，但源不应依赖于任何源，因为它的依赖项在库上。

文件路径

项目中的所有文件路径都应该是相对的。 一旦开始使用绝对文件路径，就像在示例中一样，您将开始感到痛苦。 开发机器上会出现问题，开发人员的源代码位于不同的驱动器上或构建服务器上，在运行项目的地方执行起来要困难得多。

一般的经验法则是项目应该是自包含的。 在一个完美的世界中，根本不应该依赖于根文件夹之外的任何东西。 有时这很难，特别是在遗留项目或您有com，注册表或服务要求的地方，但只需要一点点思考和改造，其中大部分都可以减轻。 最终，您希望能够尽可能轻松地将项目放到给定的计算机上并运行它。

构建输出

当我做一个API项目时，我将项目的输出放入上面提到的bin文件夹中。 您在构建后事件期间使用XCopy完成了此操作。 这没有错，因为它会做你想要的，但使用Visual Studio有一个更好的方法。 如果转到项目属性的构建部分，则可以更改输出的位置。 请记住在更改之前选择所有构建配置。

引用外部项目的程序集

将API分离到其解决方案并将输出引用为程序集引用而不是项目引用的原因之一是因为解决方案变得太大或者您需要从多个解决方案中引用它们。 如上所述，项目不应该依赖于项目根目录之外的任何内容。 因此，您不应该依赖外部项目的输出，因此依赖于A.开发人员计算机上存在的项目和B.位于正确位置的项目。

我有几种方法可以解决这个问题：

1. 让API项目成为主要项目中的子项目，使用Git的Sub Modules或SVN的Externals。 这在某种程度上有效，但您需要采取一些预防措施，互联网上有丰富的知识。
2. 将程序集添加到依赖项目的lib文件夹中，并将它们视为第三方程序集，这就是它们的真实含义。

第二步是我的首选根，这可以在构建服务器上自动完成，也可以通过将构建服务器的输出本地复制到项目中来手动完成。 这完全取决于您是想要持续集成还是定期集成。

Answer 3

你可以用你自己的程序替换“xcopy”，比如myXCopy
myXCopy可以检查环境变量以决定是否应该复制。
然后，您可以控制何时设置此环境变量。

要么

编写自己的MsBuild任务来执行复制。
将您的任务挂钩到标准编译任务的末尾
使teamcity传递自定义任务检查的MsBuild变量