runtime: Mono does not implement coreclr_create_delegate hosting API or ComponentActivator

@lambdageek I don’t fully understand why all these steps are needed in this case.

@AaronRobinsonMSFT My assumption is: we want to run the dll import generator tests on Android,ios and wasm, not just on Linux & mac desktops with Mono instead of CoreCLR as the underlying runtime.

If we only want to run on desktops then (4) is sufficient.

Is it because of mono’s hosting semantics?

I’d say it’s the hosting model, rather than something specific to mono. There’s no nethost, hostfxr or hostpolicy on mobile and any code that depends on them will not work.

I was assuming we could treat DNNE generated native libraries as if they were any other native binary – P/Invoke into them and be none the wiser?

The DNNE generated native libraries are probably ok (assuming we compile them with the right toolchain). But they depend on nethost, hostfxr and hostpolicy, right? So the functions that platform.c depends on get_hostfxr_path, hostfxr_get_runtime_delegate etc are not present on mobile.

We haven’t tried the desktop versions of hostfxr and hostpolicy on mobile - I have no idea how much work is required to get them working. (If I had to guess… Android and iOS Simulator are probably not too much work - they may even just work if we start building them and bundling them into the tests; iOS device and WebAssembly probably require moderate to significant changes since they’re static linking platforms).

My guess is that the most straightforward way would be to build a mobile hostfxr library that exports the symbols that DNNE needs but implements them by directly calling the coreclr_ functions in the current process (ie there’s no hostpolicy layer, and the implementation assumes the runtime is already loaded in the current process). Then the only other change needed is platform.c would need to skip get_hostfxr_path and get the symbols from RTLD_DEFAULT.

With #60200, the DllImportGenerator.Tests suite passes for me on desktop (macOS) MonoVM with both the JIT or the interpreter.

What is the usecase?

Mainly non-production/xamarin; I was coming from:

• to be able to run dotnet(1) in terminal emulator on Android (with either mono/coreclr flavors); and consume other dotnet-new templates like console / libs / benchmarkdotnet etc.
  • e.g. last year, we were able to build coreclr+libs+corehost to run simple applications. but since mono.Android configs are different, it’s currently missing from corehost.
• (in addition to the existing deploy-tests-as-app) be able to (also) execute src/tests with real corehost on mobile.

all of the logic of “find the right runtime to run this managed code” is already mostly irrelevant in self-contained desktop scenarios

Yup, there are still some implementation details even in self-contained e.g. how it uses user configuration json files, finds the hook in (coreclr) runtime and exports symbols for sos/diagnostics etc. I think making the same (familiar) hosts work on various platforms will open avenues for broader scenarios.

@jkoritzinsky thanks I’ll take a look.

Best guess so far is that ComponentActivator.InternalGetFunctionPointer isn’t doing the right thing on Mono - either wrapping a managed method too many times or not enough times. I suspect we’re missing a check for UnmanagedCallersOnly somewhere on the native side in mono for methodInfo.MethodHandle.GetFunctionPointer(). Probably won’t be a difficult fix once I find where the problem is.

+1 for corehost support on mobile (simulators for the starters). and +2 for a true static linking support (e.g. $ file singlefilehost_static to return ... statically linked, with debug_info, not stripped) 🙂