[Breaking change]: Assembly.GetCallingAssembly() behavior changes for stack-trace-disabled scenarios

[MichalStrehovsky]

Description

Assembly.GetCallingAssembly() has been implemented for Native AOT in dotnet/runtime PR #129963. As part of this change:

• On Native AOT, the method now correctly returns the calling assembly (using stack trace data) rather than always throwing PlatformNotSupportedException.
• On both Native AOT and CoreCLR, the method now throws NotSupportedException when stack trace support is disabled (i.e., the StackTraceSupport feature switch is false).

Version

.NET 11 Preview 7

Previous behavior

Native AOT: Assembly.GetCallingAssembly() threw PlatformNotSupportedException
CoreCLR: Assembly.GetCallingAssembly() worked normally regardless of whether stack trace support was disabled (via the StackTraceSupport feature switch).

New behavior

Native AOT: Assembly.GetCallingAssembly() now correctly returns the calling assembly by examining the call stack.
Both Native AOT and CoreCLR: If StackTrace.IsSupported is false (for example, when the StackTraceSupport feature switch is set to false), Assembly.GetCallingAssembly() now throws NotSupportedException with the message: "Unable to retrieve stack trace information when StackTraceSupport feature switch is set to false."

Type of breaking change

• Binary incompatible: Existing binaries might encounter a breaking change in behavior, such as failure to load or execute, and if so, require recompilation.
• Source incompatible: When recompiled using the new SDK or component or to target the new runtime, existing source code might require source changes to compile successfully.
• Behavioral change: Existing binaries might behave differently at run time.

Reason for change

Assembly.GetCallingAssembly() must use stack trace data to identify the calling assembly. When stack trace support is unavailable (which can occur in trimmed or AOT-published apps that set the StackTraceSupport feature switch to false), the method cannot reliably determine the caller and now throws NotSupportedException instead of silently returning an incorrect result or a meaningless fallback value.

CoreCLR has been aligned to also throw so that the throwing behavior is also visible during debugging and developer inner loop, not just after publish.

Recommended action

If you publish with StackTraceSupport disabled and your code calls Assembly.GetCallingAssembly(), you will now receive a NotSupportedException. Either:

• Enable stack trace support (remove or set StackTraceSupport to true).
• Remove the call to Assembly.GetCallingAssembly()
• Wrap the call in a try/catch for NotSupportedException and handle it gracefully.

Feature area

Core .NET libraries

Affected APIs

• System.Reflection.Assembly.GetCallingAssembly()

---

Associated WorkItem - 592900