MS2015中的MvcBuildViews需要很长时间 [英] MvcBuildViews in MS2015 takes a long time

查看:97
本文介绍了MS2015中的MvcBuildViews需要很长时间的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们正在转换解决方案以使用新的Roslyn编译器.当我在发布模式下通过teamCity构建它时,MVCBuildViews步骤仍然使用aspnet_compiler.exe,并且需要约15分钟的时间来预编译视图.在.NET 4.5上使用以前版本的aspnet_compiler.exe耗时3分钟,该过程相同.

We are converting a solution to use the new Roslyn compiler. When I build it via teamCity in release mode, the MVCBuildViews step still uses aspnet_compiler.exe and it takes about 15 minutes to precompile views. The same process used to take 3 minutes using the previous version of aspnet_compiler.exe on .NET 4.5

这是需要一段时间的命令:

This is the command that takes a while:

C:\ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ aspnet_compiler.exe -v temp -p E:\ path \ to \ web \ project \ Directory

C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v temp -p E:\path\to\web\project\Directory

我尝试调整MSBuild参数,但未进行任何更改.这是一个已知问题吗,有没有解决的办法,我需要用Roslyn预编译视图吗? 如果可以选择关闭MVCBuildViews步骤,那么有什么缺点(我相信我们选择在发布时进行预编译是导致此步骤运行的原因).

I have tried tweaking the MSBuild parameters but nothing changed. is this a known issue, are there any work around, Do I need to pre-compile the view with Roslyn ? what is the drawback for turning turn off the MVCBuildViews step if it is an option ( I believe our choice to pre-compile on release is what causes this step to run).

推荐答案

我们在Stack Overflow遇到了同样的问题,这就是为什么我们创建我们的公告博客文章中阅读有关此内容的信息,但这是一些令人毛骨悚然的技术细节,因为我们很自然地调查了为什么 aspnet_compiler.exe这么慢,然后才编写自己的替代品.

We've hit the same issue at Stack Overflow, that's why we created StackExchange.Precompilation. You can read about it in our announcement blog post, but here are some gory technical details, as we, naturally, investigated why aspnet_compiler.exe was so slow, before writing our own replacement for it.

aspnet_compiler.exe早于,当然,它支持通过<compilation batch="true" />进行批处理编译之类的功能.为了使视图得以编译,必须首先将CSHTML模板转换为C#(CodeDOM).不幸的是,这不是编译,因此batch="true"不适用于它.有效地,视图按顺序处理,一次处理一个视图.而且您添加到它上面的所有roslyn功能只会减慢它的速度,因为在某个时候必须有CodeDOM-> roslyn转换.

aspnet_compiler.exe has been around long before asp.net-mvc and razor, and of course, it supported stuff like batch compilation via <compilation batch="true" />. In order for a view to be compiled though, the CSHTML template has to be transformed into C# (CodeDOM), first. Unfortunately, this isn't compilation as such, so batch="true" doesn't apply to it. (in-)Effectively, views are processed in sequence, one view at a time. And any roslyn features you add on top of it only slow it down, since there has to be a CodeDOM -> roslyn conversion at some point.

这是一个很好的堆栈跟踪,显示了aspnet_compiler.exe中的 batch 编译之前发生的事情.

Here's a nice stack trace, of what's going on before a batch compilation in aspnet_compiler.exe takes place.

通知此AddBuildProvider调用(该调用 GenerateCode )已经在两个foreach循环中.我想batch="true"选项只能有效地加快网站项目中App_Code的编译速度...

Notice this AddBuildProvider call (which calls GenerateCode) is already inside two foreach loops. I guess the batch="true" options was only ever effective at speeding up the compilation of App_Code in Website Projects...

这是我们之后的构建时间所发生的事情:

This is what happened to our build times afterwards:

我不建议在生产环境中对运行ASP.NET MVC应用程序的任何人禁用预编译.

I wouldn't recommend disabling the precompilation to anybody running an ASP.NET MVC app in production.

  • 最明显的说法是,它可以验证您是否查看了代码.否则,您可以在生产环境中将构建时错误替换为构建服务器上的运行时错误.
  • 另一个理由是性能.您的视图必须在某个时候进行编译,如果在编译时没有发生,则访问您网站的前几个用户必须再次在生产中等待.

这篇关于MS2015中的MvcBuildViews需要很长时间的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆