search

pythonnet / clr-loader

Loader for different .NET runtimes
MIT License
32 stars 23 forks source link

Add get_coreclr_command_line which uses hostfxr_initialize_for_dotnet_command_line #66

Open elan-slovelock opened 6 months ago

elan-slovelock commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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.