在 ASP.NET MVC 中编译视图答案

【问题标题】：Compile Views in ASP.NET MVC在 ASP.NET MVC 中编译视图
【发布时间】：2010-09-27 20:18:07
【问题描述】：

我想要一个 msbuild 任务来编译视图，这样我就可以很好地查看是否存在编译时错误...编译时。有什么想法吗？

【问题讨论】：

我不知道您使用的是什么视图引擎，但如果您使用的是 Razor，您可能需要查看我的博客文章：chrisvandesteeg.nl/2010/11/22/…your asp.net mvc Razor 视图进入单独的 dll 应该也可以将该代码用于其他视图引擎，但尚未完成和测试

【解决方案1】：

坦率地说，我会推荐 RazorGenerator nuget 包。这样一来，您的视图会在您保存它们时生成一个 .designer.cs 文件，并且除了为您的视图获取编译时错误之外，它们还会被预编译到程序集中（= 更快的预热），Resharper 也提供了一些额外的帮助。

要使用它，请在您的 ASP.NET MVC 项目中包含 RazorGenerator nuget 包，并在 Tools → Extensions 和更新。

我们使用这种方法，每次编译的开销要少得多。最重要的是，我可能会推荐 RedGate 的 .NET Demon，它进一步大大减少了编译时间的影响。

希望这会有所帮助。

【讨论】：

VS2012有类似的解决方案吗？
可惜只支持C#，不支持VB.Net
@zoidbergi RazorGenerator 适用于 VS2012；使用 RazorGenerator.Mvc 和 RazorGenerator.MsBuild 时：无需扩展。请参阅 stacktoheap.com 上的博客条目
这可以用来只查找错误 - 还是在部署应用程序时替换视图引擎？
我已经安装了 RazorGenerator nuget 包和 Razor Generator 扩展。我的项目没有任何改变。没有 .designer.cs 文件出现。我使用 Visual Studio 2017。

【解决方案2】：

您可以为此使用 aspnet_compiler：

C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_compiler -v /Virtual/Application/Path/Or/Path/In/IIS/Metabase -p C:\Path\To\Your\WebProject -f -errorstack C:\Where\To\Put\Compiled\Site

其中“/Virtual/Application/Path/Or/Path/In/IIS/Metabase”是这样的：“/MyApp”或“ /lm/w3svc2/1/root/"

MSDN 上还有一个AspNetCompiler Task，展示了如何将 aspnet_compiler 与 MSBuild 集成：

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Target Name="PrecompileWeb">
        <AspNetCompiler
            VirtualPath="/MyWebSite"
            PhysicalPath="c:\inetpub\wwwroot\MyWebSite\"
            TargetPath="c:\precompiledweb\MyWebSite\"
            Force="true"
            Debug="true"
        />
    </Target>
</Project>

【讨论】：

这已经过时了，请参阅下面自述文件的摘录。
other answer 更详细地描述了项目任务，但 aspnet_compiler 部分仍然正确（并且对构建代理有用）。

【解决方案3】：

使用 Visual Studio 的 Productivity Power Tools（免费）扩展有点帮助。具体来说，Solution Error Visualizer 功能。有了它，在解决方案资源管理器中（在发现错误的源文件中）以可视方式标记编译错误。但是，由于某种原因，此功能不适用于代码中其他任何地方的其他错误。

对于 MVC 视图，任何编译时错误仍将在其各自的 .cs 文件中以红色下划线标出，但这些错误信号不会在解决方案资源管理器中向上传播（绝不会在包含的源文件中传播） .

感谢BlueClouds 纠正我之前的陈述。

我刚刚在扩展程序的 github 项目上将此报告为 issue。

【讨论】：

我尝试了 Productivity Power Tools。但并不像这里所说的那样行事。剃刀视图中有错误，但构建成功。视图没有用红色标记或下划线，也没有在解决方案资源管理器树中的任何位置。
@BlueClouds：你是对的。我创建了一个示例项目并在视图中添加了一个编译时错误。扩展将在错误线下划线红色，但不会在解决方案资源管理器中传播错误。正在纠正我在答案中所说的内容。我在这里留下答案，因为它仍然有点帮助，但确实没有有效地解决问题。

【解决方案4】：

构建 > 运行代码分析

热键：Alt+F11

帮助我发现 Razor 错误。

【讨论】：

我赞成这个答案，因为热键确实暴露了 Razor 错误。但是我随后注意到，它似乎只有在 IDE 中打开 .cshtml 文件时才有效。

【解决方案5】：

来自 RC1 的自述词文档（未被 google 索引）

ASP.NET 编译器构建后步骤

目前，视图文件中的错误直到运行时才会被检测到。为了让您在编译时检测到这些错误，ASP.NET MVC 项目现在包含一个 MvcBuildViews 属性，默认情况下该属性是禁用的。要启用此属性，请打开项目文件并将 MvcBuildViews 属性设置为 true，如下例所示：

<Project ToolsVersion="3.5" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <MvcBuildViews>true</MvcBuildViews>
  </PropertyGroup>

注意启用此功能会增加构建时间的一些开销。

您可以通过执行以下步骤来更新使用先前版本的 MVC 创建的项目以包括视图的构建时验证：

在文本编辑器中打开项目文件。
在最顶部的<PropertyGroup> 元素下添加以下元素： <MvcBuildViews>true</MvcBuildViews>
在项目文件的末尾，取消注释 <Target Name="AfterBuild"> 元素并修改它以匹配以下内容：

<Target Name="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
    <AspNetCompiler VirtualPath="temp" PhysicalPath="$(ProjectDir)\..\$(ProjectName)" />
</Target>

【讨论】：

如果这不适用于您的项目，请检查项目文件中的某处是否没有 false。它覆盖了我在其上添加的新元素。
@mxmissile：Scott Guthrie 建议在您的解决方案中添加一个 Web 部署项目，以便在 Web 应用程序项目中获得这种支持：weblogs.asp.net/scottgu/archive/2006/09/22/…
确保 EnableUpdateable 设置为 false，否则不会预编译视图。 falsetrue (devcarl.posterous.com/…)
为什么，为什么，为什么...没有用于构建有或没有视图的键盘快捷键？女士为什么？
这是添加到 MVC 工具中的解决方案。 stackoverflow.com/a/2670792/878612

【解决方案6】：

此处给出的答案适用于某些 MVC 版本，但不适用于其他版本。

简单的解决方案适用于 MVC1，但升级到 MVC2 后，视图不再被编译。这是由于网站项目文件中的错误造成的。请参阅这篇 Haacked 文章。

看到这个：http://haacked.com/archive/2011/05/09/compiling-mvc-views-in-a-build-environment.aspx

【讨论】：

【解决方案7】：

此外，如果您使用 Resharper，您可以激活解决方案范围分析，它会检测您在 aspx 文件中可能存在的任何编译器错误。这就是我们所做的......

【讨论】：

确实适用于 aspx 文件，但解决方案范围的分析不包括 ascx 文件（用户控件）
我相信它在 R# 5 中确实如此，但它对于大型项目来说是一个巨大的资源消耗（即使在我的 16GB 家用机器上也不值得使用）。
@Andrew / @mookid8000 -- R# 还将捕获编译器不会捕获的错误，例如缺少/不正确的视图和操作。 R# 会使您的 PC 变慢一点（我发现它在具有 4GB 内存和超线程 CPU 的大型项目上很好）但我很容易收回等待它的时间，并且我最终在我的计算机上执行的操作更少作为 R# 的代码提供了更高级别的操作，这些操作将我必须手动完成相同任务的许多步骤批处理在一起。你的项目一定很大！
对于大型项目，“让你的电脑慢一点”是轻描淡写的。我的构建机器有 16GB 的 RAM 和 8 个内核（2 个 Xeons），它只是 CRAWLS。我有一种感觉，虽然 R# 并不是为我们规模的项目而设计的......例如我们的解决方案有大约 30 个项目、几百万个 LOC 和数百个视图。我喜欢在我们较小的项目中使用 R#（例如，一些项目和不超过 50 个视图），但在我们的大项目中，我们总是必须关闭它。
这可能有效，但快跑！我打开它，以为我的解决方案很小，它从未完成“分析”并吃掉了我所有的 RAM 和 CPU。我花了 15 分钟才恢复过来。

【解决方案8】：

ASP.NET MVC 的下一个版本（1 月左右推出）应该有编译视图的 MSBuild 任务，所以您可能需要等待。

见announcement

【讨论】：