[wasi][coreclr] wasihost does not pass runtimeconfig properties to the runtime

[lewing]

Description

The CoreCLR WASI host (src/native/corehost/wasihost/wasihost.cpp) initializes the runtime with TRUSTED_PLATFORM_ASSEMBLIES, APP_PATHS and the host runtime contract, but never reads the app's runtime configuration. None of the configProperties from <app>.runtimeconfig.json reach AppContext: feature switches, RuntimeHostConfigurationOption items, globalization settings and so on.

The bundle already carries the configuration: WasiAppBuilder writes <app>.runtimeconfig.json, and the WASI targets produce runtimeconfig.bin with RuntimeConfigParserTask. On Mono, that file is registered with mono_register_runtimeconfig_bin; nothing consumes it for CoreCLR. The browser host passes the runtime configuration properties to the runtime, and hostpolicy does the same on desktop platforms.

Impact

Anything that reads its setting through AppContext at runtime sees the default instead of the configured value. This is most visible with trimming. ILLink bakes feature switch values into the product assemblies, but code that checks the switch at runtime, such as test conditions, sees the switch as missing and falls back to its default.

For example, the ILLink targets default System.Data.DataSet.XmlSerializationIsSupported to false when trimming:

• DataSet serialization is disabled in the product and throws NotSupportedException : DataSet implementation of IXmlSerializable is not trim compatible and has been disabled in the app configuration.
• PlatformDetection.DataSetXmlSerializationIsSupported reads the missing switch as true, so the tests guarded by it run instead of skipping.

In trimmed ReadyToRun runs of the CoreCLR WASI library tests on #134813, this accounts for about 360 failures in System.Data.Common.Tests. Browser's trimmed CoreCLR ReadyToRun lane runs the same suite with 0 failures because it skips those tests. DefaultValueAttribute failures (Runtime instantiation of this attribute is not allowed.) in System.Runtime.Tests and System.ComponentModel.TypeConverter.Tests are likely the same cause.

Proposed fix

In wasihost, read the app's runtime configuration and pass its properties to coreclr_initialize along with the existing host properties:

• Locate <entry assembly name>.runtimeconfig.json next to the entry assembly, or consume the runtimeconfig.bin the bundle already produces.
• Append each configProperties entry to s_property_keys/s_property_values, letting properties the host sets itself take precedence.
• Serve the same values through the get_runtime_property contract callback, which already reads from those vectors.

runtimeconfig.bin avoids a JSON parser in the host and matches what Mono consumes. Reading the JSON avoids depending on a Mono-specific artifact. Either works as long as the values match what the SDK wrote.

Note

This issue was drafted with the help of GitHub Copilot.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.