我的团队构建了一个基于 .NET 的软件和其他几个组件。目前使用 TeamCity 进行持续集成，MSBuild 用于简单地编译 .sln 文件（以及其他一些小任务，例如单元测试）。
我们的源代码控制以某种方式构建，使得 repo 包含许多在单次提交后编译的小型“插件”项目。
这使得仅构建更改的组件变得困难，而且以后仅交付那些作为构建工件的组件。
诸如将构建目标设置为“构建”而不是“重建”之类的解决方案可能会有所帮助，但它似乎有点过于脆弱，尤其是在处理可能在任意数量的构建“代理”上进行构建的分布式构建环境时，甚至那些没有以前的编译输出的。
我想知道解决这种情况的正确方法是什么？显然，这是一个已知问题，可能已经被许多人处理过。
我们希望构建和交付（每次构建）一组由当前构建（通过代码签入）修改的 DLL/组件。
我们可以实施哪些技术来实现这一目标？
这被称为增量构建，并且长期以来一直是 SCM 流程的一部分。您的 Nant/msbuild 脚本应该能够从 CLI 进行增量构建和完整构建，否则它不被称为发布过程的完整独立构建设置。
将这些脚本连接到 CIE，如 buildforge、jenkins、cnuisecontrol 等。
实现这一点的最佳方法是在 Nant/Ant/msbuild 中使用一个开关，这样当您运行增量构建时，它不会删除旧的二进制文件，而是只编译最新的更改以创建与代码更改相关的二进制文件。
RTC Enterprise build 确实有一个功能，它会在成功编译后构建本地工作区之后，将交付后交付到您的流/分支，包括增量构建和完整构建。
但是我建议我们使用构建脚本来实现这一点，而不是尝试通过 CIE 工具来实现，以便开发利益相关者可以完全控制他们的构建和打包逻辑，并消除对构建工程师（第三方独立实体）的依赖了解应用程序的编译逻辑，并将从大多数固有问题（如错误构建、人为错误等）中节省大量时间。
一种解决方案是“构建”而不是“重建”。如果构建在多个代理上运行，则在构建过程结束时将构建工件存档在共享位置，并在下一次构建开始时将这些工件复制到构建工作区（即，在他结束时自动归档工件）在构建开始时构建并复制它）。第一个构建将失败，因为将没有要复制的工件......因此保持该步骤在失败时继续或之前手动创建。运行他首先构建。这肯定会使他的构建时间增加一两分钟......所以确保共享位置与您的构建代理在同一个网络中......
您可能需要重组您的源代码控制，以便每个插件都位于自己的小项目中。他们都引用的共享代码将在它自己的项目中生成通用 DLL。
Liora 提到了一个资产存储库。这很重要，因为它将为您提供一个存储所有这些小库的地方。在 .Net 领域，我听到越来越多关于 NuGet 的消息。
这个想法是，当插件发生更改时，您的 CI 系统将接受它，拉入任何公共/共享库，然后执行构建，发布该插件的新版本。当共享代码更改时会发生什么更有趣。您可能只是构建它，或者您可能触发其所有依赖项的构建。
几年前，我在一篇关于减少构建管理痛苦的文章中谈到了这一点：http ://www.urbancode.com/html/resources/articles/build-pain-relief/components.html
我不确定我遇到了正确的问题。但是，据我所知，您需要使用某种资产库来管理您的构建结果工件。更新资产后，可以配置后续操作。
让我知道这是否能解决您的问题。
利奥拉