Assembly.GetCallingAssembly() needs IL2026-like warning for Native AOT (and self contained) builds

[HighPerfDotNet]

Description

I am trying to get Native AOT build working with NET 8 RC2 and run into the following situation:

Assembly.GetCallingAssembly() throws System.PlatformNotSupportedException: Operation is not supported on this platform.

Once I tracked it down to this it became apparent that this is due to self-contained file not having calling assembly per se, which is fine, but it would have been VERY helpful if compiler/linker produced IL2026-like warning that this usage will fail, right now there is none, so that took extra time to locate what was going on. IL2026 warnings are very helpful pointing out likely issues for Native AOT builds and this instance deserves to be added to the list.

It's possible there are other similar exceptions that would deserve similar warning for Native AOT or even just self-contained builds.

Reproduction Steps

// Native AOT build -

Assembly.GetCallingAssembly();

Expected behavior

I expected to see IL2026-like warning from compiler, maybe even elevated to error that needs to be actively supressed if user desires so.

Actual behavior

No warning during compile/link time.

Regression?

No

Known Workarounds

No response

Configuration

Windows 11 Pro on Intel x64 Visual Studio 2022 17.8 Preview 5

Other information

No response

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas See info in area-owners.md if you want to be subscribed.

Issue Details

---

### Description I am trying to get Native AOT build working with NET 8 RC2 and run into the following situation: Assembly.GetCallingAssembly() throws System.PlatformNotSupportedException: Operation is not supported on this platform. Once I tracked it down to this it became apparent that this is due to self-contained file not having calling assembly per se, which is fine, but it would have been VERY helpful if compiler/linker produced IL2026-like warning that this usage will fail, right now there is none, so that took extra time to locate what was going on. IL2026 warnings are very helpful pointing out likely issues for Native AOT builds and this instance deserves to be added to the list. It's possible there are other similar exceptions that would deserve similar warning for Native AOT or even just self-contained builds. ### Reproduction Steps // Native AOT build - Assembly.GetCallingAssembly(); ### Expected behavior I expected to see IL2026-like warning from compiler, maybe even elevated to error that needs to be actively supressed if user desires so. ### Actual behavior No warning during compile/link time. ### Regression? No ### Known Workarounds _No response_ ### Configuration Windows 11 Pro on Intel x64 Visual Studio 2022 17.8 Preview 5 ### Other information _No response_

Author:	HighPerfDotNet
Assignees:	-
Labels:	`untriaged`, `area-NativeAOT-coreclr`
Milestone:	-

[MichalStrehovsky]

71973 has a related discussion. We don't currently have a good way to annotate this API. We'd ideally want to obsolete this API instead and replace it with a language feature.

What is your use case? Would the language feature be a good replacement?

[HighPerfDotNet]

The use case is making it easier for the users to get Native AOT (or just self-contained) working - there are already similar warnings (IL2026) that help achieve that aim, they just need to be expanded to make it easy - I have no opinion on replacement feature, but since you've asked in my case I used it to get assembly for retrieval of embedded into file resources, something that does not seem to have easy solution for Native AOT builds as from what I can see EmbeddedFileProvider alternative also requires Assembly.

[MichalStrehovsky]

in my case I used it to get assembly for retrieval of embedded into file resources, something that does not seem to have easy solution for Native AOT builds as from what I can see EmbeddedFileProvider alternative also requires Assembly.

Assembly.GetExecutingAssembly will work, and so do things like typeof(SomeType).Assembly if that's an option. The problem is specifically in getting information about the method that called the current method (which is what GetCallingAssembly does).

[HighPerfDotNet]

Yep, that works, thank you! Is there an easy way (like defined conditional) to know during execution (or build time) if:

1) this is a self-contained file (therefore can't use GetCallingAssembly()) 2) on top of 1 this is also a Native AOT build (therefore other limitations apply)

I can of course define my own conditionals for multiple projects, but since multiple builds happen at the same time it seems rather error-prone way of doing it.

[MichalStrehovsky]

We don't have a detection API for the various deployment options (AOT, single file, ready to run, etc.). The app should ideally not have code that does different things based on these. The development experience is not optimized for this (e.g. F5 debugging the app from VS/VS Code will always run the version of code without any of these, so will unit tests, etc.). The app will be a lot harder to maintain with such conditionals. If you can avoid GetCallingAssembly on NativeAOT, avoid it everywhere.

[MichalStrehovsky]

Won't fixing this. https://github.com/dotnet/csharplang/issues/4984 needs to be implemented.