出于性能原因，我正在尝试将我的程序集放入GAC。它有一些绑定到AssemblyResolve事件的代码。但是，由于GAC正在组装我的程序集，因此当分辨率的来源来自我自己的GAC程序集时，不会再触发AssemblyResolve事件处理程序。
换句话说，我的GAC程序集引用了XYZ.dll。我的GAC程序集不是必须单独重新分发它，而是将XYZ.dll存储为启动时加载的嵌入式资源。程序集解析处理程序返回动态加载的XYZ.dll实例。但是，既然我的程序集是GAC，那么AssemblyResolve事件根本不会触发XYZ.dll。
我猜它与负载上下文有什么不同......但我不知道如何处理它。如果我的程序集是GAC，我如何才能解决问题呢？
答案 0 :(得分：3)
当然，这不起作用。 GAC是一个DLL Hell对策，它确保依赖于特定DLL版本的任何应用程序获得他们要求的DLL的特定版本。始终如一，无论什么过程都要求它。允许在进程的探测路径中解析GAC-ed DLL的依赖性将以最坏的方式带回DLL Hell。它完全违背了GAC提供的保证，现在可以 信任该DLL以保持一致的工作。
这也不仅仅是微妙的，一个基本上可怕的场景是在依赖程序集中定义的GAC-ed程序集中定义的派生类的基类。您希望工作的内容将允许完全不同的基类实现。如果基类没有太大的差异，那么抖动不会有任何合理的可能性。运行时的实际结果非常糟糕，错误的代码执行时很少有方法来诊断原因，尤其是对没有调试器的用户。 DLL地狱是一个用户的噩梦，最不能诊断和解决问题的人是受害者。
CLR断然拒绝让你以这种方式射击用户的脚。是的，加载上下文是关键，Fusion是潜在的api。