改善CI构建时间（.NET）我们正在开发一个使用TeamCity作为CI服务器的应用程序框架+“插件”。项目详细信息4个VisualStudio解决方案~70个项目（正在增加）当前使用TeamCity运行2个构建：CI和FULL构建。CI-在每次提交时触发。全部-每晚运行。我想提高两个构建的性能（尤其是CI构建，因为它需要尽快提供输出）。是否有关于可以有效且轻松地改进哪些内容的指南？构建过程只是构建一个.sln文件并运行一些单元测试。考虑方向：不确定这些是否适用/是否会带来性能提升。我正在寻找更多方法来缩短构建时间（大约需要3-4分钟）。最小化ci构建的工作。我正在开发一个500多个项目的C#应用程序。项目在copylocal设置为false的情况下并行编译。在没有单元测试和代码覆盖的情况下，编译时间约为37分钟。增量构建耗时13分钟，无需对代码进行任何更改。如果我关闭并行编译并将copylocal设置为true，编译时间>1h40min。我有不同的本地构建配置、门控签入构建和使用部署阶段（每晚构建）的服务器构建。这是我的经验：如果您想在不将CopyLocal设置为false的情况下并行构建项目，则将输出文件复制到目录不是一个好主意。当多个项目引用同一个程序集而MSBuild尝试同时将此引用复制到输出文件夹时，我的程序集有时会被锁定。这个解决方案对我很有帮助。我将所有引用的copylocal设置为false，我的构建目录大小减少了10倍（I/O减少了10倍）。我对本地构建和服务器构建有不同的设置。用于门控签入构建和完全部署构建的不同设置。如果我启用并行构建，构建速度会越来越快。如果您有强大的构建服务器，那么/m:2构建应该比/m:1构建快2倍。它与项目之间的依赖关系无关（如果copylocal设置为false）。如果你想做快速增量构建，你应该减少项目之间的依赖。它对完整构建没有影响（copylocalfalse）。增量编译时间取决于构建树中更改的项目位置。是的，MSBuild使用依赖项目的时间戳来确定项目是否需要重建。它将输入文件（代码文件、引用程序集、临时文件...）时间戳与输出程序集进行比较。如果有什么改变，你的项目将被重新编译。尽量减少项目之间的依赖关系，以尽量减少重新编译。如果您的更改仅在项目的“私有”部分，输出程序集将被更改，程序集时间戳将被更改，所有依赖项目也将被重建。你不能这样做。运行构建2次，诊断冗长，无需更改代码，并像我在此处描述的那样对“构建目标”CoreCompile进行“完整”检查。你可能是工程文件出错了，每次都会重新编译工程。如果您不做任何更改，构建日志不应包含“构建目标”CoreCompile“完整”日志。我们的构建服务器是虚拟机，而不是真实的硬件。将VM用于构建服务器不是一个好主意，但这不是我的决定。如果您有多个GB的RAM，请尝试将其中的一些用作内存硬盘驱动器。您的构建应该更快:)SSD驱动器每天都对高I/O敏感。影响保修。希望它对某人有所帮助...;)每晚构建不太容易受到构建时间缓慢的影响，因此您应该专注于优化由签入触发的构建。我们遇到了同样的问题并发现以下内容可以提供帮助：只构建您更改过的内容。这意味着将您的项目拆分成更小的项目。在Debug或Release（不是两者）中构建解决方案。让夜晚建造两者。保持单元测试小而快，以便为开发人员提供快速反馈。只在夜间构建中保留非关键任务（文档、更长的自动化测试等）。链接所有相关配置，因此当您的构建成功时，它们会构建最新的更改；如果依赖配置失败，那么您会立即知道更改没有与现有代码集成。我们尝试了并行MSBuild，但我不记得它是否给了我们更多；可能是因为我们有代理。此外，签出/签入时间对总时间有很大影响，因此可能正在使用VCS，因此仅检查更改的文件会有所帮助。将CopyLocal设置为false当然可以节省时间。此外，使用RAM磁盘也是一个好主意，减少项目数量（如果可能，将它们合并）参考：http://blogs.microsoft.co.il/blogs/arik/archive/2011/05/17/speed-up-visual-studio-builds.aspxhttp://www.simple-talk.com/content/print.aspx?article=1237以上就是C#学习教程：改善CI构建时间（.NET）的全部内容，如果各位有兴趣的大家有用，需要多了解C#学习教程。希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
