C#,TeamCity-避免在TeamCity服务器上执行生成后事件

据我所知,您使用XCopy将生成输出复制到外部文件夹,以便依赖解决方案可以将输出用作程序集引用。您已经正确地发现使用构建后事件和XCopy是错误的,因为它开始给您带来痛苦。我们在我们的API解决方案中有一个类似的目标,我将试着描述我们使用我们的解决方案所做的事情,但请记住,没有银弹,有时仍然需要妥协。

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

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

• 根
• 箱子 -bin是构建的输出应该去的地方。这可能只有当您有多个输出时才相关,如果您只有一个输出,比如一个web项目,它可以保持在原来的位置。我没有找到使用子文件夹进行调试和发布生成的理由。
• 建造 -包含生成文件,如用于生成源、运行测试、代码覆盖率、代码分析、文档等的MSBuild或NAnt脚本。
• -包含项目输出所依赖的所有外部或内部第三方库。我通常为每个库使用子文件夹,但我不确定是否真的需要。
• src公司 -包含在所选IDE中打开项目、编辑、生成和运行所需的所有文件。尽量保持结构的扁平化,没有必要让它变得过于复杂,因为其他开发人员不太可能像您那样有条不紊,您最终将项目放在错误的文件夹中。我做的最多的事情就是为所有的测试创建一个测试文件夹,但这并不是真正需要的。
• 工具

文件路径

项目中与的所有文件路径都应是相对的。一旦你开始使用绝对文件路径,你就会开始感到痛苦。如果开发人员的源代码位于不同的驱动器上,或者在运行项目的地方很难强制执行的生成服务器上,则会出现问题。

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

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

从外部项目引用程序集

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

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

您可以在生成配置或生成代理配置中定义环境变量,并仅在未按如下所述设置该变量时触发copy命令: Suppressing Post-build Events

你可以用自己的程序替换xcopy,比如myXCopy

然后可以控制何时设置此环境变量。

编写自己的MsBuild任务来进行复制。
将任务挂接到标准编译任务的末尾