为什么aspnet_compiler.exe这么慢（可以更快）？

Question

在我们的构建过程中，我们对我们的网站运行aspnet_compiler.exe以确保ASP.NET / MVC中所有后期绑定的内容实际构建（我对ASP.NET一无所知但我确信这对于防止在运行时发现故障。）

我们的网站规模相当大，有几百页/视图/控件/等。但是在10-15分钟的范围内所花费的时间似乎过多（作为参考，这比整个解决方案需要大约40个项目的编译要长，而且我们只是预编译了两个网站项目。）

我怀疑硬件是问题，因为我运行的是最新的四核英特尔芯片，配备4GB内存和WD Velociraptor 10,000rpm硬盘。而奇怪的是，EXE似乎没有使用太多的CPU（1-5％），并且似乎也没有做太多的I / O.

所以......这是一个众所周知的问题吗？为什么这么慢？有没有办法加快速度？

注意：为了澄清人们已经回答的一些事情，我不是在谈论Visual Studio中的代码编译。我们已经在使用Web应用程序项目了，编译速度不是问题。问题是在这些项目已经编译（see this MSDN page for more details）作为开发构建脚本的一部分之后，网站的预编译。我们正在进行就地预编译，而不是将文件复制到目标目录。

Answer 1

切换到Roslyn编译器最有可能显着改善预编译时间。这是一篇很好的文章：http://blogs.msdn.com/b/webdev/archive/2014/05/12/enabling-the-net-compiler-platform-roslyn-in-asp-net-applications.aspx。

除此之外，还要确保通过在编译元素上将批处理属性设置为true来启用批处理编译。

Answer 2

简单地说，只要aspnet_compiler开始预编译任何单独的aspx页面，aspnet_compiler.exe就会使用“全局编译器锁”。它基本上只允许按顺序编译每个页面。

这有理由（尽管我个人不同意） - 主要是为了检测和防止导致无限循环排序的循环引用，以及确保在编译需求页​​面之前正确构建所有依赖项，他们避免了很多“讨厌的CS问题”。

上次我在一家网络公司工作时，我曾经开始编写一个大量分叉的{{1}}版本，但却被“真正的工作”所束缚，从未完成它。最大的问题是ASPX页面：你可以将HELL并行化的MVC / Razor，但是ASPX解析/编译引擎大约有20级内部和私有类/方法。

Answer 3

1. 编译器应为每个.aspx页面check
生成第二个代码隐藏文件
2. 在编译期间，aspnet_compiler.exe会将所有网站文件复制到输出目录，包括css，js和images。

使用Web application project代替网站模型，您将获得更好的编译时间。

Answer 4

我没有针对此编译器的任何特定热门提示，但是当我遇到此类问题时，我运行ProcMon以查看该进程在该计算机上正在执行的操作，并运行Wireshark以检查它是否存在花费多年时间对一些长期被遗忘的机器进行一些网络访问，该机器在某些注册表项或环境变量中被引用。

Answer 5

只需2美分。

显着减慢ASP.NET视图预编译的一个原因是-fixednames的{​​{1}}命令行选项。 不要使用，特别是如果你使用的是Razor / MVC。

从Visual Studio发布wep应用程序时，请确保选择“不合并”，并且不要选择“创建单独的程序集”，因为这是导致全局锁定并减慢速度的原因。

此处有更多信息https://msdn.microsoft.com/en-us/library/hh475319(v=vs.110).aspx