[maccatalyst] `System.Diagnostics.TraceSource.Config.Tests` fails with `ClientConfigurationHost` `MissingMethodException`

[vitek-karas]

Related runtime issues: #126460, #74244, #49062
Suggested labels: Known Build Error, test-failure, os-maccatalyst, arch-x64, arch-arm64, area-System.Diagnostics.TraceSource, area-System.Configuration, untriaged

Build Information

Build: 20260404.2, 20260405.1, 20260406.2
Build error leg or test failing: System.Diagnostics.TraceSourceConfigTests.ConfigurationTests.ConfigWithEvents_RuntimeListener, System.Diagnostics.TraceSourceConfigTests.ConfigurationTests.Refresh_ChangeSwitch, System.Diagnostics.TraceSourceConfigTests.ConfigurationTests.Refresh_RemoveSource, System.Diagnostics.TraceSourceConfigTests.ConfigurationTests.RuntimeFilterChange, System.Diagnostics.TraceSourceConfigTests.ConfigurationTests.UnsupportedAttribute_Throws, System.Diagnostics.TraceSourceConfigTests.ConfigurationTests.AllTypes, System.Diagnostics.TraceSourceConfigTests.ConfigurationTests.Refresh_RemoveSwitch, System.Diagnostics.TraceSourceConfigTests.ConfigurationTests.Switch_MissingValue_Throws, System.Diagnostics.TraceSource.Config.Tests.WorkItemExecution
Affected CI jobs: build_maccatalyst_x64_Release_AllSubsets_CoreCLR, build_maccatalyst_arm64_Release_AllSubsets_CoreCLR

Error Message

Fill the error message using step by step known issues guidance.

{
  "ErrorMessage": "System.MissingMethodException : Cannot dynamically create an instance of type 'System.Configuration.ClientConfigurationHost'. Reason: No parameterless constructor defined.",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Summary

System.Diagnostics.TraceSource.Config.Tests is failing consistently on MacCatalyst CoreCLR Release after the full MacCatalyst CoreCLR library legs were enabled in dotnet/runtime#125441. The generic XHarness bucket text mentions Process log exited with 137, but the uploaded testResults.xml and app log show the real failure is deterministic and test-specific:

System.MissingMethodException : Cannot dynamically create an instance of type 'System.Configuration.ClientConfigurationHost'. Reason: No parameterless constructor defined.
   at System.Configuration.ConfigurationManager.OpenExeConfigurationImpl(...)
   at System.Diagnostics.TraceSourceConfigTests.ConfigurationTests.CreateAndLoadConfigFile(String filename)

Observed behavior:

• All 8 tests in System.Diagnostics.TraceSourceConfigTests.ConfigurationTests fail in ~1 second on both maccatalyst-x64 and maccatalyst-arm64.
• Every failing test goes through CreateAndLoadConfigFile() in src/libraries/System.Diagnostics.TraceSource/tests/System.Diagnostics.TraceSource.Config.Tests/TraceSourceWithConfigurationTests.cs.
• The Apple test app is built through ProxyProjectForAOTOnHelix.proj with TrimMode = link (confirmed from the uploaded AOTBuild.binlog), which matches the known trim incompatibility of System.Configuration.ConfigurationManager described in #49062.
• These tests are already excluded on tvOS, iOS, and Android via #74244, but MacCatalyst is not currently included in that ActiveIssue.

Mono comparison

I checked the actual uploaded xUnit testResults.xml for the Mono MacCatalyst work items in build 20260406.2, not just the parent job status:

• maccatalyst-arm64 Release AllSubsets_Mono → Helix job ee05f111-cc24-47d1-8366-98c250455730
• maccatalyst-x64 Release AllSubsets_Mono → Helix job ed8d84e6-59a6-46f2-8a43-2f400f24c10a

For both Mono runs, System.Diagnostics.TraceSource.Config.Tests reports:

• total="8" passed="8" failed="0" skipped="0"
• all 8 ConfigurationTests.* cases executed and passed

I also spot-checked the previous build 20260405.1; the same work item passed there on both Mono MacCatalyst queues as well. So this is not a case where Mono is silently skipping the test assembly: the tests genuinely run and pass on Mono, and the problem appears specific to the CoreCLR MacCatalyst configuration.

Likely causative commit

The most likely commit that introduced this failure into CI is:

• 0a726991ba — dotnet/runtime#125441, "Reduce Apple mobile CI matrix" (merged 2026-04-02)

Why this is the strongest candidate:

• The PR changed eng/pipelines/extra-platforms/runtime-extra-platforms-maccatalyst.yml to add the new full maccatalyst-{x64,arm64} Release AllSubsets_CoreCLR library-test legs.
• Those new CoreCLR library jobs build test apps with:
  • /p:UseMonoRuntime=false
  • /p:UseNativeAOTRuntime=false
  • /p:UsePortableRuntimePack=false
  • /p:EnableAggressiveTrimming=true
• In builds before that change (for example 20260401.5 / build 1363261 and 20260331.6 / build 1361338), the MacCatalyst CoreCLR coverage was limited to maccatalyst-arm64 Release AllSubsets_CoreCLR_Smoke plus runtime-test legs; the new full library-test job where System.Diagnostics.TraceSource.Config.Tests now fails did not exist yet.

I do not see evidence of a recent behavior-changing product commit in the relevant libraries:

• TraceSourceWithConfigurationTests.cs was last changed substantively in older PRs such as #73087 and Android/mobile test annotation updates, not in the April 2026 regression window.
• ClientConfigurationHost.cs has no recent behavioral change; the only 2026 entry in file history is a mechanical volatile cleanup.

So the best read is:

1. Exposure commit: 0a726991ba / #125441 made these tests run in a new MacCatalyst CoreCLR + aggressive trimming configuration.
2. Underlying product issue: older System.Configuration.ConfigurationManager trim incompatibility already known from #49062.

This looks like a newly exposed mobile/trim incompatibility rather than a fresh product regression in System.Diagnostics.TraceSource. A practical next step is to extend the existing mobile skip for System.Diagnostics.TraceSource.Config.Tests to include MacCatalyst, unless there is interest in making this ConfigurationManager scenario work in trimmed Apple test apps.

Note

This issue was filed with the assistance of GitHub Copilot.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-configuration
See info in area-owners.md if you want to be subscribed.