Audit reflection usage in our assemblies #10405
Assignees
Labels
dotnet
An issue or pull request related to .NET (6)
enhancement
The issue or pull request is an enhancement
estimate-1w
iOS
Issues affecting iOS
macOS
Issues affecting macOS
Milestone
Comments
rolfbjarne
added
enhancement
rolfbjarne
changed the title
32 tasks
rolfbjarne
added a commit
to rolfbjarne/xamarin-macios
that referenced
this issue
Feb 16, 2024
Add test to keep track of trimmer warnings and to make sure we don't accidentally introduce new ones. Ref: xamarin#10405
rolfbjarne
added a commit
that referenced
this issue
Feb 16, 2024
Add test to keep track of trimmer warnings and to make sure we don't accidentally introduce new ones. Ref: #10405
rolfbjarne
changed the title
rolfbjarne
added a commit
to rolfbjarne/xamarin-macios
that referenced
this issue
Mar 18, 2024
Contributes towards xamarin#10405.
rolfbjarne
added a commit
to rolfbjarne/xamarin-macios
that referenced
this issue
Mar 19, 2024
…Protocol members. Contributes towards xamarin#10405.
rolfbjarne
added a commit
to rolfbjarne/xamarin-macios
that referenced
this issue
Mar 20, 2024
Contributes towards xamarin#10405.
rolfbjarne
added a commit
to rolfbjarne/xamarin-macios
that referenced
this issue
Mar 21, 2024
…members. Contributes towards xamarin#10405.
rolfbjarne
added a commit
to rolfbjarne/xamarin-macios
that referenced
this issue
Mar 21, 2024
…entation a bit. * Extract code the trimmer wants to warn about into a separate method. * Suppress the trimmer warning we get. Contributes towards xamarin#10405.
This was referenced Mar 21, 2024
rolfbjarne
added a commit
that referenced
this issue
Apr 22, 2024
As we have solved all trimming warnings in the our workloads, we can now go
all in on trimming.
Early in .NET 6 we hid many trimming warnings as we did not yet plan to solve
them:
<SuppressTrimAnalysisWarnings Condition=" '$(SuppressTrimAnalysisWarnings)' == '' ">true</SuppressTrimAnalysisWarnings>
Ref: #10405
These warnings were not *actionable* at the time for customers, as
many warnings were from our code.
Going forward, let's stop suppressing these warnings if `TrimMode=full`.
We can also enable trimming for new projects:
* `dotnet new ios|tvos|macos|maccatalyst`
These will have the `TrimMode` property set to `Full` by default for `Release`
builds:
```xml
<!--
Enable full trimming in Release mode.
To learn more, see: https://learn.microsoft.com/dotnet/core/deploying/trimming/trimming-options#trimming-granularity
-->
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
<TrimMode>full</TrimMode>
</PropertyGroup>
```
We wouldn't want to do this for existing projects, as they might have existing
code, NuGet packages, etc. where trimming warnings might be present.
We can also improve the templates for class libraries and binding libraries:
* `dotnet new ioslib|iosbinding|tvoslib|tvosbinding|...`
```xml
<!--
Enable trim analyzers for Android class libraries.
To learn more, see: https://learn.microsoft.com/dotnet/core/deploying/trimming/prepare-libraries-for-trimming
-->
<IsTrimmable>true</IsTrimmable>
```
This way, new class libraries and binding libraries will be trimmable by
default and be able to react to trimming warnings.
Fixes #10405.
Ref: dotnet/android#8805
|
This is done now. |
github-project-automation
bot
moved this from Todo
to Done
in .NET 9 MAUI Performance, App Size, Inner Loop
rolfbjarne
added a commit
that referenced
this issue
Sep 27, 2024
rolfbjarne
added a commit
that referenced
this issue
Oct 1, 2024
rolfbjarne
added a commit
that referenced
this issue
Oct 24, 2024
Our own code shouldn't produce trim analysis warnings anymore (see #10405), so we don't need to suppress trim analysis warnings for everyone. Except: we still want to suppress trim analysis warnings if no assemblies are trimmed, because otherwise we'll get warnings for code that would otherwise be trimmed away. On the other hand, we want trim analyzer always enabled, so that warnings are reported for user code. The difference between "trim analyzer" and "trim analysis warnings" is that the former is an analyzer that analyzes the currently compiled code (which we always want), while the latter is reported by the trimmers, and as such will report warnings from *all* code, including all references. This also required bumping Touch.Unit and MonoTouch.Dialog. * New commits in xamarin/MonoTouch.Dialog: * xamarin/MonoTouch.Dialog@d157950 Exclude code that's not trimmer safe. Diff: [77b3337..d157950](https://github.com/xamarin/MonoTouch.Dialog/compare/77b3337dbbc9e3e2f1b06dab3d37d2822488b0b3..d157950b6e6ed32cf53d4074fe19223dc1f1e8fe) * New commits in xamarin/Touch.Unit: * xamarin/Touch.Unit@957faca [Touch.Client] Disable features that aren't trimmer safe. Diff: [92a0726..957faca](https://github.com/xamarin/Touch.Unit/compare/92a072683b69b2f61f235a7a249c2c7f261236d4..957facad80e753310f52fcbb8cf85219d9d6d887) Fixes #21293.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The ILlink is now doing reflection analysis resulting in reported warnings. Context: https://github.com/mono/linker/blob/master/docs/design/reflection-flow.md
We should audit our reflection usage by checking the reported warnings and look into how to solve these. (by updating the code where needed or suppressing the warnings)
Example output:
Note: warnings are only reported when
SuppressTrimAnalysisWarnings=falseThe text was updated successfully, but these errors were encountered: