Inbyggd AOT-distribution

När du publicerar din app som Native AOT skapas en app som är fristående och som har kompilerats i förväg (AOT) till native kod. Interna AOT-appar har snabbare starttid och mindre minnesfotavtryck. Dessa appar kan köras på datorer som inte har .NET-körningen installerad.

Fördelen med intern AOT är viktigast för arbetsbelastningar med ett stort antal distribuerade instanser, till exempel molninfrastruktur och hyperskalatjänster. .NET 8 lägger till ASP.NET Core-stöd för inbyggd AOT.

Den interna AOT-distributionsmodellen använder en kompilator i förväg för att kompilera IL till intern kod vid tidpunkten för publiceringen. Interna AOT-appar använder inte en JIT-kompilator (just-in-time) när programmet körs. Interna AOT-appar kan köras i begränsade miljöer där en JIT inte tillåts. Interna AOT-program riktar in sig på en specifik körningsmiljö, till exempel Linux x64 eller Windows x64, precis som att publicera en fristående app.

Förutsättningar

Publicera intern AOT med hjälp av CLI

1. Lägg till <PublishAot>true</PublishAot> i projektfilen.

   Den här egenskapen aktiverar intern AOT-kompilering under publiceringen. Det möjliggör även dynamisk kodanvändningsanalys under kompilering och redigering. Det är bättre att placera den här inställningen i projektfilen i stället för att skicka den på kommandoraden, eftersom den styr beteenden utanför publiceringen.

   <PropertyGroup>
       <PublishAot>true</PublishAot>
   </PropertyGroup>
   

2. Publicera appen för en specifik körningsidentifierare med hjälp av dotnet publish -r <RID>.

   I följande exempel publiceras appen för Windows som ett internt AOT-program på en dator med nödvändiga förutsättningar installerade.

   dotnet publish -r win-x64 -c Release

   I följande exempel publiceras appen för Linux som ett internt AOT-program. En intern AOT-binär fil som produceras på Linux-datorn fungerar bara på samma eller nyare Linux-version. Till exempel kommer intern AOT-binärfil som produceras på Ubuntu 20.04 att köras på Ubuntu 20.04 och senare, men den kommer inte att köras på Ubuntu 18.04.

   dotnet publish -r linux-arm64 -c Release

Appen är tillgänglig i publiceringskatalogen och innehåller all kod som behövs för att köras i den, inklusive en avskalad version av coreclr-körningen.

Kolla in Native AOT-exempel som finns tillgängliga i dotnet/samples-förvaret på GitHub. Exemplen omfattar Linux och Windows Dockerfiles som visar hur du automatiserar installationen av förhandskraven och publicerar .NET-projekt med intern AOT med containrar.

AOT-kompatibilitetsanalyserare

Egenskapen IsAotCompatible används för att ange om ett bibliotek är kompatibelt med intern AOT. Tänk på när ett bibliotek anger egenskapen IsAotCompatible till true, till exempel:

<PropertyGroup>
    <IsAotCompatible>true</IsAotCompatible>
</PropertyGroup>

Den föregående konfigurationen tilldelar standardvärdet true till följande egenskaper:

• IsTrimmable
• EnableTrimAnalyzer
• EnableSingleFileAnalyzer
• EnableAotAnalyzer

Dessa analysverktyg hjälper till att säkerställa att ett bibliotek är kompatibelt med intern AOT.

Inbyggd felsökningsinformation

Som standard genererar intern AOT-publicering felsökningsinformation i en separat fil:

• Linux: .dbg
• Windows: .pdb
• macOS: .dSYM-mappen

Felsökningsfilen är nödvändig för att köra appen under felsökaren eller inspektera kraschdumpar. På Unix-liknande plattformar anger du egenskapen StripSymbols till false för att inkludera felsökningsinformationen i den interna binära filen. Om du inkluderar felsökningsinformation blir den interna binärfilen större.

<PropertyGroup>
    <StripSymbols>false</StripSymbols>
</PropertyGroup>

Begränsningar för intern AOT-distribution

Interna AOT-appar har följande begränsningar:

• Ingen dynamisk inläsning, till exempel Assembly.LoadFile.
• Ingen körningskodgenerering, till exempel System.Reflection.Emit.
• Ingen C++/CLI.
• Windows: Ingen inbyggd COM.
• Kräver trimning, vilket har begränsningar.
• Innebär kompilering till en enda fil, som har kända inkompatibiliteter.
• Appar innehåller obligatoriska körningsbibliotek (precis som fristående appar, vilket ökar deras storlek jämfört med ramverksberoende appar).
• System.Linq.Expressions använder alltid sin tolkade form, vilket är långsammare än kod kompilerad vid körning.
• Allmänna parametrar som ersätts med argument av typen struct har specialkod genererad för varje instansiering. I den dynamiska körtiden genereras många instansieringar på begäran. I Native AOT genereras alla instansieringar i förväg. Detta kan ha stor inverkan på programmets diskstorlek. Generiska virtuella metoder och generiska instansmetoder har också en instansiering för varje implementerings- eller överordnande typ.
• Inte alla körningsbibliotek är fullt annoterade som Native AOT-kompatibla. Vissa varningar i körningsbiblioteken kan alltså inte användas av slututvecklare.
• Diagnostikstöd för felsökning och profilering med vissa begränsningar.
• Stöd för vissa ASP.NET Core-funktioner. Mer information finns i ASP.NET Core-stöd för Native AOT.

Publiceringsprocessen analyserar hela projektet och dess beroenden för möjliga begränsningar. Varningar utfärdas för varje begränsning som den publicerade appen kan stöta på vid körning.

Begränsningar för plattform/arkitektur

I följande tabell visas kompileringsmål som stöds.

Mer information om hur specifik plattform stöds med intern AOT finns i länken från tabellen.