Closed vitek-karas closed 10 months ago
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas See info in area-owners.md if you want to be subscribed.
Author: | vitek-karas |
---|---|
Assignees: | - |
Labels: | `area-NativeAOT-coreclr` |
Milestone: | - |
StartupHookSupport
is not compatible with trimming or AOT. It's a feature switch which is disabled by default if eitherPublishTrimmed
orPublishAot
is enabled. If it is explicitly enabled by the user the trimmer will produce a warning:This is to maintain the promise that the app either works the same with trimming or we produce a warning.
NativeAOT doesn't produce the warning, but the app behavior will change since no startup hooks will be executed either.
The way the warning is generated in CoreCLR/trimmer is that the CoreLib's
ILLink.Descriptor.xml
contains the startup hook entry points - specifically theStartupHookProvider
APIs, which are called by the native runtime during app startup. As such the trimmer will actually include a tiny bit ofStartupHookProvider
metadata and code in every application. If startup hooks are enabled, the trimmer will include all of the implementation of that class as well, and one of those methods intentionally producesIL2026
to create the warning.NativeAOT doesn't have a similar descriptors file in its CoreLib and in fact the
StartupHookProvider
is completely removed in the final app. I think NativeAOT should either include a reference toStartupHookProvider
in its startup path or inject a small piece of code which will produce the warning during the startup path if the feature is enabled.Repro:
Add this to the project file
And then:
This should produce a warning, but it doesn't.
Note that there might be other features with similar problems (BuiltInCOM comes to mind?)