You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Handling of startup hooks in linked applications #36526
The startup hook feature is inherently linker unfriendly as it loads "random" assemblies and executes code in them. As such using it on applications which are trimmed by the linker is problematic and likely to break the app or the startup hook.
This issue is to determine if there's some technical solution we can implement to make this more predictable experience.
Linker will also mark the implementation code in CoreLib as unfriendly and this will need some changes (either suppression, feature switch or something else):
Potentially related feature might be marking assemblies which were linked per dotnet/linker#1194 as that could be used to detect linked apps by the customers.
I think startup hooks should be behind a feature switch as that is the only reliable solution to this - trimmed apps can't use startup hooks to their full potential.
For some specific cases, where the startup hook assembly is known before hand (for example since it's part of the target environment - hosting provider telemetry, ...) it might be possible to make this work by:
Enable the feature switch
Add the startup hook assembly to the input to the linker so that it can keep around its dependencies
Suppress the linker warnings generated by the startup hook implementation
That said we should not proactively implement a solution until we know of at least a couple use cases so that we have some real-world usage to test the design on.
Activity
vitek-karas commentedon May 15, 2020
/cc @eerhardt @MichalStrehovsky
eerhardt commentedon Jul 22, 2020
Moving to 6.0 since this scenario isn't needed for Blazor WASM apps.
vitek-karas commentedon Oct 19, 2020
I think startup hooks should be behind a feature switch as that is the only reliable solution to this - trimmed apps can't use startup hooks to their full potential.
For some specific cases, where the startup hook assembly is known before hand (for example since it's part of the target environment - hosting provider telemetry, ...) it might be possible to make this work by:
That said we should not proactively implement a solution until we know of at least a couple use cases so that we have some real-world usage to test the design on.