Update host logic to support optional VM assembly

[marek-safar]

For desktop scenarios on architectures where CoreCLR is not supported we need to use MonoVM as supported runtime. Today the host hardcodes libcoreclr name as the only one to look for which makes this problematic because MonoVM capabilities and internals are different.

This should unblock issues like #34202.

/cc @steveisok

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

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

Issue Details

---

For desktop scenarios on architectures where CoreCLR is not supported we need to use MonoVM as supported runtime. Today the host hardcodes libcoreclr name as the only one to look for which makes this problematic because MonoVM capabilities and internals are different.

This should unblock issues like #34202.

/cc @steveisok

Author:	marek-safar
Assignees:	-
Labels:	area-Host, untriaged
Milestone:	-

[vitek-karas]

Are we going to use the same ABI as coreclr.dll has, or is the plan to use different one for mono?
There's also the question of where this needs to "ship". All this logic lives in hostpolicy which ships next to coreclr.dll. My understanding is that all mono scenarios are self-contained (we don't ship shared frameworks with mono VM in it). That means there's no way for one hostpolicy dll to have to deal with both CoreCLR and MonoVM. So we could just build slightly different version of hostpolicy for the mono runtime packs - and that can use whatever ABI is needed (and also look for different name of the file).

It's is also possible to build the one hostpolicy which can handle both, but as far as I can tell there's no need for this (unless it helps us with packaging shipping - which might be the case).

[marek-safar]

ABI would be the same as for coreclr and this is for shared framework scenarios where CoreCLR is not supported like s390x

[vitek-karas]

I see - do we need to case where on one machine I have shared frameworks with both CoreCLR and MonoVM? (I hope not, otherwise framework resolution will become more complex than it already is).

[marek-safar]

do we need to case where on one machine I have shared frameworks with both CoreCLR and MonoVM?

No, the simple case should be enough at least for now (although it would help with development/testing)

[vitek-karas]

In that case we can build a different version of hostpolicy for these "mono" platforms.
/cc @VSadov - as this might affect the work to move hosting components from the installer subtree to some other place

[akoeplinger]

I think we need some kind of runtime switch for choosing between mono/coreclr on the standard platforms too if we want to really unblock #34202 since right now we need to rename libmono to libcoreclr in the testhost for libraries testing.

[steveisok]

It would be nice if we could have something like --vm mono as a runtime option and be able to switch between coreclr / mono in the same install. Assuming we have different names between libmono and libcoreclr, I think we would just have to put each runtime's System.Private.CoreLib in a separate directory. Not sure how easy that would be.

[vitek-karas]

@steveisok this has been discussed in the past. It's definitely possible, but it's a rather large change as it would require changes to runtime packs, SDK, installers, ... There's also the question of breaking apps due to files lying in a different locations on disk (the typically typeof(object).Assembly.Location would now point to a subdirectory) and so on.

If we were to support installing both CoreCLR and MonoVM shared frameworks on the same machine, then the best solution would be to include some differentiator elsewhere. The problem is that currently the system doesn't have a place to do this - adding another level of directories will probably break too many things if we do this. And it still impacts pretty all parts of the toolchain.

If this would be only for development/test purposed, then I think the easiest way would be to simply create a new installation in a different location and rely on DOTNET_ROOT. This is already done in many places to handle different versions and such, and so it has broad support across our tooling. The downside is size on disk - it would have to be a full install of at least the runtime (so all libraries + runtime).

[akoeplinger]

If this would be only for development/test purposed, then I think the easiest way would be to simply create a new installation in a different location and rely on DOTNET_ROOT

We'd still need some switch to tell the host to look for libmono instead. Or we could probe for libcoreclr and fallback to libmono if it doesn't exist? For architectures like s390x the libcoreclr check could be ifdefed out.

[vitek-karas]

I think it's perfectly OK to accept more than one name for the runtime itself - so the fallback logic could definitely work. There will be another small gotcha - currently the host requires coreclr.dll to be listed in .deps.json - so to produce a valid MonoVM based framework it would now have to use the mono.dll in the .deps.json instead. It's definitely the cleaner way.

Just so that this is actually actionable - some clarifications:

• What is the name of the mono runtime library we want the host to recognize? mono (plus all the required platform prefixes and suffixes).
• Do we need any changes to the ABI through which hostpolicy communicates with the runtime library? (coreclr_initialize and so on)

[jkotas]

What would be in the .deps.json that the build produces?

I like the idea of building two different hostpolicy .dlls and having either coreclr-based shared runtime or mono-based shared runtime (but not both) much better.