C#项目在Visual Studio中重建的原因

Pro*_*ofK 6 msbuild build visual-studio-2010 visual-studio

我有一个大型解决方案,包括大约320个项目,即使对单个Web表单进行微小更改,也会导致构建时间过长,无法测试/调试一个小的更改.我怀疑构建文件复制任务是为了"触摸"文件日期时间并导致多次重建.

在没有任何强大的命名和版本控制影响的情况下,除了源文件比二进制输出文件更新之外,VS 2010还有其他原因可以运行重建吗?

附录:我对源树的大小或形状没有直接影响.它是稳定核心产品的主干,任何短期"非业务"变更都被视为风险和成本高昂.我将在这里收到的答案中提到的要点作为项目未来方向的输入.

Jas*_*ams 22

C#rebuilds因为文件已被更改,或者依赖项已被更改,但也经常因为"没有明显的原因".您通常可以连续构建2到3次而无需进行任何更改,C#将会关闭并重建大量代码.

启用工具>选项>项目和解决方案>构建并运行>仅在运行时构建启动项目和依赖项.这将最小化仅针对您要执行的项目的依赖项的构建,因此除非所有内容都是一个大型依赖树,否则这将显着减少构建中考虑的项目数.

然而,更好的解决方案是避免要求它首先编译.

  • 每个项目都会为构建增加额外的开销.在我的电脑上,这大概是3秒钟.通过将两个项目的代码合并到一个.csproj文件中,我节省了3秒的构建时间.因此,对于300多个项目,您可以通过合并项目来缩短构建时间10分钟 - 即在可能的情况下在一个程序集中使用许多模块/名称空间而不是许多程序集.您会发现您的应用程序启动时间也得到了改善.

  • 许多项目不需要一直建设.将它们作为库项目分解出来,然后链接到(引用)二进制文件

  • 同时禁用"复制本地",而是将所有OutputPath指向共享文件夹 - 这将通过避免在整个硬盘驱动器上制作320个dll的320个副本来显着减少开销.

  • 添加新构建配置(例如"Debug FastBuild"),仅构建您实际正在处理的程序集.使用配置管理器,您可以取消不想构建的项目,并且presto,构建系统会忽略它们.从源代码控制中获取代码后,构建一个完整的"Debug"构建来刷新所有内容,然后切换回"fastbuild"