我最近询问了我现在工作的地方的前首席开发人员，为什么他选择使用Razor Generator将我们的视图预编译到一个单独的程序集中。
他在下面做了一些声明，但我似乎找不到任何Razor Generator配置文件和/或web上的指标来支持该声明(10-100倍快)，和/或者，如果IIS7/ASP。. NET在幕后做关于预编译视图和运行时编译视图的工作，以及它们的优点或缺点。
谁能给我指个正确的方向?或评论?在我看来(就启动时间而言)，简单地为站点设置IIS autostart = true将抵消使用Razor Generator预编译的任何好处。以下是他的陈述:
为什么我们要使用Razor生成器来预编译我们的视图，为什么要把它们放在一个单独的程序集中?
第一个是简单的编译时错误检查。有这么多观点这似乎是避免生产中出现错误的好方法。有点必须重新编译才能看到视图的更改，这令人沮丧我承认，但(在我看来)知道你是完全值得的提前做更多的错误检查。
第二个是，当视图没有在项目中编译时，它们将被编译在运行时编译然后那些编译的表示存储在ram中。有时，如果他们不经常访问(这是大多数观点的情况，因为有太多了)存储的已编译版本将被丢弃，垃圾将被收集到节省内存。所以除了最常访问的网站视图Gaf.com最终被重新编译每次他们被访问。但是,如果你把它们放在一个项目中，编译后的版本只需要加载从DLL，如果它还没有在内存中(是的，代码可以是垃圾也收集，但不太频繁)。从dll中加载是10 - 100倍快(这是从剃刀发电机项目的网站-我我没有亲自验证，但听起来很合理)。
我们也遇到了同样的问题。我们开始编译视图，以便捕捉在集成测试和UX测试期间出现的明显问题。更糟糕的是，这些bug不知怎么就溜进了产品中。
但是，我们的构建时间变得无法忍受。我们的开发者创造了无数次内容，这也成为了我们每天的主要内容。我们开玩笑说午饭后测试，这样我们不在的时候就可以完成构建。
我们最终转移到构建之前的UX-tests。
现在我们开始进行预编译。我们团队中目前只有一个人采用了预编译，显然预编译比构建要好得多(增量vs总)。setup基本上是nuget取回。
这些文章应该是一个好的开始
http://stacktoheap.com/blog/2013/01/19/precompiling-razor-views-in-asp-dot-net-mvc-3/http://blog.davidebbo.com/2011/06/precompile-your-mvc-views-using.html预编译为我们提供了部署已构建好的二进制文件的所有优势。我们的用户不会在第一次点击View时经历短暂的延迟。
据我所知，IIS autostart = true将启动您的应用程序池，但不会强制编译您的视图。因此，留给您的是第一个使用每个View的用户的初始启动命中值。