Udostępnij za pośrednictwem

Omówienie publikowania aplikacji .NET

W tym artykule wyjaśniono różne sposoby publikowania aplikacji .NET. Obejmuje on tryby publikowania, sposób tworzenia plików wykonywalnych i plików binarnych międzyplatformowych oraz wpływ każdego podejścia do środowisk wdrażania i środowiska uruchomieniowego. Aplikacje .NET można publikować przy użyciu interfejsu wiersza polecenia .NET lub Visual Studio.

Aby zapoznać się z krótkim samouczkiem dotyczącym publikowania, zobacz Tutorial: Publikowanie aplikacji konsolowej .NET.

Aby zapoznać się z krótkim samouczkiem dotyczącym publikowania, zobacz Tutorial: Publikowanie aplikacji konsolowej .NET.

Co to jest publikowanie

Publikowanie aplikacji .NET oznacza kompilowanie kodu źródłowego w celu utworzenia pliku wykonywalnego lub binarnego wraz z jego zależnościami i powiązanymi plikami na potrzeby dystrybucji. Po opublikowaniu należy wdrożyć aplikację na serwerze, platformie dystrybucyjnej, kontenerze lub w środowisku chmury. Proces publikowania przygotowuje aplikację do wdrożenia i użycia poza środowiskiem deweloperów.

Tryby publikowania

Istnieją dwa podstawowe sposoby publikowania aplikacji. Niektóre czynniki wpływające na tę decyzję obejmują to, czy środowisko wdrażania ma zainstalowane odpowiednie środowisko uruchomieniowe .NET oraz czy potrzebujesz określonych funkcji kompilacji, które wymagają łączenia środowiska uruchomieniowego z aplikacją. Dwa tryby publikowania to:

  • Publikowanie jako samodzielna aplikacja
    Ten tryb tworzy folder publikowania zawierający plik wykonywalny specyficzny dla platformy używany do uruchamiania aplikacji, skompilowany plik binarny zawierający kod aplikacji, wszystkie zależności aplikacji i środowisko uruchomieniowe .NET wymagane do uruchomienia aplikacji. Środowisko uruchamiające aplikację nie musi mieć wstępnie zainstalowanego środowiska uruchomieniowego .NET.

  • Publikowanie zależne od platformy
    Ten tryb tworzy folder publikowania zawierający opcjonalny plik wykonywalny specyficzny dla platformy używany do uruchamiania aplikacji, skompilowanego pliku binarnego zawierającego kod aplikacji i wszystkich zależności aplikacji. Środowisko, w którym działa aplikacja, musi mieć zainstalowaną wersję środowiska uruchomieniowego .NET, którego może używać aplikacja.

Ważne

Należy określić platformę docelową z identyfikatorem środowiska uruchomieniowego (RID). Aby uzyskać więcej informacji na temat identyfikatorów RID, zobacz Katalog RID .NET.

Podstawy publikowania

Ustawienie <TargetFramework> pliku projektu określa domyślną strukturę docelową podczas publikowania aplikacji. Możesz zmienić docelowy framework na dowolny prawidłowy Target Framework Moniker (TFM). Jeśli na przykład projekt używa <TargetFramework>net9.0</TargetFramework>, zostanie utworzony plik binarny dla .NET 9.

Jeśli chcesz obsługiwać więcej niż jeden framework, możesz ustawić opcję <TargetFrameworks> na wiele wartości TFM, rozdzielonych średnikiem. Podczas tworzenia aplikacji aplikacja jest kompilowana dla każdej platformy docelowej zdefiniowanej przez projekt. Jednak podczas publikowania aplikacji należy określić strukturę docelową:

Domyślny tryb konfiguracji kompilacji to Wydanie, chyba że zostanie zmieniony przy użyciu parametru -c .

dotnet publish -c Release -f net9.0

Domyślny wyjściowy katalog polecenia dotnet publish to ./bin/<BUILD-CONFIGURATION>/<TFM>/publish/. Na przykład dotnet publish -c Release -f net9.0 publikuje do ./bin/Release/net9.0/publish/. Można jednak wyrazić zgodę na uproszczoną strukturę ścieżki wyjściowej i folderu dla wszystkich danych wyjściowych kompilacji. Aby uzyskać więcej informacji, zobacz Układ danych wyjściowych artefaktów.

W Visual Studio utwórz oddzielne profile publikowania dla każdej platformy docelowej.

Przenośne pliki binarne

Podczas publikowania aplikacji .NET można wybrać konkretną platformę lub utworzyć przenośny plik binarny. Domyślnie nawet podczas tworzenia przenośnego pliku binarnego .NET publikuje plik wykonywalny specyficzny dla platformy ("apphost") obok przenośnej biblioteki DLL, chyba że jawnie wyłączysz to zachowanie.

Plik wykonywalny specyficzny dla platformy jest tworzony ze względu na właściwość UseAppHost, która domyślnie ma wartość true. Aby opublikować tylko przenośną bibliotekę DLL bez pliku wykonywalnego specyficznego dla platformy, ustaw UseAppHostfalse w wierszu polecenia (-p:UseAppHost=false) lub jako właściwość projektu.

Zaletą kierowania do określonej platformy jest to, że może obsługiwać natywne zależności , których aplikacja może wymagać, zapewniając zgodność z określonymi wymaganiami platformy docelowej.

Zależności natywne

Jeśli aplikacja ma natywne zależności, może nie działać w innym systemie operacyjnym, jeśli zostanie opublikowana jako przenośny plik binarny. Na przykład aplikacje zależne od interfejsu API Windows nie działają natywnie w systemach macOS lub Linux. Należy podać kod specyficzny dla platformy i skompilować plik wykonywalny dla każdej platformy.

Rozważ również, jeśli biblioteka, do której odwołujesz się, udostępnia zależności specyficzne dla platformy, aplikacja może nie działać na każdej platformie. Jednak podczas publikowania i określania celu określonej platformy zależności specyficzne dla platformy pakietu NuGet są kopiowane do folderu publikowania.

Aby upewnić się, że aplikacja została opublikowana z natywnymi zależnościami, opublikuj dla określonej platformy:

dotnet publish -c Release -r <RID>

  • -c Release

    Ten przełącznik ustawia tryb kompilacji na Release, który jest zoptymalizowany na produkcję.

  • -r <RID>

    Ten przełącznik używa identyfikatora środowiska uruchomieniowego (RID) do określenia platformy docelowej i zapewnia, że zależności natywne są uwzględniane (jeśli jest to wymagane). Aby uzyskać listę identyfikatorów środowiska uruchomieniowego, zobacz wykaz identyfikatorów środowiska uruchomieniowego (RID).

  1. Kliknij prawym przyciskiem myszy projekt w Solution Explorer i wybierz pozycję Publish.
  2. Jeśli po raz pierwszy publikujesz, wybierz pozycję Folder jako element docelowy publikowania, a następnie wybierz pozycję Dalej.
  3. Wybierz lokalizację folderu lub zaakceptuj wartość domyślną, a następnie wybierz pozycję Zakończ.
  4. W profilu publikowania wybierz pozycję Pokaż wszystkie ustawienia.
  5. Ustaw Target Runtime na odpowiednią platformę (na przykład win-x64 dla 64-bitowej Windows).
  6. Wybierz pozycję Zapisz , a następnie pozycję Publikuj.

Aby uzyskać listę identyfikatorów środowiska uruchomieniowego, zobacz wykaz identyfikatorów środowiska uruchomieniowego (RID).

Krótki przewodnik

Poniższa tabela zawiera krótkie przykłady sposobu publikowania aplikacji.

Tryb publikowania Polecenie
Wdrożenie zależne od struktury dotnet publish -c Release [-r <RID>]
Wdrożenie zależne od struktury (DLL) dotnet publish -c Release -p:UseAppHost=false
Wdrożenie samodzielne dotnet publish -c Release [-r <RID>] --self-contained true
Wdrażanie pojedynczego pliku dotnet publish -c Release [-r <RID>] -p:PublishSingleFile=true
Wdrożenie natywnej usługi AOT dotnet publish -c Release [-r <RID>] -p:PublishAot=true
Gotowe do uruchomienia wdrożenia dotnet publish -c Release [-r <RID>] -p:PublishReadyToRun=true
Wdrażanie kontenera dotnet publish -c Release [-r <RID>] -t:PublishContainer

Wdrożenie zależne od struktury

Wdrożenie zależne od platformy jest domyślnym trybem podczas publikowania za pomocą interfejsu wiersza poleceń lub Visual Studio. W tym trybie tworzony jest plik wykonywalny specyficzny dla platformy, który może służyć do uruchamiania aplikacji. Plik wykonywalny specyficzny dla platformy nosi nazwę podobną do myapp.exe na Windows lub po prostu myapp na innych platformach.

Aplikacja jest skonfigurowana do obsługiwania określonej wersji .NET. To docelowe środowisko uruchomieniowe .NET musi znajdować się w środowisku, w którym działa aplikacja. Jeśli na przykład aplikacja jest przeznaczona dla .NET 9, każde środowisko uruchomione przez aplikację musi mieć zainstalowane środowisko uruchomieniowe .NET 9.

Opublikowanie wdrożenia zależnego od platformy tworzy aplikację, która automatycznie aktualizuje się do najnowszej poprawki zabezpieczeń .NET dostępnej w środowisku, w którym działa aplikacja. Aby uzyskać więcej informacji na temat powiązania wersji w czasie kompilacji, zobacz Wybierz wersję .NET do użycia.

Zalety

  • Małe wdrożenie: dystrybuowane są tylko aplikacje i jej zależności. Środowisko, w którym jest uruchomiona aplikacja, musi mieć już zainstalowane środowisko uruchomieniowe .NET.
  • Cross-platform: aplikacja i dowolna biblioteka oparta na .NET działa w innych systemach operacyjnych.
  • Używa najnowszego środowiska uruchomieniowego z poprawkami: aplikacja używa najnowszego środowiska uruchomieniowego zainstalowanego w środowisku.

Niedogodności

  • Wymaga wstępnie instalowania środowiska uruchomieniowego: aplikacja może działać tylko wtedy, gdy wersja .NET jest już zainstalowana w środowisku.
  • .NET może ulec zmianie: Środowisko, w którym jest uruchamiana aplikacja, może używać nowszego środowiska uruchomieniowego .NET, co może zmienić zachowanie aplikacji.

Uruchamianie aplikacji zależnych od platformy

Istnieją dwa sposoby uruchamiania aplikacji zależnych od platformy: za pośrednictwem pliku wykonywalnego specyficznego dla platformy ("apphost") i za pośrednictwem .dotnet myapp.dll Możesz uruchomić plik wykonywalny apphost bezpośrednio zamiast wywoływać dotnet myapp.dll, co jest nadal akceptowalnym sposobem uruchamiania aplikacji. Jeśli to możliwe, zaleca się użycie hosta apphost. Korzystanie z hosta apphost ma wiele zalet:

  • Pliki wykonywalne są wyświetlane jak standardowe pliki wykonywalne platformy natywnej.
  • Nazwy wykonywalne są zachowywane w nazwach procesów, co oznacza, że aplikacje można łatwo rozpoznać na podstawie ich nazw.
  • Ponieważ apphost jest natywnym plikiem binarnym, można do niego dołączać natywne zasoby, takie jak manifesty.
  • Apphost ma domyślnie zastosowane środki zaradcze zabezpieczeń niskiego poziomu, które zwiększają jego bezpieczeństwo. Na przykład stos wymuszania przepływu sterowania (CET) jest domyślnie włączony od .NET 9. Zastosowane działania zaradcze dla dotnet to najniższy wspólny mianownik wszystkich wspieranych środowisk uruchomieniowych.

Opublikuj

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

  • -c Release

    Ten przełącznik ustawia tryb kompilacji na Release, który jest zoptymalizowany na produkcję.

  • -r <RID>

    Ten przełącznik używa identyfikatora środowiska uruchomieniowego (RID) do określenia platformy docelowej i zapewnia, że zależności natywne są uwzględniane (jeśli jest to wymagane). Aby uzyskać listę identyfikatorów środowiska uruchomieniowego, zobacz wykaz identyfikatorów środowiska uruchomieniowego (RID).

Lub jawnie:

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

  • --self-contained false

    Ten przełącznik jawnie informuje zestaw SDK .NET o utworzeniu wdrożenia zależnego od środowiska uruchomieniowego.

  1. Kliknij prawym przyciskiem myszy projekt w Solution Explorer i wybierz pozycję Publish.
  2. Jeśli po raz pierwszy publikujesz, wybierz pozycję Folder jako element docelowy publikowania, a następnie wybierz pozycję Dalej.
  3. Wybierz lokalizację folderu lub zaakceptuj wartość domyślną, a następnie wybierz pozycję Zakończ.
  4. W profilu publikowania wybierz pozycję Pokaż wszystkie ustawienia.
  5. Ustaw Tryb wdrażania na zależny od frameworku (jest to ustawienie domyślne).
  6. Ustaw Target Runtime na odpowiednią platformę (na przykład win-x64 dla 64-bitowej Windows).
  7. Wybierz pozycję Zapisz , a następnie pozycję Publikuj.

Konfigurowanie zachowania wyszukiwania podczas instalowania .NET

Domyślnie host apphost odnajduje i używa globalnie zainstalowanego środowiska uruchomieniowego .NET z lokalizacjami instalacji różniącymi się w zależności od platformy. Aby uzyskać więcej informacji na temat odnajdywania i instalowania lokalizacji środowiska uruchomieniowego, zobacz Rozwiązywanie problemów z błędami uruchamiania aplikacji.

Ścieżkę środowiska uruchomieniowego .NET można również dostosować dla poszczególnych wykonań. Zmienna środowiskowa DOTNET_ROOT może być użyta do wskazania lokalizacji niestandardowej. Aby uzyskać więcej informacji na temat wszystkich opcji konfiguracji DOTNET_ROOT, zobacz .NET zmienne środowiskowe.

Ogólnie rzecz biorąc, najlepszym rozwiązaniem do użycia DOTNET_ROOT jest:

  1. Najpierw wyczyść DOTNET_ROOT zmienne środowiskowe, co oznacza, że wszystkie zmienne środowiskowe zaczynają się od tekstu DOTNET_ROOT.
  2. Ustaw DOTNET_ROOT, i tylko DOTNET_ROOT, na ścieżkę docelową.
  3. Uruchom host aplikacji.

W .NET 9 lub nowszych wersjach można skonfigurować ścieżki wyszukiwania instalacji .NET opublikowanego pliku wykonywalnego za pośrednictwem właściwości AppHostDotNetSearch i AppHostRelativeDotNet.

AppHostDotNetSearch umożliwia określenie co najmniej jednej lokalizacji, w której plik wykonywalny będzie szukać instalacji .NET:

  • AppLocal: folder pliku wykonywalnego aplikacji
  • AppRelative: ścieżka względem pliku wykonywalnego aplikacji
  • EnvironmentVariable: wartość DOTNET_ROOT[_<arch>] zmiennych środowiskowych
  • Global: zarejestrowane i domyślne globalne lokalizacje instalacji

AppHostRelativeDotNet określa ścieżkę względną do pliku wykonywalnego, która będzie wyszukiwana, gdy AppHostDotNetSearch zawiera AppRelative.

Aby uzyskać więcej informacji, zobacz AppHostDotNetSearch, AppHostRelativeDotNeti opcje lokalizacji instalacji w usłudze apphost.

Wdrażanie międzyplatformowej biblioteki DLL

Alternatywnie możesz opublikować aplikację jako wieloplatformową bibliotekę DLL bez pliku wykonywalnego specyficznego dla platformy. W tym trybie myapp.dll plik jest tworzony w folderze wyjściowym publikowania. Aby uruchomić aplikację, przejdź do folderu output i użyj dotnet myapp.dll polecenia .

Aby opublikować jako wieloplatformową bibliotekę DLL:

dotnet publish -c Release -p:UseAppHost=false

  • -c Release

    Ten przełącznik ustawia tryb kompilacji na Release, który jest zoptymalizowany na produkcję.

  • -p:UseAppHost=false

    Ta właściwość wyłącza tworzenie pliku wykonywalnego specyficznego dla platformy, tworząc tylko przenośną bibliotekę DLL.

  1. Kliknij prawym przyciskiem myszy projekt w Solution Explorer i wybierz pozycję Publish.
  2. Jeśli po raz pierwszy publikujesz, wybierz pozycję Folder jako element docelowy publikowania, a następnie wybierz pozycję Dalej.
  3. Wybierz lokalizację folderu lub zaakceptuj wartość domyślną, a następnie wybierz pozycję Zakończ.
  4. W profilu publikowania wybierz pozycję Pokaż wszystkie ustawienia.
  5. Ustaw Tryb wdrożenia na zależny od środowiska.
  6. Usuń zaznaczenie pola wyboru Utwórz pojedynczy plik.
  7. Ustaw wartość Target Runtime na Portable (lub pozostaw wartość pustą).
  8. Wybierz pozycję Zapisz , a następnie pozycję Publikuj.

Wdrożenie samodzielne

Podczas publikowania samodzielnego wdrożenia (SCD) proces wdrażania tworzy plik wykonywalny specyficzny dla platformy. Publikowanie pliku SCD obejmuje wszystkie wymagane pliki .NET do uruchomienia aplikacji, ale nie zawierają natywnych zależności .NET. Te zależności muszą być obecne w środowisku przed uruchomieniem aplikacji.

Opublikowanie SCD tworzy aplikację, która nie aktualizuje się do najnowszej dostępnej poprawki zabezpieczeń .NET. Aby uzyskać więcej informacji na temat powiązania wersji w czasie kompilacji, zobacz Wybierz wersję .NET do użycia.

Zalety

  • Kontroluj wersję .NET: kontrolowanie, która wersja .NET jest wdrażana z aplikacją.
  • Targetowanie specyficzne dla platformy: ponieważ aplikacja musi być opublikowana na każdą platformę, jasne jest, gdzie działa.

Niedogodności

  • Większe wdrożenia: Ponieważ aplikacja obejmuje środowisko uruchomieniowe .NET i wszystkie zależności, wymagany rozmiar pobierania i miejsce na dysku twardym jest większe niż przy wdrożeniu zależnym od frameworka.
  • Trudniej zaktualizować wersję .NET: Środowisko uruchomieniowe .NET można uaktualnić tylko przez wydanie nowej wersji aplikacji.

Napiwek

Całkowity rozmiar zgodnych samodzielnie aplikacji można zmniejszyć, publikując przycięte lub włączając niezmienny tryb globalizacji. Aby uzyskać więcej informacji na temat niezmiennego trybu globalizacji, zobacz .NET Tryb niezmienny globalizacji.

Opublikuj

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

  • -c Release

    Ten przełącznik ustawia tryb kompilacji na Release, który jest zoptymalizowany na produkcję.

  • -r <RID>

    Ten przełącznik używa identyfikatora środowiska uruchomieniowego (RID) do określenia platformy docelowej i zapewnia, że zależności natywne są uwzględniane (jeśli jest to wymagane). Aby uzyskać listę identyfikatorów środowiska uruchomieniowego, zobacz wykaz identyfikatorów środowiska uruchomieniowego (RID).

  • --self-contained true

    Ten przełącznik przekazuje zestawowi SDK .NET polecenie utworzenia pliku wykonywalnego jako samodzielnej wersji wdrożenia (SCD).

  1. Kliknij prawym przyciskiem myszy projekt w Solution Explorer i wybierz pozycję Publish.
  2. Jeśli po raz pierwszy publikujesz, wybierz pozycję Folder jako element docelowy publikowania, a następnie wybierz pozycję Dalej.
  3. Wybierz lokalizację folderu lub zaakceptuj wartość domyślną, a następnie wybierz pozycję Zakończ.
  4. W profilu publikowania wybierz pozycję Pokaż wszystkie ustawienia.
  5. Ustaw Tryb wdrażania na Samodzielny.
  6. Ustaw Target Runtime na odpowiednią platformę (na przykład win-x64 dla 64-bitowej Windows).
  7. Wybierz pozycję Zapisz , a następnie pozycję Publikuj.

Wdrażanie pojedynczego pliku

Podczas publikowania aplikacji jako wdrożenia pojedynczego pliku wszystkie pliki, od których zależy aplikacja, są łączone w jeden plik binarny. Ten model wdrażania jest dostępny zarówno dla aplikacji zależnych od platformy, jak i autonomicznych, zapewniając atrakcyjną opcję wdrażania i dystrybuowania aplikacji jako pojedynczego pliku.

Aplikacje z jednym plikiem są zawsze specyficzne dla systemu operacyjnego i architektury. Musisz publikować dla każdej konfiguracji, na przykład Linux x64, Linux Arm64, Windows x64 i tak dalej.

Zalety

  • Uproszczona dystrybucja: wdrażanie i dystrybuowanie aplikacji jako pojedynczego pliku wykonywalnego.
  • Zmniejszona ilość plików: wszystkie zależności są powiązane, eliminując konieczność zarządzania wieloma plikami.
  • Łatwe wdrażanie: skopiuj pojedynczy plik, aby wdrożyć aplikację.

Niedogodności

  • Większy rozmiar pliku: pojedynczy plik zawiera wszystkie zależności, dzięki czemu jest większy niż poszczególne pliki.
  • Wolniejsze uruchamianie: pliki muszą być wyodrębniane w czasie wykonywania, co może mieć wpływ na wydajność uruchamiania.
  • Specyficzne dla platformy: musi publikować oddzielne pliki dla każdej platformy docelowej.

Wdrożenie pojedynczego pliku można łączyć z innymi optymalizacjami, takimi jak przycinanie i kompilacja ReadyToRun w celu dalszej optymalizacji.

Aby uzyskać więcej informacji na temat wdrażania pojedynczego pliku, zobacz Wdrażanie pojedynczego pliku.

Opublikuj

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

  • -c Release

    Ten przełącznik ustawia tryb kompilacji na Release, który jest zoptymalizowany na produkcję.

  • -r <RID>

    Ten przełącznik używa identyfikatora środowiska uruchomieniowego (RID) do określenia platformy docelowej i zapewnia, że zależności natywne są uwzględniane (jeśli jest to wymagane). Aby uzyskać listę identyfikatorów środowiska uruchomieniowego, zobacz wykaz identyfikatorów środowiska uruchomieniowego (RID).

  • -p:PublishSingleFile=true

    Ta właściwość łączy wszystkie pliki zależne od aplikacji w jeden plik binarny.

  1. Kliknij prawym przyciskiem myszy projekt w Solution Explorer i wybierz pozycję Publish.
  2. Jeśli po raz pierwszy publikujesz, wybierz pozycję Folder jako element docelowy publikowania, a następnie wybierz pozycję Dalej.
  3. Wybierz lokalizację folderu lub zaakceptuj wartość domyślną, a następnie wybierz pozycję Zakończ.
  4. W profilu publikowania wybierz pozycję Pokaż wszystkie ustawienia.
  5. Ustaw Tryb wdrażania na samodzielny lub zależny od środowiska.
  6. Ustaw Target Runtime na odpowiednią platformę (na przykład win-x64 dla 64-bitowej Windows).
  7. Zaznacz pozycję Utwórz pojedynczy plik.
  8. Wybierz pozycję Zapisz , a następnie pozycję Publikuj.

Wdrożenie natywnej usługi AOT

Natywne wdrożenie usługi AOT kompiluje aplikację bezpośrednio do kodu natywnego, eliminując potrzebę środowiska uruchomieniowego. Ta opcja publikowania używa samodzielnego trybu wdrażania , ponieważ skompilowany kod natywny musi zawierać wszystkie elementy potrzebne do uruchomienia aplikacji. Powoduje to szybsze uruchamianie i zmniejszenie użycia pamięci, ale wiąże się z pewnymi ograniczeniami w zakresie obsługiwanych funkcji.

Zalety

  • Szybkie uruchamianie: brak kompilacji JIT wymaganej w czasie wykonywania, co prowadzi do szybszego uruchamiania aplikacji.
  • Wydukowane użycie pamięci: mniejsze zużycie pamięci w porównaniu z tradycyjnymi aplikacjami .NET.
  • Nie zależności środowiska uruchomieniowego: aplikacja działa bez konieczności .NET instalacji środowiska uruchomieniowego.
  • Mniejszy rozmiar wdrożenia: często mniejsze niż samodzielne wdrożenie z pełnym środowiskiem uruchomieniowym.

Niedogodności

  • Ograniczone wsparcie dla platformy: Nie wszystkie funkcje i biblioteki .NET są zgodne z natywnym AOT.
  • Dłuższy czas kompilacji: kompilacja kodu natywnego trwa dłużej niż zwykłe kompilacje.
  • Specyficzne dla platformy: należy kompilować oddzielnie dla każdej docelowej platformy i architektury.
  • Ograniczenia : Bardziej złożone środowisko debugowania w porównaniu do zwykłych aplikacji .NET.

Aby uzyskać więcej informacji na temat wdrożenia natywnego rozwiązania AOT, zobacz Wdrażanie natywnego rozwiązania AOT.

Opublikuj

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

  • -c Release

    Ten przełącznik ustawia tryb kompilacji na Release, który jest zoptymalizowany na produkcję.

  • -r <RID>

    Ten przełącznik używa identyfikatora środowiska uruchomieniowego (RID) do określenia platformy docelowej i zapewnia, że zależności natywne są uwzględniane (jeśli jest to wymagane). Aby uzyskać listę identyfikatorów środowiska uruchomieniowego, zobacz wykaz identyfikatorów środowiska uruchomieniowego (RID).

  • -p:PublishAot=true

    Ta właściwość umożliwia kompilację natywnej AOT, która kompiluje aplikację bezpośrednio do kodu natywnego.

W pliku projektu należy skonfigurować natywne publikowanie AOT. Nie można go włączyć za pośrednictwem interfejsu użytkownika publikowania Visual Studio.

  1. W Solution Explorer kliknij prawym przyciskiem myszy projekt i wybierz pozycję Edytuj plik projektu.

  2. Dodaj następującą właściwość do elementu <PropertyGroup>:

    <PublishAot>true</PublishAot>

  3. Zapisz plik projektu.

  4. Kliknij prawym przyciskiem myszy projekt w Solution Explorer i wybierz pozycję Publish.

  5. Jeśli po raz pierwszy publikujesz, wybierz pozycję Folder jako element docelowy publikowania, a następnie wybierz pozycję Dalej.

  6. Wybierz lokalizację folderu lub zaakceptuj wartość domyślną, a następnie wybierz pozycję Zakończ.

  7. W profilu publikowania wybierz pozycję Pokaż wszystkie ustawienia.

  8. Ustaw Tryb wdrażania na Samodzielny.

  9. Ustaw Target Runtime na odpowiednią platformę (na przykład win-x64 dla 64-bitowej Windows).

  10. Wybierz pozycję Zapisz , a następnie pozycję Publikuj.

Aby uzyskać więcej informacji na temat wdrożenia natywnego rozwiązania AOT, zobacz Wdrażanie natywnego rozwiązania AOT.

Gotowe do uruchomienia wdrożenia

Podczas publikowania aplikacji przy użyciu kompilacji ReadyToRun zestawy aplikacji są kompilowane jako format ReadyToRun (R2R). R2R jest formą kompilacji przed wykonaniem (AOT), która poprawia wydajność uruchamiania przez zmniejszenie ilości pracy, jaką kompilator just-in-time (JIT) musi wykonać podczas ładowania aplikacji. Tej opcji publikowania można używać zarówno z trybami wdrażania zależnymi od platformy , jak i autonomicznymi .

Pliki binarne ReadyToRun zawierają kod języka pośredniego (IL) i natywną wersję tego samego kodu. Chociaż pliki binarne R2R są większe niż zwykłe zestawy, zapewniają lepszą wydajność uruchamiania.

Zalety

  • Ulepszony czas uruchamiania: aplikacja poświęca mniej czasu na uruchamianie kompilatora JIT podczas uruchamiania.
  • Lepsza wydajność pierwszego użycia: mniejsze opóźnienie podczas pierwszego wykonywania ścieżek kodu.
  • Compatible with existing code: Działa z większością bibliotek i struktur .NET bez modyfikacji.
  • Elastyczne wdrażanie: można łączyć zarówno z wdrażaniem zależnym od platformy , jak i trybami wdrażania samodzielnego .

Niedogodności

  • Większy rozmiar: aplikacja jest większa na dysku z powodu włączenia zarówno il, jak i kodu natywnego.
  • Dłuższy czas kompilacji: kompilacja zajmuje więcej czasu niż standardowe publikowanie.
  • Optymalizacje specyficzne dla platformy: najlepsze ulepszenia wydajności wymagają ukierunkowania na konkretne platformy.

Opublikuj

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

  • -c Release

    Ten przełącznik ustawia tryb kompilacji na Release, który jest zoptymalizowany na produkcję.

  • -r <RID>

    Ten przełącznik używa identyfikatora środowiska uruchomieniowego (RID) do określenia platformy docelowej i zapewnia, że zależności natywne są uwzględniane (jeśli jest to wymagane). Aby uzyskać listę identyfikatorów środowiska uruchomieniowego, zobacz wykaz identyfikatorów środowiska uruchomieniowego (RID).

  • -p:PublishReadyToRun=true

    Ta właściwość umożliwia kompilację ReadyToRun, co zwiększa wydajność uruchamiania przez wstępne kompilowanie zestawów.

  1. Kliknij prawym przyciskiem myszy projekt w Solution Explorer i wybierz pozycję Publish.
  2. Jeśli po raz pierwszy publikujesz, wybierz pozycję Folder jako element docelowy publikowania, a następnie wybierz pozycję Dalej.
  3. Wybierz lokalizację folderu lub zaakceptuj wartość domyślną, a następnie wybierz pozycję Zakończ.
  4. W profilu publikowania wybierz pozycję Pokaż wszystkie ustawienia.
  5. Ustaw Tryb wdrażania na samodzielny lub zależny od środowiska.
  6. Ustaw Target Runtime na odpowiednią platformę (na przykład win-x64 dla 64-bitowej Windows).
  7. Zaznacz pozycję Włącz kompilację ReadyToRun.
  8. Wybierz pozycję Zapisz , a następnie pozycję Publikuj.

Aby uzyskać więcej informacji na temat wdrożenia ReadyToRun, zobacz Kompilacja ReadyToRun.

Wdrażanie kontenera

Podczas publikowania aplikacji jako kontenera zestaw SDK .NET pakuje aplikację i jej zależności do obrazu kontenera bez konieczności używania oddzielnego pliku Dockerfile. Ten tryb wdrażania tworzy kompletny obraz kontenera, który można uruchomić w dowolnym środowisku uruchomieniowym kontenera, takim jak Docker lub Podman. Wdrażanie kontenerów upraszcza proces konteneryzacji, eliminując konieczność zapisywania i obsługi plików Dockerfile przy jednoczesnym dostarczaniu zoptymalizowanych obrazów podstawowych.

Począwszy od zestawu .NET SDK 8.0.200, obsługa kontenerów jest domyślnie uwzględniana i nie wymaga dodatkowych pakietów NuGet. W przypadku aplikacji konsolowych może być konieczne jawne włączenie obsługi kontenerów przez ustawienie EnableSdkContainerSupport właściwości na true.

Napiwek

Aby uzyskać więcej informacji na temat ustawień projektu związanych z kontenerami, zobacz Containerize a .NET app reference .

Zalety

  • Uproszczona konteneryzacja: nie trzeba zapisywać ani obsługiwać plików Dockerfile dla podstawowych scenariuszy.
  • Zoptymalizowane obrazy podstawowe: korzysta z udostępnionych przez firmę Microsoft, zoptymalizowanych obrazów bazowych z najnowszymi aktualizacjami zabezpieczeń.
  • Spójne środowisko: zapewnia spójne środowisko uruchomieniowe w środowisku deweloperskim, testowym i produkcyjnym.
  • Łatwa dystrybucja: obrazy kontenerów można łatwo udostępniać i wdrażać w różnych środowiskach.
  • Izolacja platformy: aplikacje są uruchamiane w izolowanych kontenerach, co zmniejsza konflikty między aplikacjami.

Niedogodności

  • Zależność środowiska uruchomieniowego kontenera: środowisko docelowe musi mieć zainstalowane środowisko uruchomieniowe kontenera.
  • Rozmiar obrazu: obrazy kontenerów są zwykle większe niż inne metody wdrażania.
  • Krzywa uczenia: wymaga zrozumienia pojęć i narzędzi kontenera.
  • Ograniczone dostosowywanie: mniejsza elastyczność w porównaniu z niestandardowymi plikami Dockerfile w przypadku złożonych scenariuszy.

Opublikuj

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

  • -c Release

    Ten przełącznik ustawia tryb kompilacji na Release, który jest zoptymalizowany na produkcję.

  • -r <RID>

    Ten przełącznik używa identyfikatora środowiska uruchomieniowego (RID) do określenia platformy docelowej i zapewnia, że zależności natywne są uwzględniane (jeśli jest to wymagane). Aby uzyskać listę identyfikatorów środowiska uruchomieniowego, zobacz wykaz identyfikatorów środowiska uruchomieniowego (RID).

  • -t:PublishContainer

    Ten element docelowy publikuje aplikację jako obraz kontenera.

Możesz również użyć podejścia do publikowania profilu:

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

  • -p:PublishProfile=DefaultContainer

    Ten profil wyzwala proces publikowania kontenera.

  1. Kliknij prawym przyciskiem myszy projekt w Solution Explorer i wybierz pozycję Publish.
  2. Wybierz pozycję Container Registry jako element docelowy publikowania, a następnie wybierz pozycję Dalej.
  3. Wybierz docelowy rejestr kontenerów (na przykład Azure Container Registry, Docker Hub lub Generic Registry) i wybierz Next.
  4. Skonfiguruj szczegóły połączenia rejestru i uwierzytelnianie.
  5. W profilu publikowania wybierz pozycję Pokaż wszystkie ustawienia.
  6. Ustaw Tryb wdrażania na Samodzielny lub Zależny od platformy w zależności od potrzeb.
  7. Ustaw docelowe środowisko uruchomieniowe na żądaną platformę (na przykład linux-x64 dla kontenerów systemu Linux).
  8. Skonfiguruj ustawienia specyficzne dla kontenera, takie jak nazwa obrazu i tagi.
  9. Wybierz pozycję Zapisz , a następnie pozycję Publikuj.

Aby uzyskać więcej informacji na temat wdrażania kontenerów, zobacz Omówienie tworzenia kontenerów w .NET SDK.

Zobacz też

  • Last updated on