Skip to content

Link more assemblies by generating XML config files #17820

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

Closed
wants to merge 26 commits into from

Conversation

SteveSandersonMS
Copy link
Member

This is a possible implementation for #17022, but I don't actually want us to do this. I'm going to mark the PR as closed straight away. The only reason I'm submitting this PR is for future reference in case either dotnet/linker#854 gets rejected, or we come up with some other reason to want to generate linker XML config files during the build.

This PR includes a new MSBuild tasks assembly, Microsoft.AspNetCore.Components.Build that is only for internal use and would not be shipped. During the build, for each project that includes AddLinkerConfigGeneration.targets, it:

  • If you pass /p:RegenerateLinkerConfig=true, emits a file called <AssemblyName>.linkerconfig.xml, containing linker rules based on ASP.NET Core / Blazor patterns, i.e.,
    • preserve all IComponent types completely, since their constructors and property-setters are used through reflection only
    • preserve all [JSinterop] methods, since they are called through reflection only
    • preserve all DI service types, since their constructors are called through reflection only
    • preserve all EventArgs subclasses, since their property setters are called through reflection only
  • Otherwise,
    • Embeds <AssemblyName>.linkerconfig.xml as a resource called <AssemblyName>.xml (which is what the linker looks for), if such a file exists on disk
    • Validates that the resulting assembly contains an embedded resource called <AssemblyName>.xml and that its contents exactly match what would have been generated if you had passed /p:RegenerateLinkerConfig=true. If not, fails the build.

In other words, it's very much like our flow for generating reference assemblies, storing them in source control, and validating their up-to-dateness during build. I chose this approach (versus simply generating and embedding on every build) so that humans would manually inspect the diffs to the xml config files and reason about their correctness. This means we inherently have baselines for correct output and don't want a different set of tests for this functionality.

Why I don't like this

It's really complicated.

It means creating a new MSBuild tasks assembly on build, which comes with all the awful mess of locking files and caring about VS running MSBuild as netfx versus netcore. I hate this stuff.

We have to use Mono.Cecil to generate the configs. We can't use System.Reflection.Metadata or anything based on it, because the Mono linker only recognizes the exact method signature string format produced by Cecil.

The resulting size reductions aren't as big as with #17819.

@SteveSandersonMS
Copy link
Member Author

Closing because I don't want this to happen. This PR only exists so I can search for it in the future when trying to do similar things.

@dougbu dougbu deleted the stevesa/link-more-assemblies branch August 21, 2021 22:35
@github-actions github-actions bot locked and limited conversation to collaborators Dec 8, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant