我们有一个中等规模的解决方案，大约有20个项目。在其中一个我有我的业务实体。在编译任何项目时，visual studio会在这个BusinessEntities项目上等待并挂起大约一分半钟。
我在SharpDevelop中尝试了我们的解决方案，它在18秒内编译了我们的完整解决方案。与MSBuild类似的时机。
我的猜测是VS试图找出项目是否需要编译，但是这个过程比实际执行编译慢了大约15倍!!
我无法切换到极好的尖锐开发，它缺少一些小的，但我们的调试方案必不可少的要求。
我可以阻止VS检查这个项目吗？让它在没有这样检查的情况下编译项目，就像sharpdevelop一样？
我已经知道在配置管理中取消选中项目以防止构建一些项目，但我的开发人员会忘记他们需要在更新到最新源之后编译这个项目，并且他们面临着对他们来说很奇怪的问题。
编辑：有趣的调查结果：延迟发生在其中一个项目中。在配置管理器中，我取消选中所有项目，然后单独编译它们。所有项目都在几秒钟内编译完成!!关键在于：如果直接构建该特殊项目，则在几秒钟内编译，如果正在构建（或跳过，因为它是最新的），因为构建依赖于它的另一个项目，VS挂起约一分半钟，然后决定编译它（或跳过它）。我的结论是：Visual Studio正在检查是否有任何文件被更改，但由于某些原因，对于这个特殊项目来说效率非常低!!
答案 0 :(得分：8)
我转到Tools -> Options -> Projects and Solutions -> Build and Run，然后将“MSBuild项目构建[输出|构建日志]详细程度”更改为Diagnostic。在该级别，它将包括可以帮助您追踪问题的时间。
答案 1 :(得分：3)
为了当前编译项目的利益，您可能会遇到VS检查其他新建组件。
当构建程序集时，VS将检查目标程序集的引用，如果它们是最新构建的或新版本，可能包括实际将它们加载到.Net域中，该域承担加载程序集的所有负担。虽然你打算运行它。随着重建越来越多的项目，构建可能会逐渐变慢。当一个组件变得更新时，其他组件会做更多的工作。这是一个可能的解释，为什么建筑本身，而不是已经建成，而不是建筑清洁，所有都有看似相关的不同结果。它真的是其他人改变了而不是正在编译的那个。
VS将“标记”引用程序集的最后一个“内部”构建号，并查看引用的程序集在其构建过程中是否实际更改。如果没有差别，就会跳过大量的工作。是的，有一些你无法控制的内部装配体编号。这是由于实际的c＃编译器或其工作或任何后编译而不是任何方式的probalby，而是大多数情况下必需的预编译步骤。
您可以使用多种面向参考的设置，并且根据您的开发，测试或部署需求，功能差异可能无关紧要，但可能深刻影响VS的行为方式和持续时间它需要在构建期间。
转到解决方案资源管理器中其中一个项目的引用：
1）点击参考
2）如果属性窗格不是（不是属性页面或属性管理器）
，则打开属性窗格3）查看'Copy Local'，'Embed Interop Types'，'Reference Output Assembly';那些可能是非常适用的，可能是一件好事，无论如何。我强烈建议查看他们在MSDN上的操作。 “参考输出装配”可能会也可能不会显示在列表中。
4）卸载项目，并在VS中编辑.proj文件作为文本。在XML中查找程序集引用并查找“Private”。这意味着引用的程序集是否被视为从引用程序集角度来看是私有程序集，而不是共享程序集。这是一种冗长的说法，将该组件作为一个单元与其他组件一起部署。这对于减轻事情负担非常重要。背景：http://msdn.microsoft.com/en-us/magazine/cc164080.aspx
因此，这里的基本思想是，您希望在构建期间和部署之后将所有这些配置为最便宜的。如果你一起构建它们，那么你可能真的不需要“复制本地”。我不想多说你应该如何配置它们而不了解更多关于你的需求，但是阅读一些关于每个的好段落是一件非常好的事情。然而，这变得非常棘手，因为在重建引用的一个之前，你也会影响VS是否会使用陈旧的旧版本。作为进一步解释这些内容的另一个例子，复制本地可以使用本地副本，即使它已陈旧，因此具有此设置可能是双坏的。请记住，目前的目标是降低VS加载新构建的程序集jsut以编译其他程序集的负担。
最后，就目前而言，我可以很容易地说，悬挂只需1.5分钟即可获得非常幸运。由于这样的事情，有些人的构建时间要差得多;）
答案 2 :(得分：3)
我们在Visual Studio 2013中运行的ASP.NET MVC Web项目遇到了同样的问题。我们构建项目并且大约一分钟左右没有任何反应，然后输出窗口显示我们正在编译。
以下是修复它的问题...在文本编辑器中打开 .csproj文件并将MvcBuildViews设置为false：
<MvcBuildViews>false</MvcBuildViews>
我不得不使用sysinternals进程监视器来解决这个问题，但这显然是我的情况的原因。该网站现在编制时间不到5秒，之前花了一分钟。在那一分钟，Asp.net编译过程将文件和目录放入Temporary Asp.net Files文件夹。
警告：如果您设置了此选项，则不会预先编译视图，因此您将无法在构建时查看视图中的语法错误。
答案 3 :(得分：1)
听起来很傻，但首先删除所有断点。它大大加快了我的预建检查 - 但仍然不知道为什么。
答案 4 :(得分：1)
一些未提及的故障排除想法：
清洁解决方案？
删除Obj和Bin文件夹？仅供参考，Clean和Rebuild都不会删除非构建文件，例如在预构建命令期间复制的文件。
关闭VS扫描外部文件。选项＆gt;工具＆gt;环境＆gt;文件＆gt;检测何时在环境外更改文件？
回滚SVN历史记录以确认它何时开始发生？改变了什么？如果第1天的项目文件需要相同的时间，请重新创建项目，添加所有文件并构建。
否则，您可以运行Process Monitor并告诉我们Visual Studio在准备阶段正在做什么吗？
答案 5 :(得分：1)
根据提供的（有限的）信息，一种可能性是项目文件中指定的预构建操作编译速度慢。
答案 6 :(得分：1)
尝试按照here所述禁用平台验证任务。
答案 7 :(得分：1)
如果您的各个项目正在正确编译，那么您所能做的就是通过在配置中明确设置相关项目来更改编译顺序。
尝试可视化项目依赖关系层次结构并设置依赖项目。例如，如果在每个项目中引用了业务实体项目，则在每个项目的配置中，必须将此项目选择为依赖项目。
如果未设置显式构建顺序，Visual Studio将分析项目以创建构建项目的顺序。设置显式依赖项目wiki使visual studio跳过此步骤并使用您提供的顺序。
答案 8 :(得分：1)
如果在单个项目上出现如此极端的延迟，并且没有其他途径似乎提供了一个原因，我将尝试在从sysinternals运行procmon时构建该特定项目并过滤掉所有成功消息。您也可以将其缩小到仅适用于文件系统操作。根据您的描述，我可能会猜测文件被外部源（如事件集合或工作流管理流程服务）锁定。
要考虑的其他事项是，这是否是一个完全干净的构建机器，或者它是否已被用于测试构建？如果是这样，是否有人有可能直接将IIS应用程序路径映射到项目或将其注册为服务位置？
如果您运行procmon并且看不到明显的锁定或冲突，我会创建一个全新的解决方案和项目并复制文件以查看该项目是否也具有相同的延迟。如果确实有相同的延迟，我会创建一个相同类型的示例项目，但是通用数据（基本上是空的），看看它是否也很慢。如果具有相同文件的新项目构建正常，则可以对目录进行区分以查看导致问题的方差（可能是配置或项目设置）。
答案 9 :(得分：1)
对我来说，彻底禁用代码分析器对此处的说明有所帮助： https://docs.microsoft.com/en-us/visualstudio/code-quality/disable-code-analysis?view=vs-2019#net-framework-projects。
我认为我的代码分析器已经关闭，但是添加额外的xml很有帮助。
感谢Kaleb的建议，将“ MSBuild项目的构建[输出|构建日志]详细程度”设置为“诊断”。显示第一则消息需要十多秒钟：
属性重新分配：$（Features）=“; flow-analysis; flow-analysis”（先前的值：“; flow-analysis”），位于C：\ myProjectDirectory \ packages \ Microsoft.NetFramework.Analyzers.2.9.3 \ build \ Microsoft.NetFramework.Analyzers.props（32,5）
是谁带我去了代码分析器的。
答案 10 :(得分：1)
以防万一其他人陷入该问题：
在我的情况下，延迟是由“其他包含目录” 中的无效路径条目引起的，该条目指向不可访问的UNC位置。
更正此错误后，延迟消失了。