[release/8.0.1xx] Detect correctly multitargeted apps for trim/AOT/single-file warnings #35851
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.
Backport of #35767.
Customer Impact
In .NET 8 we made a breaking change that introduces a warning when setting
IsTrimmable
or related properties in a .NET Standard library. The warning was introduced because we changed the behavior (to not reference the trim analyzers, and to not mark the assembly with[assembly: AssemblyMetadat("IsTrimmable", "True")]
.The intended way to fix this in a library was by multi-targeting the library to include a TFM supported by trimming, and to set
IsTrimmable
only on the supported TFMs. We got feedback (see #35528) that the warning was a painful break for multitargeted libraries, and that the warning shouldn't be produced in the first place for libraries following our guidance.This change addresses it by silencing the warning for correctly multitargeted projects. The warning is silenced only when the multitargeting set includes a low enough supported TFM to ensure that the
IsTrimmable
assets will be consumed (instead of non-trimmable .NET Standard assets) in any supported app that references the library.Testing
Existing unit tests passed without changes. Added tests to validate the behavior for various multitargeted projects. Added tests to ensure that the changes don't break the behavior of projects that use custom
TargetFramework
values as aliases forTargetFrameworkIdentifier
andTargetFrameworkVersion
.Risk
Low to medium. This change reduces overall impact of the breaking change by limiting the scope of the warning, but adds complexity to the behavior. The complexity is unlikely to be surfaced to the developer, but is observable (it would be confusing to any developer who tried to understand the specific circumstances under which the warning was produced).
Original description
The warnings introduced by
#34077 and described in
https://learn.microsoft.com/en-us/dotnet/core/compatibility/sdk/8.0/trimming-unsupported-targetframework
are unnecessary noise for projects that multitarget to include a
TargetFramework that is compatible with
trimming/AOT/single-file, and is a low enough version to ensure
that it will be picked over any other TFM's assets when the
library is consumed in a trimmed/AOT'd/single-file app.
This fixes the issue by detecting correctly multi-targeted libraries and suppressing the warnings in these cases.
Note that prior to the .NET 8 SDK, netstandard libraries would still get the
IsTrimmable
attribute embedded in the assembly when settingIsTrimmable
, and could use trim analysis despite incomplete warnings due to unannotated ref assemblies. With the .NET 8 SDK this is no longer the case. Even for correctly multi-targeted libraries, the netstandard output assembly will no longer contain theIsTrimmable
attribute. We debated whether it was worth warning in this case, but decided that the negative impact of the warning on library developers following the "golden path" was too large to justify keeping this as a warning.This solution addresses a correctness problem that we wanted to avoid (the correctness problem: allowing an inadvertently non-"trimmable" netstandard asset to be consumed in a trimmed app that uses a supported TFM).
It's still possible to get into that situation in an app that explicitly references the netstandard assembly, or that targets an EOL TFM (causing it to consume the netstandard asset from a library that multitargets
netstandard2.0;net6.0
for example).Fixes #35528