NuGetを使った解決法
NuGetを使うと、ライブラリ構成変更の手順は次のようになります。
1. 依存関係を管理するNuGetパッケージの配布
まず、最初の段階でライブラリの依存関係を持つNuGetパッケージを作成し、利用者に配布します（図9）。
①ライブラリの依存関係を表すNuGetパッケージを作成する
NuGetにはそのパッケージが依存している他のNuGetパッケージを管理する機能があります。これを利用し、必要なライブラリへの「依存関係のみ」を表したNuGetパッケージを作成します。例えば、MyLibパッケージへの依存関係を持つMySysLibsパッケージを作成します。
②利用者がNuGetパッケージをインストールする
1.で作成したNuGetパッケージをインストールすると、依存関係で指定したNuGetパッケージも自動でインストールされます。つまり、MySysLibsパッケージをインストールすると、依存関係にあるMyLibパッケージもインストールされるということです。
2. ライブラリ構成の変更に伴うNuGetパッケージ更新
次に、ライブラリ構成の変更に合わせ、追加のライブラリのNuGetパッケージを作成します。そして、依存関係を管理するNuGetパッケージには、追加したNuGetパッケージへの依存関係を追加し、バージョンを上げて利用者に配布します（図10）。
①ライブラリ構成を変更したNuGetパッケージをアップする
ライブラリ提供者が1.のNuGetパッケージの依存関係を変更し、バージョンを挙げてプライベート・リポジトリにアップします。例えば、MyLib2パッケージへの依存をMySysLibsパッケージに追加します。
②利用者がNuGetパッケージをアップデートする
NuGetパッケージをアップデートすると、ライブラリの依存関係変更を検出し、自動で追従します。MySysLibsパッケージをアップデートすることで、3.で追加したMyLib2パッケージが新たにインストールされます。
この方法により、dll直接配布する際の問題点が次のように解消されます。
1) ライブラリ構成変更への対応がツールで行える
NuGetのUpdate-Packageコマンドを実行することで、ライブラリ構成変更への対応が自動で行われます。また、通知の漏れをなくすには、プロジェクトファイルのBeforeBuildターゲットを作成し、ビルド前にNuGetコマンドを実行するように設定することもできます。詳しくは参考資料3)のページなどを参照してください。
依存関係を含むNuGetパッケージを作成するには、*.nuspecファイルのdependencies要素に対象となるNuGetパッケージのIDとバージョンを指定します。
<?xml version="1.0"?>
<package >
<metadata>
<id>$id$</id>
<version>$version$</version>
<title>$title$</title>
<authors>$author$</authors>
<owners>$author$</owners>
<description>$description$</description>
<dependencies>
<dependency id="MyLib1" version="1.0" />
<dependency id="MyLib2" version="1.0" />
</dependencies>
</metadata>
</package>
詳細は参考資料4)のページを参照してください。
まとめ
NuGetを活用することで、ライブラリ変更への対応に関する問題点を解消できることを紹介してきました。
-
NuGetを使うとライブラリの破壊的変更に次のように対応できる
- 複数人で並行して対応できる
- 段階的に対応できる
-
NuGetを使っていても、自動ビルドでは以下のことに気を付ける
- ライブラリ変更への対応作業が途中だとフルビルドに失敗する
- 自動ビルドは差分ビルドも活用し、フルビルドの頻度を下げる
-
NuGetを使うとライブラリの構成変更に次のように対応できる
- 依存関係のみを管理するNuGetパッケージを配布する
- NuGetパッケージを更新するとライブラリ構成を自動で変更できる
2回に渡ってNuGetをチーム開発で活用する方法について紹介してきました。今回紹介したのはあくまで一例であり、実際のチーム開発ではもっと複雑な前提条件や制約があることもあるでしょう。そんなときでも、NuGetに限らず様々なツールにどのような機能があり、どう活用できるかを考え、対処していくことが大事です。
また、NuGetのようなパッケージ・マネージャーは、Rubyの「RubyGems」、Perlの「CPAN」、Node.jsの「npm」など、他のプラットフォームにもあり、それぞれのコミュニティに知見が貯まっています。したがって、NuGetの利用に関して何らかの問題に突き当たったときは、そういった他プラットフォームのコミュニティにすでに同様の問題がないか調べてみるのも良いでしょう。
最近は.NETもMac OS X、Linux等とのマルチプラットフォーム化が進んできています。これに合わせて、コミュニティでもプラットフォームをまたいで知見が共有され、洗練され、よりよいものになっていければと思います。
