dotnet publish

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>]
    [-c|--configuration <CONFIGURATION>]
    [-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>] [--use-current-runtime, --ucr [true|false]]
    [-v|--verbosity <LEVEL>] [--version-suffix <VERSION_SUFFIX>]

dotnet publish -h|--help

Description

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

• Kod języka pośredniego (IL) w zestawie z rozszerzeniem dll .
• Plik .deps.json , który zawiera wszystkie zależności projektu.
• Plik .runtimeconfig.json , który określa ś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 builddotnet run, dotnet test, , dotnet publishi 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 Azure DevOps Services lub w systemach kompilacji, które muszą jawnie kontrolować, kiedy odbywa się 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 element 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 programu MSBuildConfiguration.

Polecenie dotnet publish akceptuje opcje programu MSBuild, takie jak -p ustawianie właściwości i -l definiowanie rejestratora. Na przykład można 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 . 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 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 do tej samej wartości 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ą uznawane tylko przez program Visual Studio i nie mają wpływu na element 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 plany 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 wpływające 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 to forma kompilacji Z wyprzedzeniem (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 Trim samodzielne wdrożenia i pliki wykonywalne. Dostępne od zestawu .NET 6 SDK.

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

Więcej informacji można znaleźć w następujących zasobach:

• Dokumentacja wiersza polecenia programu MSBuild
• Profile publikowania programu Visual Studio (pubxml) na potrzeby wdrażania 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 domyślnie określony bieżący katalog.

  • 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 domyślnie określony bieżący katalog.

Options

• -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ślając --arch x86 identyfikator RID na win-x86wartość . Jeśli używasz tej opcji, nie używaj -r|--runtime tej opcji. Dostępne od wersji zapoznawczej 7 platformy .NET 6.

• -c|--configuration <CONFIGURATION>

  Definiuje konfigurację kompilacji. Wartość domyślna dla większości projektów to Debug, ale można zastąpić ustawienia konfiguracji kompilacji w projekcie.

• -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ępne od zestawu .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 wykonywalnych zależnych od platformy i plików binarnych międzyplatformowych. 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 pliki.config i json w folderze myproject/publish/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 i nowsze

    Jeśli określisz opcję 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 wielowersyjnymi, 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 .NET Core 3.x SDK i nowsze

    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 podczas publikowania rozwiązania określisz ścieżkę względną, wszystkie dane wyjściowe dla wszystkich projektów zostaną przekierowane 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 podczas publikowania projektu określisz ścieżkę względną, 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 będą przechodzić 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ą przekierowane 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ślając --os linux identyfikator RID na linux-x64wartość . Jeśli używasz tej opcji, nie używaj -r|--runtime tej 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. Ustawieniem domyślnym jest true określenie identyfikatora środowiska uruchomieniowego, a projekt jest projektem wykonywalnym (a nie projektem biblioteki). Aby uzyskać więcej informacji, zobacz Publikowanie aplikacji .NET i Publikowanie aplikacji .NET za pomocą 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 lub 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 .NET za pomocą interfejsu wiersza polecenia platformy .NET. Jeśli używasz tej opcji, użyj --self-contained lub --no-self-contained również.

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

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

  RuntimeIdentifier Ustawia element 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, PublishSingleFile, i PublishReadyToRun. Jeśli właściwość ma wartość false, ta niejawna rozdzielczość nie będzie już występować.

• --version-suffix <VERSION_SUFFIX>

  Definiuje sufiks wersji, aby 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.10.11-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.10.11-x64 --self-contained false
  

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

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

  dotnet publish --framework netcoreapp3.1 --runtime osx.10.11-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 .NET za pomocą interfejsu wiersza polecenia platformy .NET
• Platformy docelowe
• Wykaz identyfikatorów środowisk uruchomieniowych (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) na potrzeby wdrażania aplikacji ASP.NET Core
• dotnet msbuild
• Przycinanie samodzielnych wdrożeń