为什么 aspnet_compiler.exe 如此慢（是否可以使其更快）？
在我们的构建过程中，我们对我们的网站运行 aspnet_compiler.exe 以确保 ASP.NET/MVC 中的所有后期绑定内容都能真正构建（我对 ASP.NET 一无所知，但我确信这是防止在运行时发现故障所必需的）。
我们的网站规模相当大，有几百个页面/视图/控件等。 然而，所花费的时间似乎在 10-15 分钟范围内过多（作为参考，这比编译大约 40 个项目的整个解决方案所需的时间要长，而且我们只预编译了两个网站项目）。
我怀疑硬件是问题所在，因为我正在最新的四核 Intel 芯片上运行，具有 4GB RAM 和 WD Velociraptor 10,000rpm 硬盘。 奇怪的是，EXE 似乎并没有使用太多的 CPU（1-5%），而且似乎也没有执行大量的 I/O。
那么...这是一个已知问题吗？ 为什么这么慢？ 有什么办法可以加快速度吗？
注意：为了澄清人们已经回答的一些问题，我不是在谈论 Visual Studio 中的代码编译。 我们已经在使用 Web 应用程序项目，这些项目的编译速度不是问题。 问题是在编译这些项目之后对网站进行预编译（请参阅此 MSDN 页面了解更多详细信息）作为开发构建脚本的一部分。 我们正在执行就地预编译，而不是将文件复制到目标目录。
During our build process we run aspnet_compiler.exe against our websites to make sure that all the late-bound stuff in ASP.NET/MVC actually builds (I know nothing about ASP.NET but am assured this is necessary to prevent finding the failures at runtime).
Our sites are fairly large in size, with a few hundred pages/views/controls/etc. however the time taken seems excessive in the 10-15 minute range (for reference, this is longer than it takes the entire solution with approx 40 projects to compile, and we're only pre-compiling two website projects).
I doubt that hardware is the issue as I'm running on the latest Quad core Intel chip, with 4GB RAM and a WD Velociraptor 10,000rpm hard disk. And part of what's odd is that the EXE doesn't seem to be using much CPU (1-5%) and doesn't seem to be doing an awful lot of I/O either.
So... is this a known issue? Why is it so slow? And is there any way to speed it up?
Note: To clarify a couple of things people have answered about, I am not talking about the compilation of code within Visual Studio. We're using web application projects already, and the speed of compilation of those is not the issue. The problem is the pre-compilation of the site after these projects have already been compiled (see this MSDN page for more details) as part of the dev build script. We are performing in-place pre-compilation, not copying the files to a target directory.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
切换到 Roslyn 编译器很可能会显着缩短预编译时间。 这是一篇关于它的好文章： https://devblogs.microsoft.com/aspnet/enabling-the-net-compiler-platform-roslyn-in-asp-net-applications/。
除此之外，请确保通过在compilation 元素上将batch 属性设置为true 来启用批处理编译。
Switching to Roslyn compiler most likely will significantly improve precompile time. Here is a good article about it: https://devblogs.microsoft.com/aspnet/enabling-the-net-compiler-platform-roslyn-in-asp-net-applications/.
In addition to this, make sure that batch compilation is enabled by setting batch attribute to true on the compilation element.
简单地说，每当
aspnet_compiler开始预编译任何单独的 aspx 页面时，它都会使用有效的“全局编译器锁”； 基本上只允许按顺序编译每个页面。这样做是有原因的（尽管我个人不同意他们） - 主要是为了检测和防止循环引用导致无限循环，以及确保在编译所需页面之前正确构建所有依赖项，他们避免很多“讨厌的CS问题”。
上次我在一家网络公司工作时，我曾经开始编写
aspnet_compiler.exe的大规模分支版本，但由于忙于“实际工作”而从未完成。 最大的问题是 ASPX 页面：MVC/Razor 的东西你可以并行化，但是 ASPX 解析/编译引擎的内部和私有类/方法的深度约为 20 层。Simply, the
aspnet_compileruses what is effectively a "global compiler lock" whenever it starts pre-compiling any individual aspx page; it is basically only allowed to compile each page sequentially.There are reasons for this (although I personally disagree with them) - primarily, in order to detect and prevent circular references causing an infinite loop of sorts, as well as ensuring that all dependencies are properly built before the requiring page is compiled, they avoid a lot of "nasty CS issues".
I once started writing a massively-forked version of
aspnet_compiler.exelast time I worked at a web company, but got tied up with "real work" and never finished it. Biggest problem is the ASPX pages: the MVC/Razor stuff you can parallelize the HELL out of, but the ASPX parse/compile engine is about 20 levels deep of internal and private classes/methods.使用 Web 应用程序项目 而不是网站模型，您将获得更好的编译时间。
You'll get better compilation times using Web application project instead of Web site model.
我没有关于这个编译器的任何具体的热点提示，但是当我遇到此类问题时，我运行 ProcMon 来查看该进程在机器上正在做什么，然后运行 Wireshark 来检查它是否没有花费很长时间计时- 取消对某个注册表项或环境变量中引用的长期被遗忘的计算机的某些网络访问。
I don't have any specific hot tips for this compiler, but when I have this sort of problem, I run ProcMon to see what the process is doing on the machine, and I run Wireshark to check that it isn't spending ages timing-out some network access to a long-forgotten machine which is referenced in some registry key or environment variable.
只是我的2分钱。
显着减慢 ASP.NET 视图预编译速度的因素之一是
aspnet_compiler.exe的-fixednames命令行选项。 不要使用它，尤其是当您使用 Razor/MVC 时。从 Visual Studio 发布 wep 应用程序时，请确保选择“不合并”，并且不要选择“创建单独的程序集”，因为这会导致全局锁定并减慢速度。
此处有更多信息 https://msdn.microsoft.com/en-us/library/hh475319(v=vs.110).aspx
Just my 2 cents.
One of the things slowing down ASP.NET views precompilation significantly is the
-fixednamescommand line option foraspnet_compiler.exe. Do not use it especially if you're on Razor/MVC.When publishing the wep app from Visual Studio make sure you select "Do not merge", and do not select "create separate assembly" cause this is what causes the global lock and slows things down.
More info here https://msdn.microsoft.com/en-us/library/hh475319(v=vs.110).aspx