dotnet publish

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

Nazwisko

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 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 dotnet publish wyjściowe polecenia 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 .NET za pomocą interfejsu wiersza polecenia platformy .NET.

Niejawne przywracanie

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

Polecenie dotnet restore jest nadal przydatne w niektórych scenariuszach, w których jawne przywracanie ma sens, takie jak kompilacje ciągłej integracji w usługach 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 . IsPublishable Jeśli właściwość jest ustawiona na dla określonego projektu, Publish nie można wywołać false obiektu docelowego, a dotnet publish polecenie uruchamia tylko niejawne przywracanie dotnet w projekcie.

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

Polecenie dotnet publish akceptuje opcje MSBuild, takie jak -p ustawianie właściwości i -l definiowanie 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 podczas ustawiania PublishProfile właściwości określisz ścieżkę i rozszerzenie pliku, zostaną one zignorowane. Program MSBuild domyślnie wyszukuje w folderze Properties/PublishProfiles i zakłada rozszerzenie pliku pubxml. Aby określić ścieżkę i nazwę pliku wraz z rozszerzeniem, ustaw PublishProfileFullPath właściwość zamiast PublishProfile właściwości .

W pliku .pubxml:

• PublishUrl jest używany przez program Visual Studio do oznaczania miejsca 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 . Po rozwiązaniu problemu z usługą GitHub dotnet/sdk#20931 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 , aby dodać obsługę 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 istotne właściwości .pubxml , które nie są obsługiwane przez dotnet publish program, to następujące właściwości, 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 polecenia 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 (Obrazy ReadyToRun).

  Aby wyświetlić ostrzeżenia dotyczące brakujących zależności, które mogą powodować błędy środowiska uruchomieniowego, użyj polecenia 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 bundler 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 Przycinanie samodzielnych wdrożeń i plików wykonywalnych. 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:

• Dokumentacja wiersza polecenia programu MSBuild
• Profile publikowania programu Visual Studio (pubxml) dla wdrożenia aplikacji ASP.NET Core
• dotnet msbuild

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-x86wartość . Jeśli używasz tej opcji, nie używaj -r|--runtime opcji . 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 (Układ danych wyjściowych artefaktów). 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 Release konfiguracji dla projektów, których element TargetFramework jest ustawiony na net8.0 lub nowszą wersję. Domyślna konfiguracja kompilacji dotyczy Debug 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, które mają być używane do przycinania zestawu pakietów publikowanych w aplikacji. Plik manifestu jest częścią danych wyjściowych dotnet store polecenia . Aby określić wiele manifestów, dodaj --manifest opcję 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, wartość domyślna to [project_file_folder]/bin/[configuration]/[framework]/publish/ dla plików binarnych zależnych od platformy i plików binarnych zależnych od platformy. Wartość domyślna to [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 dotnet publish polecenia powodują zagnieżdżone foldery wyjściowe. Jeśli na przykład folder projektu to myproject, a folder wyjściowy publikowania to myproject/publish, a następnie uruchomisz dotnet publish dwa razy, drugi przebieg umieszcza pliki zawartości, takie jak .config i .json plików w folderze myproject/publish/publish. Aby uniknąć zagnieżdżania folderów publikowania, określ folder publikowania, który nie znajduje się bezpośrednio w folderze projektu, lub wyklucz folder publikowania z projektu. Aby wykluczyć folder publikowania o nazwie publishoutput, dodaj następujący element do PropertyGroup elementu w pliku csproj :

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

  • Zestaw .NET 7.0.200 SDK lub nowszy

    Jeśli określisz opcję podczas uruchamiania --output tego polecenia w rozwiązaniu, interfejs wiersza polecenia będzie emitować ostrzeżenie (błąd w wersji 7.0.200) z powodu niejasnej 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 projektami, które mają różne wersje zależności bezpośrednich i przechodnich. Aby uzyskać więcej informacji, zobacz Opcja na poziomie --output 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 --output opcji. Na przykład dotnet publish -p:PublishDir=.\publish wysyła dane wyjściowe publikowania dla każdego projektu do publish folderu 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-x64wartość . Jeśli używasz tej opcji, nie używaj -r|--runtime opcji . 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 platformy .NET i Publikowanie aplikacji platformy .NET przy użyciu interfejsu wiersza polecenia platformy .NET.

  Jeśli ta opcja jest używana bez określenia 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 elementu --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 platformy .NET i Publikowanie aplikacji platformy .NET przy użyciu interfejsu wiersza polecenia platformy .NET. Jeśli używasz tej opcji, użyj --self-contained lub --no-self-contained również.

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

  Określa, czy rejestrator terminalu ma być używany 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 terminalu. 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]

  RuntimeIdentifier Ustawia 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, , PublishAotPublishSelfContained, , 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], , n[ormal]m[inimal], d[etailed], i diag[nostic]. Wartość domyślna to minimal. Aby uzyskać więcej informacji, zobacz LoggerVerbosity.

• --version-suffix <VERSION_SUFFIX>

  Definiuje sufiks wersji, który zastąpi gwiazdkę (*) w polu wersji pliku projektu.

Przykłady

• Utwórz plik binarny międzyplatformowy zależny od platformy 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 struktury dla bieżącej platformy.

• Utwórz samodzielny plik wykonywalny 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 struktury 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ż

• Omówienie publikowania aplikacji platformy .NET
• Publikowanie aplikacji platformy .NET za pomocą interfejsu wiersza polecenia platformy .NET
• Platformy docelowe
• Wykaz identyfikatorów środowiska uruchomieniowego (RID)
• Konteneryzowanie aplikacji .NET za pomocą polecenia dotnet publish
• Praca z notaryzacji systemu macOS Catalina
• Struktura katalogów opublikowanej aplikacji
• Dokumentacja wiersza polecenia programu MSBuild
• Profile publikowania programu Visual Studio (pubxml) dla wdrożenia aplikacji ASP.NET Core
• dotnet msbuild
• Przycinanie wdrożeń samodzielnie zawartych