次の方法で共有

dotnet CLI を使用して NuGet パッケージを作成する

  • [アーティクル]

NuGet パッケージには、開発者がプロジェクトで再利用できるコードが含まれています。 コードの動作や内容に関係なく、コマンドライン ツール (nuget.exe または dotnet.exe のいずれか) を使用して、NuGet パッケージを作成します。

この記事では、dotnet CLI を使用してパッケージを作成する方法について説明します。 Visual Studio 2017 以降では、dotnet CLI はすべての .NET ワークロードと .NET Core ワークロードに含まれています。 dotnet CLI またはその他の NuGet クライアント ツールをインストールする必要がある場合は、「NuGet クライアント ツールをインストールする」を参照してください。

このトピックは、.NET プロジェクトおよび SDK スタイルの形式を使用する他のプロジェクトにのみを対象としています。 これらのプロジェクトでは、NuGet はプロジェクト ファイルの情報を使用してパッケージを作成します。 クイックスタート チュートリアルについては、「dotnet CLI を使用してパッケージを作成する」または「Visual Studio を使用してパッケージを作成する」を参照してください。

MSBuild の msbuild -t:pack コマンドは、機能的には dotnet pack と同一です。 MSBuild を使用したパッケージの作成の詳細については、「MSBuild を使用して NuGet パッケージを作成する」を参照してください。

Note

プロパティの設定

dotnet new classlib コマンドを使用してクラス ライブラリ プロジェクトの例を作成し、dotnet pack を使用してプロジェクトをパッケージ化できます。 dotnet pack コマンドは次のプロパティを使用します。 プロジェクト ファイルで値を指定しない場合、このコマンドは既定値を使用します。

  • パッケージ識別子である PackageId は、nuget.org とそのパッケージをホストするその他のターゲット間で一意である必要があります。 値を指定しない場合、このコマンドは AssemblyName を使用します。
  • Version は Major.Minor.Patch[-Suffix] という形式の特定のバージョン番号です。-Suffix はプレリリース バージョンを識別するものです。 指定しない場合は、既定値の 1.0.0 が使用されます。
  • Authors はパッケージの作成者です。 指定しない場合、既定値は AssemblyName です。
  • Company は会社情報です。 指定しない場合、既定値は Authors の値です。
  • Product は製品情報です。 指定しない場合、既定値は AssemblyName です。

Visual Studio では、プロジェクトのプロパティでこれらの値を設定できます。 ソリューション エクスプローラーで、プロジェクトを右クリックして [プロパティ] を選択し、[パッケージ] セクションを選択します。 .csproj またはその他のプロジェクト ファイルにこれらのプロパティを直接追加することもできます。

次の例は、パッケージ プロパティが追加されたプロジェクト ファイルを示しています。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <PackageId>UniqueID</PackageId>
    <Version>1.0.0</Version>
    <Authors>Author Name</Authors>
    <Company>Company Name</Company>
    <Product>Product Name</Product>
  </PropertyGroup>
</Project>

その他のオプションのプロパティ (Title、PackageDescription、PackageTags など) を追加できます。

Note

一般公開するためにビルドするパッケージについては、PackageTags プロパティに特に注意してください。 タグは、他のユーザーがパッケージを見つけて、その内容を理解するのに役立ちます。

dotnet pack コマンドは、プロジェクト ファイル内の PackageReference を、作成されたパッケージの依存関係に自動的に変換します。 IncludeAssets、ExcludeAssets、および PrivateAssets タグを使用して、含めるアセットを制御できます。 詳しくは、「依存関係アセットを制御する」をご覧ください。

依存関係、オプションのプロパティ、およびバージョン管理の詳細については、以下を参照してください。

一意のパッケージ識別子を選択してバージョン番号を設定する

パッケージ識別子とバージョン番号は、パッケージに含まれる正確なコードを一意に識別します。

パッケージ識別子を作成するには、次のベスト プラクティスに従ってください。

  • パッケージ識別子は、nuget.org とそのパッケージをホストするその他すべての場所間で一意である必要があります。 競合を避けるために、識別子の最初の部分に会社の名前を使用すると、適切なパターンになります。

  • ドット表記を使用して、.NET 名前空間のような名前付け規則に従います。 たとえば、Contoso-Utility-UsefulStuff や Contoso_Utility_UsefulStuff ではなく Contoso.Utility.UsefulStuff を使用します。 また、コードで使用する名前空間とパッケージ識別子を合わせると、コンシューマーにも役立ちます。

  • 別のパッケージの使用方法を示すサンプル コードのパッケージを生成する場合、Contoso.Utility.UsefulStuff.Sample のように、識別子に .Sample を付加します。

    サンプル パッケージは、元のパッケージと依存関係があります。 サンプル パッケージを作成するときに、<IncludeAssets> と値 contentFiles を追加します。 content フォルダー内の、\Samples\<identifier> というフォルダー (\Samples\Contoso.Utility.UsefulStuff.Sample など) にサンプル コードを配置します。

パッケージのバージョンを設定するには、次のベスト プラクティスに従ってください。

  • これは厳密には必須ではありませんが、一般的に、パッケージのバージョンはプロジェクトまたはアセンブリのバージョンと一致するように設定します。 パッケージを単一のアセンブリに限定する場合は、バージョンを一致させるのは簡単です。 NuGet 自体は依存関係の解決時に、アセンブリのバージョンではなくパッケージのバージョンを使います。

  • 非標準のバージョン スキームを使用するときは、「パッケージのバージョン管理」で説明するように、NuGet バージョン管理ルールを考慮してください。 NuGet は、セマンティック バージョニング 2.0.0 にほぼ準拠しています。

Note

依存関係の解決の詳細については、「PackageReference による依存関係の解決」を参照してください。 バージョン管理の理解を深めるために役立つ可能性がある情報については、こちらの一連のブログ投稿を参照してください。

省略可能な説明フィールドを追加する

パッケージのオプションの説明は、パッケージの nuget.org ページの [README] タブに表示されます。 説明は、プロジェクト ファイルの <Description> または .nuspec ファイルの $description からプルされます。

次の例は、.NET パッケージの .csproj ファイル内の Description を示しています。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <PackageId>Azure.Storage.Blobs</PackageId>
    <Version>12.4.0</Version>
    <PackageTags>Microsoft Azure Storage Blobs;Microsoft;Azure;Blobs;Blob;Storage;StorageScalable</PackageTags>
    <Description>
      This client library enables working with the Microsoft Azure Storage Blob service for storing binary and text data.
      For this release see notes - https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/storage/Azure.Storage.Blobs/README.md and https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/storage/Azure.Storage.Blobs/CHANGELOG.md
      in addition to the breaking changes https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/storage/Azure.Storage.Blobs/BreakingChanges.txt
      Microsoft Azure Storage quickstarts and tutorials - https://learn.microsoft.com/azure/storage/
      Microsoft Azure Storage REST API Reference - https://learn.microsoft.com/rest/api/storageservices/
      REST API Reference for Blob Service - https://learn.microsoft.com/rest/api/storageservices/blob-service-rest-api
    </Description>
  </PropertyGroup>
</Project>

pack コマンドを実行する

NuGet パッケージまたは .nupkg ファイルを作成するには、プロジェクト フォルダーから dotnet pack コマンドを実行します。このコマンドではプロジェクトのビルドも自動的に行われます。

dotnet pack

出力に、.nupkg ファイルへのパスが表示されます。

MSBuild version 17.3.0+92e077650 for .NET
  Determining projects to restore...
  Restored D:\proj\AppLoggerNet\AppLogger\AppLogger.csproj (in 97 ms).
  Successfully created package 'D:\proj\AppLoggerNet\AppLogger\bin\Debug\AppLogger.1.0.0.nupkg'.

ビルド時に自動的にパッケージを生成する

dotnet build の実行時に自動的に dotnet pack を実行させるには、プロジェクト ファイルの <PropertyGroup> タグ内に次の行を追加します。

<GeneratePackageOnBuild>true</GeneratePackageOnBuild>

Note

パッケージを自動的に生成する場合、パッキングによってプロジェクトのビルド時間が長くなります。

ソリューション上で dotnet pack を実行すると、パック可能なソリューション内のすべてのプロジェクト (IsPackable プロパティ true に設定されているもの) がパックされます。

パッケージ インストールのテスト

パッケージを公開する前に、プロジェクトへのパッケージのインストールをテストする必要があります。 このテストにより、必要なファイルがすべて、プロジェクト内の適切な場所に入ります。

インストールのテストは Visual Studio またはコマンド ラインで、パッケージ インストール手順を利用して手動で行うことができます。

重要

  • 作成した後にパッケージを変更することはできません。 問題を修正する場合は、パッケージの内容を変更して再パックします。

  • パッケージを再作成した後も、グローバル パッケージ フォルダーを消去するまで、再テストでは古いバージョンのパッケージが使用されます。 すべてのビルドで一意のプレリリース ラベルを使用しないパッケージの場合、このフォルダーを消去することが特に重要です。

次のステップ

パッケージを作成したら、.nupkg ファイルを任意のホストに公開できます。

パッケージの公開

パッケージの機能を拡張する方法や、他のシナリオをサポートする方法については、次の記事を参照してください。