Move ILLink.LinkAttributes.xml to a shared location

[MichalStrehovsky]

We should move src/mono/System.Private.CoreLib/src/ILLink/ILLink.LinkAttributes.xml to a shared location and make various attribute removal conditional on feature switches that SDKs (or end users) can opt into.

The list currently has things in it that are known to cause behavioral differences in XmlSerializer (ObsoleteAttribute) or Entity Framework (the nullable annotations cruft). While this is likely fine for WASM, broken Entity Framework will likely be unacceptable for Xamarin.

Without feature switches, the workarounds for someone wanting to keep the stripped attributes are pretty laborious.

[ghost]

Tagging subscribers to 'linkable-framework': @eerhardt, @vitek-karas, @LakshanF, @tannergooding, @sbomer
See info in area-owners.md if you want to be subscribed.

Issue Details

---

We should move src/mono/System.Private.CoreLib/src/ILLink/ILLink.LinkAttributes.xml to a shared location and make various attribute removal conditional on feature switches that SDKs (or end users) can opt into.

The list currently has things in it that are known to cause behavioral differences in XmlSerializer (ObsoleteAttribute) or Entity Framework (the nullable annotations cruft). While this is likely fine for WASM, broken Entity Framework will likely be unacceptable for Xamarin.

Without feature switches, the workarounds for someone wanting to keep the stripped attributes are pretty laborious.

Author:	MichalStrehovsky
Assignees:	-
Labels:	linkable-framework
Milestone:	6.0.0

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[eerhardt]

@MichalStrehovsky - do you have an idea for what the feature switches would be named? How granular do you think the switches should be? A switch per attribute feels too granular, and a switch for the whole thing feels too big.

[MichalStrehovsky]

One natural grouping would be all the nullable junk. That covers like half of the list.

I would maybe create categories for those that have reasonable payoff and the rest can be WASM only, no-feature-switch, where ~50 bytes is a meaningful saving (e.g. it doesn't feel like stripping ObsoleteAttribute could produce meaningful savings).

[marek-safar]

As a note, Xamarin is way more aggressive than Blazor today with attributes removal. Leaving attributes like Obsolete out the list is very likely not going to work because they have hundreds/thousands of them used and we'd need to mitigate that differently.

[MichalStrehovsky]

In that case it should probably go into one of those that should be under a feature switch.

In either case whether the stripping should happen should probably be decided by the SDK and not by CoreLib as it is done right now. It doesn't feel right to have e.g. XmlSerializer behave differently in the same MAUI app depending on whether you target Android (that uses Mono's corelib) vs Windows desktop (that would use CoreCLR's corelib).

[eerhardt]

@MichalStrehovsky @marek-safar - do you feel this is a "must have" for 6.0? Or can it be moved to Future?

[MichalStrehovsky]

If we don't put them in a shared location where it can be enabled/disabled by the SDK, we're going to have differences in trimmed apps depending on whether the runtime is Mono or CoreCLR.

This is around attribute trimming which is a sketchy "no warnings if we broke your app" territory. I think we would want MAUI apps to behave the same irrespective of what runtime is used.

[marek-safar]

@eerhardt it should be done for net6 release