Clarification about hdt_load_in_memory_assembly

[matteoumili]

As stated here, int hostfxr_get_runtime_delegate(const hostfxr_handle host_context_handle, hostfxr_delegate_type type, void ** delegate); can be called with the value hdt_load_in_memory_assembly for type parameter.
But it is really unclear what kind of delegate will be returned. By the name we can assume that is some kind of function that loads an assembly from memory, but the method signature can't be found anywhere.

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

As stated here, int hostfxr_get_runtime_delegate(const hostfxr_handle host_context_handle, hostfxr_delegate_type type, void ** delegate); can be called with the value hdt_load_in_memory_assembly for type parameter.
But it is really unclear what kind of delegate will be returned. By the name we can assume that is some kind of function that loads an assembly from memory, but the method signature can't be found anywhere.

Author:	matteoumili
Assignees:	-
Labels:	area-Host
Milestone:	-

[vitek-karas]

The hdt_load_in_memory_assembly is currently only supported in IJW scenarios and is designed for that scenario alone. If you're looking for a way to use native hosting APIs to load assembly from memory, there's currently no simple way to do that.
The only workaround is to have one file-based assembly with a helper which does the loading in managed code and then you can use native hosting APIs to load that helper assembly and get a function pointer for the helper.

If you're looking for details on how IJW loading works, some of it is described here: https://github.com/dotnet/runtime/blob/main/docs/design/features/IJW-activation.md

/cc @elinor-fung

[matteoumili]

Yeah, that was exactly what I was looking for sadly :(
Sorry for the dumb question, but what does "IJW" stands for?

[vitek-karas]

Sorry - IJW is an old (and bad) term - it stands for "It Just Works" (really bad name). What it really means is CPP/CLI - it's to support loading of CPP/CLI assemblies (so code written in C++ which can be both native and managed in one assembly).

One consequence is that the hdt_load_in_memory_assembly will only work on Windows - since CPP/CLI is only supported on Windows.

[elinor-fung]

@matteoumili could you share details about your scenario and use-case? Do you basically want the equivalent of Assembly.Load(byte[]) from native hosting (that is, you have a pointer to the bytes of the assembly to load)? As @vitek-karas mentioned, we don't have a simple way to do this, so I'd like a better sense of the cases that would benefit from something like this.

[vitek-karas]

I've seen a similar request (can't find the issue now) where the scenario was basically a native app (think something like a game or similar) where it wanted to use managed code for something. But it had a hard requirement to be a single file on disk. So the idea was to carry the managed dll as embedded resource for the native host. And it would then load it - "from memory" through the hosting APIs. Unfortunately we can't do that currently, we require at least one managed dll on disk.

[agocke]

Closing for now as the question appears to be answered.