UnsafeAccessorType loads DiagnosticSource to Default ALC breaking StartupHook isolation on .NET 10+

[alexeypukhov]

Update 04/21/2026

• UnsafeAccessorType assembly resolution bypasses extension points, breaking profiler-based and startup hook-based tooling dotnet/runtime#126933 was dismissed
• no runtime solution/workaround to adjust TPA or loading to Default ALC was suggested
• so, there is no managed options to stop DS v10+ to be loaded to Default ALC on .net 10+ when OpenTelemetry will reference DS v11+ (just clarify: when OpenTelemetry uses DS v11+ and is loaded on .net 10 runtime, and going forward - OpenTelemetry DS v12+ on .net 11 runtime and so on and so far)

-> which eventually leaves us with two workarounds:

1. Customers must adjust their dependency and explicitly reference our version of DS (during build time or maybe updating deps json)
2. Bring back AdditionalDeps/Store env vraibles setup in a form of a separate tool - script or .net app - shipped within installation packages or separately. NOTE this - as before - will only support portable application only

---

UnsafeAccessorType loads DiagnosticSource to Default ALC breaking StartupHook isolation on .NET 10+ (post PR #4783)

Summary

The UnsafeAccessorTypeAttribute (introduced in .NET 10) loads System.Diagnostics.DiagnosticSource into Default ALC during .NET runtime initialization, bypassing StartupHook isolation and causing type/state drift across ALCs.

This issue is already reproducible on .NET 10 and affects StartupHook isolation deployments on .NET 10+.

Background: StartupHook Isolation Mode

Our assembly conflict resolution approach (introduced in PR #4783), when the native profiler is not installed, uses StartupHook isolation to avoid assembly conflicts and works as follows:

• The entire customer application is loaded into a custom (isolated) AssemblyLoadContext
• The isolated context is set to be the CurrentContextualReflectionContext (via customALC.EnterContextualReflection()) to support runtime reflection redirection
• All dependencies the customer app brings go through isolated ALC overriden Load() method picking up the highest version (ours or app)
• Only assemblies that must remain in Default ALC (like System.Private.CoreLib, which loads before our StartupHook) are excluded from isolation

Goal: Maximize isolation to prevent version conflicts between customer dependencies and our agent dependencies.

The Problem: UnsafeAccessorType Bypasses Isolation

.NET 10 introduced a new JIT-level reflection mechanism via UnsafeAccessorTypeAttribute. Unlike traditional managed reflection, it performs JIT-level type resolution that sticks to the ALC context of the requesting assembly, bypassing CurrentContextualReflectionContext

Why UnsafeAccessorType breaks StartupHook isolation: When the requesting assembly is in Default ALC, the runtime try to load it to Default ALC. As a result the requesting assembly and all its dependencies may leaked to Default ALC.

General impact: Any assembly in Default ALC using UnsafeAccessorType will cause a leak to Default ALC.

Why This Is Especially Critical for OpenTelemetry

The .NET runtime uses this during initialization to access types from DiagnosticSource:

[UnsafeAccessor(UnsafeAccessorKind.StaticMethod, Name = "GetInstance")]
[return: UnsafeAccessorType("System.Diagnostics.Metrics.MetricsEventSource, System.Diagnostics.DiagnosticSource")]
static extern object GetInstance(
    [UnsafeAccessorType("System.Diagnostics.Metrics.MetricsEventSource, System.Diagnostics.DiagnosticSource")] object? _);

Source: EventSourceInitHelper in System.Private.CoreLib v10.0.0

What happens:

1. Runtime code in Default ALC (System.Private.CoreLib) uses UnsafeAccessorType to load MetricsEventSource from DS during initialization
2. CurrentContextualReflectionContext is ignored, the requesting assembly is in Default ALC and DS is found in TPA, therefore, the runtime loads DS immediately to Default ALC—our custom ALC's Load() method is not invoked
3. Later, customer code in the isolated ALC requests DS, triggering our Load() method which loads DS (same or different version) into the isolated ALC
4. Result: Two DS instances across ALCs → type drift and state drift

Why this is critical:

• DiagnosticSource is foundational to OpenTelemetry and must exist in only one ALC
• Already happening on .NET 10

Proposed Solutions

A clean technical fix is likely not possible here

Primary Solution: Exclude DiagnosticSource from Isolation

On .NET 10+, treat DiagnosticSource like System.Private.CoreLib—allow it to "leak" to Default ALC and never attempt to load it into the isolated ALC.

Open questions:

• What other assemblies must be excluded? We need to identify DS's dependency tree to ensure everything DS depends on is also available in Default ALC.
• However, when OpenTelemetry switches to DS v11, this workaround will stop working on net10.0: the applications running on .net 10 will get DS v10 loaded to default ALC automatically while OpenTelemetry will require DS v11. So we have two options after that: 1) if v11 doesn't introduce new API that the OpenTelemetry depends on, we may want to stick to DS v10 on net10.0 or 2) force customers to synchronize the DS version to satisfy Otel requirement

Alternative Workarounds

While these don't prevent the leak, they can control which version leaks to Default ALC:

1. Customer dependency alignment:
Ask customers to reference our version of DS dependency directly in their application project. This ensures the leaked version is compatible.

2. Additional Dependencies (through .NET env variables DOTNET_ADDITIONAL_DEPS and DOTNET_SHARED_STORE, framework-dependent applications only):
Use the additionalDeps mechanism to ensure our DS version is what leaks to Default ALC (rather than the customer's potentially incompatible version).

• NOTE: we may want to provide an installation script that builds the additionalDeps configuration based on our dependencies that we already ship in tracer-home folder

Assessment: Both alternatives address the same underlying reality—DS will leak to Default ALC due to UnsafeAccessor. The goal is ensuring the right version (compatible with our agent) is what leaks.

Related Issue

This issue is related to: Issue #4923 - UnsafeAccessorType breaks Native Profiler redirection. Both stem from UnsafeAccessorType bypassing our assembly conflict resolution mechanisms, but affect differently different deployment modes.

Runtime environment

• OpenTelemetry Automatic Instrumentation version: Discovered during work on PR #4783
• OS: All platforms
• .NET version: .NET 10+
• Deployment mode: StartupHook-only isolation

[nrcventura]

I think the dotnet store setting may be required as well in order to work around the problem, but I still believe that any applications with DS v10 in their bin folder will still have a problem with those workarounds. And that brings us back to the necessity of the nuget package in that scenario.

We may need to consider moving away from a startuphook only approach altogether.

[iskiselev]

I thought that we may provide few scripts with our installation:

• that build additionalDeps.json and runtime store
• that can patch customer deps.json to use proper version

I'll open .NET runtime issues to discuss if it is possible to do some workarounds on .NET side. But all this requires a lot of efforts to support startup hook-only solution - and I will support announcement that it is depricated and support will be dropped for non-compatible runtimes once we need to migrate to newer version of SDS. We may still do best efforts - have some tests and docs how it can be enabled - but it will be mostly dev-oriented option not intended for generic customers.

[alexeypukhov]

@nrcventura @iskiselev I agree-maintaining a StartupHook-only deployment model is becoming increasingly complex.

Regarding the AdditionalDeps workaround: Thanks for catching me, @nrcventura, it involves the combined use of DOTNET_ADDITIONAL_DEPS and DOTNET_SHARED_STORE. I've updated the issue description to reflect this.

Regarding the TPA list and future-proofing: While I haven't completed a full investigation into the TPA formation process yet, but I am exploring whether we can influence the TPA list on .NET 10 when we migrate to DS v11 - either via AdditionalDeps+Store (for framework-dependent applications) or by requiring a direct reference to the DS v11 NuGet package. I plan to verify the feasibility of these approaches as we move forward.

@iskiselev, your suggestion regarding the installation scripts is exactly what I had in mind too. Since we already aggregate our dependencies in tracer-home, we can provide a script that will expand tracer-home into AdditionalDeps+Store configuration automatically.

On the broader architectural challenge: I fully support the plan, and thank you, @iskiselev, for following up with the .NET runtime team. The JIT-level reflection introduced by UnsafeAccessorType is impossible to override from the managed side (even native redirection is effectively a hack). Because DiagnosticSource is an integral part of the .NET (Core+) runtime, and given that the TPA list is immutable, maintaining a single, latest copy of DiagnosticSource via our current design is becoming extremely challenging and for isolation - impossible. This highlights a fundamental tension: OpenTelemetry requires the latest version of DiagnosticSource to ensure consistency, yet the .NET runtime tightens it as an immutable, core component. Everything works fine if you just reference OpenTelemetry in your project but when we add it as part of OpenTelemetry.AutoInstrumentation everything starts to crumble. Given the ongoing discussion regarding our dependency version strategy: #4874, it might be worth starting a conversation about whether we should 1) continue trying to bridge this gap or if we should 2) align with the runtime-provided version (which, I understand, may create functional gaps on certain runtimes which we may have to accept unless .NET runtime team weighs in with some insights) or if we should 3) request managed tools in .NET Runtime to help us overcome TPA immutability or sticky JIT-level reflection.

[alexeypukhov]

As a temporary mitigation of this issue on NET 10, I have extended the list of libraries (including DS) that should be loaded into Default ALC in StartupHook isolation in PR #4783 - commit 82ad856

[Kielek]

1.15.0 -probably only documentation. Needs to be fully fixed before .NET11 support.