AssemblyLoadContext.Resolving event doesn't expose ResolveEventArgs.RequestingAssembly

[AArnott]

On .NET Framework the AppDomain.AssemblyResolve event offered the ResolveEventArgs.RequestingAssembly so that the resolver can consider the party requesting the assembly to help determine what assembly to load. In particular this would be useful to help find the assembly to be loaded by looking in the same directory as the requesting assembly. This in fact is the behavior of .NET Framework itself, which even without a custom resolver will load assemblies based on codebase path, base directory, probing paths, and the directory containing the requesting assembly.

On .NET Core I'm trying to emulate .NET Framework assembly loading behavior. I have implemented an AssemblyLoadContext.Resolving handler that considers the content of an .exe.config file including probing directories, codebase paths, binding redirects, etc. But I'm getting assembly load failures in cases where a .dll was only found on .NET Framework because the dll was in the same directory as the dll that requested it.

Because the ALC.Resolving event doesn't disclose who the requesting assembly is, I can't emulate .NET Framework behavior here. Why was this information left out of the new event? Presumably if I hooked the AppDomain.AssemblyResolve even on .NET Core I guess I'd still get the data, but I'm trying to use ALC APIs exclusively so that it works in any ALC instead of only the default one as using the AppDomain APIs would presumably limit me to.

[vitek-karas]

While I definitely agree with the intent, the event doesn't use event args, so I don't see a good way of extending it. I can think of a couple of really weird solutions - like have a thread local static exposed which would pass the additional information to the event handler - but that's a nasty looking API.
We could expose a new event - kind of messes up the clean API look - but it would work.

That said the AppDomain.AssemblyResolve will be called for any failed resolution attempt from any ALC. And you can basically get the ALC which asked for it by asking for the ALC of the requesting assembly. The only difference is when things happen, but only slightly.

[AArnott]

Thanks for looking. And yes, I agree the existing event's signature is unfortunately not something that can simply add a member to. :(

Your AppDomain approach is interesting, however it wouldn't work for us because after we add our own AssemblyLoadContext.Resolving handler, we add one more that throws in order to block any other handlers from ever firing since we don't want 3rd parties running in the process to customize the behavior of the default ALC. As a result, the default ALC doesn't actually failover to the AppDomain.AssemblyResolve event.

[jkotas]

FWIW, the motivation for this design was that you are not supposed to use the exact referencing assembly to resolve the dependency. The dependency should be resolved to the same assembly independent of where it is coming from.

[AArnott]

I suspected as much. And for that reason I actually think the change is good. The tendency for the .NET Framework to load assemblies based on the location of the requesting assembly leads to non-deterministic behavior in our application. So I support your goal.

It just means it's a breaking change in our app when we move from netfx to netcore, so I wanted to explore options.

[mayorovp]

@AArnott try lo load every assembly in a separate ALC (or use ALC per folder)

[AArnott]

@mayorovp That is actually one of the goals I have, but I don't understand how that relates to or solves the problem in this issue. Can you elaborate?

[AArnott]

Oh! I see. The ALC instance can come pre-programmed to know which extra folder to search for matches. :)

Yes, that should do it. Thanks.