相关文章推荐
多情的自行车  ·  HTTP response codes - ...·  2 年前    · 
曾深爱过的乒乓球  ·  load balancer does ...·  2 年前    · 
另类的沙发  ·  内核编译make ...·  2 年前    · 

このブラウザーはサポートされなくなりました。

Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。

Microsoft Edge をダウンロードする Internet Explorer と Microsoft Edge の詳細情報

この記事の対象: ✔️ .NET Core 3.1 SDK 以降のバージョン

dotnet publish - ホスティング システムへの展開のため、アプリケーションとその依存関係をフォルダーに発行します。

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

dotnet publish はアプリケーションをコンパイルし、プロジェクト ファイルに指定されたその依存関係を読み取り、結果のファイル セットをディレクトリに発行します。 出力には次のアセットが含まれます。

  • アセンブリの中間言語 (IL) コード (dll 拡張子)。
  • .deps.json ファイル。プロジェクトのすべての依存関係が含まれます。
  • .runtimeconfig.json ファイル。アプリケーションが想定する共有ランタイムと、ランタイム用の他の構成オプション (ガベージ コレクションの種類など) を指定します。
  • アプリケーションの依存関係。NuGet キャッシュから出力フォルダーにコピーされます。
  • dotnet publish コマンドの出力は、実行のためにホスト システム (サーバー、PC、Mac、ラップトップなど) にすぐに展開できます。 これは、アプリケーションの展開を準備するための正式にサポートされている唯一の方法です。 プロジェクトで指定されている展開の種類によっては、ホスティング システムに .NET 共有ランタイムがインストールされている場合とされていない場合があります。 詳細については、.NET CLI を使用した .NET アプリの発行に関する記事を参照してください。

    暗黙的な復元

    復元を必要とするすべてのコマンド (dotnet newdotnet builddotnet rundotnet testdotnet publishdotnet pack など) によって暗黙的に実行されるため、dotnet restore を実行する必要がなくなりました。 暗黙的な復元を無効にするには、--no-restore オプションを使用します。

    dotnet restoreなどの、明示的な復元が意味のある一部のシナリオや、復元が行われるタイミングを明示的に制御する必要があるビルド システムでは、dotnet restore は引き続き有用なコマンドです。

    NuGet フィードの管理方法については、 のドキュメントをご覧ください。

    MSBuild

    dotnet publish コマンドは、Publish ターゲットを呼び出す MSBuild を呼び出します。 特定のプロジェクトに対して IsPublishable プロパティfalse に設定されている場合、Publish ターゲットを呼び出すことはできません。また、dotnet publish コマンドは、プロジェクトで暗黙の dotnet restore のみを実行します。

    dotnet publish に渡されたすべてのパラメーターが MSBuild に渡されます。 -c-o のパラメーターは、それぞれ MSBuild の ConfigurationPublishDir にマップします。

    dotnet publish コマンドは、プロパティを設定する -p やロガーを定義する -l などの MSBuild オプションも受け入れます。 たとえば、-p:<NAME>=<VALUE> という形式を使用して、MSBuild プロパティを設定できます。

    .pubxml ファイル

    また、.pubxml ファイルを参照することで、公開関連のプロパティを設定することもできます。 例:

    dotnet publish -p:PublishProfile=FolderProfile
    

    前の例では、<project_folder>/Properties/PublishProfiles フォルダー内に見つかった FolderProfile.pubxml ファイルが使用されています。 PublishProfile プロパティの設定時にパスとファイル拡張子を指定した場合、それらは無視されます。 既定では、MSBuild によって Properties/PublishProfiles フォルダー内が調べられ、pubxml ファイル拡張子が前提とされます。 パスと拡張子を含むファイル名を指定するには、PublishProfile プロパティではなく PublishProfileFullPath プロパティを設定します。

    .pubxml ファイルで、次の手順を実行します。

  • PublishUrl は、発行先を示すために Visual Studio によって使用されます。
  • PublishDir は、発行先を示すために CLI によって使用されます。
  • シナリオをすべての場所で動作させる場合は、両方のプロパティを .pubxml ファイル内の同じ値に初期化できます。 GitHub issue dotnet/sdk#20931 が解決されると、これらのプロパティの 1 つだけを設定する必要があります。

    .pubxml ファイル内の一部のプロパティは Visual Studio でのみ使用され、 にはdotnet publish影響しません。 Visual Studio の動作に合わせて CLI をより多く取り入れるために取り組んでいます。 ただし、一部のプロパティは CLI では使用されません。 CLI と Visual Studio はどちらも発行のパッケージ化の側面を行い、 dotnet/sdk#29817 は それに関連するその他のプロパティのサポートを追加する予定です。 ただし、CLI では、発行のデプロイ自動化の側面は行われず、それに関連するプロパティはサポートされていません。 でdotnet publishサポートされていない最も注目すべき .pubxml プロパティは、ビルドに影響を与える次のプロパティです。

  • LastUsedBuildConfiguration
  • Configuration
  • Platform
  • LastUsedPlatform
  • TargetFramework
  • TargetFrameworks
  • RuntimeIdentifier
  • RuntimeIdentifiers
  • MSBuild プロパティ

    次の MSBuild プロパティでは、dotnet publish の出力が変更されます。

  • PublishReadyToRun

    アプリケーション アセンブリは ReadyToRun (R2R) 形式にコンパイルされます。 R2R とは、Ahead-Of-Time (AOT) コンパイルの一種です。 詳細については、「ReadyToRun イメージ」を参照してください。

    実行時エラーの原因になる可能性のある足りない依存関係に関する警告を表示するには、PublishReadyToRunShowWarnings=true を使用します。

    PublishReadyToRun は、コマンド ラインではなく、発行プロファイルで指定することをお勧めします。

  • PublishSingleFile

    アプリを、プラットフォームごとに単一の実行可能ファイルにパッケージ化します。 単一ファイルの発行の詳細については、単一ファイル バンドラー設計のドキュメントを参照してください。

    このオプションは、コマンド ラインではなく、プロジェクト ファイルで指定することをお勧めします。

  • PublishTrimmed

    自己完結型の実行可能ファイルを発行するとき、使用されていないライブラリをトリミングして、アプリの展開サイズを減らします。 詳細については、「自己完結型の展開と実行可能ファイルのトリミング」を参照してください。 .NET 6 SDK 以降で利用可能です。

    このオプションは、コマンド ラインではなく、プロジェクト ファイルで指定することをお勧めします。

    詳細については、次のリソースを参照してください。

  • MSBuild コマンド ライン リファレンス
  • ASP.NET Core アプリを配置するための Visual Studio 発行プロファイル (.pubxml)
  • dotnet msbuild
  • ワークロード マニフェストのダウンロード

    このコマンドを実行すると、ワークロードの広告マニフェストの非同期バックグラウンド ダウンロードが開始されます。 このコマンドが終了してもダウンロードが実行されている場合、ダウンロードは停止します。 詳細については、「広告マニフェスト」を参照してください。

  • PROJECT|SOLUTION

    発行するプロジェクトまたはソリューション。

  • PROJECT は、C#、F#、Visual Basic のプロジェクト ファイルのパスとファイル名、または C#、F#、Visual Basic のプロジェクト ファイルが含まれるディレクトリへのパスです。 ディレクトリが指定されていない場合は、既定で現在のディレクトリに設定されます。

  • SOLUTION は、ソリューション ファイルのパスとファイル名 ( .sln 拡張子)、またはソリューション ファイルを含むディレクトリのパスです。 ディレクトリが指定されていない場合は、既定で現在のディレクトリに設定されます。

  • -f|--framework <FRAMEWORK>

    指定したターゲット フレームワークのアプリケーションを発行します。 ターゲット フレームワークはプロジェクト ファイルで指定する必要があります。

  • --force

    最後の復元が成功した場合でも、すべての依存関係が強制的に解決されます。 このフラグを指定することは、project.assets.json ファイルを削除することと同じです。

  • -?|-h|--help

    コマンドの使用方法を示した説明を出力します。

  • --interactive

    コマンドを停止して、ユーザーの入力または操作のために待機させることができます。 たとえば、認証を完了する場合があります。 .NET Core 3.0 SDK 以降で使用できます。

  • --manifest <PATH_TO_MANIFEST_FILE>

    アプリによって公開された一連のパッケージをトリミングするために使用するターゲット マニフェストを 1 つまたは複数指定します。 マニフェスト ファイルは、dotnet store コマンドの出力の一部です。 複数のマニフェストを指定するには、マニフェストごとに --manifest を追加します。

  • --no-build

    発行の前にプロジェクトをビルドしません。 また、--no-restore フラグが暗黙的に設定されます。

  • --no-dependencies

    プロジェクト間参照を無視し、ルート プロジェクトのみを復元します。

  • --nologo

    著作権情報を表示しません。

  • --no-restore

    コマンドを実行するときに、暗黙的な復元を実行しません。

  • -o|--output <OUTPUT_DIRECTORY>

    出力ディレクトリのパスを指定します。

    指定しない場合、フレームワークに依存する実行可能ファイルおよびクロスプラットフォーム バイナリの既定値は [project_file_folder]/bin/[configuration]/[framework]/publish/ に設定されます。 自己完結型の実行可能ファイルの場合、既定値は [project_file_folder]/bin/[configuration]/[framework]/[runtime]/publish/ に設定されます。

    Web プロジェクトで、出力フォルダーがプロジェクト フォルダー内にある場合、dotnet publish コマンドを連続して実行すると、出力フォルダーが入れ子になって生成されます。 たとえば、プロジェクト フォルダーが myproject で、発行の出力フォルダーが myproject/publish であり、dotnet publish を 2 回実行した場合、2 回目の実行では myproject/publish/publish.config および .json ファイルなどのコンテンツ ファイルが配置されます。 発行フォルダーが入れ子にならないようにするには、プロジェクト フォルダーの直下以外の発行フォルダーを指定するか、またはプロジェクトから発行フォルダーを除外します。 publishoutput という名前の発行フォルダーを除外するには、 .csproj ファイルの PropertyGroup 要素に次の要素を追加します。

    <DefaultItemExcludes>$(DefaultItemExcludes);publishoutput**</DefaultItemExcludes>
    
  • .NET 7.0.200 SDK 以降

    ソリューションでこのコマンドを実行するときに --output オプションを指定すると、出力パスの不明なセマンティクスが原因で、CLI から警告 (7.0.200 のエラー) が出力されます。 このオプションは、ビルドされたすべてのプロジェクトのすべての出力が指定されたディレクトリにコピーされるため、この --output オプションは許可されません。これは、複数のターゲットを持つプロジェクトと、直接および推移的依存関係の異なるバージョンを持つプロジェクトと互換性がありません。 詳しくは、「ソリューション レベルの --output オプションがビルド関連コマンドで無効に」を参照してください。

  • .NET Core 3.x SDK 以降

    プロジェクトを発行するときに相対パスを指定した場合、生成される出力ディレクトリは、プロジェクト ファイルの場所ではなく、現在の作業ディレクトリに相対的なパスとなります。

    ソリューションを発行するときに相対パスを指定した場合、すべてのプロジェクトに対する出力はすべて、現在の作業ディレクトリと相対的な指定されたフォルダーに移動されます。 発行の出力が各プロジェクトの個別のフォルダーに移動されるようにするには、--output オプションの代わりに、msbuild PublishDir プロパティを使用して相対パスを指定します。 たとえば、dotnet publish -p:PublishDir=.\publish を使用すると、プロジェクト ファイルが格納されているフォルダーの下にある publish フォルダーに、各プロジェクトの発行の出力が送信されます。

  • .NET Core 2.x SDK

    プロジェクトを発行するときに相対パスを指定した場合、生成される出力ディレクトリは、現在の作業ディレクトリではなく、プロジェクト ファイルの場所に相対的なパスとなります。

    ソリューションを発行するときに相対パスを指定した場合、各プロジェクトの出力は、プロジェクト ファイルの場所に相対的な別のフォルダーに移動されます。 ソリューションを発行するときに絶対パスを指定した場合、すべてのプロジェクトに対する発行の出力はすべて、指定されたフォルダーに移動されます。

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

    アプリケーションと併せて .NET ランタイムを発行します。これにより、ランタイムをターゲット コンピューターにインストールする必要がなくなります。 ランタイム識別子が指定され、プロジェクトが (ライブラリ プロジェクトではなく) 実行可能なプロジェクトである場合、既定値は true です。 詳細については、.NET アプリケーションの発行、および .NET CLI を使用した .NET アプリの発行に関する各記事を参照してください。

    true または false を指定せずに、このオプションを使用した場合、既定値は true になります。 その場合は、その位置で true または false が想定されているため、--self-contained の直後にソリューションまたはプロジェクト引数を配置しないでください。

  • --no-self-contained

    これは、--self-contained false に相当します。

  • --source <SOURCE>

    復元操作時に使用する NuGet パッケージ ソースの URI。

  • -r|--runtime <RUNTIME_IDENTIFIER>

    指定されたランタイムのアプリケーションを発行します。 ランタイム ID (RID) の一覧については、RID カタログに関するページをご覧ください。 詳細については、.NET アプリケーションの発行、および .NET CLI を使用した .NET アプリの発行に関する各記事を参照してください。 このオプションを使用する場合は、--self-contained または --no-self-contained も使用します。

  • -v|--verbosity <LEVEL>

    コマンドの詳細レベルを設定します。 指定できる値は、q[uiet]m[inimal]n[ormal]d[etailed]、および diag[nostic] です。 既定値は、minimal です。 詳細については、「LoggerVerbosity」を参照してください。

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

    RuntimeIdentifier をいずれかのマシンに基づいてプラットフォームの移植可能な RuntimeIdentifier に設定します。 これは、SelfContainedPublishAotPublishSelfContainedPublishSingleFilePublishReadyToRun などの RuntimeIdentifier を必要とするプロパティにより暗黙的に発生します。 プロパティが false に設定されていると、その暗黙の解決は発生しなくなります。

  • --version-suffix <VERSION_SUFFIX>

    プロジェクト ファイルのバージョン フィールドでアスタリスク (*) を置き換えるバージョン サフィックスを定義します。

  • 現在のディレクトリに、プロジェクト用のフレームワークに依存するクロスプラットフォーム バイナリを作成します。

    dotnet publish
    

    この例では、.NET Core 3.0 SDK 以降、現在のプラットフォーム用のフレームワークに依存する実行可能ファイルも作成されます。

  • 特定のランタイムに対して、現在のディレクトリ内にプロジェクト用の自己完結型の実行可能ファイルを作成します。

    dotnet publish --runtime osx.10.11-x64
    

    RID をプロジェクト ファイルに含める必要があります。

  • 特定のプラットフォーム用に、プロジェクト用のフレームワークに依存する実行可能ファイルを現在のディレクトリに作成します。

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

    RID をプロジェクト ファイルに含める必要があります。 この例は、.NET Core 3.0 SDK 以降のバージョンに適用されます。

  • 特定のランタイムとターゲット フレームワーク用に、現在のディレクトリのプロジェクトを発行します。

    dotnet publish --framework netcoreapp3.1 --runtime osx.10.11-x64
    
  • 指定されたプロジェクト ファイルを発行します。

    dotnet publish ~/projects/app1/app1.csproj
    
  • 現在のアプリケーションを発行します。ただし、復元操作中はルート プロジェクトのみを復元し、プロジェクト間 (P2P) 参照は復元しないでください。

    dotnet publish --no-dependencies
    
  • .NET アプリケーションの発行の概要
  • .NET CLI を使用した .NET アプリの発行
  • ターゲット フレームワーク
  • Runtime Identifier (RID) カタログ
  • dotnet publish を使用して .NET アプリをコンテナー化する
  • macOS Catalina の公証に対応する
  • 発行されたアプリケーションのディレクトリ構造
  • MSBuild コマンド ライン リファレンス
  • ASP.NET Core アプリを配置するための Visual Studio 発行プロファイル (.pubxml)
  • dotnet msbuild
  • 自己完結型の展開をトリミングする
  •