Add get_coreclr_command_line which uses hostfxr_initialize_for_dotnet_command_line

[elan-slovelock]

The problem with hostfxr_initialize_for_runtime_config is that the trusted platform assemblies (TPA) will only contain that version's assemblies. If you reference a newer version of a runtime's assembly, the assembly load context will always load the runtime version not your referenced version. There is no way to intercept the loading of this TPA. When creating a dotnet application this does not occur as the runtime is loaded using the hostfxr_initialize_for_dotnet_command_line method which uses the .runtimeconfig.json and (importantly) .deps.json. You can then continue to use the runtime as if it was loaded using hostfxr_initialize_for_runtime_config.

See for details on different ways to initialize https://github.com/dotnet/runtime/blob/main/docs/design/features/native-hosting.md#initializing-host-context

[filmor]

Thank you for your contribution, I'll try to read up and review it shortly. The macos tests failing is probably due to the recent update of the Github macos-latest runners to 14, which breaks a lot of tests.

[elan-slovelock]

TestFrameworks.zip
Attached is my minimal failing example. If you run the dotnet app it all works fine. If you run the python app it fails. The reason is that the Hosting reference which is pinned to 8.0 has a reference to DiagnosticSource which it expected to be 8.0. The version in the TPA list is 6.0 due to the 6.0 framework loaded. It then fails because metrics don't exist in that version.

[filmor]

Thank you very much for this and sorry for only merging it so late. I will adjust this slightly in a separate PR to allow us to default to this eventually (making it a flag in get_coreclr instead of a separate function).