Udostępnij za pomocą

Omówienie publikowania aplikacji platformy .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 platformy .NET można publikować przy użyciu interfejsu wiersza polecenia platformy .NET lub programu Visual Studio.

Aby zapoznać się z krótkim samouczkiem dotyczącym publikowania, zobacz Samouczek: publikowanie aplikacji konsolowej platformy .NET przy użyciu programu Visual Studio Code.

Aby zapoznać się z krótkim samouczkiem dotyczącym publikowania, zobacz Samouczek: publikowanie aplikacji konsolowej platformy .NET przy użyciu programu Visual Studio.

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 platformy .NET i czy potrzebujesz określonych funkcji kompilacji, które wymagają łączenia środowiska uruchomieniowego z aplikacją. Dwa tryby publikowania to:

  • Publikowanie samodzielnego
    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 platformy .NET wymagane do uruchomienia aplikacji. Środowisko uruchamiające aplikację nie musi mieć wstępnie zainstalowanego środowiska uruchomieniowego platformy .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 platformy .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 platformy .NET.

Podstawy publikowania

Ustawienie <TargetFramework> pliku projektu określa domyślną strukturę docelową podczas publikowania aplikacji. Możesz zmienić strukturę docelową na dowolną prawidłową strukturę docelową Moniker (TFM). Jeśli na przykład projekt używa <TargetFramework>net9.0</TargetFramework>pliku binarnego przeznaczonego dla platformy .NET 9, zostanie utworzony.

Jeśli chcesz kierować więcej niż jedną strukturę, możesz ustawić <TargetFrameworks> ustawienie na wiele wartości TFM rozdzielonych średnikami. 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 katalog dotnet publish wyjściowy polecenia to ./bin/<BUILD-CONFIGURATION>/<TFM>/publish/. Na przykład dotnet publish -c Release -f net9.0 publikuje w pliku ./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 programie Visual Studio utwórz oddzielne profile publikowania dla każdej platformy docelowej.

Przenośne pliki binarne

Podczas publikowania aplikacji platformy .NET można wybrać konkretną platformę lub utworzyć przenośny plik binarny. Domyślnie nawet podczas tworzenia przenośnego pliku binarnego platforma .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 z UseAppHost powodu właściwości , która domyślnie ma wartość true. Aby opublikować tylko przenośną bibliotekę DLL bez pliku wykonywalnego specyficznego dla platformy, ustaw wartość UseAppHostfalse na wartość 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 systemu 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 konfigurację kompilacji na Wydanie, która jest zoptymalizowana pod kątem wdrożenia produkcyjnego.

  • -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 Eksploratorze rozwiązań i wybierz polecenie Publikuj.
  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 wartość Target Runtime na odpowiednią platformę (na przykład win-x64 dla 64-bitowego systemu 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 struktury jest trybem domyślnym podczas publikowania z poziomu interfejsu wiersza polecenia lub programu Visual Studio. W tym trybie tworzony jest plik wykonywalny specyficzny dla platformy, który może służyć do uruchamiania aplikacji. Plik wykonywalny przeznaczony dla danej platformy nosi nazwę podobną do myapp.exe w systemie Windows lub myapp na innych platformach.

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

Opublikowanie wdrożenia zależnego od platformy tworzy aplikację, która automatycznie przekazuje do najnowszej poprawki zabezpieczeń platformy .NET dostępnej w środowisku, w ramach którego jest uruchamiana aplikacja. Aby uzyskać więcej informacji na temat powiązania wersji w czasie kompilacji, zobacz Wybieranie wersji platformy .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 platformy .NET.
  • Międzyplatformowe: aplikacja i dowolne . Biblioteka oparta na platformie NET działa w innych systemach operacyjnych.
  • Używa najnowszego środowiska uruchomieniowego z poprawkami: aplikacja używa najnowszego środowiska uruchomieniowego zainstalowanego w środowisku.

Wady

  • Wymaga wstępnego zainstalowania środowiska uruchomieniowego: aplikacja może działać tylko wtedy, gdy wersja platformy .NET, która jest przeznaczona, jest już zainstalowana w środowisku.
  • Platforma .NET może ulec zmianie: środowisko, w którym jest uruchamiana aplikacja, może używać nowszego środowiska uruchomieniowego platformy .NET, które 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 technologia CET (Control-flow Enforcement Technology) jest domyślnie włączona przy użyciu shadow stack 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 konfigurację kompilacji na Wydanie, która jest zoptymalizowana pod kątem wdrożenia produkcyjnego.

  • -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 .NET SDK o utworzeniu wdrożenia zależnego od platformy.

  1. Kliknij prawym przyciskiem myszy projekt w Eksploratorze rozwiązań i wybierz polecenie Publikuj.
  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 wartość Tryb wdrażania na zależny od struktury (jest to ustawienie domyślne).
  6. Ustaw wartość Target Runtime na odpowiednią platformę (na przykład win-x64 dla 64-bitowego systemu Windows).
  7. Wybierz pozycję Zapisz , a następnie pozycję Publikuj.

Konfigurowanie zachowania wyszukiwania instalacji platformy .NET

Domyślnie apphost odnajduje i używa globalnie zainstalowanego środowiska uruchomieniowego .NET, przy czym lokalizacje instalacji różnią 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 platformy .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 DOTNET_ROOT opcji konfiguracji, zobacz Zmienne środowiskowe platformy .NET.

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 programie .NET 9 i nowszych wersjach można skonfigurować ścieżki wyszukiwania instalacji platformy .NET opublikowanego pliku wykonywalnego za pomocą 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 platformy .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ą pliku wykonywalnego, który będzie wyszukiwany, gdy AppHostDotNetSearch zawiera AppRelative.

Aby uzyskać więcej informacji, zobacz AppHostDotNetSearch, AppHostRelativeDotNeti install location options in apphost (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 danych wyjściowych 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 konfigurację kompilacji na Wydanie, która jest zoptymalizowana pod kątem wdrożenia produkcyjnego.

  • -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 Eksploratorze rozwiązań i wybierz polecenie Publikuj.
  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 wartość Tryb wdrażania na zależny od platformy.
  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 publikowania tworzy plik wykonywalny specyficzny dla platformy. Publikowanie scD obejmuje wszystkie wymagane pliki .NET do uruchomienia aplikacji, ale nie obejmują natywnych zależności platformy .NET. Te zależności muszą być obecne w środowisku przed uruchomieniem aplikacji.

Publikowanie scD tworzy aplikację, która nie jest przekazywana do najnowszej dostępnej poprawki zabezpieczeń platformy .NET. Aby uzyskać więcej informacji na temat powiązania wersji w czasie kompilacji, zobacz Wybieranie wersji platformy .NET do użycia.

Zalety

  • Kontrolowanie wersji platformy .NET: kontrolowanie wersji platformy .NET wdrożonej za pomocą aplikacji.
  • Określanie wartości docelowej specyficznej dla platformy: ponieważ aplikacja musi być opublikowana dla każdej platformy, jest jasne, gdzie działa aplikacja.

Wady

  • Większe wdrożenia: ponieważ aplikacja obejmuje środowisko uruchomieniowe platformy .NET i wszystkie zależności, wymagany rozmiar pobierania i miejsce na dysku twardym jest większe niż wdrożenie zależne od platformy.
  • Trudniej zaktualizować wersję platformy .NET: Środowisko uruchomieniowe platformy .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 Tryb niezmienny globalizacji platformy .NET.

Opublikuj

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

  • -c Release

    Ten przełącznik ustawia konfigurację kompilacji na Wydanie, która jest zoptymalizowana pod kątem wdrożenia produkcyjnego.

  • -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 informuje zestaw SDK platformy .NET o utworzeniu pliku wykonywalnego jako samodzielnego wdrożenia (SCD).

  1. Kliknij prawym przyciskiem myszy projekt w Eksploratorze rozwiązań i wybierz polecenie Publikuj.
  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 wartość Tryb wdrażania na samodzielną.
  6. Ustaw wartość Target Runtime na odpowiednią platformę (na przykład win-x64 dla 64-bitowego systemu Windows).
  7. Wybierz pozycję Zapisz , a następnie pozycję Publikuj.

Wdrażanie pojedynczego pliku

Podczas publikowania aplikacji jako wdrożenia pojedynczego pliku wszystkie pliki zależne od aplikacji są umieszczane w jednym pliku binarnym. 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 opublikować dla każdej konfiguracji, takie jak Linux x64, Linux Arm64, Windows x64 itd.

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ę.

Wady

  • 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 konfigurację kompilacji na Wydanie, która jest zoptymalizowana pod kątem wdrożenia produkcyjnego.

  • -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 Eksploratorze rozwiązań i wybierz polecenie Publikuj.
  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 wartość Tryb wdrażania na samodzielną lub zależną od platformy.
  6. Ustaw wartość Target Runtime na odpowiednią platformę (na przykład win-x64 dla 64-bitowego systemu 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.
  • Mniejsze użycie pamięci: mniejsze zużycie pamięci w porównaniu z tradycyjnymi aplikacjami platformy .NET.
  • Brak zależności środowiska uruchomieniowego: aplikacja jest uruchamiana bez konieczności instalacji środowiska uruchomieniowego platformy .NET.
  • Mniejszy rozmiar wdrożenia: często mniejsze niż samodzielne wdrożenie z pełnym środowiskiem uruchomieniowym.

Wady

  • Ograniczona obsługa platformy: nie wszystkie funkcje i biblioteki platformy .NET są zgodne z natywną funkcją AOT.
  • Dłuższy czas kompilacji: kompilacja kodu natywnego trwa dłużej niż zwykłe kompilacje.
  • Specyficzne dla platformy: musi być kompilowany oddzielnie dla każdej platformy docelowej i architektury.
  • Ograniczenia debugowania: 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 konfigurację kompilacji na Wydanie, która jest zoptymalizowana pod kątem wdrożenia produkcyjnego.

  • -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 pomocą interfejsu użytkownika publikowania programu Visual Studio.

  1. W Eksploratorze rozwiązań kliknij prawym przyciskiem myszy projekt i wybierz polecenie 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 Eksploratorze rozwiązań i wybierz polecenie Publikuj.

  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 wartość Tryb wdrażania na samodzielną.

  9. Ustaw wartość Target Runtime na odpowiednią platformę (na przykład win-x64 dla 64-bitowego systemu 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 czasem (AOT), która poprawia wydajność uruchamiania przez zmniejszenie ilości pracy kompilatora just in time (JIT) musi wykonać w miarę ł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.
  • Zgodny z istniejącym kodem: 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 .

Wady

  • 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 wzrosty wydajności wymagają określania celu określonych platform.

Opublikuj

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

  • -c Release

    Ten przełącznik ustawia konfigurację kompilacji na Wydanie, która jest zoptymalizowana pod kątem wdrożenia produkcyjnego.

  • -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 Eksploratorze rozwiązań i wybierz polecenie Publikuj.
  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 wartość Tryb wdrażania na samodzielną lub zależną od platformy.
  6. Ustaw wartość Target Runtime na odpowiednią platformę (na przykład win-x64 dla 64-bitowego systemu 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 platformy .NET pakuje aplikację i jej zależności do obrazu kontenera bez konieczności użycia 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 (Konteneryzowanie dokumentacji aplikacji platformy .NET).

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.

Wady

  • 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 konfigurację kompilacji na Wydanie, która jest zoptymalizowana pod kątem wdrożenia produkcyjnego.

  • -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 Eksploratorze rozwiązań i wybierz polecenie Publikuj.
  2. Wybierz pozycję Container Registry jako element docelowy publikowania, a następnie wybierz pozycję Dalej.
  3. Wybierz docelowy rejestr kontenerów (taki jak Azure Container Registry, Docker Hub lub Rejestr ogólny) i wybierz przycisk Dalej.
  4. Skonfiguruj szczegóły połączenia rejestru i uwierzytelnianie.
  5. W profilu publikowania wybierz pozycję Pokaż wszystkie ustawienia.
  6. Ustaw wartość Tryb wdrażania na samodzielną lub zależną 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 kontenera, zobacz Omówienie tworzenia kontenera zestawu SDK platformy .NET.

Zobacz też

  • Last updated on