Too many duplicate xxx.runtimeconfig.json

[szilvaa-adsk]

Our application consists of many dlls several of which are "mixed mode" (C++/CLI). With .net8 we must ship a .runtimeconfig.json file for each mixed mode assembly otherwise the runtime refuses to load them. This seems unnecessary. Our application logic ensures that the runtime is already loaded by the time these assemblies are loaded.
It would be nice to have a mechanism to avoid having to ship a dozen identical .runtimeconfig.json files.

The following commit demonstrates how this could be done by modifying ijwhost.dll.
https://github.com/dotnet/runtime/compare/v8.0.0-preview.7.23375.6...szilvaa-adsk:runtime:default_runtimeconfig?expand=1

I'm happy to code-up a more industrial-strength solution after some discussion/guidance from others.

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

Issue Details

---

Our application consists of many dlls several of which are "mixed mode" (C++/CLI). With .net8 we must ship a .runtimeconfig.json file for each mixed mode assembly otherwise the runtime refuses to load them. This seems unnecessary. Our application logic ensures that the runtime is already loaded by the time these assemblies are loaded.
It would be nice to have a mechanism to avoid having to ship a dozen identical .runtimeconfig.json files.

The following commit demonstrates how this could be done by modifying ijwhost.dll.
https://github.com/dotnet/runtime/compare/v8.0.0-preview.7.23375.6...szilvaa-adsk:runtime:default_runtimeconfig?expand=1

I'm happy to code-up a more industrial-strength solution after some discussion/guidance from others.

Author:	szilvaa-adsk
Assignees:	-
Labels:	area-Host, untriaged
Milestone:	-

[vitek-karas]

@elinor-fung who probably knows the most about IJW hosting.

I think this should only be needed if the C++/CLI assemblies are loaded into the process first from native code (so they start execution in native land first). @elinor-fung would it help to "preload" them as managed assemblies first? I think it should...

[szilvaa-adsk]

Yes, this happens when the dll is loaded as "native" and then the "in memory assembly" is loaded into .net. What is unclear is why runtimeconfig.json is required once the runtime is already loaded. I can see that you may want to read it as an optional config file but a missing config file shouldn't be fatal when the runtime is already running.

[vitek-karas]

When the initial call comes from native, the assembly has to load the managed portions of itself into some runtime. That's what the ijwhost does in this case (there's a call from the native parts of the C++/CLI into ijwhost). The ijwhost is basically "new" to the process, so it has to be able to handle:

• No runtime in the process
• Existing runtime in the process

If there's no runtime in the process it will use the .runtimeconfig.json to load and start a runtime into the process - just like an application does on startup. This is the main reason the .runtimeconfig.json is produced - since the ijwhost doesn't know if it will need to start the runtime or not.

If there already is runtime it uses the framework version information from the .runtimeconfig.json to compare it against the versions already loaded. If they're not compatible it will fail. This is the other reason why it needs the .runtimeconfig.json for the native component - since it can't assume that it will be compatible with whatever is in the process already.

In both cases the core reason is that the ijwhost can't make any assumptions about the process it's being loaded into - so it has to validate.

I think this can be circumvented by preloading the C++/CLI assemblies from managed code first - in that case there's no call into ijwhost (I think) and there is definitely no management of runtimes and their versions - it's the responsibility of the app doing the assembly load to make sure it's compatible. In this case the system makes an assumption that the app knows what it's doing when loading the assembly (and it follows normal assembly loading rules).

[szilvaa-adsk]

Thanks for explaining!

In this case the system makes an assumption that the app knows what it's doing

Essentially what I'm asking is that system should make the same assumption when the runtime is already loaded and runtimeconfig.json is missing. Instead of rejecting the in-memory assembly it should simply load it into the current runtime.

[vitek-karas]

Essentially what I'm asking is that system should make the same assumption when the runtime is already loaded and runtimeconfig.json is missing. Instead of rejecting the in-memory assembly it should simply load it into the current runtime.

Hmm - that sounds reasonable. But the problem is the SDK in this case. We try to avoid adding features which don't have a corresponding story in the SDK. How would this look like in the SDK? The SDK has no way to guarantee that the produced C++/CLI assembly will be loaded into a process with already loaded runtime. And if it omits the .runtimeconfig.json and it so happens that the process doesn't have a runtime, it would break.

I'm curious what is the core "problem" here:

• The fact that the .runtimeconfig.json files are in a way unnecessary (they repeat the same information over and over again)
• The presence of the files as it increases the number of files in the app
• Some compatibility concerns (managed code will let you load the C++/CLI without runtime compatibility checks really, while ijwhost enforces them via the .runtimeconfig.json)
• Something else?

[szilvaa-adsk]

The core problem is the first 2 items. Managing these assets in our installer is busy work that we would like to avoid.

I think the SDK should always generate .runtimeconfig.json however the runtime should tolerate its absence when it reasonably can.

[vitek-karas]

@elinor-fung what do you think, basically the issue is a proposal to:
If the runtime is already loaded and runtimeconfig.json is missing, ijwhost should assume that the app knows what it's doing and load the in-memory assembly into the current runtime.

I can understand the desire to get rid of the files which are effectively unnecessary, but the runtime change doesn't feel right (we try hard to protect the system from loading the wrong runtime, or loading a component into a process with the wrong runtime).

Honestly the best solution to this problem would be to add the ability to bundle the .runtimeconfig.json into the component assembly (in this case the C++/CLI). I know we've been discussing this in the context of producing a simplified output of build (currently 4 files for helloworld, could be just 2 with bundling the config files into the exe). I also don't know if it's even possible to "bundle" anything into a C++/CLI assembly (given that it's not a pure IL PE image).

[elinor-fung]

I could see an argument for relaxing ijwhost only (not component loading in general). We've taken the track of having C++/CLI be a bit special and more permissive in the interest of a smoother .NET Framework transition (like how we load the assemblies in the default context now), so this could fall into that category.

I think bundling into the component assembly might be tricky. We currently bundle into our exe for single-file, where we have a known marker that we replace to point at the header describing the bundle - so I think the equivalent would be bundling into ijwhost and pulling the bits needed to support reading / mapping into that. And having some version of hostfxr_initialize_for_runtime_config that takes a pointer and size.

[szilvaa-adsk]

Component loading in general is already relaxed (i.e. when I load a C# assembly from disk there's no runtimeconfig.json being checked). The only time when this happens is for C++/CLI assemblies loaded from memory. It "feels like" runtimeconfig.json is overused: it should only be used to start the runtime if necessary, otherwise it should be optional.

Again, I'm happy to code this up if we reach agreement that this is the right direction.

[vitek-karas]

I could see an argument for relaxing ijwhost only (not component loading in general). We've taken the track of having C++/CLI be a bit special and more permissive in the interest of a smoother .NET Framework transition

Makes sense for ijwhost, I'm not sure we want this elsewhere.

It "feels like" runtimeconfig.json is overused: it should only be used to start the runtime if necessary, otherwise it should be optional.

For C++/CLI I think this makes sense - mainly because there's a discrepancy in "compat" behavior between loading the assembly from managed and native while the runtime is already running. That feels weird - and making this change would effectively fix that.

For other components, I don't think the same argument applies really - as they typically act more like standalone units (unlike C++/CLI assemblies). There's no equivalent of "load from managed" for the other use cases right now. COM can't do that really, and native hosting is explicitly NOT a "from managed" scenario.