Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling of startup hooks in linked applications #36526

Closed
vitek-karas opened this issue May 15, 2020 · 5 comments · Fixed by #44050
Closed

Handling of startup hooks in linked applications #36526

vitek-karas opened this issue May 15, 2020 · 5 comments · Fixed by #44050
Assignees
Labels
area-AssemblyLoader-coreclr linkable-framework Issues associated with delivering a linker friendly framework
Milestone

Comments

@vitek-karas
Copy link
Member

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):

private static void CallStartupHook(StartupHookNameOrPath startupHook)

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.

@vitek-karas vitek-karas added the linkable-framework Issues associated with delivering a linker friendly framework label May 15, 2020
@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added area-Infrastructure-libraries untriaged New issue has not been triaged by the area owner labels May 15, 2020
@ghost
Copy link

ghost commented May 15, 2020

Tagging subscribers to this area: @safern, @ViktorHofer
Notify danmosemsft if you want to be subscribed.

@vitek-karas
Copy link
Member Author

/cc @eerhardt @MichalStrehovsky

@ViktorHofer ViktorHofer removed the untriaged New issue has not been triaged by the area owner label Jul 8, 2020
@Anipik Anipik added this to the 5.0.0 milestone Jul 8, 2020
@eerhardt
Copy link
Member

Moving to 6.0 since this scenario isn't needed for Blazor WASM apps.

@eerhardt eerhardt modified the milestones: 5.0.0, 6.0.0 Jul 22, 2020
@vitek-karas
Copy link
Member Author

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.

@ghost
Copy link

ghost commented Oct 31, 2020

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

@ghost ghost locked as resolved and limited conversation to collaborators Dec 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-AssemblyLoader-coreclr linkable-framework Issues associated with delivering a linker friendly framework
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants