次の方法で共有

NuGet

  • [アーティクル]

NuGet でプロジェクト ライブラリを管理する

Phil Haack

 

どれほど努力しても、マイクロソフトはすべてのライブラリ開発者のニーズを満たせるわけではありません。マイクロソフトの従業員は世界各地に 9 万人近くいます。ところが、全世界の開発者は数百万人です。特殊な需要をすべて満たそうとすることは、マイクロソフトにとって意味がないばかりか、拡張性を失うことになります。そのため、開発者はしばしば自分で "自分のニーズに応える" ことになり、その結果、これまで何千ものライブラリが作成され、Web のあちこちに分散するようになりました。

多数のライブラリが存在することで、こうしたライブラリの共有が問題になります。コードの共有と再利用は大きな課題です。ちょっと信じられなければ、中～大規模の企業を訪れて、ログ記録用のライブラリをいくつ所有しているかたずねてみてください。一定数の企業を訪れるとわかりますが、Log4Net、NLog、エラー ログのモジュールとハンドラー (ELMAH: Error Logging Modules and Handlers) など、優れたログ記録用ライブラリが存在するにもかかわらず、ほとんどの企業が社内で作成したログ記録用ライブラリを所有しています。

新しいプロジェクトに着手するときに、開発者は "何も描かれていないキャンバス" に向かって、この問題と向き合うことになります。このような役立つライブラリを見つけるにはどうすればよいでしょう。ライブラリをプロジェクトに組み込むとしたら、ライブラリの依存関係や更新をどのように管理すればよいでしょう。

ELMAH は、役立つライブラリの好例ですが、開発者が責任を持って作成するライブラリです。ELMAH は、例外がスローされたときに、Web アプリケーション内でハンドルされないすべての例外を、すべての要求情報 (ヘッダー、サーバー変数など) と共にログに記録します。ここで、この ELMAH について知ったばかりで、次のプロジェクトで ELMAH を使用するつもりだと考えてください。

この場合、おそらく次のような手順を踏むことになります。

  1. ELMAH を見つける: ELMAH という名前は独特なので、Bing 検索を実行すると最初の検索結果ページに ELMAH の Google コード ページが見つかります。
  2. 正しい ZIP パッケージをダウンロードする: 見つかったダウンロード ページには、複数の ZIP パッケージが公開されています。そのため、よく考えて、正しい ZIP パッケージを選択する必要があります。正しいパッケージは、直感的に正しいと思えるものと異なる場合があります。
  3. パッケージのブロックを解除する: パッケージを Web からダウンロードしたら、パッケージのファイルを右クリックしてプロパティ ダイアログ ボックスを開きます。このダイアログ ボックスの [ブロックの解除] ボタンをクリックして、ファイルから "Web の印" を削除します。
  4. ホスティング環境から提供されたハッシュに照らしてファイルのハッシュを検証する: Google コード サイトには、ZIP ファイルを表す QR コードが表示されています。QR コードに照らしてファイルを検証することに時間を掛ける開発者が何人いるかご存じでしょうか。
  5. ソリューションの明確な場所にパッケージ コンテンツを展開する: ほとんどの開発者は、アセンブリを bin ディレクトリには展開しません。これは、bin ディレクトリがビルドの出力用であって入力用ではなく、バージョン管理で追跡されないためです。バージョン管理に委ねられるフォルダーに依存関係を追加して、このフォルダーからアセンブリを参照することが重要です。
  6. アセンブリ参照をプロジェクトに追加する: アセンブリは、Visual Studio プロジェクト内からアセンブリへの参照を追加するまで使用できません。
  7. web.config を適切な設定に更新する: この作業では、構成ファイルに必要かつ正しい設定を見つようとする過程で、Bing または Google を使用してさらに検索することもあります。

とても手間がかかりますね。では、この手順を 10 ～ 15 もの依存関係に対して実行する必要があるとしましょう。次期バージョンをリリースするときになると、アプリケーションの依存関係の更新を検索するためにかなりの時間がかかります。

批判されがちな "自社開発主義" (NIH: not invented here) が、すばらしく思えてきませんか。

困ったときの NuGet

NuGet は、Visual Studio プロジェクトの (パッケージとして配置される) ライブラリの追加、更新、および削除を容易にする Visual Studio の拡張機能です。NuGet パッケージは、Open Packaging Conventions (OPC) 形式を使用する .nupkg という拡張子の単一ファイルに、一連のファイルがパッケージ化されたものです。

OPC は、あるメタデータを含む ZIP ファイルを表す便利な頭字語です。OPC は Word 文書や Excel ブックで使用される形式なので、実際には、皆さんはおそらく既に OPC についてご存じだと思います。任意の .docx ファイルの拡張子を .zip に変更すると、ファイルを開いて内容を調査できることがわかります。これは .nupkg ファイルについても同じです。

NuGet 製品には、パッケージを容易に作成して公開できるユーティリティも付属しています。この記事では、まず、NuGet を使用してパッケージを見つけてインストールする方法に注目します。パッケージの作成方法と公開方法についてはその後説明します。

NuGet をインストールする

NuGet をインストールするには、[ツール] メニューの [拡張機能マネージャー] をクリックし、Visual Studio 拡張機能マネージャーを起動します。[オンライン ギャラリー] タブをクリックして、利用できる Visual Studio 拡張機能を表示します (図 1 参照)。ご覧のとおり、NuGet はランキング最上位のパッケージなので、最初の画面に表示されます。最初の画面に表示されない場合は、画面右上の検索ボックスを使用します。[ダウンロード] ボタンをクリックして、NuGet をインストールします。

Visual Studio Extension Manager
図 1 Visual Studio 拡張機能マネージャー

ASP.NET MVC 3 をインストールしていれば、既に NuGet はインストールされています。ASP.NET MVC 3 には NuGet が付属しており、マイクロソフトは次期バージョンの Visual Studio に NuGet を同梱する予定です。

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

まず、NuGet の使いやすいダイアログ ボックスを使用してパッケージをインストールしましょう。後で説明するように、NuGet には、パワー ユーザーを対象とする Windows PowerShell ベースのコンソールも付属しています。

NuGet を起動するには、プロジェクトの [参照設定] ノードを右クリックし、[Manage NuGet Packages] (NuGet パッケージの管理) をクリックします (NuGet 1.4 より前のバージョンでは、このオプションには別のラベルが付いていました)。[Manage NuGet Packages] (NuGet パッケージの管理) ダイアログ ボックスが表示されます (図 2 参照)。

NuGet Package Manager Dialog
図 2 NuGet のパッケージ マネージャー ダイアログ ボックス

[Online] (オンライン) タブを選択していることを確認し、右上のボックスに検索語句を入力します (たとえば、StackOverflow.com (英語) のユーザーによる MiniProfiler を検索します)。

パッケージを見つけたら、[Install] (インストール) ボタンをクリックしてパッケージをインストールします。NuGet によってパッケージとその依存関係がダウンロードされ、パッケージで指定された必要な変更がプロジェクトに適用されます。

NuGet では、パッケージをインストールするために次の作業を実行します。

  1. パッケージ ファイルとすべての依存関係をダウンロードする: 明示的にライセンスに同意することを求められ、ユーザーにパッケージのライセンス条項への同意を求めるメッセージが表示するパッケージもあります。
ほとんどのパッケージはライセンスへの暗黙の同意で十分なので、このメッセージは表示されません。パッケージが既にソリューションまたはローカル コンピューターのキャッシュに存在する場合、NuGet はパッケージのダウンロードがスキップします。
  2. パッケージのコンテンツを取り出す: NuGet によってコンテンツが packages フォルダーに取り出されます (必要な場合はこのフォルダーが作成されます)。packages フォルダーは、ソリューション (.sln) ファイルと同じディレクトリ階層にあります。1 つのソリューションに含まれる複数のプロジェクトに同じパッケージをインストールする場合、パッケージは 1 回だけ展開され、すべてのプロジェクトで共有されます。
  3. パッケージのアセンブリを参照する: 原則として、パッケージの lib フォルダーに含まれる適切な (1 つまたは複数の) アセンブリを参照するように、NuGet によってプロジェクトが更新されます。たとえば、Microsoft .NET Framework 4 を対象とするプロジェクトにパッケージをインストールすると、lib/net40 フォルダーに含まれるアセンブリへの参照が追加されます。
  4. コンテンツをプロジェクトにコピーする: 原則として、パッケージの content フォルダーのコンテンツが NuGet によってプロジェクトにコピーされます。これは、JavaScript ファイルや画像が含まれたパッケージの場合に便利です。
  5. パッケージの変換を適用する: パッケージに変換ファイル (構成ファイルの場合は app.config.transform や web.config.transform など) が含まれている場合、コンテンツのコピー前にこの変換が適用されます。一部のパッケージには、ソース ファイルに現在のプロジェクトの名前空間をインクルードするよう変換できるソース コードが含まれていることがあります。NuGet では、このようなファイルも変換されます。
  6. パッケージの関連 Windows PowerShell スクリプトを実行する: パッケージによっては、NuGet の設計に適していない作業を処理するために、デザイン時環境 (DTE) を使用して Visual Studio をオートメーション化する Windows PowerShell スクリプトが含まれていることがあります。

NuGet でこれらの作業がすべて実行されると、ライブラリを使用できるようになります。多くのパッケージは、インストール後の構成を最小限に抑えるために、WebActivator パッケージを使用して設定されます。

パッケージはアンインストールでき、アンインストールすると、プロジェクトはそのパッケージをインストールする前の状態に戻ります。

パッケージを更新する

Robert L. Glass は、著書『ソフトウエア開発 55 の真実と 10 のウソ』(日経 BP 出版センター、2004 年) において、次のように述べています。「保守には、ソフトウエアのコストの 40 ～ 80% (平均 60%) がかかる。したがって、ソフトウエア ライフサイクルの最重要フェーズである。」

パッケージのインストールは、手始めにすぎません。パッケージに含まれるライブラリの保守を続けるうちに、やがてはライブラリの最新のバグを修正することで、アプリケーションを最新に保つことが重要になります。そのためには、「このプロジェクトのどの依存関係に、新しい更新を利用できるか」という疑問に答える必要があります。

既に述べたように、この疑問に答えることは、これまで常に時間のかかる作業でした。しかし、NuGet を使用すると、ダイアログ ボックスを起動して [Updates] (更新) タブをクリックするだけで利用可能な更新の一覧が表示されます (図 3 参照)。パッケージを最新バージョンに更新するには、[Update] (更新) ボタンをクリックします。

Updates Available for the Current Project
図 3 現在のプロジェクトで利用可能な更新

この [Update] (更新) をクリックすると、以前のパッケージがアンインストールされて新しいパッケージがインストールされ、すべての依存関係が必要に応じて適切に更新されます。

NuGet の Package Manager Console (パッケージ マネージャー コンソール) には、ソリューションのすべてのパッケージの更新や、"安全な" 更新の実行など、更新の管理を強化するコマンドが用意されています。

パワー ユーザー向けの NuGet

私は使いやすい GUI が大好きですが、私のようにマウスでのドラッグにこだわるユーザーを軽く見る開発者が多いことも知っています。このような開発者は、複数のコマンドを組み合わせる機能があることからコマンド ライン シェルを好みます。

NuGet では、パッケージ マネージャー コンソールと呼ばれる Windows PowerShell ベースのコンソール ウィンドウと、NuGet を操作する一連の Windows PowerShell コマンドを用意することで、このニーズに応えています。Windows PowerShell は .NET ベースのスクリプト言語とコマンド ライン シェルであり、一連のコマンドを組み合わせてオブジェクトを操作する作業に適しています。

パッケージ マネージャー コンソールを起動するには、[ツール] メニュー、[Library Package Manager] (ライブラリ パッケージ マネージャー)、[Package Manager Console] (パッケージ マネージャー コンソール) の順にクリックします。

パッケージ一覧を表示およびインストールする

パッケージ一覧を表示して検索するには、Get-Package コマンドを使用します。既定では、このコマンドを実行すると、現在のプロジェクトにインストールされたパッケージが一覧されます。ListAvailable フラグと Filter フラグを組み合わせて指定すると、パッケージをオンラインで検索できます。次のコマンドは、"MVC" について言及しているすべてのパッケージを検索します。

Get-Package -ListAvailable -Filter Mvc

インストールするパッケージを見つけたら、Install-Package コマンドを使用します。たとえば、ELMAH を現在のプロジェクトにインストールするには、次のコマンドを実行します。

Install-Package Elmah

Windows PowerShell は動的言語なので、正しいコマンド引数の入力に役立つタブ拡張を使用できます。タブ拡張は C# の IntelliSense に相当しますが、コンパイル時の情報に基づく IntelliSense とは異なり、タブ拡張は実行時に設定できます。

たとえば、「Install-Package Mvc」と入力して Tab キーを押すと、パッケージ ソースから入手可能なパッケージ名の一覧が表示されます (図 4 参照)。

A Tab-Expanded List of Packages
図 4 タブ拡張で表示されるパッケージの一覧

パッケージを更新する

パッケージ マネージャー コンソールには、ダイアログ ボックスよりもきめ細かく更新を制御できるコマンドが用意されています。たとえば、次のコマンドを引数を指定せずに呼び出すと、ソリューションのすべてのプロジェクトに含まれるすべてのパッケージが更新されます。

Update-Package

このコマンドは、すべてのパッケージを最新バージョンに更新しようとします。そのため、パッケージのバージョン 1.0 をインストール済みで、パッケージ ソースでバージョン 1.1 と 2.0 を利用できる場合、このコマンドを実行すると、最新のバージョン 2.0 に更新されます。

互換性に影響を及ぼす変更が加えられているパッケージがある場合、このコマンドによって大量の操作が実行されることがあります。多くの場合、すべてのパッケージを最新のバグ修正リリースに更新することをお勧めします。これは、"安全な" 更新と呼ばれ、ビルド番号やリビジョン番号が大きい (ただし、メジャー およびマイナー バージョン番号は同じ) パッケージの下位互換性が確保されます。安全な更新を実行するには、次のように Safe フラグを追加するだけです。

Update-Package -Safe

このコマンドの場合、パッケージのバージョン 1.0.0 をインストール済みで、パッケージ ソースでバージョン 1.0.1 と 1.1 を利用できるときは、パッケージがバージョン 1.1 ではなく 1.0.1 に安全に更新されます。

Update-Package コマンドには、パッケージを最新バージョンではなく特定のバージョンのパッケージに更新するなど、さらにきめ細かい機能も備わっています。

新しいコマンドで Visual Studio を拡張する

Windows PowerShell を使用したパッケージのインストール機能は優れていますが、Windows PowerShell の採用につながった最も説得力のある理由ではありません。最も説得力のある理由の 1 つは、パッケージからパッケージ マネージャー コンソールに新しいコマンドを追加できることです。追加したコマンドにより、Visual Studio の DTE を操作してさまざまな作業を行うことができます。

たとえば、MvcScaffolding パッケージをインストールすると、新しい Scaffold Controller コマンドがコンソールに追加されます。Entity Framework (EF) の Code First オブジェクトがある場合にこのコマンドを実行すると、コントローラーに加えて、EF オブジェクトの基本的な作成、読み取り、更新、および削除 (CRUD) 操作に対応するコントローラーのアクションとビューが生成されます (図 5 参照)。

MvcScaffolding Custom Scaffold Command in Action
図 5 MvcScaffolding の Scaffold カスタム コマンドの動作

組織での NuGet

このように NuGet による開発者のパブリック コミュニティでのライブラリ共有が容易になることに重点を置いて説明すると、企業内でも NuGet が役立つことを見落としがちです。

結局のところ、企業と言えども、コードの共有時にソフトウェア コミュニティが直面するのと同じ課題の影響を免れるという点では、特別なことはありません。企業は、成長するにつれて無秩序な状態に陥ります。同じ社内の別々のグループが、企業の "標準" ライブラリから派生した独自のプライベート バージョンを保有するようになります。一部のグループが標準ライブラリを完全に無視して、独自のライブラリをゼロから作成することも考えられます。

たいていの場合、問題はライブラリ自体ではなく、このようなライブラリを他のチームと共有して変更をチーム間で通知する作業の煩わしさです。聞き覚えのある表現だと思いませんか。

パッケージ ソース

ここまではパッケージのインストール方法について説明してきましたが、「インストールするパッケージはどこに存在するのか」という当然の疑問に答えていませんでした。パッケージは、公式の NuGet パッケージ ギャラリー (nuget.org、英語) に存在しています。このギャラリーでは、OData フィード (packages.nuget.org/v1/FeedService.svc) を公開しています。

OData 形式により、NuGet クライアントがクライアント上のパッケージ ソースを検索するアドホック クエリを生成できます。ただし、生成したクエリを実行するのはサーバー上です。

NuGet にパッケージ ソースを追加するには、[ツール] メニュー、[Library Package Manager] (ライブラリ パッケージ マネージャー)、[Package Manager Settings] (パッケージ マネージャーの設定) の順にクリックして、[Package Sources] (パッケージ ソース) ノードをクリックします (図 6 参照)。

Package Manager Settings
図 6 [Package Manager Settings] (パッケージ マネージャーの設定)

既定のパッケージ ソースは Web 上の OData エンドポイントですが、サンプルのスクリーンショットには、ローカル フォルダーもパッケージ ソースとして表示されています。NuGet では、(ローカルまたはネットワーク共有のいずれであっても) フォルダーはパッケージ ソースとして扱われ、フォルダー内の各パッケージが [Online] (オンライン) ウィンドウに一覧表示されます。そのため、コードをフォルダーに配置する程度の容易さで他のユーザーとコードを共有できます。この機能は、自分で作成したパッケージをテストする場合にも役立ちます。

独自の NuGet サーバーをホストする

ネットワーク共有でパッケージをホストするだけでなく、パッケージ ソースとして Web サイトを設定し、このサイトを使用して組織内の他の開発者とパッケージを共有することもできます。

多くの作業と同様に、この作業に役立つパッケージが存在します。まず、Visual Studio で空の ASP.NET Web アプリケーションを作成します (ASP.NET 4 を対象にします)。NuGet を使用して、NuGet.Server パッケージをインストールします。このパッケージをインストールすると、空の Web アプリケーションにシンプルな OData エンドポイントが追加されます。

次に、パッケージ ファイルを Web アプリケーションの Packages フォルダーに追加して公開し、Web サイトを配置します。この Web サイトの設定方法の詳細については、NuGet のドキュメント サイト (bit.ly/jirmLO、英語) を参照してください。

nuget.org (英語) のようにギャラリーとしての完全な機能を備えたサイトを配置する場合は、NuGet ギャラリーのコードをオープンソース プロジェクトとして nugetgallery.codeplex.com (英語) プロジェクトから入手することもできます。

プライベートな NuGet サーバーやギャラリーの実装をホストすると、パブリックなサイトに公開しなくても社内の非公開のコードを簡単に共有できます。

パッケージを作成する

そもそもインストールするパッケージがなければ、NuGet は役立ちません。NuGet で利用できるパッケージが役立つほど、各開発者にとっての NuGet の価値が高まります。NuGet チームがパッケージ作成をできる限り簡単で手間のかからない作業にすることを追求したのは、このためです。パッケージの作成は簡単ですが、NuGet チームではさらに簡単にするための機能に力を注ぎ続けています。チームでは、NuGet パッケージを作成するためのツールをいくつか構築しました。たとえば、Package Explorer は、NuGet チームに所属する開発者の 1 人が作成した ClickOnce アプリケーションで、パッケージを視覚的に構築および調査できます。このツールは、npe.codeplex.com (英語) で入手できます。

NuGet.exe

ほとんどのパッケージ作成者はパッケージの作成をビルド プロセスに統合するため、NuGet のコマンド ライン ユーティリティを使用した別の方法を説明しましょう。ユーティリティは、bit.ly/gmw54b (英語) から 1 回だけダウンロードする必要があります。NuGet.exe ユーティリティをダウンロードしたら、PATH 環境変数に追加したフォルダーに、このユーティリティを配置します。今回は、このようなユーティリティ向けに utils という名前のフォルダーを用意しています。

先ほど NuGet.exe を 1 回だけ (正確にはコンピューター 1 台あたり 1 回) ダウンロードする必要があると述べた理由は、このユーティリティが自己更新型の実行可能ファイルであるためです。次のコマンドを実行すると、NuGet によってユーティリティがオンラインで確認され、新しいバージョンを利用できる場合は最新バージョンに更新されます。

nuget update –self

NuGet.exe コマンド ライン ツールでは、パッケージ マネージャー コンソールなどのオンライン フィードにクエリできます。たとえば、"MVC" を含むすべてのパッケージを検索するには、次のコマンドを実行できます。

nuget list Mvc

NuGet.exe では、パッケージと依存関係をダウンロードして展開することもできますが、ダウンロードしたパッケージ アセンブリを参照するプロジェクトを変更することや、パッケージに含まれる Windows PowerShell スクリプトを実行することはできません。

プロジェクトからパッケージを作成する

アセンブリを 1 つだけ含むパッケージは、(私の個人的調査によれば) 全体の 90% に及びます。ここでは、NuGet.exe をプロジェクト ファイル (.csproj ファイルや .vbproj ファイル) に対して使用してこのようなパッケージを作成する、単純なワークフローを説明します。

複数の .NET Framework のバージョンを対象とする単一パッケージなど、複雑なパッケージを作成する方法の詳細については、NuGet のドキュメント Web サイト (docs.nuget.org、英語) を参照してください。

パッケージを作成する基本的な手順は、次のとおりです。

  1. クラス ライブラリ プロジェクトを作成します。
  2. プロジェクトから NuSpec マニフェストを生成します。
  3. プロジェクトのアセンブリ メタデータを更新します。
  4. NuGet.exe を使用してパッケージを作成します。

クラス ライブラリ プロジェクトの作成: アセンブリを共有するには、まずクラス ライブラリ プロジェクトを作成します。NuGet では複数の種類のプロジェクトをパッケージ化できますが、コードを共有する場合はたいていクラス ライブラリを使用します。パッケージを作成したら、必ず AssemblyInfo.cs ファイルを開いて、アセンブリのメタデータを更新します。

NuSpec マニフェストの作成: NuSpec ファイルは、作成者、説明、パッケージの依存関係など、パッケージに関する重要なメタデータが含まれたパッケージ マニフェストです。NuSpec 形式は手動で簡単に作成できますが、spec コマンドを使用してファイルを生成するとさらに便利です。プロジェクト ファイルと同じディレクトリで、次のコマンドを実行します。

**  nuget spec**

今回は spec コマンドでプロジェクト ファイルから NuSpec を生成したので、NuSpec の一部のメタデータにはプレースホルダーが含まれています (図 7 参照)。

図 7 生成された NuSpec ファイル

<?xml version="1.0"?>
<package xmlns=
  "https://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
  <metadata>
    <id>$id$</id>
    <version>$version$</version>
    <title>$title$</title>
    <authors>$author$</authors>
    <owners>$author$</owners>
    <licenseUrl>http://LICENSE_URL_HERE_OR_DELETE_THIS_LINE</licenseUrl>
    <projectUrl>http://PROJECT_URL_HERE_OR_DELETE_THIS_LINE</projectUrl>
    <iconUrl>http://ICON_URL_HERE_OR_DELETE_THIS_LINE</iconUrl>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>$description$</description>
    <copyright>Copyright 2011</copyright>
    <tags>Tag1 Tag2</tags>
  </metadata>
</package>

プレースホルダーが含まれているフィールドは編集せず、licenseUrl、projectUrl、iconUrl、tags など他のフィールドに適切な値を入力します。

プロジェクトのアセンブリ メタデータの更新: すべてのアセンブリには、そのアセンブリに関連するメタデータがあります。NuGet では、パッケージの作成時にこのようなアセンブリ メタデータを読み取って NuSpec マニフェストにマージできるため、アセンブリの情報は必ずパッケージとアセンブリの間で同期されます。

既に述べたように、この情報は、通常 AssemblyInfo.cs という名前のファイルに含まれています。図 8 の表は、アセンブリ メタデータと NuSpec のプレースホルダー値の対応を示しています。

図 8 NuSpec に対応するアセンブリ メタデータ

トークン プレースホルダー値の取得元
$id$ アセンブリ名
$title$ AssemblyTitleAttribute で指定しているアセンブリのタイトル
$version$ AssemblyVersionAttribute で指定しているアセンブリのバージョン
$author$ AssemblyCompanyAttribute で指定している企業
$description$ AssemblyDescriptionAttribute で指定している説明

他のフィールドと異なり、$id$ フィールドの値はアセンブリ属性から抽出されるのではなく、アセンブリ名に設定されます。

パッケージの作成: プロジェクト ファイルや NuSpec ファイルと同じディレクトリで次のコマンドを実行して、パッケージを作成します。

nuget pack ProjectName.csproj

同じディレクトリに存在するプロジェクト ファイルが 1 つの場合は、コマンドの実行時にプロジェクト ファイル名を指定しなくてもかまいません。

プロジェクトをまだコンパイルしていない場合は、Build フラグを使用して、プロジェクトをコンパイルしてからパッケージ化します。次のように指定すると、プロジェクトのコンパイル後に pack コマンドが実行されます。

nuget pack ProjectName.csproj -Build

このコマンドを実行すると、ProjectName.<バージョン>.nupkg という名前のファイルが作成され、<バージョン> には AssemblyVersionAttribute で指定した値と同じ値が使用されます。たとえば、バージョンが 1.0.0 の場合、パッケージの名前は ProjectName.1.0.0.nupkg になります。Package Explorer を使用すると、作成後にパッケージを調査して、パッケージが正常に作成されたかどうか確認できます。

パッケージをインストールする開発者のために、次のように Symbols フラグを使用して、デバッガーのシンボルを含むパッケージを作成することを検討してください。

nuget pack ProjectName.csproj -Build -Symbols

このコマンドを実行すると、メインのパッケージに加えて、シンボル パッケージが作成されます。そのため、パッケージをインストールしたユーザーは、アプリケーションのデバッグ時にパッケージ コードにステップ インできるようになります。

パッケージを公開する

パッケージを作成したら、おそらく、作成したパッケージを世界中と共有したくなります。NuGet.exe には、ちょうどこの目的のために作成された公開用コマンドがあります。パッケージを公開するには、nuget.org (英語) でアカウントを作成する必要があります。

アカウントを登録したら、アカウントへのリンクをクリックして、アクセス キーを確認します。このキーは、ギャラリーに対する nuget.exe コマンドを識別し、失効可能なパスワードとして機能するので、重要です。

キーを取得したら、次のコマンドを使用して、安全な場所にキーを格納します。

nuget setApiKey b688a925-0956-40a0-8327-ff2251cf5f9a

続いて、次のように push コマンドを使用して、パッケージをギャラリーに公開します。

nuget push ProjectName.1.0.0.nupkg

このコマンドでは、パッケージのアップロード前に、API キーをギャラリーに対して検証します。先ほど説明したようにシンボル パッケージを作成した場合は、パッケージの公開時に次のような Symbols フラグを指定する必要があります。

nuget push ProjectName.1.0.0.nupkg -Symbols

シンボル パッケージの名前ではなく、メインのパッケージの名前を指定することに注意してください。このコマンドを実行すると、規則に従って適切なシンボル パッケージが検出されます。また、メインのパッケージは NuGet ギャラリーに公開され、シンボル パッケージはパートナー サイトである symbolsource.org (英語) のリポジトリに公開されます。

今後の展望

今回は、NuGet で NuGet ギャラリーから便利なライブラリを取得して、新しいプロジェクトの開発を効率的に着手する方法について説明しました。組織内では、社内のさまざまな開発者どうしでコードを共有するうえで NuGet が役立ちます。

ただし、NuGet に関する根深い誤解を解く必要があります。それは、NuGet が Web 開発者だけを対象にしているという考えです。この誤解の原因は、おそらく NuGet が ASP.NET MVC 3 のリリースに付属していたことにありますが、これは正しくありません。NuGet は Web 開発者だけを対象にせず、すべての開発者を対象にしています。NuGet では、さまざまな種類のプロジェクトの中でも特に Windows Phone、Silverlight、および Windows Presentation Foundation をサポートし、今後サポートするプロジェクトの種類が広がる予定です。

NuGet は、Apache 2 ライセンスに基づいてライセンスされたコミュニティ主導型のオープンソース プロジェクトです。NuGet プロジェクトは Outercurve Foundation に属していますが、マイクロソフト製品に組み込まれており、マイクロソフトの開発者が数名協力しています。

NuGet の開発に協力するには、nuget.codeplex.com (英語) にアクセスして、プロジェクトに参加する方法や、場合によっては NuGet の開発に加わる方法について学習してください。

今回は、NuGet で実現できることの概要を説明しただけです。詳細については、NuGet のドキュメント Web サイト (docs.nuget.org、英語) を参照してください (NuGet チームではこのサイトの管理に尽力しており、ドキュメントに対する皆さんのご協力を歓迎いたします)。チームは NuGet プロジェクトに関する CodePlex のディスカッション フォーラムで活動しており、皆さんの質問をお待ちしています。

Phil Haack は、マイクロソフトの ASP.NET チームのシニア プログラム マネージャーとして、優れた開発者向け製品の構築を目指しています。ASP.NET のさまざまな分野を探求していますが、主に携わっているプロジェクトは、ASP.NET MVC と NuGet Package Manager (どちらも OSS ライセンスでリリース) です。また、余暇には、ブログ (haacked.com (英語) でソフトウェアに関して執筆したり、オープンソースのブログ エンジンである Subtext に携わったりしています。

この記事のレビューに協力してくれた技術スタッフの David Fowler に心より感謝いたします。