coreclr hosting in unamanged app via hostfxr and problems with AssemblyLoadContext

[podprad]

Hello,

In my scenario I have:

• Unmanaged, legacy application MyUnmanaged.exe
• Managed .NET Framework MyManaged.dll

MyManaged.dll uses DllExport/.export technique for exposing methods for unmanaged application.

This works like this:

    // somewhere in MyManaged.exe
    auto hManaged = LoadLibrary("MyManaged.dll");
    auto myExportedProc = GetProcAddress(hManaged, "MyExportedProcedure")
    myExportedProc();

After calling myExportedProc the shim locates .NET Framework, initializes clr, does some replacements in export code (JMPs of "MyExportedProcedure" are replaced with JMP to clr code).
Anyway, it works for me for ages.

Now I'm trying to switch to .NET 6.

I compiled MyManaged.dll for .NET 6 with DllExport/.export.
I used DllExport library from nuget.

Additionally I had to create new MyManaged.Host.DLL that will start and initialize coreclr.

I did that by using hostfxr.

 // Somewhere in MyManaged.Host.DLL / DllMain:
 
 SetEnvironmentVariable(L"COREHOST_TRACE", L"1");
 SetEnvironmentVariable(L"COREHOST_TRACE_VERBOSITY", L"4");
	
 // ... 
 
  hostfxr_handle ctx;
    error = hostfxr_initialize_for_runtime_config(configPath.c_str(), NULL, &ctx);
    if (error != 0)
    {
        printf("hostfxr_initialize_for_runtime_config failed with code %X08\r\n", error);
        return -1;
    }
	
 // ...
 
 error = load_assembly_and_get_function_pointer_fun(
        dotnetDllPath.c_str(),
        dotnetTypeName,
        dotnetMethodName,
        nullptr /*delegate_type_name*/,
        nullptr,
        (void**)&dotnetMethod);
		
  // ... error checking etc.
  
  dotnetMethod(nullptr, 0);

    // somewhere in MyManaged.exe
	
	// Start dotnet host library first by calling MyManaged.Host.DLL / DllMain
	auto hManagedHost = LoadLibrary("MyManaged.Host.DLL");
	
	// Old stuff:
    auto hManaged = LoadLibrary("MyManaged.dll");
    auto myExportedProc = GetProcAddress(hManaged, "MyExportedProcedure")
    myExportedProc();

In general, it works.

I had to do additional stuff like:

// Set the base directory to initialize AppDomain.Current.BaseDirectory correctly
hostfxr_set_runtime_property_value(ctx, L"APP_CONTEXT_BASE_DIRECTORY", L"path\\to\\application");

The problem I have is AssemblyLoadContext.

The code below loads MyManaged.dll and referenced assemblies in isolated AssemblyLoadContext.

 error = load_assembly_and_get_function_pointer_fun(
        dotnetDllPath.c_str(),
        dotnetTypeName,
        dotnetMethodName,
        nullptr /*delegate_type_name*/,
        nullptr,
        (void**)&dotnetMethod);	
  
  dotnetMethod(nullptr, 0);

Afterwards I call:

auto hManaged = LoadLibrary("MyManaged.dll");
    auto myExportedProc = GetProcAddress(hManaged, "MyExportedProcedure")
    myExportedProc();

MyExportedProcedure loads other assemblies located in bin directory and they are loaded in Default AssemblyLoadContext.

This way I'm getting some of my assemblies loaded twice, which finally leads to errors.

Is it possible to force all my dotnet assemblies to be loaded in the same AssemblyLoadContext?

I suppose that I cannot use load_assembly_and_get_function_pointer_fun, because it isolates the requested assembly by default.

I tried to bypass load_assembly_and_get_function_pointer_fun step, however then I'm getting exception when calling myExportedProc().

Should I try to speak with coreclr.dll directly? I see that it has few useful exports:

MetaDataGetDispenser
coreclr_execute_assembly
coreclr_initialize
coreclr_shutdown_2
GetCLRRuntimeHost
coreclr_create_delegate
coreclr_shutdown
g_CLREngineMetrics
CLRJitAttachState

Here is my playground source code:
https://github.com/podprad/misc_public/tree/main/playgrounds/csharp/Net6Hosting

Update
I made it working by using coreclr.dll directly.

Best regards,
Michal

[vitek-karas]

https://github.com/dotnet/runtime/blob/main/docs/design/features/native-hosting.md#calling-managed-function-net-5-and-above

Basically the recommendation is to use hostfxr_initialize_for_dotnet_command_line (which should fix the app base issue as well I think) and then use the get_function_pointer to get a pointer to the managed code - the default load context.

We currently don't have functionality which would allow loading assemblies into the default load context via the hosting APIs (other than CPP/CLI which does this).

/cc @elinor-fung