Overzicht van .NET-toepassingspublicatie

In dit artikel worden de verschillende manieren uitgelegd waarop u een .NET-toepassing kunt publiceren. Het omvat publicatiemodi, het produceren van uitvoerbare bestanden en binaire bestanden op meerdere platforms, en de impact van elke benadering op implementatie- en runtimeomgevingen. U kunt .NET-toepassingen publiceren met behulp van de .NET CLI of Visual Studio.

Wat is publiceren

Het publiceren van een .NET-app betekent het compileren van broncode voor het maken van een uitvoerbaar bestand of binair bestand, samen met de bijbehorende afhankelijkheden en gerelateerde bestanden, voor distributie. Nadat u de app hebt gepubliceerd, implementeert u de app in een server, distributieplatform, container of cloudomgeving. Het publicatieproces bereidt een app voor op implementatie en gebruik buiten een ontwikkelomgeving.

Publicatiemodi

Er zijn twee primaire manieren om een app te publiceren. Sommige factoren die van invloed zijn op deze beslissing, zijn onder andere of de implementatieomgeving de juiste .NET Runtime heeft geïnstalleerd en of u specifieke compilatiefuncties nodig hebt waarvoor de runtime moet worden gebundeld met uw app. De twee publicatiemodi zijn:

• Zelfstandig publiceren
  Deze modus produceert een publicatiemap met een platformspecifiek uitvoerbaar bestand dat wordt gebruikt om de app te starten, een gecompileerd binair bestand met app-code, eventuele app-afhankelijkheden en de .NET-runtime die nodig is om de app uit te voeren. In de omgeving waarop de app wordt uitgevoerd, hoeft de .NET-runtime niet vooraf te zijn geïnstalleerd.

• Frameworkafhankelijk publiceren
  Deze modus produceert een publicatiemap met een optioneel platformspecifiek uitvoerbaar bestand dat wordt gebruikt om de app te starten, een gecompileerd binair bestand met app-code en eventuele app-afhankelijkheden. De omgeving waarop de app wordt uitgevoerd, moet een versie van de .NET-runtime hebben geïnstalleerd die door de app kan worden gebruikt.

Basisbeginselen van publiceren

Met de <TargetFramework> instelling van het projectbestand wordt het standaarddoelframework opgegeven wanneer u uw app publiceert. U kunt het doelframework wijzigen in elke geldige Target Framework Moniker (TFM). Als uw project bijvoorbeeld gebruikt <TargetFramework>net9.0</TargetFramework>, wordt er een binair bestand gemaakt dat is gericht op .NET 9.

Als u meer dan één framework wilt toepassen, kunt u de <TargetFrameworks> instelling instellen op meerdere TFM-waarden, gescheiden door een puntkomma. Wanneer u uw app bouwt, wordt uw app gebouwd voor elk doelframework dat door uw project is gedefinieerd. Wanneer u uw app publiceert, moet u echter het doelframework opgeven:

dotnet publish -c Release -f net9.0

Draagbare binaire bestanden

Wanneer u een .NET-app publiceert, kunt u zich richten op een specifiek platform of een draagbaar binair bestand maken. Standaard publiceert .NET, zelfs wanneer u een draagbaar binair bestand maakt, een platformspecifiek uitvoerbaar bestand ('apphost') naast de draagbare DLL, tenzij u dit gedrag expliciet uitschakelt.

Het platformspecifieke uitvoerbare bestand wordt gemaakt vanwege de UseAppHost eigenschap, die standaard wordt gebruikt true. Als u alleen de draagbare DLL wilt publiceren zonder het platformspecifieke uitvoerbare bestand, stelt u deze in UseAppHostfalse op de opdrachtregel (-p:UseAppHost=false) of als projecteigenschap.

Het voordeel van het richten van een specifiek platform is dat het systeemeigen afhankelijkheden kan verwerken die uw app mogelijk vereist, waardoor compatibiliteit met de specifieke vereisten van het doelplatform wordt gewaarborgd.

Systeemeigen afhankelijkheden

Als uw app systeemeigen afhankelijkheden heeft, wordt deze mogelijk niet uitgevoerd op een ander besturingssysteem als deze wordt gepubliceerd als een draagbaar binair bestand. Apps die afhankelijk zijn van de Windows-API, worden bijvoorbeeld niet systeemeigen uitgevoerd op macOS of Linux. U moet platformspecifieke code opgeven en een uitvoerbaar bestand compileren voor elk platform.

Houd er ook rekening mee dat als een bibliotheek waarnaar u verwijst platformspecifieke afhankelijkheden biedt, uw app mogelijk niet op elk platform wordt uitgevoerd. Wanneer u echter een specifiek platform publiceert en richt, worden de platformspecifieke afhankelijkheden van een NuGet-pakket gekopieerd naar de publicatiemap.

Als u ervoor wilt zorgen dat uw app wordt gepubliceerd met de bijbehorende systeemeigen afhankelijkheden, publiceert u deze voor een specifiek platform:

dotnet publish -c Release -r <RID>

Zie de rid-catalogus (Runtime Identifier) voor een lijst met runtime-id's.

Frameworkafhankelijke implementatie

Frameworkafhankelijke implementatie is de standaardmodus wanneer u publiceert vanuit de CLI of Visual Studio. In deze modus wordt een platformspecifiek uitvoerbaar bestand gemaakt dat kan worden gebruikt om uw app te starten. Het platformspecifieke uitvoerbare bestand heeft een naam die lijkt op myapp.exe Windows of alleen myapp op andere platforms.

Uw app is geconfigureerd voor een specifieke versie van .NET. Deze beoogde .NET-runtime moet zich bevinden in de omgeving waarin uw app wordt uitgevoerd. Als uw app bijvoorbeeld is gericht op .NET 9, moet de .NET 9-runtime zijn geïnstalleerd in elke omgeving waarop uw app wordt uitgevoerd.

Als u een frameworkafhankelijke implementatie publiceert, wordt er een app gemaakt die automatisch wordt doorgestuurd naar de nieuwste .NET-beveiligingspatch die beschikbaar is in de omgeving waarop de app wordt uitgevoerd. Zie De .NET-versie selecteren die u wilt gebruiken voor meer informatie over versiebinding tijdens het compileren.

Voordelen

• Kleine implementatie: Alleen de app en de bijbehorende afhankelijkheden worden gedistribueerd. In de omgeving waarop de app wordt uitgevoerd, moet de .NET-runtime al zijn geïnstalleerd.
• Platformoverschrijdend: de app en elke . Bibliotheek op basis van NET wordt uitgevoerd op andere besturingssystemen.
• Maakt gebruik van de meest recente gepatchte runtime: de app maakt gebruik van de meest recente runtime die in de omgeving is geïnstalleerd.

Nadelen

• Vereist dat de runtime vooraf wordt geïnstalleerd: de app kan alleen worden uitgevoerd als de versie van .NET die is geïnstalleerd in de omgeving.
• .NET kan veranderen: de omgeving waarin de app wordt uitgevoerd, kan een nieuwere .NET-runtime gebruiken, waardoor het gedrag van apps kan worden gewijzigd.

Frameworkafhankelijke apps starten

Er zijn twee manieren om frameworkafhankelijke apps uit te voeren: via het platformspecifieke uitvoerbare bestand ('apphost') en via dotnet myapp.dll. U kunt het uitvoerbare bestand apphost rechtstreeks uitvoeren in plaats van aanroepen dotnet myapp.dll. Dit is nog steeds een acceptabele manier om de app uit te voeren. Waar mogelijk is het raadzaam om de apphost te gebruiken. Er zijn een aantal voordelen voor het gebruik van de apphost:

• Uitvoerbare bestanden lijken op standaard systeemeigen platformbestanden.
• Uitvoerbare namen blijven behouden in de procesnamen, wat betekent dat apps eenvoudig kunnen worden herkend op basis van hun namen.
• Omdat de apphost een systeemeigen binair bestand is, kunnen systeemeigen assets, zoals manifesten, eraan worden gekoppeld.
• Apphost heeft standaard beveiligingsbeperking op laag niveau toegepast, waardoor deze veiliger wordt. Control-flow Enforcement Technology (CET)-schaduwstack is bijvoorbeeld standaard ingeschakeld vanaf .NET 9. Toepassingen van mitigaties op dotnet zijn de laagste gemene deler van alle ondersteunde runtimes.

Publiceren

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

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

Zoekgedrag voor .NET-installatie configureren

Standaard detecteert en gebruikt de apphost een wereldwijd geïnstalleerde .NET-runtime, met installatielocaties die verschillen per platform. Zie Problemen met het starten van apps oplossen voor meer informatie over runtimedetectie en installatielocaties.

Het .NET Runtime-pad kan ook per uitvoering worden aangepast. De DOTNET_ROOT omgevingsvariabele kan worden gebruikt om naar de aangepaste locatie te verwijzen. Zie DOTNET_ROOT voor meer informatie over alle configuratieopties.

Over het algemeen is de beste praktijk voor het gebruik van DOTNET_ROOT:

1. Wis eerst DOTNET_ROOT omgevingsvariabelen; dat wil zeggen, alle omgevingsvariabelen die beginnen met tekst DOTNET_ROOT.
2. Stel DOTNET_ROOT in, en stel alleen DOTNET_ROOT in op het doelpad.
3. Voer de doel-apphost uit.

In .NET 9 en latere versies kunt u de .NET-installatiezoekpaden van het gepubliceerde uitvoerbare bestand configureren via de AppHostDotNetSearch en AppHostRelativeDotNet eigenschappen.

AppHostDotNetSearch hiermee kunt u een of meer locaties opgeven waar het uitvoerbare bestand zoekt naar een .NET-installatie:

• AppLocal: de map van het uitvoerbare app-bestand
• AppRelative: pad ten opzichte van het uitvoerbare bestand van de app
• EnvironmentVariable: waarde van DOTNET_ROOT[_<arch>] omgevingsvariabelen
• Global: geregistreerde en standaard algemene installatielocaties

AppHostRelativeDotNet geeft het pad ten opzichte van het uitvoerbare bestand dat wordt doorzocht wanneer AppHostDotNetSearch deze bevat AppRelative.

Zie , AppHostDotNetSearchen AppHostRelativeDotNet voor meer informatie.

DLL-implementatie op meerdere platforms

U kunt uw app ook publiceren als een platformoverschrijdende DLL zonder platformspecifiek uitvoerbaar bestand. In deze modus wordt een myapp.dll bestand gemaakt in de uitvoermap publiceren. Als u uw app wilt uitvoeren, gaat u naar de uitvoermap en gebruikt u de dotnet myapp.dll opdracht.

Publiceren als platformoverschrijdende DLL:

dotnet publish -c Release -p:UseAppHost=false

Zelfstandige implementatie

Wanneer u een zelfstandige implementatie (SCD) publiceert, maakt het publicatieproces een platformspecifiek uitvoerbaar bestand. Het publiceren van een SCD bevat alle vereiste .NET-bestanden om uw app uit te voeren, maar bevat niet de systeemeigen afhankelijkheden van .NET. Deze afhankelijkheden moeten aanwezig zijn in de omgeving voordat de app wordt uitgevoerd.

Als u een SCD publiceert, wordt er een app gemaakt die niet wordt doorgestuurd naar de nieuwste beschikbare .NET-beveiligingspatch. Zie De .NET-versie selecteren die u wilt gebruiken voor meer informatie over versiebinding tijdens het compileren.

Voordelen

• .NET-versie beheren: bepalen welke versie van .NET wordt geïmplementeerd met de app.
• Platformspecifieke targeting: omdat de app voor elk platform moet worden gepubliceerd, is duidelijk waar de app wordt uitgevoerd.

Nadelen

• Grotere implementaties: omdat de app de .NET-runtime en alle afhankelijkheden bevat, is de downloadgrootte en de benodigde schijfruimte groter dan een frameworkafhankelijke implementatie.
• Moeilijker om de .NET-versie bij te werken: de .NET Runtime kan alleen worden bijgewerkt door een nieuwe versie van de app uit te brengen.

Publiceren

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

Implementatie van één bestand

Wanneer u uw app publiceert als implementatie met één bestand, worden alle toepassingsafhankelijke bestanden gebundeld in één binair bestand. Dit implementatiemodel is beschikbaar voor zowel frameworkafhankelijke als zelfstandige toepassingen, wat een aantrekkelijke optie biedt voor het implementeren en distribueren van uw toepassing als één bestand.

Apps met één bestand zijn altijd specifiek voor het besturingssysteem en de architectuur. U moet publiceren voor elke configuratie, zoals Linux x64, Linux Arm64, Windows x64, enzovoort.

Voordelen

• Vereenvoudigde distributie: Implementeer en distribueer uw toepassing als één uitvoerbaar bestand.
• Minder onbelangrijke bestanden: alle afhankelijkheden worden gebundeld, waardoor het niet meer nodig is om meerdere bestanden te beheren.
• Eenvoudige implementatie: Kopieer één bestand om de toepassing te implementeren.

Nadelen

• Grotere bestandsgrootte: het ene bestand bevat alle afhankelijkheden, waardoor het groter is dan afzonderlijke bestanden.
• Trager opstarten: bestanden moeten tijdens runtime worden geëxtraheerd, wat van invloed kan zijn op de opstartprestaties.
• Platformspecifiek: moet afzonderlijke bestanden publiceren voor elk doelplatform.

Implementatie van één bestand kan worden gecombineerd met andere optimalisaties, zoals bijsnijden en ReadyToRun-compilatie voor verdere optimalisatie.

Zie Implementatie met één bestand voor meer informatie over implementatie met één bestand.

Publiceren

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

Systeemeigen AOT-implementatie

Systeemeigen AOT-implementatie compileert uw app rechtstreeks naar systeemeigen code, waardoor er geen runtime meer nodig is. Deze publicatieoptie maakt gebruik van de zelfstandige implementatiemodus , omdat de gecompileerde systeemeigen code alles moet bevatten dat nodig is om de toepassing uit te voeren. Dit resulteert in snellere opstarttijden en minder geheugengebruik, maar heeft enkele beperkingen voor ondersteunde functies.

Voordelen

• Snel opstarten: er is geen JIT-compilatie nodig tijdens runtime, waardoor de toepassing sneller kan worden opgestart.
• Verminderd geheugengebruik: lagere geheugenvoetafdruk vergeleken met traditionele .NET-toepassingen.
• Geen runtime-afhankelijkheid: de toepassing wordt uitgevoerd zonder dat .NET Runtime hoeft te worden geïnstalleerd.
• Kleinere implementatiegrootte: vaak kleiner dan zelfstandige implementatie met de volledige runtime.

Nadelen

• Beperkte frameworkondersteuning: Niet alle .NET-functies en -bibliotheken zijn compatibel met Systeemeigen AOT.
• Langere buildtijden: compilatie naar systeemeigen code duurt langer dan gewone builds.
• Platformspecifiek: moet afzonderlijk worden gecompileerd voor elk doelplatform en elke architectuur.
• Beperkingen voor foutopsporing: complexere foutopsporingservaring vergeleken met reguliere .NET-toepassingen.

Zie Systeemeigen AOT-implementatie voor meer informatie over systeemeigen AOT-implementatie.

Publiceren

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

ReadyToRun-implementatie

Wanneer u uw app publiceert met ReadyToRun-compilatie, worden uw toepassingsassembly's gecompileerd als ReadyToRun-indeling (R2R). R2R is een vorm van vooraf uitgevoerde compilatie (AOT) die de opstartprestaties verbetert door de hoeveelheid werk te verminderen die de JIT-compiler (Just-In-Time) moet doen wanneer uw toepassing wordt geladen. Deze publicatieoptie kan worden gebruikt met zowel frameworkafhankelijke als zelfstandige implementatiemodi.

Binaire ReadyToRun-bestanden bevatten zowel tussenliggende taalcode (IL) als de systeemeigen versie van dezelfde code. Hoewel binaire R2R-bestanden groter zijn dan gewone assembly's, bieden ze betere opstartprestaties.

Voordelen

• Verbeterde opstarttijd: de app besteedt minder tijd aan het uitvoeren van de JIT-compiler tijdens het opstarten.
• Betere prestaties voor het eerste gebruik: verminderde latentie voor de eerste keer uitvoeren van codepaden.
• Compatibel met bestaande code: werkt met de meeste .NET-bibliotheken en frameworks zonder aanpassingen.
• Flexibele implementatie: kan worden gecombineerd met zowel frameworkafhankelijke implementatie als zelfstandige implementatiemodi .

Nadelen

• Groter: de app is groter op schijf vanwege zowel IL als systeemeigen code.
• Langere buildtijden: Compilatie kost meer tijd dan standaardpublicatie.
• Platformspecifieke optimalisaties: De beste prestatieverbeteringen vereisen specifieke platforms.

Publiceren

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

Zie ReadyToRun-compilatie voor meer informatie over de implementatie van ReadyToRun.

Containerimplementatie

Wanneer u uw app publiceert als een container, worden uw toepassing en de bijbehorende afhankelijkheden door de .NET SDK in een containerinstallatiekopieën verpakt zonder dat hiervoor een afzonderlijk Dockerfile nodig is. Met deze implementatiemodus maakt u een volledige containerinstallatiekopieën die kunnen worden uitgevoerd op elke containerruntime, zoals Docker of Podman. Containerimplementatie vereenvoudigt het containerisatieproces door het schrijven en onderhouden van Dockerfiles te elimineren en tegelijkertijd geoptimaliseerde basisinstallatiekopieën te bieden.

Vanaf .NET SDK 8.0.200 is containerondersteuning standaard opgenomen en zijn er geen extra NuGet-pakketten vereist. Voor consoletoepassingen moet u containerondersteuning mogelijk expliciet inschakelen door de EnableSdkContainerSupport eigenschap in te stellen op true.

Voordelen

• Vereenvoudigde containerisatie: u hoeft geen Dockerfiles te schrijven of te onderhouden voor basisscenario's.
• Geoptimaliseerde basisinstallatiekopieën: maakt gebruik van door Microsoft geleverde, geoptimaliseerde basisinstallatiekopieën met de nieuwste beveiligingsupdates.
• Consistente omgeving: zorgt voor een consistente runtime-omgeving voor ontwikkeling, testen en productie.
• Eenvoudige distributie: Containerinstallatiekopieën kunnen eenvoudig worden gedeeld en geïmplementeerd in verschillende omgevingen.
• Platformisolatie: toepassingen worden uitgevoerd in geïsoleerde containers, waardoor conflicten tussen toepassingen worden verminderd.

Nadelen

• Afhankelijkheid van containerruntime: in de doelomgeving moet een containerruntime zijn geïnstalleerd.
• Grootte van installatiekopieën: containerinstallatiekopieën zijn doorgaans groter dan andere implementatiemethoden.
• Leercurve: vereist inzicht in containerconcepten en hulpprogramma's.
• Beperkte aanpassing: Minder flexibiliteit vergeleken met aangepaste Dockerfiles voor complexe scenario's.

Publiceren

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

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

Zie het overzicht van het maken van .NET SDK-containers voor meer informatie over containerimplementatie.

Zie ook

• RID-catalogus (.NET Runtime Identifier)
• Selecteer de .NET-versie die u wilt gebruiken
• Publiceren voor macOS