Why does core_create_delegate appear to only support on-disk assemblies? Can this be changed?

[RoryBecker]

Hey everyone.
First time post on this project, so please forgive any indiscressions as I'm not sure on protocol.

My scenario
I am trying to host the CLR in a cpp application I'm writing.
My application uses coreclr_create_delegate (successfully) to locate a method in my C# assembly.
In my case, FoundMethod is called, , passing some C# script text I have loaded from disk.
FoundMethod uses calls to CSharpCompilation.Create (and Emit) to create a memory stream of an assembly which I then load into memory using Assembly.Load.

I then attempt to call coreclr_create_delegate once again in order to reference the methods in the loaded ScriptAssembly.
However this does not work and a code of 0x80070002 is returned.

A bunch of searching suggests this is a 'file not found' code.

So I decided to go look around the source of CLRCore, hoping to understand enough to confirm what was happening.

So I am loading Coreclr.dll and getting a reference to coreclr_create_delegate via a GetProcAddress method.

This would appear to get me to

runtime/src/coreclr/dlls/mscoree/exports.cpp

Line 428 in 37445d4

int coreclr_create_delegate(

From here I need to find an implementation of CreateDelegate
I have surmized that this is the corrrect implementation ->

runtime/src/coreclr/vm/corhost.cpp

Line 672 in 37445d4

HRESULT CorHost2::CreateDelegate(

With reference to the following code...
https://github.com/dotnet/runtime/blob/37445d4964a50eeff87ca7ed8cbdf251b547b779/src/coreclr/vm/corhost.cpp#L720C9-L726C30

If I'm reading the code correctly, it would seem that there is an assumption here, that the assembly being targetted must be on disk and not already in memory.

So a few questions...

Am I remotely in the right location? ie. have I correctly traced the path of the code?

Am I correct that the code can currently only operate against assemblies which are on disk (ie within dll files)?

Is there any reason why this should not be changed? Any tips?

Is there some other way around my predicament.

Many thanks for any help.

[jkotas]

Am I remotely in the right location? ie. have I correctly traced the path of the code?

Yes, it is the correct location.

Am I correct that the code can currently only operate against assemblies which are on disk (ie within dll files)?

I do not think you are correct. This coreclr_create_delegate takes assembly name. It does not take a file path. The assembly name should not need to be on disk.

[RoryBecker]

Whilst I agree with your logic, things do not appear to function as you suggest.

If I have my code save the MemoryStream out to an assembly in the main folder immediately prior to attempting to get a reference to it, everything works.

If I delete the assembly, everything breaks again.

It would certainly appear as if the code requires the assembly to be on disk.

Saving the rendered assembly, is actually proving to be a useful work around for now, but I would really prefer not to have to do this.

[jkotas]

create a memory stream of an assembly which I then load into memory using Assembly.Load.

coreclr_create_delegate expects the assembly to be loaded in the default load context. Assembly.Load(byte[]) loads the assembly into its own load context. It explains why coreclr_create_delegate does not see it.

Try loading the in-memory assembly using AssemblyLoadContext.LoadFromStream method instead. It is going to load it explicitly into the default load context and make it visible to coreclr_create_delegate.

[huoyaoyuan]

Assembly.Load(byte[]) loads the assembly into its own load context.

Try loading the in-memory assembly using AssemblyLoadContext.LoadFromStream method instead.

This difference is interesting and counter-institutive to me. Users may not be even aware of them. I didn't even mention it when writing the binder change.
Should we provide overloads to specify which ALC to load?

[jkotas]

Assembly.Load(byte[]) and Assembly.LoadFrom APIs exist for compatibility with .NET Framework. They come with number of non-intuitive behaviors for compatibility.

AssemblyLoadContext is where all APIs that give you full control over dynamic assembly loading live in modern .NET.

[huoyaoyuan]

AssemblyLoadContext is where all APIs that give you full control over dynamic assembly loading live in modern .NET.

Well I didn't notice the class difference. That's fair.

[RoryBecker]

create a memory stream of an assembly which I then load into memory using Assembly.Load.

coreclr_create_delegate expects the assembly to be loaded in the default load context. Assembly.Load(byte[]) loads the assembly into its own load context. It explains why coreclr_create_delegate does not see it.

Try loading the in-memory assembly using AssemblyLoadContext.LoadFromStream method instead. It is going to load it explicitly into the default load context and make it visible to coreclr_create_delegate.

Worked like a charm. Thankyou so very much @jkotas.

Not only an accurate answer, but with good background info also.
I will now spend some time reading up on AsemblyLoadContext for additional contextual information.