Skip to content

Conversation

@marek-safar
Copy link
Contributor

Fixes #1713

@MichalStrehovsky
Copy link
Member

If this is the behavior we want to codify, we need to mark https://docs.microsoft.com/en-us/dotnet/api/system.reflection.assembly.entrypoint?view=net-5.0 as RequiresUnreferencedCode. The API is currently considered trimming safe.

@vitek-karas
Copy link
Member

I'm not sure I like this - mainly due to the issue which Michal raised. Assembly.EntryPoint will be trim-compatible in almost all cases, except for these special projects which refer to .exe as a library. I would probably prefer to make linker always preserve entry-point on an assembly, regardless if it's a main app assembly or not. So that we don't have to make the EntryPoint API trim-incompatible.

Otherwise we would basically ask everybody who uses that API to suppress the warning - that's a bad experience.

@marek-safar
Copy link
Contributor Author

marek-safar commented Jan 6, 2021

I think these are two separate things.

The PR fixes a crash because linker keeps dangling method reference to a removed method it does not change linker behaviour regarding of Assembly.EntryPoint.

Michal raised a point about Assembly.EntryPoint which today linker does not keep either and this PR does not change. We could always preserve all entry-points everywhere but we have a case in dotnet/runtime which adds I think over 10% because of duplicate entry-point and we'd need a way to opt-out from that. Another option would be to teach linker to recognize Assembly.EntryPoint reference and make the logic conditional.

@vitek-karas
Copy link
Member

Thanks @marek-safar for clarification. Just curious what (roughly) is the case in dotnet/runtime which causes such a large size impact?

@marek-safar
Copy link
Contributor Author

Large is relative here, the team is working on getting each libraries tests under 2MB and we hit some unnecessary dependency in xunit runner.

Thinking about the options we could also just document that if someone needs to keep entry point in "non-default" assembly they need to add it to the AssemblyRootEntryPoint items

@vitek-karas
Copy link
Member

That would still not solve the annotation/warning problem - the API would still have to be annotated as dangerous. Unless we go with the intrinsic approach - what could work.

@marek-safar
Copy link
Contributor Author

Made #1729 issue about Assembly.EntryPoint API handling

@marek-safar marek-safar merged commit 7a095fa into dotnet:master Jan 11, 2021
@marek-safar marek-safar deleted the sweep branch January 11, 2021 15:45
agocke pushed a commit to dotnet/runtime that referenced this pull request Nov 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Linker OutputStep failing

3 participants