dll直接配布の問題点
このやり方で起こりうる問題として、ここでは以下の2つを例として挙げます。
1）ライブラリ利用までの手順が煩雑
まずはライブラリを利用するまでの手順が多いため、利用者にとっては負担となります。参照すべきライブラリが少なければそれほどではないかもしれませんが、業務システム開発等においては参照すべきライブラリが多くなる傾向があります。数が多ければ、その分ミスも発生しやすいでしょう。
また、ライブラリ配置用フォルダー（上記の例ではlibフォルダー）はその位置、名前をチームで統一しなければなりません。もし統一されていない場合、他者の作成したソリューションファイルを開いたとき、参照が必要なdllファイルが見つからず、参照設定をやり直さなければならない可能性もあります。
こういった手順やルールをチーム内に周知、徹底させるための教育コストが必要である、というのも一つの問題です。
2）異なるバージョンが同居できない
libフォルダーには、常に最新バージョンのdllだけが配置されます。つまり、ライブラリのバージョンがアップしても、新バージョンのdllファイルで旧バージョンのdllファイルを上書きすることになります。
その結果、今使っているライブラリのバージョンを確認するには、dllファイルのタイムスタンプやバージョン番号で確認するしかなくなります。よって、最新のバージョンであるかどうかは、これらの情報をローカルと共有フォルダー双方のdllファイルで比較するしかありません。
また、開発中に何かしらライブラリの不具合を見つけても、問題がなかった過去のバージョンに戻すといったことも、容易ではありません。
その他、こういう運用を行っている場合、ライブラリのバージョンが適切に管理されず、変更前後のdllファイルが何度も同じバージョンのまま配布されてしまう懸念もあります。この時は、ファイルのタイムスタンプしかdllファイルが最新であるかどうかを判断する方法がなくなってしまいます。
NuGetを使った解決法
NuGetを使うとライブラリ配布の手順は次のようになります（図2）。
1. 提供者がライブラリのNuGetパッケージをプライベート・リポジトリにアップする
ライブラリ提供者は、dllファイルを含むNuGetパッケージを作成し、NuGetのプライベート・リポジトリにアップします。プライベート・リポジトリは共有フォルダーや専用サーバー等で提供できます。
2. 利用者がプライベート・リポジトリからNuGetパッケージをインストールする
事前にVSに1.のプライベート・リポジトリを登録しておき、後は必要なライブラリのNuGetパッケージをインストールします。インストールしたライブラリは自動的にダウンロードされ、ソリューション内のpackagesフォルダーに、NuGetパッケージ名とバージョン名を含むサブフォルダーが作成されて配置されます。また、dll参照も同時に行われます。
この方法により、dll直接配布する際の問題点が次のように解消されます。
1）ライブラリ利用までの手順がシンプル
利用者が行うのは初回のプライベート・リポジトリ登録と、NuGetパッケージをインストールするだけです。これだけでライブラリのダウンロードとライブラリ用フォルダーへの配置、並びに参照設定が行えます。
2）異なるバージョンを混在させられる
NuGetはバージョン番号を含むパッケージ名のフォルダーにファイルを展開するため、ライブラリのバージョンがアップした場合でも新旧バージョンが別フォルダーに配置されます（図2）。そのため、ソリューションで同一ライブラリの異なるバージョンを使用するプロジェクトを混在させることもできます。
また、NuGetのUpdate-Packageコマンドを使うことで、特定バージョンへのロールバックも容易です（リスト1）。
PM> Update-Package (パッケージ名) -Version (バージョン番号)
NuGet採用時の注意点
NuGetを採用することで、様々な問題が解決できることがわかってもらえたかと思います。しかし、NuGetを採用することにはメリットばかりではありません。dllを直接配布する場合に比べて、一部注意が必要なところもあります。
1）バージョン管理を徹底する必要がある
NuGetは特定バージョンへアップデートすることできるということは、すなわちライブラリ提供側でしっかりとバージョン管理を行う必要があるということです。例えば、配布後にすぐに軽微なバグが見つかったとしても、それは新たなバージョン番号を付けて再度プライベート・リポジトリにアップしなければなりません。
これは一見面倒なようですが、これまでバージョン管理を疎かにしていたのであれば、習慣を見直すよい機会として捉えることもできます。特に、システムが大規模になればライブラリの利用者も増えるため、適切なバージョンを付けて管理していくことは、後々の問題発生時のトレーサビリティ確保にも役立ちます。
なお、バージョン番号の付け方については様々な流儀があります。参考資料4）、5）のページ等を参考に、チームの状況に合わせて運用方法を考えてみてください。
2）ライブラリのデバッグに注意が必要
dllを直接配布する場合、Debug構成でビルドしてできたpdbファイルも、dllファイルと一緒に配布することができます。こうすることで、利用者側がデバッガーでライブラリのコードにステップ・インすることができるようになります。これは、ライブラリの不具合等を利用者側でも調査することができるので、チーム開発では便利な運用方法の一つです。
しかし、NuGetでライブラリを配布する場合、NuGetパッケージにpdbファイルを含めることができないため、この方法は使えません。代わりに「シンボル・パッケージ」をライブラリとは別に作成した上で、対応したNuGetサーバーソフトを使う必要があります。詳しくは参考資料6）の記事を参考にして下さい。
