小编点评

**.NET8.0中ASP.NET Core的NativeAOT改进** **简介** .NET 8.0中引入了对本地AOT的支持，允许使用Minimal APIs实现应用程序的本地AOT发布。此功能允许开发人员在创建和发布可执行文件时简化开发过程，并减少构建、发布和运行时警告。 **主要改进** * 支持使用Minimal APIs实现本地AOT发布。 * 扩展对云应用程序的本地AOT支持。 * 使用C#语言中的代码生成器、分析器和代码修复器等工具，确保本地AOT代码的可读性和可维护性。 **本地AOT发布阶段 1** * 使用新的项目模板创建ASP.NET Core API项目，启用本地AOT。 * 在没有任何警告或错误的情况下构建、发布和运行。 * 满足可执行文件大小、启动时间、工作集和吞吐量的定义指标。 **本地AOT发布阶段 2** * 建立在第一阶段的基础上，使更多的“真实世界”的ASP.NET Core API应用程序成为本地AOT发布。 * 这些应用程序使用更多通常与在云环境中运行API应用程序有关的功能，包括AuthN/Z、数据访问、OpenTelemetry等。 * 满足相同的大小和性能要求的本地AOT发布标准。 **性能优化** * TrimmedTodo API应用程序将作为本地AOT发布的最初例子。 * 降低可执行文件大小、缩短启动时间、降低内存占用。 **结论** .NET 8.0中的NativeAOT是一个重要的改进，它简化了开发人员的本地AOT发布过程，并为应用程序性能带来了显着提升。

正文

.NET7.0刚发布不久，.NET社区开始了.NET8.0的开发，重心重新回到了新功能的迭代。

我们知道在.NET7.0中一个令人激动的特新就是支持了NativeAOT，我们可以通过NativeAOT生成本机程序，由于无需JIT编译，所以无需安装.NET Runtime，也进一步的提升了.程序的启动速度，降低了程序的体积，在客户端软件开发、ServerLess等场景会有不错的前景。关于NativeAOT发布的详情可以点下方链接：
https://learn.microsoft.com/zh-cn/dotnet/core/deploying/native-aot/

作为地表最强的.NET WEB服务器ASP.NET Core，自然也是支持NativeAOT编译，而今天就是为大家介绍关于.NET8.0中ASP.NET Core中计划的一些NativeAOT改进。

概述

.NET 7引入了对将.NET控制台项目作为本地AOT发布的支持，产生了一个独立的、针对平台的可执行文件，没有任何运行时JIT。本地AOT应用程序启动非常快，而且使用的内存更少。该应用程序可以被部署到没有安装任何.NET运行时的机器或容器中。在.NET 8中，我们将把对本地AOT的支持扩展到ASP.NET Core，首先是以云为重点，用最小的API构建的API应用程序，满足关于发布文件大小、启动时间、工作集和吞吐性能的期望。

范围

如前所述，.NET8.0的主要重点是使用Minimal APIs实现ASP.NET Core API应用程序的本地AOT发布。这里的 "支持本地AOT"是指确保项目能够通过<PublishAOT>项目属性启用本地AOT发布，并且由此产生的开发经验能够引导开发人员制作本地AOT发布的应用程序，而不会出现构建、发布或运行时警告和错误。这意味着ASP.NET Core和.NET的大多数基础功能领域都需要更新，以支持本地AOT，包括：

• 托管API，包括WebApplication，等等。
• Kestrel HTTP服务器
• 配置和选项
• 日志
• 依赖性注入
• 通用中间件
• 认证和授权
• 最低限度的API
• 健康检查
• 用ADO.NET进行数据访问（SQLite和PostgreSQL为主要目标）
• 支持OpenAPI
• 可观测性和诊断

此外，作为一个次要目标，我们将在实现以下功能领域的NativeAOT发布方面取得进展：

• gRPC
• SignalR
• MVC Web APIs
• Entity Framework

以下功能领域暂时不在NativeAOT支持的范围内：

• MVC视图和Razor页面
• Blazor服务器

开发经验原则

本地AOT有一些限制，这意味着在发布本地AOT时不支持.NET中的某些API和代码模式。这些包括依赖运行时JIT的功能，如动态代码生成和编译、汇编加载等，以及导致代码被本地AOT编译过程修剪掉的模式，这些都是执行应用程序所需要的，导致运行时失败。

在为ASP.NET Core增加对本地AOT的支持时，我们必须确保开发体验是这样的：开发人员可以合理地确定他们的应用程序在发布为本地AOT后将如何运行。如果当前的API和功能的设计方式与原生AOT不兼容，我们将利用包括源码生成器、分析器和代码修复器在内的工具，让现有的API与NativeAOT协同工作，或者让开发者以合理的方式更新他们的应用程序与NativeAOT协同工作。

阶段

阶段 1

这项工作的第一阶段是使用新的项目模板创建ASP.NET Core API项目，启用本地AOT，可以在没有任何警告或错误的情况下构建、发布和运行，并且满足可执行文件大小、启动时间、工作集和吞吐量的定义指标。

度量目标

这些指标主要以Linux为重点，因为它是主要的部署目标，但Windows和macOS上的大小仍将被跟踪，并与这些目标保持一致，因为在候选平台调查期间，它往往有助于感知。

• 10MB的可执行文件大小
• <50毫秒的启动时间（准备接受第一个请求）。
• <50 MB的工作集内存足迹（准备接受第一个请求）。
• <50 MB的工作集内存占用（处理完负载测试）。
• 在Citrine perf环境下，默认CoreCLR RPS的5%以内

这里的 "默认"是指与基于CoreCLR的应用程序部署的默认配置相比，例如包括分层JIT。

阶段 2

第二阶段建立在第一阶段的基础上，使更多的"真实世界"的ASP.NET Core API应用程序成为本地AOT发布。这些应用程序将使用更多通常与在云环境中运行API应用程序有关的功能，包括AuthN/Z、数据访问、OpenTelemetry等。TrimmedTodo API应用程序将作为这种应用程序的最初例子。

度量目标

这些主要是以Linux为重点，因为这是主要的部署目标，但在Windows和macOS上的大小仍将被跟踪，并与这些目标保持一致，因为它往往有助于在候选平台调查中的感知。

• 20MB的可执行文件大小
• <150毫秒的启动时间（准备接受第一个请求）。
• <60 MB工作集内存占用（准备接受第一个请求）。
• <60 MB的工作集内存占用（处理完负载测试）。
• RPS在Citrine性能环境中的目标待定

总结

我们从.NET社区最新的计划可以看出，ASP.NET Core将继续在云原生场景发力，通过支持NativeAOT来降低可执行文件大小、缩短启动时间降低内存占用，笔者本人是非常期待这样的更新，在之前笔者的文章AOT和单文件发布对程序性能的影响中测试了.NET6.0时代ASP.NET Core AOT的的一些数据，后面.NET8.0发布以后期待它的改进。

以下是.NET6.0 ASP.NET Core AOT的数据：

Github对应链接：https://github.com/dotnet/aspnetcore/issues/45910