-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 includesAddLinkerConfigGeneration.targets
, it:/p:RegenerateLinkerConfig=true
, emits a file called<AssemblyName>.linkerconfig.xml
, containing linker rules based on ASP.NET Core / Blazor patterns, i.e.,IComponent
types completely, since their constructors and property-setters are used through reflection only[JSinterop]
methods, since they are called through reflection onlyEventArgs
subclasses, since their property setters are called through reflection only<AssemblyName>.linkerconfig.xml
as a resource called<AssemblyName>.xml
(which is what the linker looks for), if such a file exists on disk<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.