これは、アプリケーションAが共有DLL v1.0をインストールするときです。アプリケーションBは、共有DLLをv1.1に更新しますが、互換性があるはずですが、わずかにさまざまな動作、その後、アプリAが正常に機能しなくなり、v1.0を再インストールして、アプリBが機能しなくなります... 2つ以上のアプリでこれを想像してください。1ダースとしましょう：DLL地獄。
DLL hellは、主にCOMの時代のもので、COM dllを登録する必要があり、そのクライアントはレジストリでそれを検索していました。ファイルシステム（* .dll、*。ocx）が変更され、古いエントリがレジストリに残る可能性があるため、これは悪夢でした。アプリが機能しなくなるのは恐ろしいことでした。
次に、新しいアプリがDLLの新しいバージョンをインストールして登録するというシナリオを取得し、古いバージョンを本当に必要とするアプリを壊します。あなたは古いアプリを再インストールし、その過程で新しいアプリを壊します。
。
古き良きCOM時代の要するに、各COMコンポーネントは、使用する前に登録（レジストリにエントリを作成）する必要がありました。次に、プログラムは型名（レジストリのキー）を指定して新しいオブジェクトを作成します。そして、あなたは実際にどのdllがロードされるのか、他のソフトウェアがこのdllの新しい/古い/完全に異なるバージョンを登録するなどの制御がありませんでした。
シンプル-以前のバージョンのウィンドウでは、複数のアプリケーションがすべて同じ共有ライブラリにアクセスしようとすることが可能でした。そこに問題はありません、それが共有されている理由です。問題は、異なるアプリが中央の場所から同じアセンブリの異なるバージョンにアクセスしようとしたときに発生します。それ以降のバージョンのdllはすべて下位互換性があり、最新バージョンを使用していることは問題ありませんが、v2を必要とするアプリをインストールしてから、バージョン1を必要とする（および含む）アプリをインストールすると、 x、最初のアプリが機能しなくなることがあります（v2 dllがv1.xで上書きされているため）。
Windowsの最近のバージョンでは、DLLの複数のバージョンを保存でき、要求に応じて正しいバージョンを提供できます。
これは、アプリケーションがシステムにDLLをインストールし、別のアプリケーションがそれを古いバージョンと互換性のないDLLの別のバージョンに置き換えるときに発生します。
.NETアセンブリはバージョンを認識できるほどスマートです（そして.NETにはさまざまなバージョンを管理するGACがあるため）は、c＃（および.NET全般）では問題ではありません。