You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 25, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 25, 2026. It is now read-only.
Adding UnconditionalSuppressMessage doesn't solve IL2104 for entire assembly #2265
In dotnet/android#6270, I'm trying to solve some of the remaining ILLink warnings we have:
> dotnet new android
> dotnet build -c Release -p:SuppressTrimAnalysisWarnings=false
...
src\Mono.Android\Android.Runtime\ResourceIdManager.cs(37,6): warning IL2026: Android.Runtime.ResourceIdManager.GetResourceTypeFromAssembly(Assembly): Using method 'System.Reflection.Assembly.GetType(String)' which has 'RequiresUnreferencedCodeAttribute' can break functionality when trimming application code. Types might be removed.
src\Mono.Android\Java.Interop\JavaObjectExtensions.cs(136,4): warning IL2026: Java.Interop.JavaObjectExtensions.GetHelperType(Type,String): Using method 'System.Reflection.Assembly.GetType(String)' which has 'RequiresUnreferencedCodeAttribute' can break functionality when trimming application code. Types might be removed.
src\Mono.Android\Java.Interop\JavaObjectExtensions.cs(131,5): warning IL2026: Java.Interop.JavaObjectExtensions.GetHelperType(Type,String): Using method 'System.Reflection.Assembly.GetType(String)' which has 'RequiresUnreferencedCodeAttribute' can break functionality when trimming application code. Types might be removed.
Java.Interop.dll warning IL2104: Assembly 'Java.Interop' produced trim warnings. For more information see https://aka.ms/dotnet-illink/libraries
Mono.Android.dll warning IL2104: Assembly 'Mono.Android' produced trim warnings. For more information see https://aka.ms/dotnet-illink/libraries
I added UnconditionalSuppressMessage such as:
[UnconditionalSuppressMessage("Trimming","IL2026",Justification="Types in Resource.designer.cs are preserved, because it is the root assembly passed to the linker.")][UnconditionalSuppressMessage("Trimming","IL2026",Justification="*Invoker types are preserved by the MarkJavaObjects linker step.")]
Both cases there isn't actually a problem here. So we just want to suppress the warnings.
UnconditionalSuppressMessage caused the above warnings to go away, but the warnings for the assemblies remain:
Java.Interop.dll warning IL2104: Assembly 'Java.Interop' produced trim warnings. For more information see https://aka.ms/dotnet-illink/libraries
Mono.Android.dll warning IL2104: Assembly 'Mono.Android' produced trim warnings. For more information see https://aka.ms/dotnet-illink/libraries
Is there an issue here, where IL2104 is displayed and shouldn't be? Or do we need to do something else here? Thanks!
Could you try building with /p:TrimmerSingleWarn=false?
My guess is that the IL2026 warnings you are seeing come from the Roslyn analyzer (which doesn't have full coverage of the warnings produced by the linker) but that there are remaining warnings produced only by the linker. What I'm not sure of is why the linker would be "collapsing" thee warnings into IL2104 - normally that is only supposed to happen for PackageReferences where the source isn't available. In any case disabling TrimmerSingleWarn should show all of the remaining warnings.
Would you be able to provide an MSBuild log or repro instructions? I'll have to investigate why the warnings are being collapsed - it might be something particular to how these projects are set up in xamarin-android.
Thanks for the logs! From what I can tell the trimmer behavior is expected in this case. When building an app that references assemblies like Java.Interop.dll that contain trim analysis issues, we intentionally hide the verbose warnings per-assembly behind IL2014, so as not to overwhelm developers with warnings that they have no control over.
However I don't know why you were seeing IL2026 originally. Since those assemblies come from workload packs I wouldn't have expected to see verbose warnings for them (from the linker or the analyzer). Would you be able to share a log that includes the original IL2026?
Thanks... I see what is going on. Since the assembly has AssemblyMetadata("IsTrimmablue", "True"), we treat IL2026 specially and show it even though remaining warnings get collapsed into IL2014.
This behavior was added in #2087 to ensure that certain IL2026 warnings which were intentionally left in System.Private.CoreLib get displayed, but has the unfortunate side-effect that IsTrimmable libraries which aren't annotated yet produce inconsistent and misleading warnings.
I think this basically works as designed - I don't see much wrong with it. Assemblies should only add IsTrimmable attribute when they're prepared for trimming - which means they should not produce any warnings. If they do produce some warnings trimmer must report them. The IL2026 is special that it gets reported on its own, all other warnings are "hidden" behind the IL2014 to reduce noise.
The only improvement which we discussed in this area was the idea that we should only "leak" IL2026 through the single-warn if it originates from the assembly itself (meaning the RequiresUnreferencedCode attribute which produced the warning is in the assembly). That would get rid of the IL2026 above and only leave IL2014 (no help for fixing the problems, just better UX). I honestly don't remember why we didn't do this - it's possible that some of the issues we had in CoreLib needed us to always report IL2026, I'm not sure.
we should only "leak" IL2026 through the single-warn if it originates from the assembly itself (meaning the RequiresUnreferencedCode attribute which produced the warning is in the assembly).
We only leak it if it originates from an IsTrimmable assembly, but we do so when the warning origin (not necessarily the attribute) is in the assembly. This way it works even if the method which has RequiresUnreferencedCode lives in a different assembly. If we don't need that ability in general, maybe another option is to special-case it so that only System.Private.CoreLib can leak these warnings?
Activity
sbomer commentedon Sep 8, 2021
Could you try building with
/p:TrimmerSingleWarn=false?My guess is that the IL2026 warnings you are seeing come from the Roslyn analyzer (which doesn't have full coverage of the warnings produced by the linker) but that there are remaining warnings produced only by the linker. What I'm not sure of is why the linker would be "collapsing" thee warnings into IL2104 - normally that is only supposed to happen for
PackageReferences where the source isn't available. In any case disablingTrimmerSingleWarnshould show all of the remaining warnings.Would you be able to provide an MSBuild log or repro instructions? I'll have to investigate why the warnings are being collapsed - it might be something particular to how these projects are set up in xamarin-android.
jonathanpeppers commentedon Sep 8, 2021
Ok...
-p:TrimmerSingleWarn=falseshows a whole new list of warnings, we didn't see before:Logs: msbuild.zip
sbomer commentedon Sep 8, 2021
Thanks for the logs! From what I can tell the trimmer behavior is expected in this case. When building an app that references assemblies like Java.Interop.dll that contain trim analysis issues, we intentionally hide the verbose warnings per-assembly behind IL2014, so as not to overwhelm developers with warnings that they have no control over.
However I don't know why you were seeing IL2026 originally. Since those assemblies come from workload packs I wouldn't have expected to see verbose warnings for them (from the linker or the analyzer). Would you be able to share a log that includes the original IL2026?
jonathanpeppers commentedon Sep 8, 2021
Here is another log with IL2026: msbuild.zip
[One .NET] fix more Mono.Android.dll linker warnings
sbomer commentedon Sep 8, 2021
Thanks... I see what is going on. Since the assembly has
AssemblyMetadata("IsTrimmablue", "True"), we treat IL2026 specially and show it even though remaining warnings get collapsed into IL2014.This behavior was added in #2087 to ensure that certain IL2026 warnings which were intentionally left in System.Private.CoreLib get displayed, but has the unfortunate side-effect that
IsTrimmablelibraries which aren't annotated yet produce inconsistent and misleading warnings.In theory anyone using the instructions at https://docs.microsoft.com/en-us/dotnet/core/deploying/prepare-libraries-for-trimming shouldn't run into this, but it's easy to hit this if you're not strictly following those steps. I don't see much we can do here in .NET6 except call it out in the documentation. @vitek-karas any thoughts?
vitek-karas commentedon Sep 9, 2021
I think this basically works as designed - I don't see much wrong with it. Assemblies should only add
IsTrimmableattribute when they're prepared for trimming - which means they should not produce any warnings. If they do produce some warnings trimmer must report them. TheIL2026is special that it gets reported on its own, all other warnings are "hidden" behind theIL2014to reduce noise.The only improvement which we discussed in this area was the idea that we should only "leak"
IL2026through the single-warn if it originates from the assembly itself (meaning theRequiresUnreferencedCodeattribute which produced the warning is in the assembly). That would get rid of theIL2026above and only leaveIL2014(no help for fixing the problems, just better UX). I honestly don't remember why we didn't do this - it's possible that some of the issues we had in CoreLib needed us to always reportIL2026, I'm not sure.sbomer commentedon Sep 9, 2021
We only leak it if it originates from an
IsTrimmableassembly, but we do so when the warning origin (not necessarily the attribute) is in the assembly. This way it works even if the method which hasRequiresUnreferencedCodelives in a different assembly. If we don't need that ability in general, maybe another option is to special-case it so that only System.Private.CoreLib can leak these warnings?[One .NET] fix more Mono.Android.dll linker warnings (#6270)