我最近询问了我目前工作地点的前首席开发人员，为什么他选择使用 Razor Generator 将我们的观点预先编译成一个单独的组装
他在下面做了一些声明，但我似乎无法在网上找到任何 Razor Generator 个人资料和/或指标来备份声明（10-快速100倍），和/或，如果 IIS7 / ASP.NET 在幕后做了关于预编译和运行时编译的视图及其好处或缺点-there-的。
有人能指出我正确的方向吗？还是评论？
在我看来（就启动时而言）只需为网站设置IIS autostart = true即可平衡使用 Razor Generator 进行预编译的任何好处即可。以下是他的发言：
为什么我们使用Razor Generator预编译我们的视图以及为什么将它们放在一个单独的程序集中？
第一个是简单的编译时错误检查。有这么多的意见 这似乎是避免生产错误的好方法。这有点儿 令人沮丧的是必须重新编译才能看到对视图的更改 承认，但（我认为）完全值得你知道 有更多的错误检查预先。
第二个是当视图没有在项目中编译时 在运行时编译，然后编译表示 存放在ram中。有时，如果他们不经常访问 （因为有很多这样的观点，大多数情况都是如此） 那些存储的编译版本被放弃并收集垃圾 保存ram。所以除了网站中最常访问的视图之外的所有视图 gaf.com最终会在每次访问时重新编译。但如果 你把它们放在一个项目中，只需要加载编译版本 来自dll，如果它还没有在内存中（是的代码可以是垃圾 收集，但不经常）。从dll加载10到100 时间更快（来自Razor Generator项目的网站 - 我 我自己没有验证，但这听起来很合理。）
答案 0 :(得分：7)
我们在同样的问题上挣扎。我们开始编译视图，以便在集成测试和 UX测试期间捕获可能会出现的明显问题。更糟糕的是，这些错误以某种方式悄悄进入生产阶段。
但是，我们的构建时间变得无法容忍。我们的开发人员建立了无数次，这成为我们今天的主要部分。午饭后我们开玩笑说测试，所以我们外出时可以完成构建。
我们最终在 UX-tests 之前搬到了建筑。
现在我们正在进行预编译。我们团队中只有一个人现在采用它，显然预编译明显优于构建（增量与总数）。设置基本上是一个nuget fetch。
这些文章应该是一个好的开始
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
预编译为我们提供了部署现成二进制文件的所有优势。我们的用户在第一次观看视频时不会遇到短暂的延迟。
据我所知IIS autostart = true将启动您的应用程序池，但不会强制编译您的视图。因此，您将获得第一个用户使用每个View的初始启动命中。