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

Question

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

visual-studiovisual-studio-2010msbuildbuild

7

我有一个庞大的解决方案，包含320个项目。即使对单个Web表单进行小修改，也会导致长时间的构建时间以测试/调试小的更改。我怀疑后构建文件复制任务“触碰”文件日期并导致多次重建。

在没有任何强命名和版本控制影响的情况下，VS 2010运行重建的其他原因是什么？

补充说明：我对源树的大小或形状没有直接影响。它是稳定核心产品的主干，任何短期的“非业务”更改都被认为是有风险或成本高昂的。我将提出在此处收到的答案作为项目未来方向的输入点。

- ProfK

1

我不知道如何具体解决你的重建问题，但在一个解决方案中有320个项目并不是一个好主意。如果我是你，我会发布一个问题，详细说明这些项目的类别，它们之间的一般依赖关系，并询问使它们可管理的最佳方法。 - Binary Worrier

我的天啊，320个项目？我曾经做过10个，都难以承受。非常非常抱歉。为了帮助解决这个问题，您可以创建多个解决方案或使用像psake这样的工具手动构建流程，仅针对特定情况精简必要的项目。 - George Mauer

5个回答

2

你可以尝试使用msbuild和/v:d（用于诊断日志记录）构建解决方案。

日志中可能会有提示，说明为什么项目不是最新的。

- Arve

1

我认为在320个项目上，您早已超过了Visual Studio舒适设计的限制。这里有很多好建议，但如果您确实必须保留320个项目，您可能需要放弃使用Visual Studio进行构建和设计自己的构建过程。就像我在评论中说的，在Windows上，我的建议是使用psake作为构建工具，它是基于PowerShell构建的（因此包含在每台现代Windows机器上），非常强大且轻量级，足以将整个过程提交到源代码控制中。

- George Mauer

0

首先，请确保对其他项目的引用是“项目引用”，而不是“程序集引用”。

其次，请检查是否存在循环引用。

第三步，将日志详细程度设置为“诊断级别”，并查看第一行，了解为什么在第一次构建解决方案后会重新构建项目。

还有很多可以检查的内容，但首先请查看这3个事项。

- Antebios

0

320个项目在依赖树中是很多的文件：所有这些文件都需要由构建引擎检查更改。使用类似Process Monitor的工具将允许您查看正在进行的文件操作以确认此事。

此外，运行时加载320个程序集（除了.NET框架程序集）会减慢应用程序的速度，并且真正减慢调试器的速度（需要加载大量符号）。请查看“调试”|“窗口”|“模块”以查看已加载的模块。

除了减少解决方案中的项目数量（完全可以有多个解决方案，每个解决方案都有一部分项目），您真的需要那么多单独的项目吗？在调试器之外，.NET加载器仅在需要时从程序集中加载和JIT代码，较大的程序集不意味着更慢的加载时间，并避免了来自Windows加载器的每个程序集的开销。

- Richard

我相信他们可以通过一个 post-build ILMerge 步骤来解决最后一个问题。 - George Mauer

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Jason Williams · Accepted Answer

C#会因为文件被更改或依赖项更改而进行重建，但也经常出现“毫无明显原因”的情况。你可以连续构建2或3次，而不做任何更改，C#将开始重建大量的代码。

打开工具>选项>项目和解决方案>生成和运行>仅在运行时构建启动项目和依赖项。这将最小化构建，只构建您打算执行的项目的依赖项，因此，除非所有内容都是一个庞大的依赖树，否则将显着减少构建中考虑的项目数量。

然而，更好的解决方案是避免首先要求编译。

每个项目都会增加构建的额外开销。在我的电脑上，大约是3秒钟。通过将两个项目的代码合并到一个.csproj文件中，我可以节省3秒的构建时间。因此，对于300多个项目，您可以通过合并项目来缩短10分钟的构建时间 - 即尽可能使用一个程序集中的多个模块/命名空间而不是多个程序集。你会发现应用程序启动时间也得到了改善。
许多项目并不需要一直进行构建。将它们拆分为库项目，并只链接（引用）二进制文件。
还要禁用“复制本地”功能，而是将所有OutputPaths指向共享文件夹 - 这将通过避免在硬盘上制作320个dll的320个副本来显著减少开销。
添加新的构建配置（例如“Debug FastBuild”），仅构建您实际正在工作的程序集。使用配置管理器，您可以取消勾选不想构建的项目，然后就会被构建系统忽略掉。从源代码获取代码后，建议进行完整的“Debug”构建以刷新所有内容，然后切换回“fastbuild”