Översikt över publicering av .NET-program

Den här artikeln beskriver de olika sätten att publicera ett .NET-program. Den omfattar publiceringslägen, hur du skapar körbara filer och plattformsoberoende binärfiler samt hur varje metod påverkar distributions- och körningsmiljöer. Du kan publicera .NET-program med hjälp av .NET CLI eller Visual Studio.

Vad är publicering?

Att publicera en .NET-app innebär att kompilera källkod för att skapa en körbar eller binär fil, tillsammans med dess beroenden och relaterade filer, för distribution. Efter publiceringen distribuerar du appen till en server, distributionsplattform, container eller molnmiljö. Publiceringsprocessen förbereder en app för distribution och användning utanför en utvecklingsmiljö.

Publiceringslägen

Det finns två huvudsakliga sätt att publicera en app på. Några faktorer som påverkar det här beslutet är om distributionsmiljön har rätt .NET Runtime installerat och om du behöver specifika kompileringsfunktioner som kräver paketering av körningen med din app. De två publiceringslägena är:

• Publicera fristående
  Det här läget skapar en publiceringsmapp som innehåller en plattformsspecifik körbar fil som används för att starta appen, en kompilerad binär fil som innehåller appkod, eventuella appberoenden och den .NET-körning som krävs för att köra appen. Miljön som kör appen behöver inte ha .NET-körningen förinstallerad.

• Publicera ramverksberoende
  Det här läget skapar en publiceringsmapp som innehåller en valfri plattformsspecifik körbar fil som används för att starta appen, en kompilerad binär fil som innehåller appkod och eventuella appberoenden. Miljön som kör appen måste ha en version av .NET-körningen installerad som appen kan använda.

Grunderna för publicering

Inställningen <TargetFramework> för projektfilen anger standardmålramverket när du publicerar din app. Du kan ändra målramverket till valfri giltig Target Framework Moniker (TFM). Om ditt projekt till exempel använder <TargetFramework>net9.0</TargetFramework>skapas en binär fil som riktar sig mot .NET 9.

Om du vill rikta in dig på fler än ett ramverk kan du ange <TargetFrameworks> inställningen till flera TFM-värden, avgränsade med ett semikolon. När du skapar din app skapas din app för varje målramverk som definieras av projektet. Men när du publicerar din app måste du ange målramverket:

dotnet publish -c Release -f net9.0

Bärbara binärfiler

När du publicerar en .NET-app kan du rikta in dig på en specifik plattform eller skapa en bärbar binärfil. Även när du skapar en bärbar binär fil publicerar .NET som standard en plattformsspecifik körbar fil ("apphost") tillsammans med den bärbara DLL:en om du inte uttryckligen inaktiverar det här beteendet.

Den plattformsspecifika körbara filen skapas på grund av UseAppHost egenskapen, som standard är true. Om du bara vill publicera den bärbara DLL:en utan den plattformsspecifika körbara filen anger du UseAppHost till false antingen på kommandoraden (-p:UseAppHost=false) eller som en projektegenskap.

Fördelen med att rikta in sig på en specifik plattform är att den kan hantera interna beroenden som din app kan kräva, vilket säkerställer kompatibilitet med målplattformens specifika krav.

Inbyggda beroenden

Om din app har inbyggda beroenden kanske den inte körs på ett annat operativsystem om den publiceras som en bärbar binär fil. Appar som är beroende av Windows-API:et körs till exempel inte internt på macOS eller Linux. Du skulle behöva tillhandahålla plattformsspecifik kod och kompilera en körbar fil för varje plattform.

Tänk också på att om ett bibliotek som du refererade till tillhandahåller plattformsspecifika beroenden kanske din app inte körs på alla plattformar. Men när du publicerar och riktar in dig på en specifik plattform kopieras de plattformsspecifika beroendena för ett NuGet-paket till publiceringsmappen.

För att säkerställa att din app publiceras med sina inbyggda beroenden publicerar du för en specifik plattform:

dotnet publish -c Release -r <RID>

En lista över körningsidentifierare finns i RID-katalogen (Runtime Identifier).

Ramverksberoende distribution

Ramverksberoende distribution är standardläget när du publicerar från ANTINGEN CLI eller Visual Studio. I det här läget skapas en plattformsspecifik körbar fil som kan användas för att starta din app. Den plattformsspecifika körbara filen heter något som liknar myapp.exe på Windows eller bara myapp på andra plattformar.

Appen är konfigurerad för att rikta in sig på en specifik version av .NET. Den riktade .NET-körningen måste finnas i den miljö där appen körs. Om din app till exempel riktar in sig på .NET 9 måste alla miljöer som appen körs på ha .NET 9-körningen installerad.

När du publicerar en ramverksberoende distribution skapas en app som automatiskt återställs till den senaste .NET-säkerhetskorrigeringen som är tillgänglig i miljön som kör appen. Mer information om versionsbindning vid kompilering finns i Välj den .NET-version som ska användas.

Fördelar

• Liten distribution: Endast appen och dess beroenden distribueras. Miljön där appen körs måste redan ha .NET-körningen installerad.
• Plattformsoberoende: Appen och alla . NET-baserat bibliotek körs på andra operativsystem.
• Använder den senaste korrigerade körningen: Appen använder den senaste körningen som installerats i miljön.

Nackdelar

• Kräver förinstallation av körningen: Appen kan bara köras om den version av .NET som den riktar sig mot redan är installerad i miljön.
• .NET kan ändras: Miljön där appen körs kan använda en nyare .NET-körning, vilket kan ändra appens beteende.

Starta ramverksberoende appar

Det finns två sätt att köra ramverksberoende appar: via den plattformsspecifika körbara filen ("apphost") och via dotnet myapp.dll. Du kan köra den körbara apphost-filen direkt i stället för att anropa dotnet myapp.dll, vilket fortfarande är ett acceptabelt sätt att köra appen. När det är möjligt rekommenderar vi att du använder apphost. Det finns ett antal fördelar med att använda apphost:

• Körbara filer liknar körbara filer för standardplattformar.
• Körbara namn bevaras i processnamnen, vilket innebär att appar enkelt kan identifieras baserat på deras namn.
• Eftersom apphost är en intern binär fil kan inbyggda tillgångar som manifest kopplas till dem.
• Apphost har tillgängliga säkerhetsreduceringar på låg nivå som tillämpas som standard, vilket gör det säkrare. Till exempel är CET-skuggstacken (Control-flow Enforcement Technology) aktiverad som standard från och med .NET 9. Minskningar som tillämpas på dotnet är den lägsta gemensamma nämnaren för alla körningskörningar som stöds.

Publicera

dotnet publish -c Release [-r <RID>]

dotnet publish -c Release [-r <RID>] --self-contained false

Konfigurera beteende för .NET-installationssökning

Som standard identifierar och använder appvärden en globalt installerad .NET-körning, med installationsplatser som varierar beroende på plattform. Mer information om körningsidentifiering och installationsplatser finns i Felsöka appstartsfel.

.NET-körningssökvägen kan också anpassas för varje exekvering. Miljövariabeln DOTNET_ROOT kan användas för att peka på den anpassade platsen. Mer information om alla DOTNET_ROOT konfigurationsalternativ finns i .NET-miljövariabler.

I allmänhet är bästa praxis för användning DOTNET_ROOT att:

1. Rensa DOTNET_ROOT miljövariabler först, vilket innebär att alla miljövariabler som börjar med texten DOTNET_ROOT.
2. Ange DOTNET_ROOT, och endast DOTNET_ROOT, till målsökvägen.
3. Kör målappens värd.

I .NET 9 och senare versioner kan du konfigurera sökvägarna för .NET-installationssökningen för den publicerade körbara filen via AppHostDotNetSearch egenskaperna och AppHostRelativeDotNet .

AppHostDotNetSearch tillåter att du anger en eller flera platser där den körbara filen letar efter en .NET-installation:

• AppLocal: mappen för den körbara appen
• AppRelative: sökväg i förhållande till den körbara appen
• EnvironmentVariable: värdet för DOTNET_ROOT[_<arch>] miljövariabler
• Global: registrerade och standard globala installationsplatser

AppHostRelativeDotNet anger sökvägen i förhållande till den körbara fil som ska sökas efter när AppHostDotNetSearch innehåller AppRelative.

Mer information finns i AppHostDotNetSearch, AppHostRelativeDotNetoch installera platsalternativ i apphost.

Plattformsoberoende DLL-distribution

Du kan också publicera din app som en plattformsoberoende DLL utan en plattformsspecifik körbar fil. I det här läget skapas en myapp.dll fil i mappen publicera utdata. Om du vill köra appen går du till utdatamappen och använder dotnet myapp.dll kommandot .

Så här publicerar du som en plattformsoberoende DLL:

dotnet publish -c Release -p:UseAppHost=false

Fristående distribution

När du publicerar en fristående distribution (SCD) skapar publiceringsprocessen en plattformsspecifik körbar fil. Publicering av en SCD innehåller alla nödvändiga .NET-filer för att köra din app, men den innehåller inte de interna beroendena för .NET. Dessa beroenden måste finnas i miljön innan appen körs.

När du publicerar en SCD skapas en app som inte vidarekopplas till den senaste tillgängliga .NET-säkerhetskorrigeringen. Mer information om versionsbindning vid kompilering finns i Välj den .NET-version som ska användas.

Fördelar

• Kontrollera .NET-version: Kontrollera vilken version av .NET som distribueras med appen.
• Plattformsspecifik inriktning: Eftersom appen måste publiceras för varje plattform är det tydligt var appen körs.

Nackdelar

• Större distributioner: Eftersom appen innehåller .NET-körningen och alla beroenden är nedladdningsstorleken och hårddiskutrymmet som krävs större än en ramverksberoende distribution.
• Svårare att uppdatera .NET-versionen: .NET Runtime kan bara uppgraderas genom att släppa en ny version av appen.

Publicera

dotnet publish -c Release -r <RID> --self-contained true

Distribution med en fil

När du publicerar din app som en distribution med en enda fil paketeras alla programberoende filer i en enda binär fil. Den här distributionsmodellen är tillgänglig för både ramverksberoende och fristående program, vilket ger ett attraktivt alternativ för att distribuera och distribuera ditt program som en enda fil.

Appar med en fil är alltid specifika för operativsystem och arkitektur. Du måste publicera för varje konfiguration, till exempel Linux x64, Linux Arm64, Windows x64 och så vidare.

Fördelar

• Förenklad distribution: Distribuera och distribuera ditt program som en enda körbar fil.
• Minskad filtrassel: Alla beroenden paketeras, vilket eliminerar behovet av att hantera flera filer.
• Enkel distribution: Kopiera en enda fil för att distribuera programmet.

Nackdelar

• Större filstorlek: Den enskilda filen innehåller alla beroenden, vilket gör den större än enskilda filer.
• Långsammare start: Filer måste extraheras vid körning, vilket kan påverka startprestanda.
• Plattformsspecifik: Måste publicera separata filer för varje målplattform.

Distribution med en fil kan kombineras med andra optimeringar som trimning och ReadyToRun-kompilering för ytterligare optimering.

Mer information om distribution med en fil finns i Distribution med en fil.

Publicera

dotnet publish -c Release -r <RID> -p:PublishSingleFile=true

Intern AOT-distribution

Den interna AOT-distributionen kompilerar appen direkt till intern kod, vilket eliminerar behovet av en körning. Det här publiceringsalternativet använder fristående distributionsläge eftersom den kompilerade interna koden måste innehålla allt som behövs för att köra programmet. Detta resulterar i snabbare starttider och minskad minnesanvändning, men har vissa begränsningar för funktioner som stöds.

Fördelar

• Snabb start: Ingen JIT-kompilering behövs vid körning, vilket leder till snabbare programstart.
• Minskad minnesanvändning: Lägre minnesfotavtryck jämfört med traditionella .NET-program.
• Inget körningsberoende: Programmet körs utan att .NET-körningsinstallation krävs.
• Mindre distributionsstorlek: Ofta mindre än fristående distribution med full körning.

Nackdelar

• Begränsat ramverksstöd: Alla .NET-funktioner och bibliotek är inte kompatibla med intern AOT.
• Längre byggtider: Kompilering till intern kod tar längre tid än vanliga versioner.
• Plattformsspecifik: Måste kompileras separat för varje målplattform och arkitektur.
• Felsökningsbegränsningar: Mer komplex felsökning jämfört med vanliga .NET-program.

Mer information om intern AOT-distribution finns i Intern AOT-distribution.

Publicera

dotnet publish -c Release -r <RID> -p:PublishAot=true

ReadyToRun-distribution

När du publicerar din app med ReadyToRun-kompilering kompileras programsammansättningarna som R2R-format (ReadyToRun). R2R är en form av AOT-kompilering (i förväg) som förbättrar startprestanda genom att minska mängden arbete som JIT-kompilatorn (just-in-time) behöver utföra när programmet läses in. Det här publiceringsalternativet kan användas med både ramverksberoende och fristående distributionslägen.

ReadyToRun-binärfiler innehåller både mellanliggande språkkod (IL) och den interna versionen av samma kod. Även om R2R-binärfiler är större än vanliga sammansättningar ger de bättre startprestanda.

Fördelar

• Förbättrad starttid: Appen ägnar mindre tid åt att köra JIT-kompilatorn under starten.
• Bättre prestanda för första användning: Kortare svarstid för första gången körning av kodsökvägar.
• Kompatibel med befintlig kod: Fungerar med de flesta .NET-bibliotek och ramverk utan ändringar.
• Flexibel distribution: Kan kombineras med både ramverksberoende distribution och fristående distributionslägen .

Nackdelar

• Större storlek: Appen är större på disken på grund av att både IL och intern kod ingår.
• Längre byggtider: Kompilering tar längre tid än standardpublicering.
• Plattformsspecifika optimeringar: Bästa prestandavinster kräver att specifika plattformar riktas in.

Publicera

dotnet publish -c Release -r <RID> -p:PublishReadyToRun=true

Mer information om ReadyToRun-distribution finns i ReadyToRun-kompilering.

Containerdistribution

När du publicerar appen som en container paketerar .NET SDK ditt program och dess beroenden i en containeravbildning utan att det krävs någon separat Dockerfile. Det här distributionsläget skapar en fullständig containeravbildning som kan köras på valfri containerkörning, till exempel Docker eller Podman. Containerdistribution förenklar containeriseringsprocessen genom att eliminera behovet av att skriva och underhålla Dockerfiles samtidigt som optimerade basavbildningar tillhandahålls.

Från och med .NET SDK 8.0.200 ingår containerstöd som standard och kräver inte extra NuGet-paket. För konsolprogram kan du behöva aktivera containerstöd explicit genom att ange EnableSdkContainerSupport egenskapen till true.

Fördelar

• Förenklad containerisering: Du behöver inte skriva eller underhålla Dockerfiles för grundläggande scenarier.
• Optimerade basavbildningar: Använder Microsoft-tillhandahållna, optimerade basavbildningar med de senaste säkerhetsuppdateringarna.
• Konsekvent miljö: Säkerställer en konsekvent körningsmiljö för utveckling, testning och produktion.
• Enkel distribution: Containeravbildningar kan enkelt delas och distribueras i olika miljöer.
• Plattformsisolering: Program körs i isolerade containrar, vilket minskar konflikterna mellan program.

Nackdelar

• Beroende av containerkörning: Målmiljön måste ha en containerkörning installerad.
• Avbildningsstorlek: Containeravbildningar är vanligtvis större än andra distributionsmetoder.
• Inlärningskurva: Kräver förståelse för containerbegrepp och verktyg.
• Begränsad anpassning: Mindre flexibilitet jämfört med anpassade Dockerfiles för komplexa scenarier.

Publicera

dotnet publish -c Release [-r <RID>] /t:PublishContainer

dotnet publish -c Release [-r <RID>] -p:PublishProfile=DefaultContainer

Mer information om containerdistribution finns i Översikt över hur du skapar .NET SDK-container.

Se även

• RID-katalog (.NET Runtime Identifier)
• Välj den .NET-version som ska användas
• Publicera för macOS