How to locate coreclr.dll from hostfxr_initialize_for_runtime_config (original) (raw)

TL;DR What's the correct way to locate coreclr.dll using the results of a successful call to hostfxr_initialize_for_runtime_config?

I am writing a custom .NET Core host for wixtoolset/issues#6108. The use case here is that the main application (the Burn engine, or burn.exe) is a native application that loads basically another application (the Bootstrapper Application, or BA) from a DLL. Both Burn and the BA run on their own threads and communicate with each other to get the job done. So my custom host needs to load the .NET Core runtime, instantiate the managed code BA (from a user provided DLL), and return essentially a handle to that managed BA to the native engine. This was implemented long ago for the full .NET Framework here.

Since I need to load the managed code as a component, I started with hostfxr_initialize_for_runtime_config with an self-contained deployment (SCD) style test project. I quickly learned, however, that hostfxr_initialize_for_runtime_config doesn't support a .runtimeconfig.json for SCD. (Why does my custom host need to know whether the target was deployed by the SCD or FDD (framework-dependent deployment) style?) I eventually got SCD working by not using the nethost/hostfxr/hostpolicy layer.

So I came back to hostfxr_initialize_for_runtime_config for testing FDD style projects, since I need the logic of finding the appropriate framework based on the requirements of the target managed application. The initialization worked great, but I had trouble with load_assembly_and_get_function_pointer. (Why do the type and delegate parameters require an assembly qualification, when I'm required to provide the assembly path as a parameter to the same function?)

After working that out, I successfully got to the managed side of this custom host. But I ran into some issues trying to load the target managed DLL. The original code was using AppDomain.Current.Load, which returned E_FILE_NOT_FOUND. (AppDomain.Current.Load was working perfectly when I loaded the framework directly through coreclr for the SCD workflow, why would it behave differently through hostfxr_initialize_for_runtime_config?) Then I switched to Assembly.Load and eventually started setting the APP_PATHS runtime property with the target directory. I don't remember which combinations produced which errors, but sometimes a dependent assembly wasn't getting loaded and sometimes that dependent assembly was getting loaded twice. (Are AppDomain.Current.Load and Assembly.Load supposed to work differently? )

Because of those managed assembly load issues with hostfxr_initialize_for_runtime_config, and plus the SCD workflow can't use it either, I want to use coreclr directly in both scenarios. But I still need hostfxr_initialize_for_runtime_config in the FDD workflow so that it can tell me which coreclr.dll to load. What is the correct way to do that? I have called hostfxr_get_runtime_properties and there are multiple properties that I could use to guess where coreclr.dll is. For instance, go through the TPAs and get the parent directory of a certain DLL (but which DLL?). Or get the parent directory of JIT_PATH (is this always going to be available in future versions?). Or use the directories in NATIVE_DLL_SEARCH_DIRECTORIES (it includes C:\ which seems weird to me).