I am having an issue where Assembly.Load fails,
even after installing a signed assembly to the GAC via the fusion.dll
API.

I have supplied a link to the simple test harness that reproduces the
issue.

I use the AssemblyResolve event to determine what assemblies are
missing and
so are needed to be remotely
downloaded to the local machine and installed into the GAC.
After an initial Assembly.Load call the AssemblyResolve event is fired
as expected.
In the event handler, the assembly is installed fine via the
fusion.dll API, however when the assembly
is attempted to be loaded from the GAC via Assembly.Load, the call
will cause the
AssemblyResolve to fire again, and again, and again.. etc. infinite
loop.
If I where to exit the app and start it again the firs call to
Assembly.Load is succesful as is
expected since it in the GAC. I would not expect the before mentioned
inifinite loop of
AssemblyResolve events, since I would think the CLR would find it once
in the GAC.

It seems the CLR perhaps has already probed for the dll in the initial
Assembly.Load call. So whether it found it or not the CLR has finished
probing and will not look in the GAC for the newly installed assembly
until I restart the app which causes the CLR to probe again for the
assembly.

Is there a way to have the CLR probe again without restarting the app?

Here is the link to the simple test harness that reproduces the issue.
http://oxygenaddicts.com/code/GACTest.zip

Any help on this issue is greatly appreciated.

Thanks

Show quote Hide quote Yes, I've seen that happen as well.  It's a good thing.

Why?  Why not Assembly.LoadFrom or Assembly.LoadFile the dll after placing
it into the GAC, and then return that Assembly instance from
AssemblyResolve?  That's what I do (well actually I don't use the GAC, but I
do load from a private plugins directory) and it works well enough.

Show quoteHide quote

Strange server socket behaviour
app.config and user.config files
Encoding to ISO-8859-1 problems
.NET property names and translation
.NET to x86