Repository navigation
[wasi][coreclr] wasihost does not pass runtimeconfig properties to the runtime #134954
Description
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:
DataSetserialization is disabled in the product and throwsNotSupportedException : DataSet implementation of IXmlSerializable is not trim compatible and has been disabled in the app configuration.PlatformDetection.DataSetXmlSerializationIsSupportedreads 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.jsonnext to the entry assembly, or consume theruntimeconfig.binthe bundle already produces. - Append each
configPropertiesentry tos_property_keys/s_property_values, letting properties the host sets itself take precedence. - Serve the same values through the
get_runtime_propertycontract 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.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsNo status
Activity
dotnet-policy-service commentedon Sep 30, 2026
Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.
[wasi] Quarantine UTF-7 tests on WASI
[wasi] Quarantine runtimeconfig switch tests on WASI
[wasi] Quarantine UTF-7 tests on WASI
[wasi] Quarantine runtimeconfig switch tests on WASI
[wasi] Quarantine UTF-7 tests on WASI
[wasi] Quarantine runtimeconfig switch tests on WASI
[wasi] Quarantine trimmed WASI R2R failures
[wasi] Quarantine UTF-7 tests on WASI
[wasi] Quarantine runtimeconfig switch tests on WASI
[wasi] Quarantine trimmed WASI R2R failures
[wasi] Quarantine remaining WASI ReadyToRun library failures
[wasi] Pass runtimeconfig properties to the runtime in wasihost (dotn…
[wasi] Quarantine UTF-7 tests on WASI
[wasi] Quarantine runtimeconfig switch tests on WASI
[wasi] Quarantine trimmed WASI R2R failures
[wasi] Quarantine remaining WASI ReadyToRun library failures
[wasi] Remove quarantines for wasihost runtimeconfig properties (#135224