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

Question

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

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

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

谢谢.

编辑:

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

Answer 1

据我了解，您正在使用 XCopy 将构建输出复制到外部文件夹，以便依赖的解决方案可以使用输出作为程序集引用。您正确地发现使用构建后事件和 XCopy 是错误的，因为它开始给您带来痛苦。我们在 API 解决方案中也有类似的目标，我将尝试描述我们的解决方案，但请记住，没有灵丹妙药，有时仍然需要妥协。

项目结构

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

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

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

文件路径

项目中的所有文件路径都应该是相对的。一旦您开始像示例中那样使用绝对文件路径，您就会开始感到痛苦。在开发机器上会出现问题，因为开发人员的源代码位于不同的驱动器上，或者在构建服务器上，很难强制执行项目的运行位置。

一般的经验法则是项目应该是独立的。在完美的世界中，不应该依赖于根文件夹之外的任何内容。有时这很困难，特别是在遗留项目或有 com、注册表或服务需求的情况下，但只要稍加思考和返工，大多数问题都可以得到缓解。最终，您希望能够尽可能轻松地将项目放到给定的机器上并运行它。

构建输出

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

从外部项目引用程序集

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

我有几种方法可以克服这个问题：

1. 使用 Git 的子模块或 SVN 的外部之类的东西让 API 项目成为主项目内的子项目。这在某种程度上有效，但您需要采取一些预防措施，互联网上有丰富的知识。
2. 将程序集添加到依赖项目的 lib 文件夹中，并将它们视为第三方程序集，这才是它们真正的样子。

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