ASP.NET网站编译，到底该注意什么？

ASP.NET 的编译机制在不同版本（Web Forms, MVC, Core）中有所不同，但核心思想都是将你编写的源代码（如 .cs, .vb, .aspx 文件）转换成中间语言（IL），然后由 Just-In-Time (JIT) 编译器转换成机器码执行。

下面我将分三大部分来阐述：

1. ASP.NET Web Forms 的编译机制 (传统、经典)
2. ASP.NET MVC / Razor Pages 的编译机制 (基于 MVC 模式)
3. ASP.NET Core 的编译机制 (现代化、跨平台)

ASP.NET Web Forms 的编译机制

Web Forms 的编译模型非常独特，它结合了编译时和运行时的编译，并且有一个关键的“前置编译”（Precompilation）步骤。

核心概念

• 动态编译：当你修改了 .aspx 页面或 .ascx 用户控件的标记部分时，ASP.NET 运行时会自动检测到这些变化，并在第一次请求该页面时，将其编译成一个临时的程序集（.dll 文件），这个编译过程是按需进行的，非常灵活,但首次访问修改过的页面时会有轻微延迟。
• 代码隐藏编译：你写在 .aspx.cs 或 .aspx.vb 文件中的服务器端代码，会在你构建网站（Build Website）时被编译成一个程序集，并放入 bin 目录，这部分代码在应用程序启动时就已加载,性能更高。
• 前置编译：这是 Web Forms 部署前的一个关键步骤，你可以使用 aspnet_compiler.exe 工具（通常在 .NET Framework 的目录下）来对整个网站进行编译。
  • 目的：
    1. 移除源代码：编译后，所有的 .aspx, .ascx, .master 等源文件都会被移除，只留下编译后的 .dll 和 .compiled 文件，这极大地提高了安全性,因为别人无法直接看到你的页面逻辑和标记。
    2. 提前发现错误：在部署前就能编译整个网站，发现所有潜在的编译错误,而不是等到用户访问某个页面时才发现。
    3. 提升启动性能：网站启动时不需要再动态编译页面,所以首次响应速度更快。
    4. 减少部署文件：你只需要部署 bin 目录和配置文件,而不是整个网站源代码。

编译流程总结 (Web Forms)

1. 开发阶段：
   • 修改代码隐藏文件（.aspx.cs） -> 按 F5 或 Ctrl+Shift+B -> Visual Studio 将代码编译到 bin 目录。
   • 修改页面标记（.aspx） -> 首次访问 -> ASP.NET 运行时动态编译该页面。
2. 部署阶段：
   • 开发完成后，右键点击网站 -> “发布” (Publish)。
   • 在发布配置中，可以选择“仅文件”（直接复制文件）或“预编译”（推荐）。
   • 选择“预编译”后，Visual Studio 会调用 aspnet_compiler.exe 对网站进行前置编译,生成一个只包含编译后文件和配置文件的发布包。
   • 将这个发布包部署到服务器上。

ASP.NET MVC / Razor Pages 的编译机制

ASP.NET MVC (包括后来的 Razor Pages) 引入了一个更现代、更清晰的模型，它完全依赖于项目的构建系统，而不是像 Web Forms 那样有复杂的运行时动态编译。

核心概念

• 项目构建：整个应用程序（包括 Controllers, Views, Models, Pages, Services 等）被看作一个标准的 .NET 项目（通常是类库项目）。
• 编译时机：当你构建项目时（在 Visual Studio 中按 F6 或使用 dotnet build 命令），所有的 C# 代码（Controllers, Models, Services）和 Razor 视图/页面（.cshtml）都会被编译。
• Razor 编译：Razor 语法（@model, @foreach, @Html.ActionLink 等）在构建时被转换成 C# 类，一个 Index.cshtml 文件最终会被转换成一个继承自 WebViewPage<TModel>（或 PageModel）的 C# 类，这个转换和编译过程由 Razor SDK 自动完成。
• 输出：构建的最终产物是一个或多个 .dll 文件，位于项目的 bin/Debug 或 bin/Release 目录下。
• 部署：你只需要将编译好的 .dll 文件和相关的配置文件（如 web.config）、静态文件（JS, CSS, 图片）部署到服务器上。不需要部署 .cshtml 源文件。

编译流程总结 (MVC / Razor Pages)

1. 开发阶段：
   • 任何修改（无论是 C# 代码还是 .cshtml 视图）后，按 F5 运行或按 F6 构建。
   • Visual Studio 会触发整个项目的编译，包括 Razor 视图的编译。
   • 编译后的 DLL 被更新到 bin 目录。
2. 部署阶段：
   • 在 Visual Studio 中右键项目 -> “发布”。
   • 发布过程会执行一次完整的 Release 模式下的构建，然后将 bin/Release 目录下的 DLL、配置文件和 wwwroot 目录下的静态文件复制到目标位置。
   • 在服务器上，IIS 或 Kestrel 会直接加载这些已编译的 DLL 来处理请求。

优点：

• 性能更高：所有代码在应用启动时已就绪,没有运行时编译开销。
• 更安全：源代码（特别是视图逻辑）不会暴露在服务器上。
• 流程简单：与标准的 .NET 项目构建流程一致,易于理解。

ASP.NET Core 的编译机制

ASP.NET Core 在 .NET Core / .NET 5+ 的基础上，将编译模型推向了一个新的高度，使其更加现代化、高效和跨平台。

核心概念

• 完全依赖 SDK 样式项目：ASP.NET Core 项目不再是特殊的“网站项目”，而是标准的 .NET SDK 样式项目，这使得构建、发布和依赖管理都非常统一。

• Razor SDK 的进化：Razor 编译功能被完全集成到了 .NET SDK 中，你可以在你的 .csproj 文件中通过 MSBuild 属性来精细控制 Razor 文件的编译行为。

• 两种编译模式：ASP.NET Core 引入了两种 Razor 编译模式,这比旧版本更灵活。

  
  （图片来源网络，侵删）

  1. 传统编译

     • 时机：在构建项目时（dotnet build）。
     • 行为：和 MVC 一样，.cshtml 文件在构建时被编译成 DLL。
     • 部署：部署时只包含 DLL，不包含 .cshtml 源文件。
     • 优点：发布包小，启动快,安全性高。

  2. Razor SDK 的增量编译

     • 时机：在开发过程中，当你保存 .cshtml 文件时。
     • 行为：它不是重新编译整个项目，而是只重新编译被修改的那个视图文件，并生成一个临时的 DLL 供开发服务器使用。
     • 优点：极大地提高了开发时的热重载速度，你修改一个视图，浏览器几乎会立即刷新看到效果，而无需等待整个项目的重新编译，这是现代 Web 开发体验的核心。
     • 部署：此模式仅用于开发，当你发布项目时（dotnet publish），SDK 会自动切换到“传统编译”模式，将所有视图编译进最终的 DLL 中。

编译流程总结 (ASP.NET Core)

1. 开发阶段 (dotnet run)：

   • 运行 dotnet run 命令会启动一个开发服务器（如 Kestrel）。
   • 默认情况下，它启用增量编译。
   • 修改 .cshtml 文件 -> 保存 -> 开发服务器检测到变化 -> 只重新编译该视图 -> 浏览器自动刷新。
   • 修改 C# 代码 -> 保存 -> 需要手动刷新浏览器，因为 C# 代码需要重新编译整个项目。

2. 构建阶段 (dotnet build)：

   • 执行完整的编译，包括所有 C# 代码和 Razor 视图（使用传统编译模式）。
   • 输出 bin/Debug/<target-framework>/ 目录，包含编译好的 DLL 和其他依赖项。

3. 发布阶段 (dotnet publish)：

   • 执行一次 Release 模式的构建，并将所有必要的文件（编译后的 DLL、配置文件、静态文件等）复制到一个独立的文件夹中,这个文件夹就是可以直接部署到生产环境的包。
   • 在发布包中，没有任何 .cshtml 源文件。

总结与对比

理解这些编译机制对于优化开发流程、提升网站性能和正确部署 ASP.NET 应用程序至关重要，对于新项目，毫无疑问应该选择 ASP.NET Core,它提供了最佳的开发和部署体验。