MS_LibraryUpgradeConsumerTesting

クラスライブラリのバージョンアップ時のライブラリ利用者側のテスト

• TOP > テスト
  • 異種環境への移行時のテスト・ポリシー
  • クラスライブラリのバージョンアップ時のライブラリ利用者側のテスト

概要

• I/F変更が無い場合、利用者側の修正・リビルドが不要なこともある（動作上問題なければ）。
• しかし、「定数、列挙型」などの変更時は、「ライブラリ利用者」側のリビルドが必要になる。

補足: 定数（const）や列挙型のリテラルは、C# ではコンパイル時に 呼び出し側のアセンブリへ値が埋め込まれる（インライン化される）ため、 ライブラリ側だけを差し替えても古い値のまま動作してしまう。 変更を伝播させたい値は static readonly にするという回避策がある。

対応

自前

ライブラリの変更点が明確なら、ソレに合わせてテストを実施すれば、「ライブラリ利用者」側のリビルドは不要。

製品

• 製品系は
  • GACに格納する事が多く、GACへの格納には厳密名が必須。
  • 厳密名 + バージョン番号変更でリビルドが必要になってくる。
• なので、基本的に、製品系のバージョンアップではリビルドが必要になってくるが、
  「アセンブリ バージョンのリダイレクト」でリビルドをしないで対応可能。

※ GAC とアセンブリ バージョンのリダイレクト（bindingRedirect）は .NET Framework の仕組み。 現行の .NET には GAC がなく、依存解決は NuGet とランタイムのロールフォワード（RollForward）で行う。

昨今

• 最近は、NuGetでガンガン取ってくることが増えた。

• NuGetは、GACに入れるのではなく、packagesフォルダで管理する。
  なので、厳密名が設定されていないケースも増えてきていると思う。

• こういう文化ではライブラリの更新頻度も高いので、いろいろ悩ましい。

  ↓ 月単位で更新されるライブラリの例。
  https://www.nuget.org/packages/Npgsql/

  • NuGetは開発環境、ビルド動作と紐付いているので、
    運用中に下位のDLLだけ差し替えるという運用は無い。
  • しかし、度重なる更新をテストしきれるか？は別の話。
    こういうケースに、レグレッション系のテスト自動化がハマるのではないか？

参考

• .NET、DLLの修正で参照元も全部ビルドし直すのか？ - misc.log
• 参照側プログラムのリビルドが必要となるような DLL の変更について | Visual Studio サポート チーム blog
• ど素人が C# で作られたサイトの dll を更新作業をした時のお話 - Qiita
  • アセンブリ バージョンのリダイレクト

---

Tags: テスト