Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
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.
Zie Tutorial: Een .NET-consoletoepassing publiceren voor een korte zelfstudie over publiceren.
Zie Tutorial: Een .NET-consoletoepassing publiceren voor een korte zelfstudie over publiceren.
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 de app kan gebruiken.
Belangrijk
U geeft het doelplatform op met een runtime-id (RID). Zie .NET RID-catalogus voor meer informatie over RID's.
Basisbeginselen van publiceren
Met de 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 <TargetFramework>net9.0</TargetFramework> gebruikt, wordt er een binair bestand gemaakt dat is gericht op .NET 9.
Als u meer dan één framework wilt toepassen, kunt u de 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:
De standaard buildconfiguratiemodus is Release, tenzij gewijzigd met de parameter.
dotnet publish -c Release -f net9.0
De standaarduitvoermap van de opdracht is . Publiceert bijvoorbeeld naar . U kunt echter kiezen voor een vereenvoudigd uitvoerpad en een mapstructuur voor alle build-uitvoer. Zie Indeling van artefactenuitvoer voor meer informatie.
Maak in Visual Studio afzonderlijke publicatieprofielen voor elk doelframework.
Draagbare binaire bestanden
Wanneer u een .NET-app publiceert, kunt u zich richten op een specifiek platform of een draagbaar binair bestand maken. Zelfs wanneer u een draagbaar binair bestand maakt, publiceert .NET standaard een platformspecifiek uitvoerbaar uitvoerbaar bestand ('apphost') naast de draagbare DLL, tenzij u dit gedrag expliciet uitschakelt.
Het platformspecifieke uitvoerbare bestand wordt gemaakt vanwege de eigenschap, die standaard wordt gebruikt . Als u alleen de draagbare DLL wilt publiceren zonder het platformspecifieke uitvoerbare bestand, stelt u deze in op de opdrachtregel () 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. Echter, wanneer u op 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>
-c ReleaseMet deze switch wordt de buildconfiguratie ingesteld op Release, die is geoptimaliseerd voor productie-implementatie.
-r <RID>Deze switch maakt gebruik van een runtime-id (RID) om het doelplatform op te geven en zorgt ervoor dat systeemeigen afhankelijkheden worden opgenomen (indien nodig). Zie de rid-catalogus (Runtime Identifier) voor een lijst met runtime-id's.
- Klik met de rechtermuisknop op het project in Solution Explorer en selecteer Publicatie.
- Als dit de eerste keer is dat u publiceert, selecteert u Map als publicatiedoel en selecteert u Volgende.
- Kies een maplocatie of accepteer de standaardwaarde en selecteer Voltooien.
- Selecteer alle instellingen weergeven in het publicatieprofiel.
- Stel Target Runtime in op het gewenste platform (bijvoorbeeld win-x64 voor 64-bits Windows).
- Selecteer Opslaan en vervolgens Publiceren.
Zie de rid-catalogus (Runtime Identifier) voor een lijst met runtime-id's.
Snelzoekgids
De volgende tabel bevat snelle voorbeelden van het publiceren van uw app.
| Publicatiemodus | Bevelen |
|---|---|
| Frameworkafhankelijke implementatie | dotnet publish -c Release [-r <RID>] |
| Frameworkafhankelijke implementatie (DLL) | dotnet publish -c Release -p:UseAppHost=false |
| Zelfstandige implementatie | dotnet publish -c Release [-r <RID>] --self-contained true |
| Implementatie van één bestand | dotnet publish -c Release [-r <RID>] -p:PublishSingleFile=true |
| Systeemeigen AOT-implementatie | dotnet publish -c Release [-r <RID>] -p:PublishAot=true |
| ReadyToRun-implementatie | dotnet publish -c Release [-r <RID>] -p:PublishReadyToRun=true |
| Containerinzet | dotnet publish -c Release [-r <RID>] -t:PublishContainer |
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 op Windows of gewoon myapp op andere platforms.
Uw app is geconfigureerd voor een specifieke versie van .NET. Deze doel-.NET runtime moet zich bevinden in de omgeving waarin uw app wordt uitgevoerd. Als uw app bijvoorbeeld is gericht op .NET 9, moet voor elke omgeving waarop uw app wordt uitgevoerd de .NET 9 runtime zijn geïnstalleerd.
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 Selecteer de .NET-versie 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.
- Cross-platform: De app en een 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 vooraf te installeren runtime: De app werkt alleen als de versie van .NET al aanwezig is 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 . U kunt het uitvoerbare bestand apphost rechtstreeks uitvoeren in plaats van aanroepen . 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. Zo is de schaduwstack van Control-flow Enforcement Technology (CET) standaard ingeschakeld vanaf .NET 9. Toepassingen van mitigaties op zijn de laagste gemene deler van alle ondersteunde runtimes.
Publiceren
dotnet publish -c Release [-r <RID>]
-c ReleaseMet deze switch wordt de buildconfiguratie ingesteld op Release, die is geoptimaliseerd voor productie-implementatie.
-r <RID>Deze switch maakt gebruik van een runtime-id (RID) om het doelplatform op te geven en zorgt ervoor dat systeemeigen afhankelijkheden worden opgenomen (indien nodig). Zie de rid-catalogus (Runtime Identifier) voor een lijst met runtime-id's.
Of expliciet:
dotnet publish -c Release [-r <RID>] --self-contained false
--self-contained falseDeze optie zorgt ervoor dat de .NET SDK expliciet een frameworkafhankelijke implementatie maakt.
- Klik met de rechtermuisknop op het project in Solution Explorer en selecteer Publicatie.
- Als dit de eerste keer is dat u publiceert, selecteert u Map als publicatiedoel en selecteert u Volgende.
- Kies een maplocatie of accepteer de standaardwaarde en selecteer Voltooien.
- Selecteer alle instellingen weergeven in het publicatieprofiel.
- Stel de implementatiemodusin op Frameworkafhankelijk (dit is de standaardinstelling).
- Stel Target Runtime in op het gewenste platform (bijvoorbeeld win-x64 voor 64-bits Windows).
- Selecteer Opslaan en vervolgens Publiceren.
.NET-installatiezoekgedrag 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 runtimepad kan ook per uitvoering worden aangepast. De omgevingsvariabele kan worden gebruikt om naar de aangepaste locatie te verwijzen. Zie DOTNET_ROOT voor meer informatie over alle configuratieopties voor .
Over het algemeen is de beste praktijk voor het gebruik van :
- Wis eerst omgevingsvariabelen; dat wil zeggen, alle omgevingsvariabelen die beginnen met tekst .
- Stel in, en stel alleen in op het doelpad.
- Voer de doel-apphost uit.
In .NET 9 en latere versies kunt u de .NET installatiezoekpaden van het gepubliceerde uitvoerbare bestand configureren via de eigenschappen AppHostDotNetSearch en AppHostRelativeDotNet.
AppHostDotNetSearch staat het opgeven van een of meer locaties toe waar het uitvoerbare bestand zoekt naar een .NET installatie:
- : de map van het uitvoerbare app-bestand
- : pad relatief aan het uitvoerbare app-bestand
- : waarde van omgevingsvariabelen
- : geregistreerde en standaard algemene installatielocaties
specificeert het pad ten opzichte van het uitvoerbare bestand dat wordt doorzocht wanneer bevat.
Zie voor meer informatie , en installatielocatie-opties in apphost .
DLL-implementatie op meerdere platforms
U kunt uw app ook publiceren als een platformoverschrijdende DLL zonder platformspecifiek uitvoerbaar bestand. In deze modus wordt een bestand gemaakt in de uitvoermap publiceren. Als u uw app wilt uitvoeren, gaat u naar de uitvoermap en gebruikt u de opdracht.
Publiceren als platformoverschrijdende DLL:
dotnet publish -c Release -p:UseAppHost=false
-c ReleaseMet deze switch wordt de buildconfiguratie ingesteld op Release, die is geoptimaliseerd voor productie-implementatie.
-p:UseAppHost=falseMet deze eigenschap wordt het maken van een platformspecifiek uitvoerbaar bestand uitgeschakeld, waardoor alleen de draagbare DLL wordt geproduceerd.
- Klik met de rechtermuisknop op het project in Solution Explorer en selecteer Publicatie.
- Als dit de eerste keer is dat u publiceert, selecteert u Map als publicatiedoel en selecteert u Volgende.
- Kies een maplocatie of accepteer de standaardwaarde en selecteer Voltooien.
- Selecteer alle instellingen weergeven in het publicatieprofiel.
- Stel de implementatiemodusin op Frameworkafhankelijk.
- Schakel Produce single file uit.
- Stel Target Runtime in op Portable (of laat leeg).
- Selecteer Opslaan en vervolgens Publiceren.
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 meest recente beschikbare .NET beveiligingspatch. Zie Selecteer de .NET-versie die u wilt gebruiken voor meer informatie over versiebinding tijdens het compileren.
Voordelen
- Control .NET version: 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
- Larger-implementaties: Omdat de app de .NET runtime en alle afhankelijkheden bevat, is de benodigde downloadgrootte en hardeschijfruimte groter dan een frameworkafhankelijke implementatie.
- Moeilijker te updaten naar de .NET-versie: de .NET Runtime kan alleen worden bijgewerkt door een nieuwe versie van de app uit te brengen.
Fooi
U kunt de totale grootte van compatibele zelf-ingesloten apps verkleinen door ingekort te publiceren of door de invariante modus voor globalisatie in te schakelen. Zie .NET Globalization Invariant Mode voor meer informatie over de invariantmodus voor globalisatie.
Publiceren
dotnet publish -c Release -r <RID> --self-contained true
-c ReleaseMet deze switch wordt de buildconfiguratie ingesteld op Release, die is geoptimaliseerd voor productie-implementatie.
-r <RID>Deze switch maakt gebruik van een runtime-id (RID) om het doelplatform op te geven en zorgt ervoor dat systeemeigen afhankelijkheden worden opgenomen (indien nodig). Zie de rid-catalogus (Runtime Identifier) voor een lijst met runtime-id's.
--self-contained trueDeze schakelaar instrueert de .NET SDK om een uitvoerbaar bestand te maken voor een zelfstandige distributie (SCD).
- Klik met de rechtermuisknop op het project in Solution Explorer en selecteer Publicatie.
- Als dit de eerste keer is dat u publiceert, selecteert u Map als publicatiedoel en selecteert u Volgende.
- Kies een maplocatie of accepteer de standaardwaarde en selecteer Voltooien.
- Selecteer alle instellingen weergeven in het publicatieprofiel.
- Stel de implementatiemodusin op Zelfstandig.
- Stel Target Runtime in op het gewenste platform (bijvoorbeeld win-x64 voor 64-bits Windows).
- Selecteer Opslaan en vervolgens Publiceren.
Uitrol 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 de opstartprestaties kan beïnvloeden.
- 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
-c ReleaseMet deze switch wordt de buildconfiguratie ingesteld op Release, die is geoptimaliseerd voor productie-implementatie.
-r <RID>Deze switch maakt gebruik van een runtime-id (RID) om het doelplatform op te geven en zorgt ervoor dat systeemeigen afhankelijkheden worden opgenomen (indien nodig). Zie de rid-catalogus (Runtime Identifier) voor een lijst met runtime-id's.
-p:PublishSingleFile=trueMet deze eigenschap worden alle toepassingsafhankelijke bestanden gebundeld in één binair bestand.
- Klik met de rechtermuisknop op het project in Solution Explorer en selecteer Publicatie.
- Als dit de eerste keer is dat u publiceert, selecteert u Map als publicatiedoel en selecteert u Volgende.
- Kies een maplocatie of accepteer de standaardwaarde en selecteer Voltooien.
- Selecteer alle instellingen weergeven in het publicatieprofiel.
- Stel de implementatiemodusin op zelfstandige of frameworkafhankelijke modus.
- Stel Target Runtime in op het gewenste platform (bijvoorbeeld win-x64 voor 64-bits Windows).
- Controleer Single file aanmaken.
- Selecteer Opslaan en vervolgens Publiceren.
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.
- Herduceerd geheugengebruik: lagere geheugenvoetafdruk vergeleken met traditionele .NET toepassingen.
- No 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 ondersteuning van frameworks: Niet alle .NET-functies en bibliotheken zijn compatibel met Native AOT.
- Langere buildtijden: compilatie naar systeemeigen code duurt langer dan gewone builds.
- Platformspecifiek: moet afzonderlijk worden gecompileerd voor elk doelplatform en elke architectuur.
- Debugging-beperkingen: 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
-c ReleaseMet deze switch wordt de buildconfiguratie ingesteld op Release, die is geoptimaliseerd voor productie-implementatie.
-r <RID>Deze switch maakt gebruik van een runtime-id (RID) om het doelplatform op te geven en zorgt ervoor dat systeemeigen afhankelijkheden worden opgenomen (indien nodig). Zie de rid-catalogus (Runtime Identifier) voor een lijst met runtime-id's.
-p:PublishAot=trueMet deze eigenschap wordt systeemeigen AOT-compilatie ingeschakeld, waarmee de app rechtstreeks naar systeemeigen code wordt gecompileerd.
Systeemeigen AOT-publicatie moet worden geconfigureerd in het projectbestand. U kunt deze niet inschakelen via de Visual Studio publicatiegebruikersinterface.
Klik in Solution Explorer met de rechtermuisknop op het project en selecteer Projectbestand bewerken.
Voeg de volgende eigenschap toe aan een :
<PublishAot>true</PublishAot>Sla het projectbestand op.
Klik met de rechtermuisknop op het project in Solution Explorer en selecteer Publicatie.
Als dit de eerste keer is dat u publiceert, selecteert u Map als publicatiedoel en selecteert u Volgende.
Kies een maplocatie of accepteer de standaardwaarde en selecteer Voltooien.
Selecteer alle instellingen weergeven in het publicatieprofiel.
Stel de implementatiemodusin op Zelfstandig.
Stel Target Runtime in op het gewenste platform (bijvoorbeeld win-x64 voor 64-bits Windows).
Selecteer Opslaan en vervolgens Publiceren.
Zie Systeemeigen AOT-implementatie voor meer informatie over systeemeigen AOT-implementatie.
ReadyToRun-implementatie
Wanneer u uw app publiceert met ReadyToRun-compilatie, worden uw assemblies van de toepassing gecompileerd in het ReadyToRun (R2R) formaat. 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.
- Compatible 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
- Grotere grootte: De app neemt meer schijfruimte in beslag omdat hij zowel IL- als systeemeigen code bevat.
- Langere buildtijden: Compilatie kost meer tijd dan standaardpublicatie.
- Platformspecifieke optimalisaties: De grootste prestatieverbeteringen vereisen gerichte aandacht op specifieke platforms.
Publiceren
dotnet publish -c Release -r <RID> -p:PublishReadyToRun=true
-c ReleaseMet deze switch wordt de buildconfiguratie ingesteld op Release, die is geoptimaliseerd voor productie-implementatie.
-r <RID>Deze switch maakt gebruik van een runtime-id (RID) om het doelplatform op te geven en zorgt ervoor dat systeemeigen afhankelijkheden worden opgenomen (indien nodig). Zie de rid-catalogus (Runtime Identifier) voor een lijst met runtime-id's.
-p:PublishReadyToRun=trueDeze eigenschap maakt ReadyToRun-compilatie mogelijk, waardoor de opstartprestaties worden verbeterd door assembly's vooraf te compileren.
- Klik met de rechtermuisknop op het project in Solution Explorer en selecteer Publicatie.
- Als dit de eerste keer is dat u publiceert, selecteert u Map als publicatiedoel en selecteert u Volgende.
- Kies een maplocatie of accepteer de standaardwaarde en selecteer Voltooien.
- Selecteer alle instellingen weergeven in het publicatieprofiel.
- Stel de implementatiemodusin op zelfstandige of frameworkafhankelijke modus.
- Stel Target Runtime in op het gewenste platform (bijvoorbeeld win-x64 voor 64-bits Windows).
- Controleer De compilatie ReadyToRun inschakelen.
- Selecteer Opslaan en vervolgens Publiceren.
Zie ReadyToRun-compilatie voor meer informatie over de implementatie van ReadyToRun.
Containerimplementatie
Wanneer u uw app publiceert als een container, verpakt de .NET SDK uw toepassing en de bijbehorende afhankelijkheden in een containerinstallatiekopieën zonder dat hiervoor een afzonderlijk Dockerfile nodig is. Met deze implementatiemodus maak je een volledige containerimage die kan 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 eigenschap in te stellen op .
Fooi
Zie Containerize a .NET app reference voor meer informatie over projectinstellingen met betrekking tot containers.
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: Containerafbeeldingen kunnen eenvoudig worden gedeeld en ingezet 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 containerafbeeldingen: containerafbeeldingen 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
-c ReleaseMet deze switch wordt de buildconfiguratie ingesteld op Release, die is geoptimaliseerd voor productie-implementatie.
-r <RID>Deze switch maakt gebruik van een runtime-id (RID) om het doelplatform op te geven en zorgt ervoor dat systeemeigen afhankelijkheden worden opgenomen (indien nodig). Zie de rid-catalogus (Runtime Identifier) voor een lijst met runtime-id's.
-t:PublishContainernl-NL: Deze taak publiceert de toepassing als een containerafbeelding.
U kunt ook de publicatieprofielbenadering gebruiken:
dotnet publish -c Release [-r <RID>] -p:PublishProfile=DefaultContainer
-p:PublishProfile=DefaultContainerMet dit profiel wordt het proces voor het publiceren van containers geactiveerd.
- Klik met de rechtermuisknop op het project in Solution Explorer en selecteer Publicatie.
- Selecteer Container Registry als het publicatiedoel en selecteer Volgende.
- Kies het doelcontainerregister (zoals Azure Container Registry, Docker Hub of Generic Registry) en selecteer Volgend.
- Configureer de details en verificatie van de registerverbinding.
- Selecteer alle instellingen weergeven in het publicatieprofiel.
- Stel de implementatiemodusin op zelfstandig of frameworkafhankelijk op basis van uw behoeften.
- Stel Target Runtime in op het gewenste platform (bijvoorbeeld linux-x64 voor Linux-containers ).
- Configureer containerspecifieke instellingen, zoals de afbeeldingsnaam en tags.
- Selecteer Opslaan en vervolgens Publiceren.
Zie Overzicht van het maken van .NET SDK-containers voor meer informatie over de implementatie van containers.
Zie ook
- .NET Runtime Identifier (RID)-catalogus
- Selecteer de .NET-versie die u wilt gebruiken
- Publiceren voor macOS