特集:NuGetプライベート・リポジトリ概説

特集:NuGetプライベート・リポジトリ概説

社内の開発環境の改善&効率化のためにNuGetを活用しよう

2013年6月19日

.NET開発の必需品となった「NuGet」。しかし公開ライブラリのインストールにしか使っていないならもったいない。プライベート・リポジトリ機能を活用して、開発現場の作業効率を高めよう。

きよくら ならみ
  • このエントリーをはてなブックマークに追加

NuGetのプライベート・リポジトリ機能

 マイクロソフトの開発環境向けライブラリ・パッケージ・マネージャー「NuGet」は、Visual Studio 2012において既定でインストールされるようになったことや、マイクロソフト製の公式なライブラリもNuGetで提供されるようになったことなどからも、今や.NET開発に欠かせないインフラになったといえる。

 このNuGet、単に「公開されているライブラリを利用するためだけのツール」と捉えていないだろうか。NuGetは公開されているライブラリを利用するだけでなく、パッケージを自分で作成し、公式リポジトリであるNuGetギャラリーにプッシュして公開することも可能である。

 あるいは、「パッケージが自作できても、フリーウェアとして公開するつもりはないから……」などと、自分とは無関係だと捉えている開発者も少なくないのではないだろうか。だが、決してそうではない。NuGetは「プライベート・リポジトリ」と呼ばれる、いわば「クローズドなNuGetギャラリー」を作成して運用する機能を保有している。このプライベート・リポジトリを活用することで、開発現場における環境の改善と効率化を行うことも可能だ。

 今回は実際に筆者が運用している例も交えながら、その活用方法をお伝えしたい。なお、本稿で使用するOSはWindows 8、IDEのバージョンはVisual Studio 2012(Update 2。NuGetは執筆時点の最新版)である。

プライベート・リポジトリを実現する手段

 具体的にプライベート・リポジトリを構築する方法を説明しよう。具体的には大きく2通りの手段がある。

ファイル・システム・ベースのプライベート・リポジトリ

 まず1つ目はファイル・システム・ベースのプライベート・リポジトリの構築方法だ。実はこれは「リポジトリ構築」などとかしこまって言うほど大げさなものではない。単純に特定のフォルダーにパッケージを配置し、参照するよう設定するだけである。手順を紹介しよう。

1. リポジトリとして利用するフォルダーを準備

 リポジトリとしてパッケージを配置するフォルダーを準備する。“準備する”といっても、特別なことをする必要はない。どこか適当なフォルダーを専用に確保するだけでよい。今回は例として、「C:\MyNuGetRep」としよう。

2. Visual Studioのオプション設定ダイアログを起動、設定画面を表示する

 Visual Studioのメニューバーの[ツール]-[オプション]からオプション設定ダイアログを起動し、[パッケージ マネージャー]-[パッケージ ソース]を選択する。

3. 名前とソースを入力し追加する

 設定ダイアログの右上にある[+]ボタンをクリックして新規パッケージ・ソースを追加し、そのパッケージ・ソースが選択された状態で [名前]欄に任意の名称(例:「My NuGet パッケージソース」)、[ソース]欄にリポジトリとして利用するバス(例:「C:\MyNuGetRep」)を入力し、[更新]ボタンを実行する。

Visual Studioのオプション設定ダイアログ

ファイル・システム・ベースのプライベート・リポジトリを設定しているところ。

  • 1[パッケージ マネージャー]-[パッケージ ソース]を選択。
  • 2[+]ボタンをクリックして新規パッケージ・ソースを追加。
  • 3[名前]欄に任意の名称を設定。
  • 4[ソース]欄に今回リポジトリとして利用するフォルダーを指定。
  • 5最後に[更新]ボタンをクリックする。

 以上でリポジトリの設定は完了である。この後、作成したパッケージを該当のフォルダーに配置すると、NuGet利用時(次の画面はその例)に、先ほど追加したリポジトリ(例では「My NuGet パッケージソース」)を指定すると、プライベート・リポジトリに配置したパッケージが参照・利用できることが確認できる。

加されたプライベート・リポジトリにパッケージを配置し、参照した例

 またパッケージをバージョン・アップした場合の扱いも簡単である。最新のパッケージ(通常、パッケージ名にバージョン番号が付与される)を同じフォルダーに配置するだけで、自動的に適切に扱うため、特に気にする必要はない。以下の画面はその例だ。

更新されたパッケージを旧バージョンと同時に配置
パッケージ・マネージャー(GUI)からは最新版が表示される。コマンドラインや依存関係により旧バージョンが指定された場合は、正しく旧バージョンがインストールされる

  なお、この方法で特に知っていただきたいのは、ローカルのファイル・システムだけでなく、ネットワーク上の共有フォルダーも同様に利用可能、という点である。パッケージ・ソースを指定する際、[ソース]欄にUNCでネットワーク・パスを記述すれば(次の画面を参照)、ローカルの場合と全く同様に利用することができる。

リポジトリ・ソースとしてネットワーク上の共有フォルダー「\\FileServer01\NuGetRepository」を指定した例

  このため、部署や社内などWindowsのファイル共有が利用できる範囲での利用であれば、複数人で利用する場合であっても、後述するHTTPを利用する手法よりも手軽に運用が可能である。

HTTPベースのプライベート・リポジトリ

 2つ目の方法はHTTPを利用して公開するリポジトリの構築だ。いわゆるWebサーバーによるプライベート・リポジトリである。ファイル・システムを利用する手法は手軽ではあるが、ファイアウォールを超えてアクセスする必要がある場合は運用が困難となることが予想される。その場合はWebサーバーを利用してプライベート・リポジトリを構築・運用する方法を検討してみるとよい。

 この方法で作成する場合、原理的には、NuGetがWebサーバーから最低限以下のものをダウンロードできればよい。

  • パッケージ・ファイルのメタデータなどがXML(Atom)で記述されたカタログ
  • パッケージ・ファイルのバイナリ

 そのため、上記の要件さえ満たせればLinux上でホストしたApacheなどのIIS以外のWebサーバーも問題なく使える。その場合、最も原始的な手段を取るのであれば、手作業でカタログを作成してパッケージとともに公開ディレクトリに配置すればよい。次のXML(Atom)データは、公式のNuGetギャラリーにブラウザでアクセスして得られたカタログの内容を一部抜粋したものだ。このようなカタログを作成する必要がある。

公式のNuGetギャラリーにブラウザでアクセスし、得られたカタログの例
公式のNuGetギャラリーにブラウザでアクセスし、得られたカタログの例

  とはいえ現実問題として、パッケージの管理やカタログの作成などの運用を考慮するならば、それらの作業を補助する何らかのアプリケーションを導入する方が現実的であろう。

 NuGetでは「NuGet.Server」というサーバー・アプリケーションが提供されている。IISおよびASP.NETが動作する環境であれば手軽にプライベート・リポジトリを公開・運用できるため、今回はこのアプリケーションの利用手順を手短ではあるが紹介しよう。なお、実際に運用する場合はIIS上にデプロイするべきであるが、今回は説明のためVisual Studio上での実行するに留めている点をご了承いただきたい。

1. ASP.NET Webアプリケーション・プロジェクトを作成する

 まずは空のWebアプリケーション・プロジェクトを作成する。この際、(次の画面に示すとおり).NET Framweorkのバージョンは「.NET Framework 4」、プロジェクト・テンプレートは「ASP.NET 空の Web アプリケーション」を選択すること。

プロジェクト新規作成ダイアログ

NuGet.Serverをインストールするために、空のWebアプリケーションを作成しているところ。

  • 1フレームワーク・バージョンは「.NET Framework 4」を選択*1
  • 2プロジェクト・テンプレートは「ASP.NET 空の Web アプリケーション」を選択。
  • *1 「4.5」を選択してもよいが、2013年5月26日現在のバージョンでは一部Web.Configファイルの修正が必要になる。
2. NuGetで「NuGet.Server」を検索し、インストールする

 プロジェクト・テンプレートの展開が終了したら、NuGetで「NuGet.Server」を検索してインストールする(次の画面はその例)。これにより、依存関係のあるライブラリと同時にNuGet.Serverがインストールされる。

NuGet.Serverをインストールする(画面は2013年5月26日現在のバージョン「2.5.0.1」)
3.NuGet.Serverを実行する

 パッケージのインストールが終わったら[F5]キーを押すなどしてNuGet.Serverを実行してみよう。問題なければ、ブラウザが起動し、下記のような画面が表示されるはずだ。

NuGet.Serverを実行した際のブラウザ表示

このWebページは、NuGet.Server v2.5.40416.9020が実行中であることを示している。

  • 1NuGetのパッケージ・ソースとして指定するURL。
  • 2コマンドラインからパッケージをプッシュする際のコマンド例。
  • 3直接、フォルダーにパッケージを配置する際の配置先のパス。

 リポジトリとしての設定は以上で完了である。この状態ですでにリポジトリとして動作する状態となっている。以下では、引き続き、このリポジトリへのパッケージの配置方法と、そのパッケージをソースとして指定する方法を説明する。

4. パッケージ・ファイルを配置する

 配布するパッケージを配置しよう。NuGet.Serverでは公式のNuGetギャラリーと同様、コマンドラインによるプッシュ配置と、フォルダーへの直接配置の2つの方法をサポートしている。前者の方法で配置する場合はブラウザの指示に従いコマンドを実行すればよい。ただし、この場合はWeb.Configファイル内の<appSettings>セクションにて「apikey」(=全ユーザーで共有するキー、任意の値でOK)の設定を行っておく必要がある(この設定項目は、NuGet.Serverのインストール時に自動生成されている)。後者の場合は、単に所定のフォルダーにパッケージ・ファイルをコピーしておくだけでよい。

5. パッケージ・ソースを指定する

 最後にパッケージのソースを指定しよう。指定方法は「●ファイル・システム・ベースのプライベート・リポジトリ」で紹介した場合と同様、Visual Studioのオプション設定ダイアログから行う。違いはソースに先ほどブラウザで指定されたURLを設定する点のみである(次の画面を参照)。

NuGet.Serverによるプライベート・リポジトリをパッケージ・ソースに指定

 いかがだろうか。どちらの手法の場合でもごく簡単にプライベート・リポジトリを構築できることをご理解いただけただろうか。

NuGetプライベート・リポジトリ利用による社内開発環境改善事例

 それでは最後に、筆者の体験に基づく利用シナリオをいくつか紹介しよう。

利用シナリオ例1: 社内ライブラリの配布管理

 社内標準ライブラリなど、自社内で作成・利用するライブラリの配布を行うという、最もオーソドックスな利用方法である。まずはここから始めてみるとよいだろう。

 すでにNuGetをご利用の方はお分かりだと思うが、NuGetを利用するとプロジェクトでのライブラリ利用はとても快適なものとなる。ライブラリ利用時の設定作業や依存関係の解決など、面倒な作業の大半が自動化されるためだ。ライブラリの初期導入時はもちろんだが、バージョン・アップ時の方がこの恩恵をより多く受けることになる場合も少なくない。

 NuGetを利用したパッケージには大変多くの機能がある。ライブラリをはじめとした各種ファイルを配布するだけでなく、設定ファイル(Web.Config/App.Config)への設定の追加や、PowerShellのスクリプト実行することも可能だ。これらの機能を有効に利用すれば、ライブラリをプロジェクトで利用する際に必要な作業の大部分をNuGetに任せてしまうことも可能となる。

利用シナリオ例2: NuGetパッケージが提供されていないライブラリを管理する

 NuGetギャラリーで公開されるパッケージは日々増加しており、.NETで開発を行う際に必要なライブラリの多くはNuGetギャラリー経由での利用することが可能となっている。

 とはいえ世の中で公開されている全てのライブラリがNuGetギャラリーで提供されているわけではない。またソース・コードのみが提供されており、自分でビルドして利用する必要があるライブラリもあるかもしれない。

 そんな場合でも、NuGetを活用する方法がある。自分でそれらのパッケージを作成し、プライベート・リポジトリに配置すればよいのだ。ただし、利用するライブラリのライセンスや再配布のポリシーには十分注意する必要があるのは言うまでもない(当然ではあるが)。

利用シナリオ例3: 「ライブラリの依存のみ」を配布する

 業務でアプリケーションを作成する際、社内標準/チーム標準により利用するべきライブラリが指定されているということはないだろうか。例えば「社内Webアプリ作成の際はlog4netGlimpseを利用すること」などである。NuGetを使うと、これらを簡単に管理することができる。

 NuGetではファイルを配布することなく、依存関係のみをメタデータに記述したパッケージを作成・配布することができる。これを適用すれば、自動的に必要なライブラリがアプリケーション内に取り込まれるというわけだ。例えば次の画面で示す[社内Webアプリでの標準...]という自作のパッケージをインストールすると、アプリケーションに必要なlog4netとGlimspeがプロジェクトに取り込まれる。

log4netとGlimspeをプロジェクトに取り込むためのパッケージの例

 また、「社内検証を行い、Goサインが出たバージョンしか利用してはいけない」というようなルールがある現場もあるだろう。NuGetでは依存関係の指定時、依存するバージョンを詳細に指定することができる。例えば「○○ライブラリのバージョン1,2.0以上、1.3.0未満」や「△△ライブラリのバージョン1.1.0のみ」といった具合だ。これを利用して適切に依存関係のバージョンを指定しておくことで、ルールを無視して不用意にライブラリのバージョンを上げてしまうような事故を防止できる。新しいバージョンの検証が終わり次第、依存関係が更新されたパッケージを作成して配布すれば、更新処理も簡単に行える。

まとめ

 NuGetで容易にクローズドなプライベート・リポジトリを作成することが可能であること、そしてNuGetを活用することで日々の開発業務の効率を大きく改善できる可能性があることをご理解いただけただろうか。

 NuGetは非常にパワフルで可能性を秘めたツールである。今回は紹介できなかったが、シンボル・サーバーと連携してソース・ファイルやデバッグ・シンボルを配布・利用する仕組みも存在する。さらには“ライブラリ”・パッケージ・マネージャーの枠を超え、NuGetの仕組みをアプリケーション・パッケージの管理に利用する動きもある。

 NuGetを、単に「NuGetギャラリーに公開されているライブラリを利用するためのツール」としてしか利用しないのは大変もったいない。是非、皆様なりのNuGetの有効な活用方法を見つけ出し、日々の開発に利用していただければと思う。

サイトからのお知らせ

Twitterでつぶやこう!