.NET Conf

Kompilacja Native Ahead-of-Time (AOT) to przełom w świecie .NET – eliminując tradycyjny model Just-in-Time (JIT), zapewnia zupełnie nowe możliwości wydajnościowe i wdrożeniowe. Wraz z .NET 8 Microsoft rozszerzył potencjał Native AOT dla aplikacji ASP.NET Core, umożliwiając tworzenie niezwykle lekkich oraz błyskawicznie startujących aplikacji konkurujących z Go czy Rust w środowiskach chmurowych. Odpowiada to na najważniejsze wyzwania, takie jak szybkość uruchamiania, zużycie pamięci czy prostota dystrybucji, choć pojawiają się też nowe ograniczenia związane z kompatybilnością i praktykami programistycznymi. W poniższym opracowaniu znajdziesz analizę architektury, wydajności, kluczowych ograniczeń oraz praktycznych strategii implementacji Native AOT w .NET 8 i 9.

Spis treści [odkryj]

Techniczna architektura i proces kompilacji

Native AOT zmienia cykl życia aplikacji .NET – kompilacja zachodzi w całości przed uruchomieniem, eliminując runtime’owy JIT. Standardowo kod C# jest tłumaczony do MSIL (Microsoft Intermediate Language), a następnie JIT konwertuje go na natywny kod podczas startu. Native AOT pomija etap JIT, generując od razu samodzielny, natywny plik wykonywalny zoptymalizowany pod docelową platformę.

Zastosowana analiza statyczna i przycinanie kodu (trimming) pozwalają pozostawić wyłącznie potrzebne fragmenty runtime i aplikacji, radykalnie zmniejszając finalny rozmiar pliku. To skutkuje mniejszymi, szybciej uruchamianymi plikami – ale oznacza też konieczność rezygnacji z funkcji wymagających dynamicznego generowania kodu, takich jak refleksja run-time czy dynamiczne ładowanie bibliotek.

Architektura tak przygotowanej aplikacji łączy logikę biznesową i wybrane składniki runtime (GC, system typów, wybrane API) w jednym pliku. Przykładowo, typowa aplikacja „Hello World” z Native AOT waży ok. 9 MB, a jej odpowiednik oparty o JIT – 40 KB (z wymaganą instalacją .NET Runtime). To rozwiązanie daje pełną niezależność wdrożeniową, lecz wymusza kompromis pomiędzy rozmiarem a prostotą deploymentu.

Zalety wydajnościowe i zachowanie aplikacji w czasie działania

Wydajność i responsywność Native AOT można podsumować poprzez następujące korzyści:

  • znacznie krótszy czas uruchamiania aplikacji – eliminacja narzutu JIT i optymalizacja już na etapie builda,
  • redukcja zużycia pamięci RAM podczas działania przez zminimalizowanie runtime oraz brak kodu pośredniego,
  • uzyskanie mniejsze rozmiaru plików wynikowych,
  • lepsza efektywność kosztowa i gęstość uruchamiania instancji w środowiskach chmurowych,
  • większa przewidywalność działania oraz uproszczony monitoring wydajności.

Przykładowe testy wykazały dla Native AOT 2-3x szybszy start aplikacji i 2,75-krotny wzrost wydajności przy krótkich operacjach. Dla długotrwałych procesów przewaga jest mniejsza i wynosi średnio ok. 20%.

Warto pamiętać, że zysk z natywnej kompilacji jest największy przy mikroserwisach, startupach funkcji serverless oraz aplikacjach o wyśrubowanych wymaganiach cold-startu. Jednocześnie brak dynamicznych optymalizacji JIT może ograniczyć przewagę w aplikacjach długo działających, bardzo intensywnie korzystających z zasobów procesora.

Ograniczenia i techniczne wyzwania

Przed wdrożeniem Native AOT należy uwzględnić następujące ograniczenia platformy:

  • brak dynamicznego generowania kodu (np. System.Reflection.Emit) i refleksji runtime,
  • zakaz dynamicznego ładowania bibliotek (Assembly.LoadFile),
  • konieczność jawnego zdefiniowania wszystkich wykorzystywanych typów oraz ścieżek kodu na etapie kompilacji,
  • niemożność korzystania w pełni z System.Linq.Expressions (działają wyłącznie w trybie interpretowanym),
  • każdy wariant generyka musi być wygenerowany osobno, co może zwiększyć rozmiar wynikowy,
  • uzależnienie pliku wykonywalnego od konkretnej architektury i systemu operacyjnego.

To rodzi spore wyzwanie migracyjne zwłaszcza dla aplikacji rozbudowanych, korzystających z refleksji, dynamicznej serializacji czy plug-inów. Projekty wymagające wieloplatformowości muszą przygotować osobne buildy dla każdej architektury docelowej oraz uwzględnić to w pipeline’ach CI/CD.

Integracja z ASP.NET Core i zgodność funkcji

Wprowadzenie Native AOT do ASP.NET Core w .NET 8 to rewolucja, jednak zakres wsparcia zależy od używanych funkcjonalności:

  • gRPC, JWT Authentication, CORS, health checks oraz obsługa plików statycznych – pełne wsparcie w trybie AOT;
  • Minimal APIs – wsparcie podstawowych scenariuszy, częściowe ograniczenia przy zaawansowanych przypadkach (np. dynamiczne bindowanie, skomplikowane typy);
  • MVC, Blazor Server, pełny SignalR, session state, integracja SPA – brak wsparcia w AOT, konieczność rewizji architektury projektu.

Dla projektów opartych o MVC czy zaawansowaną konfigurację bindowania należy rozważyć refaktoryzację na Minimal APIs lub implementacje własnych mechanizmów. Adopcja Native AOT powinna być bardzo ostrożna w projektach pełnostackowych, a architekturę trzeba projektować pod ograniczoną refleksję.

Wsparcie Entity Framework Core i dostęp do danych

Integracja EF Core z Native AOT pozostaje sporym wyzwaniem. Microsoft udostępnia mechanizmy eksperymentalne, oparte o prekompilowane zapytania LINQ. Oto kluczowe zasady ich wykorzystania:

  • Prekompilowane zapytania – budowanie zapytań i generowanie interceptorów na etapie kompilacji,
  • Wymóg pakietu Microsoft.EntityFrameworkCore.Tasks i aktywacji interpolatorów dla integracji build/MSBuild,
  • Ograniczona elastyczność – dynamiczne zapytania muszą być przemyślane lub uproszczone,
  • wróbki dotyczą także wsparcia zaawansowanych możliwości EF Core.

Najlepiej w trybie Native AOT sprawdzają się narzędzia typu ADO.NET, Dapper AOT czy lekkie ORM-y, które nie wykorzystują w szerokim zakresie refleksji runtime – to one są rekomendowane do rozwiązań chmurowych z PostgreSQL i SQLite.

Strategie wdrożeń kontenerowych i chmurowych

Native AOT jest stworzone z myślą o środowiskach kontenerowych i cloud-native. Samodzielny plik wykonywalny pozwala porzucić bazowe obrazy z .NET Runtime i wykorzystać ultra-lekkie opcje, jak Alpine Linux czy distroless, drastycznie redukując rozmiar końcowego kontenera.

Korzyści architektoniczne wdrożeń Native AOT w chmurze obejmują:

  • szybszy cold start i dynamiczne skalowanie (auto-scaling) usług,
  • oszczędność zasobów w orkiestrowanych środowiskach (np. Kubernetes),
  • łatwiejszą dystrybucję i bezpieczeństwo (jeden plik wykonywalny, bez zależności na obrazie),
  • możliwość cross-kompilacji i stosowania dedykowanych build-image’ów przygotowanych przez Microsoft,
  • prosty workflow: build natywny → przeniesienie pliku wykonywalnego do minimalnego obrazu runtime.

Najlepszą praktyką jest stosowanie wieloetapowych buildów Docker – najpierw build, potem kopiowanie wyłącznie pliku wynikowego do właściwego, minimalnego obrazu.

Workflow deweloperski i dobre praktyki

Wdrożenie Native AOT wymaga zmian w całym cyklu deweloperskim. Kluczowe kroki obejmują:

  • dodanie <PublishAot>true</PublishAot> do projektu lub ustanowienie flagi --aot przy zakładaniu projektu,
  • przejście przez raport ostrzeżeń kompilatora dotyczących niekompatybilnych miejsc,
  • stosowanie source generatorów w miejsce refleksji i dynamicznej serializacji,
  • pełne testowanie aplikacji już w wersji AOT-build – najlepiej na docelowej architekturze,
  • benchmarkowanie wydajności i przemyślane ustawienia <OptimizationPreference> w projekcie .csproj.

Najważniejsze wyzwania to eliminacja refleksji, dynamicznych plug-inów oraz testowanie zewnętrznych bibliotek pod kątem zgodności z AOT. Rekomendowana jest inkrementalna adopcja oraz szerokie testy kompatybilności przed każdą produkcyjną migracją.

Strategie migracji i ocena kompatybilności

Etapy bezpiecznej migracji do Native AOT przedstawiają się następująco:

  • analiza i inwentaryzacja zależności projektu,
  • identyfikacja bibliotek i frameworków wymagających aktualizacji lub zamiany,
  • ocena architektury pod kątem intensywnego użycia refleksji i dynamiki,
  • weryfikacja typów plug-inów, mechanizmów DI oraz serializacji,
  • inkrementalne wdrażanie (pojedyncze serwisy lub mikroserwisy na początek),
  • rozbudowanie pipeline’ów CI/CD o testowanie buildów JIT i AOT,
  • pełny przegląd testów jednostkowych oraz integracyjnych przed wdrożeniem produkcyjnym.

Architektura mikroserwisowa dobrze wpisuje się w inkrementalną migrację do AOT, pozwalając nabierać doświadczenia i ograniczać ryzyko produkcyjne. Kluczowe są obszerne testy kompatybilności i monitoring różnic zachowań pomiędzy JIT a AOT.