NuGet の概要An introduction to NuGet

最新の開発プラットフォームに欠かせないツールは、開発者が役に立つコードを作成、共有、および使用するために利用できるメカニズムです。An essential tool for any modern development platform is a mechanism through which developers can create, share, and consume useful code. 多くの場合、このようなコードは "パッケージ" にバンドルされています。このパッケージにはコンパイルされたコード (DLL) に加えて、このパッケージが使用されるプロジェクトで必要なその他のコンテンツが含まれています。Often such code is bundled into "packages" that contain compiled code (as DLLs) along with other content needed in the projects that consume these packages.

Microsoft がサポートする.NET (.NET Core を含む) のコード共有メカニズムである NuGet では、.NET 用のパッケージを作成、ホスト、および使用する方法が定義されており、それらの各ロール用のツールが提供されています。For .NET (including .NET Core), the Microsoft-supported mechanism for sharing code is NuGet, which defines how packages for .NET are created, hosted, and consumed, and provides the tools for each of those roles.

つまり、NuGet パッケージは、拡張子が .nupkg の 1 つの ZIP ファイルであり、コンパイル済みのコード (DLL)、そのコードに関連する他のファイル、パッケージのバージョン番号などの情報が記述されているマニフェストが含まれます。Put simply, a NuGet package is a single ZIP file with the .nupkg extension that contains compiled code (DLLs), other files related to that code, and a descriptive manifest that includes information like the package's version number. 開発者はコードを共有して、パッケージを作成し、それをパブリック ホストまたはプライベート ホストに公開します。Developers with code to share create packages and publish them to a public or private host. パッケージ利用者は、これらのパッケージを適切なホストから取得して、プロジェクトに追加した後、プロジェクトのコードでパッケージの機能を呼び出します。Package consumers obtain those packages from suitable hosts, add them to their projects, and then call a package's functionality in their project code. その過程での細部はすべて NuGet 自体が処理します。NuGet itself then handles all of the intermediate details.

NuGet では、パブリック ホストの nuget.org に加えてプライベート ホストもサポートされるので、NuGet パッケージを使用して、組織またはワーク グループ専用のコードを共有できます。Because NuGet supports private hosts alongside the public nuget.org host, you can use NuGet packages to share code that's exclusive to an organization or a work group. また、自身のプロジェクト以外では使用されない専用のコードを格納するための便利な方法として、NuGet パッケージを使用することもできます。You can also use NuGet packages as a convenient way to factor your own code for use in nothing but your own projects. 要するに、NuGet パッケージは共有可能なコード単位ですが、特定の共有手段を必要とすることも、暗黙に指定することもありません。In short, a NuGet package is a shareable unit of code, but does not require nor imply any particular means of sharing.

作成者、ホスト、利用者の間のパッケージのフローThe flow of packages between creators, hosts, and consumers

パブリック ホストとしての役割の NuGet は、100,000 以上の個別パッケージの中央リポジトリを nuget.org で保持します。これらのパッケージを、毎日数百万人の .NET/.NET Core 開発者が使用しています。In its role as a public host, NuGet itself maintains the central repository of over 100,000 unique packages at nuget.org. These packages are employed by millions of .NET/.NET Core developers every day. また、NuGet を使うと、クラウド (Azure DevOps 上など)、プライベート ネットワーク、さらにはローカル ファイル システムで、プライベートにパッケージをホストすることもできます。NuGet also enables you to host packages privately in the cloud (such as on Azure DevOps), on a private network, or even on just your local file system. こうすることにより、これらのパッケージは、ホストにアクセスできる開発者のみが使用できるようになるので、パッケージを特定の利用者グループに対して利用可能にすることができます。By doing so, those packages are available to only those developers that have access to the host, giving you the ability to make packages available to a specific group of consumers. オプションの説明については、「Hosting your own NuGet feeds」(独自の NuGet フィードのホスト) をご覧ください。The options are explained on Hosting your own NuGet feeds. さらに、構成オプションを使用して、指定されたコンピューターがアクセス可能なホストを厳密に制御して、パッケージが、nuget.org などのパブリック リポジトリではなく特定のソースから取得されるようにすることができます。Through configuration options, you can also control exactly which hosts can be accessed by any given computer, thereby ensuring that packages are obtained from specific sources rather than a public repository like nuget.org.

ホストは、それがどのような性質であっても、パッケージ作成者とパッケージ利用者 の間の接続ポイントとして機能します。Whatever its nature, a host serves as the point of connection between package creators and package consumers. 作成者は、便利な NuGet パッケージを作成して、ホストに公開します。Creators build useful NuGet packages and publish them to a host. 利用者は、アクセスできるホストで役に立ち互換性のあるパッケージを検索し、ダウンロードしてプロジェクトに組み込みます。Consumers then search for useful and compatible packages on accessible hosts, downloading and including those packages in their projects. プロジェクトにインストールされたパッケージの API は、プロジェクト コードの他の部分から利用できます。Once installed in a project, the packages' APIs are available to the rest of the project code.

パッケージ作成者、パッケージ ホスト、パッケージ利用者の間の関係

互換性を目的とするパッケージPackage targeting compatibility

"互換性のある" パッケージとは、パッケージを利用するプロジェクトのターゲット フレームワークと互換性のある少なくとも 1 つの .NET Framework 用にビルドされたアセンブリが含まれていることを意味します。A "compatible" package means that it contains assemblies built for at least one target .NET framework that's compatible with the consuming project's target framework. 開発者は、UWP コントロールと同様、1 つのフレームワークに固有のパッケージを作成することも、広範囲のターゲットをサポートすることもできます。Developers can create packages that are specific to one framework, as with UWP controls, or they can support a wider range of targets. パッケージの互換性を最大化するには、開発者は、すべての .NET および .NET Core プロジェクトで利用可能な .NET Standard をターゲットにします。To maximize a package's compatibility, developers target .NET Standard, which all .NET and .NET Core projects can consume. この場合、単一のパッケージ (通常、単一のアセンブリを含む) が、パッケージを利用するすべてのプロジェクトに対して機能するので、作成者と利用者の両方にとって最も効率的な手段です。This is the most efficient means for both creators and consumers, as a single package (usually containing a single assembly) works for all consuming projects.

一方、.NET Standard 以外の API を必要とするパッケージ開発者は、サポートするさまざまなターゲット フレームワーク用に個別のアセンブリを作成し、これらのすべてのアセンブリを同じパッケージに含めます (これは、「マルチターゲット」と呼ばれています)。Package developers who require APIs outside of .NET Standard, on the other hand, create separate assemblies for the different target frameworks they want to support and include all of those assemblies in the same package (which is called "multi-targeting"). 利用者がこのようなパッケージをインストールすると、NuGet では、プロジェクトで必要されるアセンブリのみが抽出されます。When a consumer installs such a package, NuGet extracts only those assemblies that are needed by the project. これにより、最終的なアプリケーションやそのプロジェクトによって生成されるアセンブリでのパッケージのフットプリントが最小になります。This minimizes the package's footprint in the final application and/or assemblies produced by that project. 当然、作成者にとっては、マルチターゲット パッケージを保守する方が困難です。A multi-targeting package is, of course, more difficult for its creator to maintain.

注意

.NET Standard をターゲットにする方法は、さまざまなポータブル クラス ライブラリ (PCL) ターゲットを使用する以前の方法よりも優先されます。Targeting .NET Standard supercedes the previous approach of using various portable class library (PCL) targets. このため、このドキュメントでは、.NET Standard 用のパッケージの作成に重点を置いて説明します。This documentation therefore focuses on creating packages for .NET Standard.

NuGet のツールNuGet tools

ホストのサポートに加えて、NuGet では作成者と利用者の両方が使用できるさまざまなツールも提供されています。In addition to hosting support, NuGet also provides a variety of tools used by both creators and consumers. 特定のツールの取得方法については、「NuGet クライアント ツールのインストール」を参照してください。See Installing NuGet client tools for how to obtain specific tools.

ツールTool プラットフォームPlatforms 該当シナリオApplicable Scenarios 説明Description
nuget.exe CLInuget.exe CLI すべてAll 作成、利用Creation, Consumption NuGet のすべての機能を提供します。パッケージ作成者のみに適用されるコマンド、利用者のみに適用されるもの、両方に適用されるものがあります。Provides all NuGet capabilities, with some commands applying specifically to package creators, some applying only to consumers, and others applying to both. たとえば、パッケージ作成者は nuget pack コマンドを使用して、さまざまなアセンブリと関連ファイルからパッケージを作成し、パッケージ利用者は nuget install を使用して、パッケージをプロジェクトフォルダーに格納します。また、nuget config は、NuGet の構成変数を設定するためにすべてのユーザーによって使用されます。For example, package creators use the nuget pack command to create a package from various assemblies and related files, package consumers use nuget install to include packages in a project folder, and everyone uses nuget config to set NuGet configuration variables. プラットフォームに依存しないツールである NuGet CLI は、Visual Studio プロジェクトと対話しません。As a platform-agnostic tool, the NuGet CLI does not interact with Visual Studio projects.
dotnet CLIdotnet CLI すべてAll 作成、利用Creation, Consumption 特定の NuGet CLI 機能を、.NET Core ツール チェーン内に直接提供します。Provides certain NuGet CLI capabilities directly within the .NET Core tool chain. NuGet CLI と同様、dotnet CLI も Visual Studio プロジェクトと対話しません。As with the NuGet CLI, the dotnet CLI does not interact with Visual Studio projects.
パッケージ マネージャー コンソールPackage Manager Console Windows の Visual StudioVisual Studio on Windows 利用Consumption Visual Studio プロジェクトでパッケージをインストールして管理するための PowerShell コマンドを提供します。Provides PowerShell commands for installing and managing packages in Visual Studio projects.
パッケージ マネージャー UIPackage Manager UI Windows の Visual StudioVisual Studio on Windows 利用Consumption Visual Studio プロジェクトでパッケージをインストールして管理するための使いやすい UI を提供します。Provides an easy-to-use UI for installing and managing packages in Visual Studio projects.
NuGet 管理 UIManage NuGet UI Visual Studio for MacVisual Studio for Mac 利用Consumption Visual Studio for Mac プロジェクトでパッケージをインストールして管理するための使いやすい UI を提供します。Provide an easy-to-use UI for installing and managing packages in Visual Studio for Mac projects.
MSBuildMSBuild WindowsWindows 作成、利用Creation, Consumption パッケージを作成する機能と、プロジェクトで使用されているパッケージを、MSBuild ツール チェーンを介して直接復元する機能を提供します。Provides the ability to create packages and restore packages used in a project directly through the MSBuild tool chain.

このように、どの NuGet ツールを使用するかは、パッケージの作成、利用、公開のいずれを行うか、およびどのプラットフォームで作業しているかによって大きく異なります。As you can see, the NuGet tools you work with depend greatly on whether you're creating, consuming, or publishing packages, and the platform on which you're working. パッケージ作成者は、通常、他の NuGet パッケージの機能を基にして開発を行うので、利用者でもあります。Package creators are typically also consumers, as they build on top of functionality that exists in other NuGet packages. そして、これらのパッケージは、もちろん、他のパッケージにさらに依存している場合があります。And those packages, of course, may in turn depend on still others.

詳細については、「パッケージ作成ワークフロー」 および パッケージ利用のワークフロー」の記事を最初にお読みください。For more information, start with the Package creation workflow and Package consumption workflow articles.

依存関係の管理Managing dependencies

他の開発者の作業を簡単に利用できることは、パッケージ管理システムの最も強力な機能の 1 つです。The ability to easily build on the work of others is one of most powerful features of a package management system. したがって、NuGet の機能の多くは、プロジェクトに代わって、その依存関係ツリーつまり "グラフ" を管理することです。Accordingly, much of what NuGet does is managing that dependency tree or "graph" on behalf of a project. 簡単に言えば、開発者が関心を持つ必要があるのは、プロジェクト内で直接使っているパッケージだけです。Simply said, you need only concern yourself with those packages that you're directly using in a project. そのようなパッケージ自体のいずれかで他のパッケージ (それがさらに他のパッケージを利用している場合があります) が利用されている場合、下位の依存関係はすべて NuGet で処理されます。If any of those packages themselves consume other packages (which can, in turn, consume still others), NuGet takes care of all those down-level dependencies.

次の図で示すプロジェクトは、5 つのパッケージに依存しており、それらがさらに他の複数のパッケージに依存しています。The following image shows a project that depends on five packages, which in turn depend on a number of others.

.NET プロジェクトの NuGet 依存関係グラフの例

依存関係グラフの複数の箇所に出現しているパッケージがあることに注意してください。Notice that some packages appear multiple times in the dependency graph. たとえば、パッケージ B には 3 つの異なるコンシューマーがあり、各コンシューマーがそのパッケージの異なるバージョンを指定している可能性もあります (図には示されていません)。For example, there are three different consumers of package B, and each consumer might also specify a different version for that package (not shown). 特に広く使用されているパッケージの場合、これはよくあることです。This is a common occurrence, especially for widely-used packages. さいわいなことに、すべての利用者の要求を満たすパッケージ B のバージョンを正確に特定する困難な作業はすべて、NuGet によって実行されます。NuGet fortunately does all the hard work to determine exactly which version of package B satisfies all consumers. その後、NuGet は、依存関係グラフの深さに関係なく、他のすべてのパッケージについても同じように処理します。NuGet then does the same for all other packages, no matter how deep the dependency graph.

NuGet がこのサービスを実行する方法について詳しくは、依存関係の解決に関するページをご覧ください。For more details on how NuGet performs this service, see Dependency resolution.

参照の追跡とパッケージの復元Tracking references and restoring packages

プロジェクトは開発者のコンピューター、ソース管理リポジトリ、ビルド サーバーなどの間を簡単に移動するので、プロジェクトに直接バインドされた NuGet パッケージからバイナリ アセンブリを維持するのは極めて困難です。Because projects can easily move between developer computers, source control repositories, build servers, and so forth, it's highly impractical to keep the binary assemblies of NuGet packages directly bound to a project. プロジェクトの各コピーが必要以上に肥大化する (それにより、ソース管理リポジトリ内の領域を浪費する) だけでなく、Doing so would make each copy of the project unnecessarily bloated (and thereby waste space in source control repositories). パッケージのバイナリを新しいバージョンに更新する処理も、プロジェクトのすべてのコピーについて行う必要があるため、非常に困難になります。It would also make it very difficult to update package binaries to newer versions as updates would have to be applied across all copies of the project.

代わりに、NuGet は、最上位と下位の依存関係を含めて、プロジェクトが依存する、単純なパッケージの参照リストを保持します。NuGet instead maintains a simple reference list of the packages upon which a project depends, including both top-level and down-level dependencies. つまり、どこかのホストからプロジェクトにパッケージをインストールすると常に、NuGet によってパッケージの識別子とバージョン番号がこの参照リストに記録されます That is, whenever you install a package from some host into a project, NuGet records the package identifier and version number in the reference list. (もちろん、パッケージをアンインストールするとリストから削除されます)。その後、「パッケージの復元」で説明しているように、NuGet は、参照されているすべてのパッケージを復元する手段を提供します。(Uninstalling a package, of course, removes it from the list.) NuGet then provides a means to restore all referenced packages upon request, as described on Package restore.

NuGet の参照リストはパッケージのインストール時に作成され、別の場所にパッケージを復元するために使うことができる

それ以降いつでも、NuGet は、参照リストのみを使って、パブリック ホストやプライベート ホストからすべてのパッケージを再インストール、—つまり復元—できます。With only the reference list, NuGet can then reinstall—that is, restore—all of those packages from public and/or private hosts at any later time. ソース管理にプロジェクトをコミットするとき、またはプロジェクトを他のなんらかの方法で共有する場合は、参照リストを含めるだけで済み、パッケージのバイナリを含める必要はありません (「パッケージとソース管理」を参照してください)。When committing a project to source control, or sharing it in some other way, you include only the reference list and exclude any package binaries (see Packages and source control.)

自動展開システムの一部としてプロジェクトのコピーを取得するビルド サーバーのような、プロジェクトを受け取るコンピューターは、必要なときに依存関係を復元するよう NuGet に要求するだけです。The computer that receives a project, such as a build server obtaining a copy of the project as part of an automated deployment system, simply asks NuGet to restore dependencies whenever they're needed. Azure DevOps などのビルド システムでは、この目的のための "NuGet 復元" ステップが提供されています。Build systems like Azure DevOps provide "NuGet restore" steps for this exact purpose. 同様に、開発者は、プロジェクトのコピーを取得する場合 (リポジトリを複製するときと同じように)、nuget restore (NuGet CLI)、dotnet restore (dotnet CLI)、または Install-Package (パッケージ マネージャー コンソール) などのコマンドを呼び出して、すべての必要なパッケージを取得できます。Similarly, when developers obtain a copy of a project (as when cloning a repository), they can invoke command like nuget restore (NuGet CLI), dotnet restore (dotnet CLI), or Install-Package (Package Manager Console) to obtain all the necessary packages. この部分については、Visual Studio では、プロジェクトを構築するときに自動的にパッケージを復元します (「ただし、「パッケージの復元」で説明されているように、自動復元が有効になっていることが条件です)。Visual Studio, for its part, automatically restores packages when building a project (provided that automatic restore is enabled, as described on Package restore).

その場合に開発者が関係する NuGet の主要な役割は明らかに、プロジェクトに代わってその参照リストを維持し、参照されているパッケージを効率的に復元 (および更新) する手段を提供することです。Clearly, then, NuGet's primary role where developers are concerned is maintaining that reference list on behalf of your project and providing the means to efficiently restore (and update) those referenced packages. このリストは、次の 2 つのパッケージ管理形式のいずれかで保持されます。This list is maintained in one of two package management formats, as they're called:

  • packages.config: (NuGet 1.0 以降) プロジェクト内のすべての依存関係のフラット リストを保持する XML ファイルです。インストールされている他のパッケージの依存関係も含みます。packages.config: (NuGet 1.0+) An XML file that maintains a flat list of all dependencies in the project, including the dependencies of other installed packages. インストールまたは復元されたパッケージは、packages フォルダーに保管されます。Installed or restored packages are stored in a packages folder.

  • PackageReference (または "プロジェクト ファイルでのパッケージ参照") | (NuGet 4.0 以降) プロジェクトの最上位の依存関係のリストがプロジェクト ファイル内に直接保持されるので、個別のファイルは必要ありません。PackageReference (or "package references in project files") | (NuGet 4.0+) Maintains a list of a project's top-level dependencies directly within the project file, so no separate file is needed. 関連するファイル obj/project.assets.json は、プロジェクトがすべての下位レベルの依存関係と共に使用するパッケージの依存関係の全体グラフを管理するために、動的に作成されます。An associated file, obj/project.assets.json, is dynamically generated to manage the overall dependency graph of the packages that a project uses along with all down-level dependencies. PackageReference は常に、.NET Core プロジェクトで使用されます。PackageReference is always used by .NET Core projects.

指定されたプロジェクトでどのパッケージ管理形式が採用されるかは、プロジェクトの種類と、NuGet (および Visual Studio) の使用可能なバージョンによって異なります。Which package management format is employed in any given project depends on the project type, and the available version of NuGet (and/or Visual Studio). 使用されている形式を確認するには、最初のパッケージをインストールした後で、プロジェクトのルートにある packages.config を調べるだけで済みます。To check what format is being used, simply look for packages.config in the project root after installing your first package. そのファイルが見つからない場合は、プロジェクト ファイルで直接 <PackageReference> 要素を調べます。If you don't have that file, look in the project file directly for a <PackageReference> element.

いくつかの選択肢がある場合は、PackageReference を使用することをお勧めします。When you have a choice, we recommend using PackageReference. packages.config はレガシを目的として保持され、アクティブな開発からは除外されます。packages.config is maintained for legacy purposes and is no longer under active development.

ヒント

nuget install などのさまざまな nuget.exe CLI コマンドが、パッケージを参照リストに自動追加することはありません。Various nuget.exe CLI commands, like nuget install, do not automatically add the package to the reference list. リストは、Visual Studio パッケージ マネージャー (UI またはコンソール) でパッケージをインストールしたとき、また、dotnet.exe CLI によって、更新されます。The list is updated when installing a package with the Visual Studio Package Manager (UI or Console), and with dotnet.exe CLI.

NuGet の他の機能What else does NuGet do?

これまで、NuGet の次の特性について説明しました。So far you've learned the following characteristics of NuGet:

  • NuGet は、中央リポジトリ nuget.org を提供し、プライベート ホスティングをサポートします。NuGet provides the central nuget.org repository with support for private hosting.
  • NuGet は、開発者がパッケージの作成、公開、使用に必要なツールを提供します。NuGet provides the tools developers need for creating, publishing, and consuming packages.
  • 最も重要な特性として、NuGet は、プロジェクトで使用されるパッケージの参照リストを保持し、そのリストからパッケージを復元および更新できます。Most importantly, NuGet maintains a reference list of packages used in a project and the ability to restore and update those packages from that list.

これらの処理を効率的に実行するため、NuGet はバックグラウンドでいくつかの最適化を行います。To make these processes work efficiently, NuGet does some behind-the-scenes optimizations. 注目すべき点は、NuGet ではパッケージ キャッシュとグローバル パッケージ フォルダーを管理して、インストールおよび再インストールを省略することです。Most notably, NuGet manages a package cache and a global packages folder to shortcut installation and reinstallation. キャッシュは、コンピューターに既にインストールされているパッケージのダウンロードを回避します。The cache avoids downloading a package that's already been installed on the machine. グローバル パッケージ フォルダーは、インストールされている同じパッケージを複数のプロジェクトで共有できるようにし、それによりコンピューター上の NuGet のフット プリント全体を減らします。The global packages folder allows multiple projects to share the same installed package, thereby reducing NuGet's overall footprint on the computer. また、キャッシュおよびグローバル パッケージ フォルダーは、ビルド サーバーなどのように多数のパッケージを頻繁に復元する場合は非常に役立ちます。The cache and global packages folder are also very helpful when you're frequently restoring a larger number of packages, as on a build server. これらのメカニズムの詳細については、「Managing the global packages and cache folders」 (グローバル パッケージおよびキャッシュ フォルダーを管理する) をご覧ください。For more details on these mechanisms, see Managing the global packages and cache folders.

個々のプロジェクトでは、NuGet は依存関係グラフ全体を管理します。これにも、同じパッケージの異なるバージョンへの複数の参照の解決が含まれます。Within an individual project, NuGet manages the overall dependency graph, which again includes resolving multiple references to different versions of the same package. プロジェクトが 1 つ以上のパッケージに依存関係を持ち、それらのパッケージ自体にも同じような依存関係があることは、ごく一般的なことです。It's quite common that a project takes a dependency on one or more packages that themselves have the same dependencies. nuget.org の最も便利なユーティリティ パッケージのいくつかは、他の多くのパッケージで使用されています。Some of the most useful utility packages on nuget.org are employed by many other packages. 依存関係グラフ全体では、同じパッケージの異なるバージョンに対する 10 個の異なる参照が簡単にできてしまいます。In the entire dependency graph, then, you could easily have ten different references to different versions of the same package. そのパッケージの複数のバージョンがアプリケーション自体に組み込まれるのを回避するために、NuGet は、すべての利用者が使用できる 1 つのバージョンを選別します To avoid bringing multiple versions of that package into the application itself, NuGet sorts out which single version can be used by all consumers. (詳細については、「依存関係の解決」を参照してください)。(For more information, see Dependency Resolution.)

さらに、NuGet は、パッケージの構成方法 (ローカライズデバッグ シンボルを含みます) およびパッケージの参照方法 (バージョン参照プレリリース バージョンを含みます) に関するすべての仕様を保持しています。NuGet は、そのサービスとプログラムで連携する各種の API を提供し、Visual Studio 拡張機能およびプロジェクト テンプレートを作成する開発者用のサポートも提供します。Beyond that, NuGet maintains all the specifications related to how packages are structured (including localization and debug symbols) and how they are referenced (including version ranges and pre-release versions.) NuGet also provides various APIs to work with its services programmatically, and provides support for developers who write Visual Studio extensions and project templates.

このドキュメントの目次を見るとわかるように、これらすべての機能に関するトピックと、最初の NuGet からのすべてのリリース ノートが提供されています。Take a moment to browse the table of contents for this documentation, and you see all of these capabilities represented there, along with release notes dating back to NuGet's beginnings.

コメント、投稿、問題Comments, contributions, and issues

最後に、このドキュメントに関するコメントや投稿をお寄せください。—各ページの上部にある [ご意見ご感想] および [編集] コマンドを選択するか、GitHub のドキュメント リポジトリおよびドキュメント問題リストにアクセスしてください。Finally, we very much welcome comments and contributions to this documentation—just select the Feedback and Edit commands on the top of any page, or visit the docs repository and docs issue list on GitHub.

また、さまざまな GitHub リポジトリから NuGet 自体への投稿も歓迎します。NuGet の問題については、https://github.com/NuGet/home/issues をご覧ください。We also welcome contributions to NuGet itself through its various GitHub repositories; NuGet issues can be found on https://github.com/NuGet/home/issues.

NuGet のエクスペリエンスをお楽しみください。Enjoy your NuGet experience!