我有一个大型解决方案，包括大约320个项目，即使对单个Web表单进行微小更改，也会导致较长的构建时间来测试/调试一个小的更改。我怀疑构建文件复制任务是为了“触摸”文件日期时间并导致多次重建。
在没有任何强大的命名和版本控制影响的情况下，除了源文件比二进制输出文件更新之外，VS 2010还有其他原因来运行重建吗？
ADDENDUM：我对源树的大小或形状没有直接影响。它是稳定核心产品的主干，任何短期“非业务”变更都被视为风险和成本高昂。我将在此处收到的答案中提到的要点作为项目未来方向的输入。
答案 0 :(得分：21)
C＃rebuilds，因为文件已被更改，或者依赖项已被更改，但也经常因为“没有明显的原因”。您通常可以连续构建2到3次而无需进行任何更改，C＃将会关闭并重建大量代码。
启用工具＆gt;选项＆gt;项目和解决方案＆gt;构建并运行＆gt;仅在运行时构建启动项目和依赖项。这将最小化仅针对您要执行的项目的依赖项的构建，因此除非所有内容都是一个大型依赖树，否则这将显着减少构建中考虑的项目数。
然而，更好的解决方案是避免要求它首先编译。
每个项目都会为构建添加额外的开销。在我的电脑上，这大概是3秒钟。通过将两个项目的代码合并到一个.csproj文件中，我节省了3秒的构建时间。因此，对于300多个项目，您可以通过合并项目来缩短构建时间10分钟 - 即在可能的情况下在一个程序集中使用许多模块/名称空间而不是许多程序集。您会发现您的应用程序启动时间也得到了改善。
许多项目不需要一直建设。将它们作为库项目分解出来并链接到（引用）二进制文件
同时禁用“复制本地”，而是将所有OutputPath指向共享文件夹 - 这样可以避免在硬盘上制作320个dll的320个副本，从而大大减少开销。
添加新构建配置（例如“Debug FastBuild”），仅构建您实际正在处理的程序集。使用配置管理器，您可以取消不想构建的项目，并且presto，构建系统会忽略它们。从源代码控制中获取代码后，构建一个完整的“Debug”构建来刷新所有内容，然后切换回“fastbuild”
答案 1 :(得分：2)
您可以尝试使用msbuild和/ v：d（用于诊断日志记录）构建解决方案。
日志中可能会提示为什么项目不是最新的。
答案 2 :(得分：1)
我认为在很久以前的320个项目中，你已经超出了Visual Studio设计的极限。
这里有很多好的建议但是如果你真的必须保留320个项目，你可能想放弃Visual Studio来构建和设计你自己的构建过程。
正如我在评论中所说，至少在Windows上，我对构建工具的建议是psake，它建立在powershell上（因此包含在每个现代的Windows机器上），非常强大，并且足够轻便将整个事物提交给你的源代码控制。
答案 3 :(得分：0)
320项目是依赖树中的大量文件：所有需要通过构建引擎检查更改。使用Process Monitor之类的内容可以让您查看正在进行的文件操作以确认这一点。
在运行时加载320个程序集（在.NET框架程序集之上）会降低应用程序的速度，并且会使调试程序变慢（加载大量符号）。看看Debug | Windows |用于查看加载模块的模块。）
除了减少解决方案中的项目数量（很可能有多个解决方案，每个解决方案都有一个项目的子集），你真的需要那么多单独的项目吗？在调试器之外，.NET加载器仅在需要时加载和JIT组装代码，较大的组件并不意味着加载时间较慢并且避免了Windows加载器的每个组件开销。
答案 4 :(得分：0)
首先，检查以确保对其他项目的引用是PROJECT引用而不是程序集引用。
其次，检查循环引用。
第三，将日志记录详细程度设置为DIAGNOSTIC并查看第一行，看看为什么它在第一次构建解决方案后重建项目。
还有很多可以检查的东西，但首先要看看这3件事。