.NET プロジェクトにパッケージを追加する

完了

.NET には、ファイルや HTTP の管理からファイルの圧縮まで、あらゆる処理に関するコア ライブラリが多数用意されています。 サードパーティによるライブラリの非常に大きなエコシステムもあります。 NuGet (.NET パッケージ マネージャー) を使用すれば、これらのライブラリをインストールし、お使いのアプリケーションで使用することができます。

.NET とそのエコシステムでは、"依存関係" という言葉がよく使用されます。 パッケージの依存関係とは、サードパーティのライブラリです。 これは、何らかの処理を実行する再利用可能なコードの一部であり、アプリケーションに追加できます。 サードパーティのライブラリは、アプリケーションが機能するために "依存する" ものであるため、"依存関係" と呼ばれます。

サード パーティのライブラリはリポジトリに格納されるパッケージと考えることができます。 パッケージは 1 つまたは複数のライブラリで構成されており、アプリケーションに追加することで、その機能を利用できます。

ここでは、パッケージの依存関係に焦点を当てます。 ただし、.NET プロジェクトには、パッケージの依存関係に加えて、他の種類の依存関係を持つことができます。 これには、フレームワーク、アナライザー、プロジェクト参照、共有プロジェクトの依存関係などが含まれます。

パッケージが必要かどうかを決定する

プロジェクトにパッケージが必要かどうかを確認するにはどうすればよいでしょうか? これは、次のいくつかの要因を含む複雑な質問です。

  • より良いコードを記述する: たとえば、自分はセキュリティのようなタスクを扱っていて、認証と認可を実装しようとしているのかどうかを考えます。 これは、自分のデータと顧客のデータを保護するために "適切に行う" 必要があるタスクです。 標準的なパターンとライブラリがあり、多くの開発者が使用しています。 これらのライブラリには、おそらく常に必要な機能が実装されており、問題が発生するとパッチが適用されます。 独自に作成するのではなく、そのようなライブラリを使用する必要があります。 考慮する必要があるエッジ ケースが多くあるため、コードの記述まで自分でやることはほとんどありません。
  • 時間を節約する: おそらくユーティリティや UI コンポーネント ライブラリのようなものはほとんど自分で作成できるでしょうが、時間がかかります。 使用可能なものと結果は既製のものと同じであっても、時間を使って作業をレプリケートすることは時間の浪費です。
  • メンテナンス: すべてのライブラリやアプリは、遅かれ早かれメンテナンスが必要になります。 メンテナンスには、新機能の追加とバグの修正が含まれます。 ライブラリのメンテナンスを自分や自分のチームで行うのは時間のよい使い方でしょうか、それともオープンソース ソフトウェア チームに処理を任せる方がよいでしょうか。

パッケージを評価する

ライブラリをインストールする前に、それが依存する依存関係を調べることが必要な場合があります。 これらの依存関係のために、パッケージの使用が適切になる場合もあれば、不適切になる場合もあります。 プロジェクトの依存関係を選択するときは、次のような要素について考慮する必要があります。

  • サイズ: 依存関係の数が多いと、占有領域が大きくなる可能性があります。 帯域幅が限られている場合や、その他のハードウェア制限がある場合は、この要素が問題になる可能性があります。
  • ライセンス: このライブラリに付与されたライセンスが、商用、個人用、あるいは教育機関用であるかにかかわらず、確実に目的の用途に対応するようにする必要があります。
  • アクティブなメンテナンス:パッケージが、アクティブにメンテナンスされていない依存関係に依存している場合、問題になるかもしれません。 依存関係は非推奨になる、または長時間更新される可能性があります。

インストールの前に、パッケージの詳細について https://www.nuget.org/packages/<package name> を参照してください。 この URL では、そのパッケージの詳細ページが表示されます。 [依存関係] ドロップダウン リストを選択して、それが機能するために依存しているパッケージを確認します。

リストされている依存関係の数は真実を完全に示しているとは限らない場合があります。 パッケージをダウンロードすると、パッケージの依存関係に多数のパッケージが含まれるようになる可能性があります。 なぜでしょうか。 すべてのパッケージには依存関係のリストがあます。 パッケージを確実に使用できるようにするために、dotnet add package <package name> コマンドを実行すると、すべての依存関係がクロールされてダウンロードされます。

パッケージをインストールする

パッケージをインストールするには、いくつかの方法があります。 Visual Studio と Visual Studio for Mac には、パッケージ マネージャー用の組み込みのコマンド ラインおよびグラフィカル ユーザー インターフェイスが用意されています。 プロジェクト ファイルにパッケージ参照を手動で追加することや、Paket や .NET Core CLI などのコマンド ライン インターフェイス (CLI) ツールを使用してインストールすることができます。

このモジュールでは、組み込みの .NET Core CLI を使用してパッケージをインストールします。 ターミナルでコマンドを呼び出すことにより、.NET プロジェクトにパッケージを追加できます。 一般的なインストール コマンドは、dotnet add package <name of package> のようになります。 add package コマンドを実行すると、コマンドライン ツールによってグローバル レジストリに接続され、パッケージがフェッチされ、すべてのプロジェクトで使用できるキャッシュされたフォルダーの場所に格納されます。

プロジェクトをインストールしてビルドすると、デバッグまたはリリース フォルダーに参照が追加されます。 プロジェクト ディレクトリは次のようになります。

-| bin/
---| Debug/
------| net3.1
--------| <files included in the dependency>

パッケージを見つける

個々の開発者は、NuGet.org でグローバル レジストリを使用し、アプリに必要なパッケージを見つけてダウンロードすることができます。 会社の場合は、使用できるパッケージとそれを見つける場所について、戦略が設けられている場合があります。

一般的なパッケージの一覧を示す NuGet.org のスクリーンショット。

パッケージは、さまざまな場所に配置されている場合があります。 これらのソースは、一般に公開されている場合と、制限されていて特定の会社の従業員だけが利用できる場合があります。 パッケージが存在する可能性のある場所を次に示します。

  • レジストリ: 例として、NuGet.org レジストリのようなグローバル レジストリがあります。 独自のレジストリをホストして、非公開または公開にすることができます。 GitHub や Azure DevOps などのサービスにより、プライベート レジストリが利用できるようになります。
  • ファイル: ローカル フォルダーからパッケージをインストールできます。 パッケージからのインストールは、独自の.NET ライブラリを開発しようとしていて、パッケージをローカルでテストしたい場合に一般的です。 または、何らかの理由でレジストリを使用したくない場合も含まれます。

パッケージ作成者、パッケージ ホスト、およびパッケージ コンシューマー間のリレーションシップを示す図。

NuGet レジストリと dotnet ツール

dotnet add package <name of dependency> を実行すると、.NET は、https://nuget.org に配置される NuGet.org レジストリと呼ばれるグローバル レジストリに移動して、ダウンロードするコードを探します。 ブラウザーを使用してアクセスした場合は、このページでパッケージを閲覧することもできます。 どのパッケージにも、アクセスできる専用の Web サイトがあります。

NuGet パッケージのランディング ページのスクリーンショット。

これらのサイト上で、ソース コードが置かれている場所について詳しく知ることができます。 ダウンロードのメトリックなどの情報や、メンテナンスに関する情報を見つけることもできます。

NuGet パッケージに関する情報とメトリックのスクリーンショット。

.NET コマンド

ここまで、.NET Core CLI を使用して依存関係をインストールする方法を説明してきました。 このツールを使用すると、さらに多くのことが可能になります。

.NET Core CLI には、非常に多くのコマンドが用意されています。 これらのコマンドは、パッケージのインストール、パッケージの作成、.NET プロジェクトの初期化などのタスクに役立ちます。 すべてのコマンドを詳しく把握する必要はありません。 .NET の使用を開始するときは、コマンドのサブセットのみを使用することがあります。 .NET の使用範囲が広がれば、さまざまなカテゴリのより多くのコマンドを使用できます。

コマンドの機能を覚えるには、それが属するカテゴリを考えるのが便利です。

  • 依存関係の管理: このカテゴリのコマンドは、インストール、削除、パッケージのインストール後のクリーンアップ、およびパッケージの更新に対応しています。
  • プログラムの実行: .NET Core ツールは、アプリケーション開発のフローを管理するのに役立ちます。 アプリケーション フローの例としては、テストの実行、コードのビルド、およびプロジェクトをアップグレードするための migrate コマンドの実行などがあります。
  • パッケージを作成して発行する: 圧縮パッケージの作成や、レジストリへのパッケージのプッシュなど、タスクに役立つコマンドがいくつかあります。

すべてのコマンドの詳細な一覧を確認するには、ターミナルで「dotnet --help」と入力します。

パッケージをインストールする方法

アプリケーションの一部としての使用が意図されている通常の依存関係をインストールするには、dotnet add package <dependency name> コマンドを使用します。

Note

一部のパッケージは、"グローバル" にインストールすることができます。 これらのパッケージは、プロジェクトへのインポートが意図されているものではありません。 そのため、多くのグローバル パッケージは CLI ツールまたはテンプレートです。 これらのグローバル ツールは、パッケージ リポジトリからインストールすることもできます。 ツールをインストールするには、dotnet tool install <name of package> コマンドを使用します。 テンプレートをインストールするには、dotnet new -i <name of package> コマンドを使用します。

インストール後に

インストールされたパッケージは、.csproj ファイルの dependencies セクションに一覧表示されます。 フォルダー内のパッケージを確認するには、「dotnet list package」と入力します。

Project 'DotNetDependencies' has the following package references
   [net8.0]:
   Top-level Package      Requested   Resolved
   > Humanizer            2.7.9       2.7.9

このコマンドによって一覧表示されるのは、最上位のパッケージのみであって、"推移的なパッケージ" と呼ばれている、それらのパッケージの依存関係は対象外となります。 このコマンドは、すばやく確認する場合に適しています。 より詳しく確認したい場合は、推移的なパッケージをすべて一覧表示することができます。 そのようにすると、list コマンドは次のようになります。

dotnet list package --include-transitive

transitive を含めると、インストールしたすべてのパッケージと共に依存関係を確認できます。 dotnet list package --include-transitive を実行すると、次のような出力が表示されることがあります。

Project 'DotNetDependencies' has the following package references
   [net8.0]:
   Top-level Package      Requested   Resolved
   > Humanizer            2.7.9       2.7.9

   Transitive Package               Resolved
   > Humanizer.Core                 2.7.9
   > Humanizer.Core.af              2.7.9
   > Humanizer.Core.ar              2.7.9
   > Humanizer.Core.bg              2.7.9
   > Humanizer.Core.bn-BD           2.7.9
   > Humanizer.Core.cs              2.7.9
   ...

依存関係を復元する

プロジェクトを作成または複製する場合、プロジェクトをビルドするまでは、含まれている依存関係がダウンロードされることも、インストールされることもありません。 dotnet restore コマンドを実行することで、プロジェクト ファイルに指定されている依存関係とプロジェクト固有のツールを手動で復元できます。 ほとんどの場合、コマンドを明示的に使用する必要はありません。 newbuildrun などのコマンドを実行すると、必要に応じて、NuGet の復元が暗黙的に実行されます。

依存関係のクリーンアップ

遅かれ早かれ、パッケージが必要なくなったことに気付くことがあります。 または、インストールしたパッケージが必要なパッケージではなかったことに気付くことがあります。 タスクをより適切に実行するパッケージが見つかることもあります。 理由は何であれ、使用していない依存関係は削除します。 そうすることで、すっきりします。 また、依存関係は領域を占有します。

プロジェクトからパッケージを削除するには、dotnet remove package <name of dependency> のように remove コマンドを使用します。 このコマンドを実行すると、プロジェクトの .csproj ファイルからパッケージが削除されます。