パッケージの機能や含まれるコードに関係なく、 nuget.exe または dotnet.exeのいずれかのコマンド ライン インターフェイス (CLI) ツールを使用して、その機能を他の開発者と共有して使用できるコンポーネントにパッケージ化します。 NuGet CLI ツールをインストールするには、「 NuGet クライアント ツールのインストール」を参照してください。 Visual Studioには CLI ツールは自動的に含まれません。
SDK スタイル以外のプロジェクト (通常は Framework プロジェクト.NET) の場合は、この記事で説明されている手順に従ってパッケージを作成します。 Visual Studioと
nuget.exeCLI の使用に関する詳細な手順を示すクイック スタートについては、「Quickstart: Visual Studio (.NET Framework,Windows) を使用してパッケージを作成して発行する」を参照してください。SDK スタイルの形式、およびその他の SDK スタイルのプロジェクトを使用する .NET Core および .NET Standard プロジェクトについては、「 dotnet CLI を使用して NuGet パッケージを作成するを参照してください。
packages.configからPackageReferenceに移行されたプロジェクトの場合は、msbuild -t:packコマンドを使用します。
技術的には、NuGet パッケージは、拡張子 が .nupkg に変更され、その内容が特定の規則に一致するように名前が変更された ZIP ファイルです。 この記事では、これらの規則を満たすパッケージを作成する詳細なプロセスについて説明します。
パッケージ化は、パッケージとして配信するコンパイル済みコード (アセンブリ)、シンボル、およびその他のファイルから始まります。 パッケージ化プロセスの概要については、「 パッケージ作成ワークフロー」を参照してください。 このプロセスは、パッケージに入るファイルのコンパイルや生成とは無関係です。 ただし、プロジェクト ファイル内の情報から描画して、コンパイル済みのアセンブリとパッケージを同期させることができます。
Important
この記事は、SDK スタイル以外のプロジェクトに適用されます。通常は、.NET Core および .NET Standard プロジェクト以外のプロジェクトで、Visual Studio 2017 以降のバージョンと NuGet 4.0 以降を使用します。
パッケージ化するアセンブリを決定する
ほとんどの汎用パッケージには、他の開発者が独自のプロジェクトで使用できる 1 つ以上のアセンブリが含まれています。
一般に、各アセンブリが個別に役立つ場合は、NuGet パッケージごとに 1 つのアセンブリを用意することをお勧めします。 たとえば、Parser.dllというアセンブリに依存する Utilities.dll というアセンブリを含む次のケースを考えて みます 。
Parser.dll 単独で便利な場合は、Utilities.dll用と Parser.dll 用に 1 つのパッケージを作成します。 これにより、開発者はUtilities.dllとは別に Parser.dll を使用できます。
Parser.dllUtilities.dll によってのみ使用されるコードが含まれている場合は、Parser.dllを同じパッケージに保持しても問題ありません。 一般に、ライブラリが個別に役立たない複数のアセンブリで構成されている場合は、それらを 1 つのパッケージに結合しても問題ありません。
Utilities.dll も Utilities.resources.dllに依存しており、Utilities.resources.dll 単独では役に立たない場合は、両方を同じパッケージに配置します。
前の例の Utilities.resources.dll アセンブリなどのリソースは特殊なケースです。 パッケージがプロジェクトにインストールされると、NuGet はパッケージの DLL にアセンブリ参照を自動的に追加します。ただし、アセンブリ参照はローカライズされたサテライト アセンブリと見なされるため、.resources.dllという名前の DLL は除きます。 ライブラリのローカライズされたバージョンの詳細については、「 ローカライズされた NuGet パッケージの作成」を参照してください。 このため、重要なパッケージ コードを含むファイルには .resources.dll を使用しないでください。
ライブラリにコンポーネント オブジェクト モデル (COM) 相互運用機能アセンブリが含まれている場合は、「COM 相互運用機能アセンブリを 含む NuGet パッケージを作成する」の追加のガイドラインに従ってください。
.nuspec ファイルのロールと構造
パッケージ化するファイルがわかっている場合は、次の手順として 、.nuspec XML ファイルにパッケージ マニフェストを作成します。
マニフェスト:
- パッケージの内容について説明し、それ自体がパッケージに含まれます。
- パッケージの作成を開始し、パッケージをプロジェクトにインストールする方法を NuGet に指示します。 たとえば、マニフェストは他のパッケージの依存関係を識別するため、メイン パッケージのインストール時に NuGet がそれらの依存関係をインストールすることもできます。
- このセクションの残りの部分で説明するように、必須プロパティと省略可能なプロパティの両方が含まれています。 ここに記載されていないその他のプロパティなど、詳細については、 .nuspec リファレンスを参照してください。
マニフェストでは、次のプロパティが必要です。
- パッケージ識別子。パッケージをホストするギャラリー全体で一意である必要があります
- Major.Minor.Patch[-Suffix] という形式の特定のバージョン番号。-Suffix はプレリリース バージョンを識別します
- ホストに表示されるパッケージ タイトル (nuget.org など)
- 作成者情報
- パッケージの長い説明
次のプロパティは、省略可能な一般的なプロパティです。
- リリースノート
- 著作権情報。
- Visual StudioPackage Manager UI の簡単な説明>。
- ロケール ID。
- プロジェクトの URL。
- 式またはファイルとしてのライセンス。
licenseUrlプロパティは非推奨です。 代わりに、licensenuspec メタデータ要素を使用してください。 - リードミー ファイル。
- アイコン ファイル。
iconUrlプロパティは非推奨です。 代わりに、iconnuspec メタデータ要素を使用してください。 - 依存関係と参照の一覧。
- ギャラリーの検索に役立つタグ。
次のコードは、プロパティを記述するコメントを含む一般的な (ただし架空の) .nuspec ファイルです。
<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
<metadata>
<!-- An identifier that must be unique within the hosting gallery -->
<id>Contoso.Utility.UsefulStuff</id>
<!-- A package version number that's used when resolving dependencies -->
<version>1.8.3</version>
<!-- A comma-separated list of package authors that sometimes appears directly on the gallery -->
<authors>Dejana Tesic, Rajeev Dey</authors>
<!-- A project URL that provides a link for the gallery -->
<projectUrl>http://github.com/contoso/UsefulStuff</projectUrl>
<!-- License information that's displayed on the gallery -->
<license type="expression">Apache-2.0</license>
<!-- The location of a read-me file that's displayed in the Visual Studio Package Manager UI -->
<readme>readme.md</readme>
<!-- An icon that's used in the Visual Studio Package Manager UI -->
<icon>icon.png</icon>
<!--
A property that when true, prompts the user to accept the license when
installing the package
-->
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<!-- Detailed information about a particular release -->
<releaseNotes>Bug fixes and performance improvements</releaseNotes>
<!--
A description that can be used in the Package Manager UI. The
nuget.org gallery uses information you add in the portal.
-->
<description>Core utility functions for web applications</description>
<!-- Copyright information -->
<copyright>Copyright ©2026 Contoso Corporation</copyright>
<!-- Tags that appear in the gallery and can be used for tag searches -->
<tags>web utility http json url parsing</tags>
<!-- Dependencies that are automatically installed when the package is installed -->
<dependencies>
<dependency id="Newtonsoft.Json" version="9.0" />
</dependencies>
</metadata>
<!-- A read-me Markdown file that's displayed in the Package Manager UI -->
<files>
<file src="readme.md" target="" />
<file src="icon.png" target="" />
</files>
</package>
依存関係の宣言とバージョン番号の指定の詳細については、「 packages.config と パッケージのバージョン管理」を参照してください。
include要素のexclude属性とdependency属性を使用して、パッケージに含める、または除外する依存関係資産を指定することもできます。 詳細については、「 .nuspec Reference - Dependencies 要素」を参照してください。
マニフェストはそこから作成されたパッケージに含まれているため、既存のパッケージを調べることで例を見つけることができます。 適切なソースは、コンピューター上 のグローバル パッケージ フォルダーです。 その場所を見つけるには、次のコマンドを使用します。
nuget locals -list global-packages
グローバル パッケージ フォルダーの場所がわかったら、次の手順を実行してマニフェスト ファイルを見つけます。
- グローバル パッケージ フォルダーに移動します。
- そのフォルダーで、任意のパッケージのサブフォルダーに移動し、そのパッケージの任意のバージョンのサブフォルダーに移動します。
- バージョン サブフォルダーで 、.nupkg ファイルのコピーを作成し、コピーの拡張子を zip に変更します。
- .zip ファイルを開き、その中の .nuspec ファイルを調べます。
注
Visual Studio プロジェクトから .nuspec ファイルを作成すると、パッケージのビルド時にプロジェクトからの情報に置き換えられるトークンがマニフェストに含まれます。 詳細については、「Visual Studio プロジェクトから .nuspec ファイルを作成するを参照してください。
.nuspec ファイルを作成する
完全なマニフェストの作成は、通常、次のいずれかの方法で生成された基本的な .nuspec ファイルから始まります。
その後、ファイルを手動で編集して、最終的なパッケージに必要な内容が正確に記述されるようにします。
Important
生成された .nuspec ファイルには、 nuget pack コマンドを使用してパッケージを作成する前に変更する必要があるプレースホルダーが含まれています。
.nuspec ファイルにプレースホルダーが含まれている場合、そのコマンドは失敗します。
規則ベースの作業ディレクトリから
NuGet パッケージは .nupkg 拡張子で名前が変更された ZIP ファイルであるため、多くの場合、ローカル ファイル システムに必要なフォルダー構造を作成し、その構造から直接 .nuspec ファイルを作成するのが最も簡単です。
nuget pack コマンドは、そのフォルダー構造内のすべてのファイルを自動的に追加しますが、ピリオドで始まるフォルダーは除外されるため、プライベート ファイルは同じ構造に保持できます。
この方法の利点は、このセクションで後述するように、パッケージに含めるファイルをマニフェストで指定する必要がないようにすることです。 代わりに、パッケージに入る正確なフォルダー構造をビルド プロセスで生成させることができます。 それ以外の場合は、プロジェクトの一部ではない可能性がある他のファイルを簡単に含めることもできます。
- ターゲット プロジェクトに挿入する必要があるコンテンツとソース コード
- PowerShell スクリプト
- プロジェクト内の既存の構成ファイルとソース コード ファイルへの変換
フォルダーは、次の規則に従います。
| フォルダー | 内容 | パッケージのインストール時のアクション |
|---|---|---|
| (root) | パッケージ マニフェスト、最上位フォルダー、および必要に応じて、読み取り可能な Markdown ファイルとアイコンイメージ | このフォルダーは、 lib や build などの標準化されたサブフォルダーの開始点として使用されます。 |
| lib/<tfm> | 特定のターゲット フレームワーク モニカー (TFM) のアセンブリ (.dll)、ドキュメント (.xml)、およびシンボル (.pdb) ファイル | アセンブリは、コンパイル時とランタイムの参照として追加されます。 .xml ファイルと .pdb ファイルは、プロジェクト フォルダーにコピーされます。 フレームワークのターゲット固有のサブフォルダーの作成については、「複数の.NETバージョンのサポート」を参照してください。 |
| ref/<tfm> | 指定された TFM のアセンブリ (.dll)、およびシンボル (.pdb) ファイル | アセンブリは、コンパイル時にのみ参照として追加されます。 プロジェクト bin フォルダーには何もコピーされません。 |
| ランタイム | アーキテクチャ固有のアセンブリ (.dll)、シンボル (.pdb)、ネイティブ リソース (.pri) ファイル | アセンブリは、ランタイムの参照としてのみ追加されます。 他のファイルはプロジェクト フォルダーにコピーされます。 対応するコンパイル時アセンブリを提供するには、AnyCPU フォルダーの下に、対応する (TFM) <特定のアセンブリが常に存在する必要があります。
複数の .NET バージョンのサポートを参照してください。 |
| コンテンツ | 任意のファイル | 内容がプロジェクト ルートにコピーされます。 コンテンツ フォルダーは、最終的にパッケージを使用するターゲット アプリケーションのルートと考えてください。 パッケージにアプリケーションの /images フォルダーにイメージを追加するには、パッケージの content/images フォルダーに配置します。 |
| ビルド | (3.x+) Microsoft Build Engine (MSBuild) .targets および .props ファイル | これらのファイルは自動的にプロジェクトに挿入されます。 |
| buildMultiTargeting | (4.0 以降) クロスフレームワーク ターゲット用の MSBuild .targets ファイルと .props ファイル | これらのファイルは自動的にプロジェクトに挿入されます。 |
| buildTransitive | (5.0 以降) どの使用プロジェクトにも推移的に流れる MSBuild .targets および .props ファイル | これらのファイルは自動的にプロジェクトに挿入されます。 機能に関するページをご覧ください。 |
| ツール | Package Manager コンソールからアクセスできる PowerShell スクリプトとプログラム |
tools フォルダーは、Package Manager コンソールの PATH 環境変数にのみ追加されます。 MSBuild がプロジェクトのビルド時に使用する値には追加PATH。 |
フォルダー構造には多くのターゲット フレームワークのアセンブリを含めることができるため、このメソッドは、複数のフレームワークをサポートするパッケージを作成するときに必要です。
目的のフォルダー構造が整ったら、そのフォルダーで次のコマンドを実行して .nuspec ファイルを作成します。
nuget spec
生成された .nuspec ファイルには、フォルダー構造内のファイルへの明示的な参照が含まれていません。 NuGet には、パッケージの作成時にすべてのファイルが自動的に含まれます。 ただし、マニフェストの他の部分でプレースホルダー値を編集する必要があります。
アセンブリ DLL から
アセンブリからパッケージを作成する基本的なケースでは、次のコマンドを使用して、アセンブリ内のメタデータから .nuspec ファイルを生成できます。
nuget spec <assembly-name>.dll
このフォームを使用すると、マニフェスト内のいくつかのプレースホルダーがアセンブリの特定の値に置き換えられます。 たとえば、 <id> プロパティはアセンブリ名に設定され、 <version> はアセンブリ バージョンに設定されます。 ただし、マニフェスト内の他のプロパティには、アセンブリ内に一致する値がありません。 これらのプロパティには、コマンドを実行した後もプレースホルダーが含まれます。
Visual Studio プロジェクトから
プロジェクトにインストールされている他のパッケージは依存関係として自動的に参照されるため、.csproj または .vbproj ファイルから .nuspec ファイルを作成すると便利です。 プロジェクト ファイルからマニフェストを作成するには、プロジェクト ファイルを含むフォルダーで次のコマンドを使用します。
# Use in a folder that contains a project file, such as <project-name>.csproj or <project-name>.vbproj.
nuget spec
結果の <project-name>.nuspec ファイルには、パッケージ化時にプロジェクトの値に置き換えられるトークンが含まれます。これには、既にインストールされている他のパッケージへの参照も含まれます。
.nuspec に含めるパッケージの依存関係がある場合は、代わりに nuget pack を使用します。 次に、生成された .nupkg ファイル内から .nuspec ファイルを取得します。 たとえば、次のコマンドを使用します。
# Use in a folder that contains a project file, such as <project-name>.csproj or <project-name>.vbproj.
nuget pack myproject.csproj
トークンは、プロジェクト プロパティの両側の $ 記号で区切られます。 たとえば、この方法で生成されたマニフェストの <id> 値は、通常、次の行のようになります。
<id>$id$</id>
このトークンは、パッキング時にプロジェクト ファイルの AssemblyName 値に置き換えられます。 プロジェクト値と .nuspec ファイル トークンの正確なマッピングについては、「 置換トークン」を参照してください。
トークンを使用すると、プロジェクトを更新するときに 、.nuspec ファイルのバージョン番号などの重要な値を更新する必要が軽減されます。 ただし、トークンをリテラル値に置き換えることもできます。
Visual Studio プロジェクトから作業するときに、この記事で後述する「 Nuget パックを実行して .nupkg ファイルを生成する方法について説明するように、いくつかの追加のパッケージ化オプションを使用できます。
ソリューションレベルパッケージ
NuGet 2.x のみ。 NuGet 3.0 以降では使用できません。
NuGet 2.x では、Package Manager コンソールのツールまたは追加のコマンド (tools フォルダーの内容) をインストールするソリューション レベルのパッケージの概念がサポートされていますが、ソリューション内のプロジェクトに参照、コンテンツ、ビルドのカスタマイズは追加されません。 このようなパッケージには、直接 ライブラリ、 コンテンツ、または ビルド フォルダーにファイルが含まれていないので、それぞれの lib、 コンテンツ、または ビルド フォルダーにファイルが含まれている依存関係はありません。
NuGet は、インストールされているソリューション レベルのパッケージを、プロジェクトの packages.config ファイルではなく、 .nuget フォルダー内の packages.config ファイルで追跡します。
既定値を持つ新しいファイルから
次のコマンドは、プレースホルダーを含む既定のマニフェストを作成します。これにより、適切なファイル構造から始めるのに役立ちます。
nuget spec [<package-name>]
<package-name>を省略すると、結果のファイルの名前は Package.nuspec になります。
Contoso.Utility.UsefulStuffなどの名前を指定すると、ファイルの名前は Contoso.Utility.UsefulStuff.nuspec になります。
結果の .nuspec ファイルには、 projectUrlなどの値のプレースホルダーが含まれています。 ファイルを使用して最終的な .nupkg ファイルを作成する前に、プレースホルダーを適切な値に置き換えます。
一意のパッケージ識別子を選択し、バージョン番号を設定する
パッケージ識別子 (<id> 要素) とバージョン番号 (<version> 要素) は、パッケージに含まれている正確なコードを一意に識別するため、マニフェストの 2 つの最も重要な値です。
パッケージ識別子のベスト プラクティス
-
一意性: 識別子は、パッケージをホストするギャラリー内で一意である必要があります (nuget.org など)。識別子を決定する前に、該当するギャラリーを検索して、名前が既に使用されているかどうかを確認します。 競合を回避するには、
Contosoなど、識別子の最初の部分として会社名を使用することをお勧めします。 -
Namespace のような名前: ハイフンではなくドット表記を使用して、.NETの名前空間に似たパターンに従います。 たとえば、
Contoso.Utility.UsefulStuffやContoso-Utility-UsefulStuffではなく、Contoso_Utility_UsefulStuffを使用します。 コンシューマーは、パッケージ識別子がコードで使用される名前空間と一致する場合にも役立ちます。 -
サンプル パッケージ: 別のパッケージの使用方法を示すサンプル コードのパッケージを生成する場合は、
.Sampleのように識別子にサフィックスとしてContoso.Utility.UsefulStuff.Sampleをアタッチします。 この型のサンプル パッケージは、使用方法を示すパッケージに依存しています。 サンプル パッケージを作成するときは、前述の規則ベースの作業ディレクトリ メソッドを使用します。 コンテンツ フォルダーで、\Samples\< のように、\Samples\>identifier という名前のフォルダーにサンプル コードを配置します。
パッケージ バージョンのベスト プラクティス
- 一般に、ライブラリに合わせてパッケージのバージョンを設定します。 このガイダンスは推奨されますが、厳密には必須ではありません。 この方法は、「パッケージ化するアセンブリを決定する」で前述したように、パッケージを 1 つの アセンブリに制限する場合は簡単です。 一般に、NuGet 自体は、アセンブリ バージョンではなく依存関係を解決するときにパッケージ バージョンを処理することに注意してください。
- 標準以外のバージョンスキームを使用する場合は、「パッケージのバージョン管理」で説明されているように、NuGet のバージョン管理規則 を検討してください。
バージョン管理を理解するのに役立つその他のリソースについては、次の一連の簡単なブログ記事を参照してください。
read-me ファイルとその他のファイルを追加する
パッケージに含めるファイルを直接指定するには、<files> ファイル内の ノードを使用します。このノードは、 タグに<metadata>。
<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
<metadata>
<!-- ... -->
</metadata>
<files>
<!-- Add files from an arbitrary folder that's not necessarily in the project. -->
<file src="..\..\SomeRoot\**\*.*" target="" />
</files>
</package>
ヒント
規則ベースの作業ディレクトリアプローチを使用する場合は、 readme.md ファイルをパッケージ ルートに配置し、その他の コンテンツをコンテンツ フォルダーに配置できます。 マニフェストには <file> 要素は必要ありません。
パッケージに read-me ファイルを含めるには、 readme メタデータ要素を使用して、読み取り/me ファイルへのターゲット パスを指定します。 また、 file メタデータ要素を使用して、read-me ファイルのソース パスとターゲット フォルダーを指定します。 詳細については、readmeを参照してください。
<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
<metadata>
<!-- ... -->
<readme>docs\readme.md</readme>
<!-- ... -->
</metadata>
<files>
<!-- Add a read-me file. -->
<file src="..\readme.md" target="docs\" />
</files>
</package>
Visual Studioは、Package Manager UI に read-me ファイルの内容を表示します。 たとえば、次のスクリーンショットは、 HtmlAgilityPack パッケージの read-me ファイルを示しています。
注
<files> ファイルに空の ノードを含める場合、NuGet にはパッケージ内の lib フォルダーの内容が含まれますが、他のコンテンツは含まれていません。
MSBuild のプロパティとターゲットをパッケージに含める
場合によっては、ビルド中にカスタム ツールやプロセスを実行するなど、パッケージを使用するプロジェクトにカスタム ビルド ターゲットまたはプロパティを追加することが必要になる場合があります。 カスタム ビルド ターゲットとカスタム プロパティの詳細については、 パッケージ内の MSBuild .props と .targets を参照してください。
プロジェクトの< フォルダー> ファイル (< など) を作成します。
次に 、.nuspec ファイルで、 <files> ノード内の次のファイルを参照します。
<?xml version="1.0"?>
<package >
<metadata minClientVersion="2.5">
<!-- ... -->
</metadata>
<files>
<!-- In the package build folder, include everything that's in the local build folder. -->
<file src="build\**" target="build" />
<!-- Other files -->
<!-- ... -->
</files>
</package>
パッケージがプロジェクトに追加されると、NuGet にはこれらのプロパティとターゲットが自動的に含まれます。
nuget パックを実行して .nupkg ファイルを生成する
アセンブリまたは規則ベースの作業ディレクトリを使用する場合は、nuget pack ファイルでを実行してパッケージを作成します。 次のコマンドで、 <project-name> をプロジェクトの名前に置き換えます。
nuget pack <project-name>.nuspec
Visual Studio プロジェクトを使用する場合は、プロジェクト ファイルで nuget pack を実行します。 このコマンドは、プロジェクトの .nuspec ファイルを自動的に読み込み、その中のトークンをプロジェクト ファイル内の対応する値に置き換えます。
nuget pack <project-name>.csproj
注
トークンの置換では、プロジェクトがトークン値のソースであるため、プロジェクト ファイルを直接使用する必要があります。
nuget pack ファイルでを使用した場合、トークンの置換は成功しません。
いずれの場合も、 nuget pack はピリオドで始まるフォルダー ( .git や .hg など) を除外します。
NuGet は、更新が必要なマニフェストのプレースホルダー値など、修正が必要なエラーが .nuspec ファイルに存在するかどうかを示します。
nuget pack成功すると、「NuGet パッケージの発行」の説明に従って、適切なギャラリーに発行できる .nupkg ファイルが作成されます。
ヒント
作成後にパッケージを調べるのに役立つ方法は、 パッケージ エクスプローラー ツールでパッケージを開く方法です。 このツールを使用すると、パッケージの内容とそのマニフェストをグラフィカルに表示できます。 また、結果の .nupkg ファイルの名前を .zip ファイルに変更し、その内容を直接調べることもできます。
追加オプション
さまざまなコマンド ライン スイッチと nuget pack を使用して、ファイルを除外したり、マニフェストのバージョン番号をオーバーライドしたり、出力フォルダーを変更したりできます。 完全な一覧については、 pack コマンド (NuGet CLI) を参照してください。
次のオプションは、Visual Studio プロジェクトで一般的なオプションです。
参照先プロジェクト: プロジェクトが他のプロジェクトを参照している場合は、
-IncludeReferencedProjectsオプションを使用して、参照先のプロジェクトをパッケージの一部として、または依存関係として追加できます。nuget pack MyProject.csproj -IncludeReferencedProjectsこの包含プロセスは再帰的です。 たとえば、 MyProject.csproj が プロジェクト B と C を参照し、それらのプロジェクトが D、E、F を参照している場合、B、C、D、E、F のファイルがパッケージに含まれます。
参照先プロジェクトに独自の .nuspec ファイルが含まれている場合、NuGet はその参照先プロジェクトを依存関係として追加します。 そのプロジェクトを個別にパッケージ化して発行する必要があります。
ビルド構成: 既定では、NuGet はプロジェクト ファイルに設定されている既定のビルド構成 (通常は
Debug) を使用します。Releaseなど、別のビルド構成のファイルをパックするには、-propertiesオプションを構成と共に使用します。nuget pack MyProject.csproj -properties Configuration=Releaseシンボル: コンシューマーがデバッガーでパッケージ コードをステップ実行できるようにするシンボルを含めるには、
-Symbolsオプションと-SymbolPackageFormatオプションを使用します。-SymbolPackageFormatオプションには、snupkgの形式を指定します。nuget pack MyProject.csproj -symbols -SymbolPackageFormat snupkg
パッケージのインストールをテストする
パッケージを発行する前に、通常、パッケージをプロジェクトにインストールするプロセスをテストする必要があります。 テストにより、必要なすべてのファイルがプロジェクト内の正しい場所に配置されるようになります。
標準の package インストール手順を使用して、Visual Studioまたはコマンド ラインでインストールを手動でテストできます。
自動テストでは、次の基本的なプロセスを使用できます。
- .nupkg ファイルをローカル フォルダーにコピーします。
-
nuget sources add -name <name> -source <path>コマンドを使用して、パッケージ ソースにフォルダーを追加します。 詳細については、 sources コマンド (NuGet CLI) を参照してください。 このローカル ソースは、特定のコンピューターで 1 回だけ設定する必要があります。 -
nuget install <package-ID> -source <name>を使用して、そのソースからパッケージをインストールします。 このコマンドでは、<name>は、nuget sourcesコマンドで使用するソースの名前と一致する必要があります。 ソースを指定すると、そのソースからパッケージをインストールするように NuGet に指示されます。 - ファイル システムを調べて、ファイルが正しくインストールされていることを確認します。
関連するコンテンツ
.nupkg ファイルであるパッケージを作成したら、任意のギャラリーに発行できます。 詳細については、「 NuGet パッケージの発行」を参照してください。
パッケージの機能を拡張したり、他のシナリオをサポートしたりすることもできます。 詳細については、次の記事を参照してください。
- パッケージのバージョン管理
- 複数の.NETバージョンをサポート
- ソース コードと構成ファイルの変換
- ローカライズされた NuGet パッケージの作成
- プレリリース パッケージのビルド
- NuGet パッケージの種類を設定する
- COM 相互運用機能アセンブリを含む NuGet パッケージを作成する
注意すべきその他のパッケージの種類については、次の記事を参照してください。