Udostępnij za pośrednictwem

dotnet publish

  • Artykuł

Ten artykuł dotyczy: ✔️ .NET Core 3.1 SDK i nowsze wersje

Nazwa

dotnet publish — publikuje aplikację i jej zależności w folderze na potrzeby wdrożenia w systemie hostingu.

Streszczenie

dotnet publish [<PROJECT>|<SOLUTION>] [-a|--arch <ARCHITECTURE>]
    [--artifacts-path <ARTIFACTS_DIR>]
    [-c|--configuration <CONFIGURATION>] [--disable-build-servers]
    [-f|--framework <FRAMEWORK>] [--force] [--interactive]
    [--manifest <PATH_TO_MANIFEST_FILE>] [--no-build] [--no-dependencies]
    [--no-restore] [--nologo] [-o|--output <OUTPUT_DIRECTORY>]
    [--os <OS>] [-r|--runtime <RUNTIME_IDENTIFIER>]
    [--sc|--self-contained [true|false]] [--no-self-contained]
    [-s|--source <SOURCE>] [--tl:[auto|on|off]]
    [--use-current-runtime, --ucr [true|false]]
    [-v|--verbosity <LEVEL>] [--version-suffix <VERSION_SUFFIX>]

dotnet publish -h|--help

Opis

dotnet publish kompiluje aplikację, odczytuje jej zależności określone w pliku projektu i publikuje wynikowy zestaw plików do katalogu. Dane wyjściowe obejmują następujące zasoby:

  • Kod języka pośredniego (IL) w zestawie z rozszerzeniem biblioteki dll .
  • Plik .deps.json zawierający wszystkie zależności projektu.
  • Plik .runtimeconfig.json określający środowisko uruchomieniowe udostępnione oczekiwane przez aplikację, a także inne opcje konfiguracji środowiska uruchomieniowego (na przykład typ odzyskiwania pamięci).
  • Zależności aplikacji, które są kopiowane z pamięci podręcznej NuGet do folderu wyjściowego.

Dane wyjściowe polecenia dotnet publish są gotowe do wdrożenia w systemie hostingu (na przykład serwer, komputer PC, Mac, laptop) do wykonania. Jest to jedyny oficjalnie obsługiwany sposób przygotowania aplikacji do wdrożenia. W zależności od typu wdrożenia określonego przez projekt system hostingu może lub nie ma zainstalowanego na nim współużytkowanego środowiska uruchomieniowego platformy .NET. Aby uzyskać więcej informacji, zobacz Publikowanie aplikacji platformy .NET przy użyciu interfejsu wiersza polecenia platformy .NET.

Niejawne przywracanie

Nie musisz uruchamiać dotnet restore, ponieważ jest ona uruchamiana niejawnie przez wszystkie polecenia, które wymagają przywrócenia, takie jak dotnet new, dotnet build, dotnet run, dotnet test, dotnet publishi dotnet pack. Aby wyłączyć niejawne przywracanie, użyj opcji --no-restore.

Polecenie dotnet restore jest nadal przydatne w niektórych scenariuszach, w których jawne przywracanie ma sens, takie jak kompilacji ciągłej integracji w usłudze Azure DevOps Services lub w systemach kompilacji, które muszą jawnie kontrolować, kiedy nastąpi przywracanie.

Aby uzyskać informacje na temat zarządzania kanałami informacyjnymi NuGet, zobacz dokumentację dotnet restore.

MSBuild

Polecenie dotnet publish wywołuje program MSBuild, który wywołuje obiekt docelowy Publish. Jeśli właściwość jest ustawiona na dla określonego projektu, nie można wywołać obiektu docelowego , a polecenie uruchamia tylko niejawne przywracania dotnet w projekcie.

Wszystkie parametry przekazywane do dotnet publish są przekazywane do programu MSBuild. Parametry -c i -o są mapować odpowiednio na właściwości Configuration i PublishDir programu MSBuild.

Polecenie dotnet publish akceptuje opcje msBuild, takie jak -p do ustawiania właściwości i -l do definiowania rejestratora. Można na przykład ustawić właściwość MSBuild przy użyciu formatu: -p:<NAME>=<VALUE>.

Pliki .pubxml

Można również ustawić właściwości związane z publikowaniem, odwołując się do pliku .pubxml. Na przykład:

dotnet publish -p:PublishProfile=FolderProfile

W poprzednim przykładzie użyto pliku FolderProfile.pubxml znajdującego się w folderze <project_folder>/Properties/PublishProfiles. Jeśli określisz ścieżkę i rozszerzenie pliku podczas ustawiania właściwości PublishProfile, są one ignorowane. Program MSBuild domyślnie wyszukuje w folderze Properties/PublishProfiles i zakłada rozszerzenie pubxml pliku. Aby określić ścieżkę i nazwę pliku wraz z rozszerzeniem, ustaw właściwość PublishProfileFullPath zamiast właściwości PublishProfile.

W pliku .pubxml:

  • PublishUrl jest używany przez program Visual Studio do oznaczania elementu docelowego publikowania.
  • PublishDir jest używany przez interfejs wiersza polecenia do oznaczania elementu docelowego publikowania.

Jeśli chcesz, aby scenariusz działał we wszystkich miejscach, możesz zainicjować obie te właściwości na tę samą wartość w pliku .pubxml. Gdy problem z usługą GitHub dotnet/sdk#20931 zostanie rozwiązany, należy ustawić tylko jedną z tych właściwości.

Niektóre właściwości w pliku .pubxml są honorowane tylko przez program Visual Studio i nie mają wpływu na dotnet publish. Pracujemy nad zwiększeniem zgodności interfejsu wiersza polecenia z zachowaniem programu Visual Studio. Jednak niektóre właściwości nigdy nie będą używane przez interfejs wiersza polecenia. Interfejs wiersza polecenia i program Visual Studio wykonują zarówno aspekt pakowania publikowania, jak i dotnet/sdk#29817 plany dodania obsługi większej liczby właściwości związanych z tym. Jednak interfejs wiersza polecenia nie wykonuje aspektu automatyzacji wdrażania publikowania i właściwości związanych z tym nie są obsługiwane. Najbardziej godne uwagi właściwości .pubxml, które nie są obsługiwane przez dotnet publish są następujące, które mają wpływ na kompilację:

  • LastUsedBuildConfiguration
  • Configuration
  • Platform
  • LastUsedPlatform
  • TargetFramework
  • TargetFrameworks
  • RuntimeIdentifier
  • RuntimeIdentifiers

Właściwości programu MSBuild

Następujące właściwości programu MSBuild zmieniają dane wyjściowe dotnet publish.

  • PublishReadyToRun

    Kompiluje zestawy aplikacji jako format ReadyToRun (R2R). R2R jest formą kompilacji przed czasem (AOT). Aby uzyskać więcej informacji, zobacz ReadyToRun images.

    Aby wyświetlić ostrzeżenia dotyczące brakujących zależności, które mogą powodować błędy środowiska uruchomieniowego, użyj PublishReadyToRunShowWarnings=true.

    Zalecamy określenie PublishReadyToRun w profilu publikowania, a nie w wierszu polecenia.

  • PublishSingleFile

    Pakuje aplikację do pliku wykonywalnego pojedynczego pliku specyficznego dla platformy. Aby uzyskać więcej informacji na temat publikowania w jednym pliku, zobacz dokument projektowy programu z jednym plikiem.

    Zalecamy określenie tej opcji w pliku projektu, a nie w wierszu polecenia.

  • PublishTrimmed

    Przycina nieużywane biblioteki, aby zmniejszyć rozmiar wdrożenia aplikacji podczas publikowania samodzielnego pliku wykonywalnego. Aby uzyskać więcej informacji, zobacz Trim samodzielne wdrożenia i pliki wykonywalne. Dostępny od wersji .NET 6 SDK.

    Zalecamy określenie tej opcji w pliku projektu, a nie w wierszu polecenia.

Aby uzyskać więcej informacji, zobacz następujące zasoby:

Pobieranie manifestu obciążenia

Po uruchomieniu tego polecenia inicjuje asynchroniczne pobieranie manifestów reklamowych dla obciążeń. Jeśli pobieranie jest nadal uruchomione po zakończeniu tego polecenia, pobieranie zostanie zatrzymane. Aby uzyskać więcej informacji, zobacz Manifesty reklamowe.

Argumenty

  • PROJECT|SOLUTION

    Projekt lub rozwiązanie do opublikowania.

    • PROJECT to ścieżka i nazwa pliku projektu C#, F# lub Visual Basic albo ścieżka do katalogu zawierającego plik projektu C#, F# lub Visual Basic. Jeśli katalog nie zostanie określony, zostanie on domyślnie określony w bieżącym katalogu.

    • SOLUTION to ścieżka i nazwa pliku rozwiązania (rozszerzenie.sln) lub ścieżka do katalogu zawierającego plik rozwiązania. Jeśli katalog nie zostanie określony, zostanie on domyślnie określony w bieżącym katalogu.

Opcje

  • -a|--arch <ARCHITECTURE>

    Określa architekturę docelową. Jest to skrócona składnia ustawiania identyfikatora środowiska uruchomieniowego (RID), gdzie podana wartość jest połączona z domyślnym identyfikatorem RID. Na przykład na maszynie win-x64 określenie --arch x86 ustawia identyfikator RID na win-x86. Jeśli używasz tej opcji, nie używaj opcji -r|--runtime. Dostępne od wersji zapoznawczej 7 platformy .NET 6.

  • --artifacts-path <ARTIFACTS_DIR>

    Wszystkie pliki wyjściowe kompilacji z wykonanego polecenia zostaną umieszczone w podfolderach w określonej ścieżce oddzielonej przez projekt. Aby uzyskać więcej informacji, zobacz Artifacts Output Layout. Dostępne od zestawu .NET 8 SDK.

  • -c|--configuration <CONFIGURATION>

    Definiuje konfigurację kompilacji. Jeśli programujesz przy użyciu zestawu .NET 8 SDK lub nowszej wersji, polecenie domyślnie używa konfiguracji Release dla projektów, których element TargetFramework jest ustawiony na net8.0 lub nowszą wersję. Domyślna konfiguracja kompilacji to Debug dla wcześniejszych wersji zestawu SDK i wcześniejszych platform docelowych. Wartość domyślną można zastąpić w ustawieniach projektu lub za pomocą tej opcji. Aby uzyskać więcej informacji, zobacz "dotnet publish" używa konfiguracji wydania i "dotnet pack" używa konfiguracji wydania.

  • --disable-build-servers

    Wymusza zignorowanie jakichkolwiek trwałych serwerów kompilacji. Ta opcja zapewnia spójny sposób wyłączania całego użycia buforowania kompilacji, co wymusza kompilację od podstaw. Kompilacja, która nie opiera się na pamięciach podręcznych, jest przydatna, gdy pamięci podręczne mogą być uszkodzone lub niepoprawne z jakiegoś powodu. Dostępne od zestawu .NET 7 SDK.

  • -f|--framework <FRAMEWORK>

    Publikuje aplikację dla określonej platformy docelowej . Należy określić strukturę docelową w pliku projektu.

  • --force

    Wymusza rozwiązanie wszystkich zależności, nawet jeśli ostatnie przywracanie zakończyło się pomyślnie. Określenie tej flagi jest takie samo jak usunięcie pliku project.assets.json.

  • -?|-h|--help

    Wyświetla opis sposobu używania polecenia .

  • --interactive

    Umożliwia zatrzymanie polecenia i oczekiwanie na wprowadzenie lub działanie użytkownika. Na przykład w celu ukończenia uwierzytelniania. Dostępny od wersji .NET Core 3.0 SDK.

  • --manifest <PATH_TO_MANIFEST_FILE>

    Określa jeden lub kilka manifestów docelowych użyć do przycinania zestawu pakietów publikowanych w aplikacji. Plik manifestu jest częścią danych wyjściowych polecenia dotnet store. Aby określić wiele manifestów, dodaj opcję --manifest dla każdego manifestu.

  • --no-build

    Nie kompiluje projektu przed opublikowaniem. Ponadto niejawnie ustawia flagę --no-restore.

  • --no-dependencies

    Ignoruje odwołania do projektu i przywraca tylko projekt główny.

  • --nologo

    Nie wyświetla baneru startowego ani wiadomości o prawach autorskich.

  • --no-restore

    Nie wykonuje niejawnego przywracania podczas uruchamiania polecenia.

  • -o|--output <OUTPUT_DIRECTORY>

    Określa ścieżkę katalogu wyjściowego.

    Jeśli nie zostanie określony, domyślnie [project_file_folder]/bin/[configuration]/[framework]/publish/ dla plików wykonywalnych zależnych od struktury i plików binarnych międzyplatformowych. Domyślnie [project_file_folder]/bin/[configuration]/[framework]/[runtime]/publish/ dla samodzielnego pliku wykonywalnego.

    W projekcie internetowym, jeśli folder wyjściowy znajduje się w folderze projektu, kolejne polecenia dotnet publish powodują zagnieżdżone foldery wyjściowe. Jeśli na przykład folder projektu jest myproject, a folder wyjściowy publikowania jest myproject/publishi uruchomisz dotnet publish dwa razy, drugi przebieg umieszcza pliki zawartości, takie jak .config i .json plików w myproject/publish/publish. Aby uniknąć zagnieżdżania folderów publikowania, określ folder publikowania, który nie jest bezpośrednio w folderze projektu, lub wyklucz folder publikowania z projektu. Aby wykluczyć folder publikowania o nazwie publishoutput, dodaj następujący element do elementu PropertyGroup w pliku .csproj:

    <DefaultItemExcludes>$(DefaultItemExcludes);publishoutput**</DefaultItemExcludes>

    • Zestaw .NET 7.0.200 SDK lub nowszy

      Jeśli określisz opcję --output podczas uruchamiania tego polecenia w rozwiązaniu, interfejs wiersza polecenia będzie emitować ostrzeżenie (błąd w wersji 7.0.200) ze względu na niejasne semantyki ścieżki wyjściowej. Opcja --output jest niedozwolona, ponieważ wszystkie dane wyjściowe wszystkich projektów skompilowanych zostaną skopiowane do określonego katalogu, który nie jest zgodny z projektami wielokierunkowymi, a także projektów, które mają różne wersje zależności bezpośrednich i przechodnich. Aby uzyskać więcej informacji, zobacz Opcja --output na poziomie rozwiązania nie jest już prawidłowa dla poleceń związanych z kompilacją.

    • Zestaw SDK platformy .NET Core 3.x lub nowszy

      Jeśli określisz ścieżkę względną podczas publikowania projektu, wygenerowany katalog wyjściowy jest względny względem bieżącego katalogu roboczego, a nie lokalizacji pliku projektu.

      Jeśli określisz ścieżkę względną podczas publikowania rozwiązania, wszystkie dane wyjściowe dla wszystkich projektów zostaną wprowadzone do określonego folderu względem bieżącego katalogu roboczego. Aby opublikować dane wyjściowe, przejdź do oddzielnych folderów dla każdego projektu, określ ścieżkę względną przy użyciu właściwości msbuild PublishDir zamiast opcji --output. Na przykład dotnet publish -p:PublishDir=.\publish wysyła dane wyjściowe publikowania dla każdego projektu do folderu publish w folderze zawierającym plik projektu.

    • Zestaw SDK platformy .NET Core 2.x

      Jeśli określisz ścieżkę względną podczas publikowania projektu, wygenerowany katalog wyjściowy jest względny względem lokalizacji pliku projektu, a nie bieżącego katalogu roboczego.

      Jeśli określisz ścieżkę względną podczas publikowania rozwiązania, dane wyjściowe każdego projektu przechodzą do oddzielnego folderu względem lokalizacji pliku projektu. Jeśli określisz ścieżkę bezwzględną podczas publikowania rozwiązania, wszystkie dane wyjściowe publikowania dla wszystkich projektów zostaną wprowadzone do określonego folderu.

  • --os <OS>

    Określa docelowy system operacyjny. Jest to skrócona składnia ustawiania identyfikatora środowiska uruchomieniowego (RID), gdzie podana wartość jest połączona z domyślnym identyfikatorem RID. Na przykład na maszynie win-x64 określenie --os linux ustawia identyfikator RID na linux-x64. Jeśli używasz tej opcji, nie używaj opcji -r|--runtime. Dostępne od platformy .NET 6.

  • --sc|--self-contained [true|false]

    Publikuje środowisko uruchomieniowe platformy .NET z aplikacją, aby środowisko uruchomieniowe nie musi być zainstalowane na maszynie docelowej. Wartość domyślna to true, jeśli określono identyfikator środowiska uruchomieniowego, a projekt jest projektem wykonywalnym (a nie projektem biblioteki). Aby uzyskać więcej informacji, zobacz publikowanie aplikacji .NET i Publikowanie aplikacji platformy .NET przy użyciu interfejsu wiersza polecenia platformy .NET.

    Jeśli ta opcja jest używana bez określania true lub false, wartość domyślna to true. W takim przypadku nie umieszczaj rozwiązania ani argumentu projektu bezpośrednio po --self-contained, ponieważ true lub false jest oczekiwana w tej pozycji.

  • --no-self-contained

    Odpowiednik --self-contained false.

  • --source <SOURCE>

    Identyfikator URI źródła pakietu NuGet do użycia podczas operacji przywracania.

  • -r|--runtime <RUNTIME_IDENTIFIER>

    Publikuje aplikację dla danego środowiska uruchomieniowego. Aby uzyskać listę identyfikatorów środowiska uruchomieniowego (RID), zobacz wykaz identyfikatorów RID . Aby uzyskać więcej informacji, zobacz publikowanie aplikacji .NET i Publikowanie aplikacji platformy .NET przy użyciu interfejsu wiersza polecenia platformy .NET. Jeśli używasz tej opcji, użyj również --self-contained lub --no-self-contained.

  • --tl:[auto|on|off]

    Określa, czy rejestratora terminalu powinny być używane dla danych wyjściowych kompilacji. Wartość domyślna to auto, która najpierw weryfikuje środowisko przed włączeniem rejestrowania terminalu. Sprawdzanie środowiska sprawdza, czy terminal może korzystać z nowoczesnych funkcji wyjściowych i nie używa przekierowanych standardowych danych wyjściowych przed włączeniem nowego rejestratora. on pomija sprawdzanie środowiska i włącza rejestrowanie terminali. off pomija sprawdzanie środowiska i używa domyślnego rejestratora konsoli.

    Rejestrator terminalu pokazuje fazę przywracania, po której następuje faza kompilacji. W każdej fazie obecnie projekty budowlane są wyświetlane w dolnej części terminalu. Każdy projekt, który tworzy, generuje dane wyjściowe zarówno docelowy programu MSBuild, który jest obecnie kompilowany, jak i ilość czasu spędzonego na tym obiekcie docelowym. Możesz wyszukać te informacje, aby dowiedzieć się więcej o kompilacji. Po zakończeniu kompilowania projektu zostanie napisana pojedyncza sekcja "ukończona kompilacja", która przechwytuje:

    • Nazwa utworzonego projektu.
    • Struktura docelowa (jeśli jest przeznaczona dla wielu celów).
    • Stan tej kompilacji.
    • Podstawowe dane wyjściowe tej kompilacji (która jest hiperlinkowana).
    • Każda diagnostyka wygenerowana dla tego projektu.

    Ta opcja jest dostępna począwszy od platformy .NET 8.

  • --use-current-runtime, --ucr [true|false]

    Ustawia RuntimeIdentifier na platformę przenośną RuntimeIdentifier na podstawie jednej z maszyn. Dzieje się to niejawnie z właściwościami, które wymagają RuntimeIdentifier, takich jak SelfContained, PublishAot, PublishSelfContained, PublishSingleFilei PublishReadyToRun. Jeśli właściwość ma wartość false, ta niejawna rozdzielczość nie będzie już występować.

  • -v|--verbosity <LEVEL>

    Ustawia poziom szczegółowości polecenia. Dozwolone wartości to q[uiet], m[inimal], n[ormal], d[etailed]i diag[nostic]. Wartość domyślna to minimal. Aby uzyskać więcej informacji, zobacz LoggerVerbosity.

  • --version-suffix <VERSION_SUFFIX>

    Definiuje sufiks wersji, aby zastąpić gwiazdkę (*) w polu wersji pliku projektu.

Przykłady

  • Utwórz zależne od platformy binarne dla projektu w bieżącym katalogu:

    dotnet publish

    Począwszy od zestawu .NET Core 3.0 SDK, w tym przykładzie tworzony jest również plik wykonywalny zależny od platformy zależny od platformy.

  • Utwórz samodzielnego pliku wykonywalnego dla projektu w bieżącym katalogu dla określonego środowiska uruchomieniowego:

    dotnet publish --runtime osx-x64

    Identyfikator RID musi znajdować się w pliku projektu.

  • Utwórz plik wykonywalny zależny od platformy dla projektu w bieżącym katalogu dla określonej platformy:

    dotnet publish --runtime osx-x64 --self-contained false

    Identyfikator RID musi znajdować się w pliku projektu. Ten przykład dotyczy zestawu .NET Core 3.0 SDK i nowszych wersji.

  • Opublikuj projekt w bieżącym katalogu dla określonego środowiska uruchomieniowego i platformy docelowej:

    dotnet publish --framework net8.0 --runtime osx-x64

  • Opublikuj określony plik projektu:

    dotnet publish ~/projects/app1/app1.csproj

  • Opublikuj bieżącą aplikację, ale nie przywracaj odwołań do projektu (P2P), tylko głównego projektu podczas operacji przywracania:

    dotnet publish --no-dependencies

Zobacz też