環境移行直後のWin2012R2サーバで、プログラムのエラーが発生しました。

エラーログを見ると、「foobar05.dllのバージョン1.0.0.0が無い」との事。

C:\windows\assemblyを参照すると、foobar05.dllは登録されているのだけど…

※ただしバージョン1.0.4.0

■解決方法

C:\windows\assemblyには、最新バージョンだけでなく過去のバージョンのDLLも登録する必要がありました。

移行元環境に登録されていた全バージョンを追加で登録すると、正常に動作しました。

■理由

C:\windows\assemblyにDLLを登録すると、内部的には「該当バージョンのDLLの実体」が保持されます。

（今回はここの仕組みが理解出来ていませんでした…）

あるプログラムに起因する共有DLLバージョンの変更が、他のプログラムの動作に影響を及ぼさないように、と考えられた仕掛けみたいです。

アセンブリとグローバルアセンブリキャッシュの使用

https://docs.microsoft.com/ja-jp/dotnet/framework/app-domains/working-with-assemblies-and-the-ga

こういう事ができるらしいです。

例えばある端末のC:\Windows\assemblyをエクスプローラで見てみると

こんな風に、同じ名前で複数バージョンが表示されたりします。

しかしてその実体は、というと。コマンドプロンプトから参照出来ます

※開発ツールをインストールしていれば gacutil -l でも可

更に掘り下げていくと、各バージョン__公開キートークンのフォルダが見つかります。

各フォルダの中をサンプルで幾つか見てみると、サイズ違いの同名DLLが！

そもそもGACとは？

グローバルアセンブリキャッシュ

https://docs.microsoft.com/ja-jp/dotnet/framework/app-domains/gac

■経緯

該当のDLLは顧客内で自作したものでした。

以前にもfoobarXX.dllの不足によるエラーが発生した事があり、プログラムのデプロイ手順を参考に

１．%windir%\Microsoft.NET\Framework\v2.0.50727　にDLLを配置

２．配置したDLLをC:\Windows\assemblyにドラッグ＆ドロップで登録

という手順を踏んでいました。

手順１で実体を配置する事から、２で登録するのはバージョン情報だけで、実際の動作時は１で配置した実体にリンクするのだと思いこんでいました。

調べた結果から考えると、寧ろ不要なのは手順１の作業で、DLL登録さえ出来ていればOKだったのかと思います。

今回のサーバ移行では、実行環境をどのように構築し、その後どのように手を加えたか、全く資料が存在しませんでした。

その為、ファイル比較やプログラムの実動作確認で必要コンポーネントの洗い出しを行いました。

条件網羅が不十分だった為、特定条件で実行されるスクリプト内で呼び出されるDLLについて確認出来ていなかった、というのが不具合原因になると思います。

環境変更時のテストは、やっぱり全ての条件を元に実施する必要がありますね…

端折った所でエラーが起きる、を如実に体現してしまった案件でした。ｶﾞｯｸﾘ

共有DLLバージョンの罠(c:\windows\assembly)