Announcing .NET 8 Preview 1 - .NET Blog

David · 2월 21, 2023, 9:39오후

dimohy · 2월 21, 2023, 11:50오후

하이라이트

Native AOT로 컴파일된 용량 최대 50% 축소
.NET 컨테이너 기본 리눅스 배포판을 Debian 12(Bookworm)로 업데이트
목록의 항목을 무작위로 선택하는 Random.Shared.Shuffle() 및 무작위 목록을 만드는 Random.Shared.GetItems() 유틸리티 메소드 추가
System.Numberics과 System.Runtime.Intrinsics 성능 개선 및 특성을 통한 상수 유무의 성능 저하 확인
JSON의 NativeAOT 애플리케이션의 성능 및 안정성 개선
System.Collections.Frozen 네임스페이스의 FrozenDictionary<TKey, TValue>및 FrozenSet<T> 등의 성능 개선을 위한 핵심 라이브러리 추가
.NET 8과 함께 우분투 Chiseled 컨테이너 이미지 게시
다양한 코드젠 개선

rkttu · 2월 22, 2023, 4:34오전

ASP.NET Core에서 좀 더 적극적으로 NativeAOT 지원을 확대해 나간다는 소식은 고무적입니다. CPU 사용률, 네트워크 사용률을 낮추는 것이 요즈음 Carbon Net-Zero/Neutral 경영 기조랑 엮이면서 중요해지다보니 런타임 고효율을 집중해서 보기 시작한 것 같네요

github.com/dotnet/aspnetcore

EPIC: Support publishing ASP.NET Core API apps with Native AOT (WIP)

opened 01:54AM - 06 Jan 23 UTC

DamianEdwards

Epic Theme: cloud native

# Overview .NET 7 introduced [support for publishing .NET console projects as… _native AOT_](https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/), producing a self-contained, platform-specific executable without any runtime JIT. Native AOT apps start up very quickly and use less memory. The application can be deployed to a machine or container that doesn't have any .NET runtime installed. In .NET 8 we will extend support for native AOT to ASP.NET Core, starting with cloud-focused, API applications built with Minimal APIs that meet expectations regarding published file size, startup time, working set, and throughput performance. # Scope As stated, the primary focus for .NET 8 will be on enabling native AOT publish of ASP.NET Core API applications using Minimal APIs. "Support native AOT" in this context means ensuring that projects can enable native AOT publish via the `<PublishAOT>` project property and the resulting development experience leads developers to producing native AOT published applications without build, publish, or runtime warnings and errors. This means that the majority of foundational feature areas of ASP.NET Core and .NET will need to be updated to support native AOT, including: - Hosting APIs including `WebApplication`, etc. - Kestrel HTTP server - Configuration & Options - Logging - Dependency injection - Common middleware - Authentication and Authorization - Minimal APIs - Health Checks - Data access with ADO.NET (SQLite and PostgreSQL as the primary targets) - OpenAPI support - Observability and diagnostics Additionally, as a secondary goal, we will make progress towards enabling native AOT publish for the following feature areas: - gRPC - SignalR - MVC Web APIs - Entity Framework The following feature areas are out of scope for native AOT support for now: - MVC views and Razor Pages - Blazor Server ## Development experience principles Native AOT has limitations that mean certain APIs and code patterns in .NET are not supported when publishing native AOT. These include features that rely on runtime JIT, e.g. dynamic code generation and compilation, assembly loading, etc., as well as patterns that result in code being trimmed away by the native AOT compilation process that is needed to execute the application, resulting in runtime failures. In adding support to ASP.NET Core for native AOT, we must ensure that the development experience is such that developers can reasonably determine how their app will run once published as native AOT. Where current APIs and features are designed in such a way that are incompatible with native AOT, we will utilize tools including source generators, analyzers, and code fixers, to allow existing APIs to work with native AOT or for developers to update their apps to work with native AOT in a reasonable fashion. # Stages ## Stage 1 Stage 1 of this effort will be to enable creation of ASP.NET Core API projects using a [new project template](#45526), enabled for native AOT, that can be built, published, and run without any warnings or errors, and that meets the defined metric targets for executable file size, startup time, working set, and throughput. ### Metric Targets These are primarily Linux-focused as that's the primary deployment target, but size on Windows on macOS will still be tracked and kept in line with these targets as it often contributes to perception during candidate platform investigations. - 10 MB executable file size - <50 ms startup time (ready to accept first request) - <50 MB working set memory footprint (ready to accept first request) - <50 MB working set memory footprint (after handling load test) - Within 5% of default CoreCLR RPS on Citrine perf environment - *"default" here means compared to the default configuration of a CoreCLR-based deployment of the app, e.g. including tiered JIT* ### Tasks todo ## Stage 2 Stage 2 builds on stage 1 to enable more "real-world" ASP.NET Core API applications to be native AOT published. These applications will use more features typically associated with running API applications in cloud environments including AuthN/Z, data access, OpenTelemetry, etc. The [TrimmedTodo API application](https://github.com/DamianEdwards/TrimmedTodo) will serve as the initial example of this kind of application. ### Metric Targets These are primarily Linux-focused as that's the primary deployment target, but size on Windows on macOS will still be tracked and kept in line with these targets as it often contributes to perception during candidate platform investigations. - 20 MB executable file size - <150 ms startup time (ready to accept first request) - <60 MB working set memory footprint (ready to accept first request) - <60 MB working set memory footprint (after handling load test) - RPS on Citrine perf environment target TBD ### Tasks todo

dimohy · 2월 22, 2023, 5:57오전

오오 Hello World! 프로그램이 이제 1.8MB 실행 크기입니다!