Home/ Questions/Q 7559503
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-30T12:39:19+00:00

I’m trying to put my assembly in the GAC for performance reasons. It has

  • 0

I’m trying to put my assembly in the GAC for performance reasons. It has some code that binds to the AssemblyResolve event. However, since GAC’ing my assembly, the AssemblyResolve event handler is no longer hit when the source of the resolution is coming from my own GAC’d assembly.

In other words, my GAC’d assembly has a reference to XYZ.dll. Instead of having to redistribute it separately, my GAC’d assembly has XYZ.dll stored as an embedded resource that is loaded on startup. The assembly resolution handler returns the dynamically loaded instance of XYZ.dll. However, now that my assembly is GAC’d the AssemblyResolve event doesn’t fire for XYZ.dll at all.

I’m guessing it has to do with the load context being different…but I’m not sure how to deal with it. How can I get resolution to work now that my assembly is GAC’d?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Sure, this doesn’t work. The GAC is a DLL Hell counter-measure, it ensures that any app that relies on a specific version of a DLL gets the specific version of the DLL they asked for. Consistently, no matter what process asked for it. Allowing the dependencies of the GAC-ed DLL to be resolved in the probing path of the process would bring back DLL Hell in the worst possible way. It completely defeats the guarantee that the GAC provides, the DLL can now not be trusted to work consistently.

    This is not just subtle either, a basically scary scenario is where the base class of a derived class that’s defined in an assembly that’s GAC-ed is defined in a dependent assembly. What you hope to work will allow a completely different base class implementation. There are reasonable odds that the jitter won’t fall over if the base class isn’t too different. The actual outcome at runtime is quite miserable, the wrong code executes with few ways to diagnose why, especially to a user without a debugger. DLL Hell is a user nightmare, the person least capable of diagnosing and fixing the problem is the victim.

    The CLR categorically refuses to let you shoot the user’s foot this way. Yes, loading context is the key, Fusion is the underlying api.

    • 0