SDK reports a number of new errors when multi-targeting and enabling AOT/Trim analyzers

[tannergooding]

As per the title, the .NET 8 RC1 SDK is reporting a number of new errors when setting properties such as:

• EnableAotAnalyzer
• EnableSingleFileAnalyzer
• EnableTrimAnalyzer
• IsTrimmable

These errors surface if the properties are set to true and the TFM does not support the functionality.

This is unfortunate because it puts a responsibility on the end user to understand the inner complexities and limitations of the tooling and what TFMs they support in a multi-targeted project.

The SDK and tooling itself already knows this information and it would, in my opinion, be significantly better if the SDK simply did the right thing and ignored the property on TFMs where the analyzer don't work.

It might be desirable to still surface a warning so users are aware that netstandard2.0 won't be analyzed or trimmed, but I wholeheartedly believe that erroring out here is the wrong thing and that if a warning is surfaced, the user should be able to suppress it.

[tannergooding]

This looks to be caused by #34077 and has already been hit by various dotnet repos.

[eerhardt]

@agocke @sbomer @vitek-karas - FYI.

I'm not sure where we landed is a good place for typical library authors.

[tannergooding]

I've just seen a lot of people basically avoid anything MSBuild related, because they view it as spooky/complex

My expectation is that a typical developer won't know they can do something like '$(TargetFrameworkIdentifier)' == '.NETCoreApp or $([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', '...')) or any of these other conditionals that may or may not work depending on their setup

So I expect they'll try to enable trimming/AOT, get an error that they don't know how to handle, not be able to find a solid solution for it because it's MSBuild, and then will simply not go through with enabling the functionality.

The tooling knows what it does and doesn't support and so it's fully capable of doing the right thing by default and surfacing a warning or informational diagnostic that the user could suppress. That helps, in my opinion, lead users towards a pit of success around the feature.

[sbomer]

The breaking change is described here: https://learn.microsoft.com/en-us/dotnet/core/compatibility/sdk/8.0/trimming-unsupported-targetframework.

The SDK and tooling itself already knows this information and it would, in my opinion, be significantly better if the SDK simply did the right thing and ignored the property on TFMs where the analyzer don't work.

It might be desirable to still surface a warning so users are aware that netstandard2.0 won't be analyzed or trimmed

That's the intention for the properties you listed - they should have no effect, except that they produce a warning (not an error). Are you seeing something different? Maybe we need to adjust the wording of the message if that's not clear - happy to take any suggestions.

Note that the publish settings (PublishAot, PublishTrimmed) produce hard errors instead - we discussed this and came to the conclusion that the publish settings in particular warranted an error on unsupported TFMs, even if the above properties were treated as a warning.

[tannergooding]

I saw a number of different build failures related to these properties but didn't check exactly which reported what kind.

It simply represented a break from the previous preview/release and one where I had to go dig up uncommon MSBuild knowledge to resolve.

It makes the entire experience with multi-targeting and supporting AOT painful and much harder to get people to adopt if they don't have the knowledge of how to resolve MSBuild issues.

[sbomer]

Yeah, it's definitely a break and will cause some pain, but we hope it makes the experience more predictable in the long run. Before this, we allowed turning on these analyzers for netstandard2.0 apps even though they produced incomplete results (since the netstandard ref assemblies aren't annotated for trim compatibility).

If it helps at all, the warnings include the right MSBuild magic so that people don't have to figure it out themselves:

 warning NETSDK1210: IsAotCompatible and EnableAotAnalyzer are not supported for the target framework. Consider multi-targeting to a supported framework to enable ahead-of-time compilation analysis, and set IsAotCompatible only for the supported frameworks. For example:
 warning NETSDK1210: <IsAotCompatible Condition="$([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', 'net7.0'))">true</IsAotCompatible> 

[tannergooding]

Why not just have the analyzer be a no-op for those TFMs? They don't support trimming, so there's nothing for a dev to do, the tooling can simply decide to not run the analyzer for unsupported TFMs and the user will see nothing different.

I can somewhat understand PublishTrimmed since they may expect trimming to occur and then find it didn't happen. But even that seems like something that could be a warning since the tool is functionally doing a no-op there. It can't trim it, so it produces the same output.

[sbomer]

Libraries built for a TFM that's not supported by the tooling can still be included as a dependency of an app, where it might produce trim warnings when the app gets published. If a library author sets IsTrimmable and it produces no warnings, for the supported TFMs this is supposed to mean that the library is trim-compatible. For the unsupported TFMs, we want to avoid giving the false impression that the library is trim-compatible.

[vitek-karas]

For the motivation behind this: We've seen people run into the "False sense of security" - they set IsTrimmable=true and didn't get any warnings, so thought they were fine (which was not the case obviously).

We've also seen cases where project has some net6.0 libraries but it also has some netstandard2.0 libraries in the mix. Currently we don't have a good way to run analyzers on all of those, because we don't know what it means to run the analyzer on netstandard2.0 (the analyzer would run, but would produce cca 50% of the warnings it should, because the ref assemblies from framework are missing trim annotations).

Finally, we really want people to multi-target to NET 6+, since otherwise they will have a problem with annotating the library (the attributes only exist in NET 6, so they would have to backfill their implementations).

As for hard error when trying to PublishTrimmed/PublishAot something which is not net6/net7+:

• For AOT this is actually important - in 7+ dotnet publish /PublishAot=true on a classlib project is actually a valid scenario and will produce a native library in the output. On 6- this doesn't work, so I think it's reasonable to fail.
• For Trimming, currently trimming libraries is not supported in any case, but again, I think it's important to error since we're not going to do what the user asked for. In addition, it's basically undefined what does it mean to dotnet publish a classlib project.

Overall - our main design goal behind trimming/AOT is to make the experience predictable - no surprises. Large part of how we achieve that is to provide built-time feedback about possible incompatibilities. We actually started with publish-time feedback only, but got reactions that it's cumbersome, so we added the analyzer for IDE/build-time feedback. Recently we've seen people (even our own - ASP.NET) basically ask if they can rely solely on the analyzer, as it's an easier experience. All this combined: if the analyzer is unreliable because it sometimes doesn't run without any feedback to the user, then developers will lose trust in it and we're back in publish-time feedback land (which is really not a great UX for library authors).

I definitely appreciate that the suggested solution to make the IsTrimmably conditioned on TFM is not very nice, so if there are better ideas, we'd love to hear them. Maybe suppressing the warnings (although that's potential dangerous)? What we really wanted was:

• netstandard2.0 library should produce a warning - to get rid of the false sense of security
• guide library authors toward multi-targeting with net6+
• make it possible, but not simple, to annotate netstandard2.0 library

[MichalPetryka]

• guide library authors toward multi-targeting with net6+

Why not suppress the warning automatically when multi-targetting then? Or use the supported TFM for checking of the unsupported one then?

[vitek-karas]

Why not suppress the warning automatically when multi-targetting then?

We were looking into that... and I'm revisiting that right now as well. It was rather difficult, but we'll do more investigation if there's some better way.

[lewing]

Xamarin and wasm apps have been trimming netstandard assemblies since pre NET5 as part of every build, this appears to be a massive breaking change for these targets first introduced in rc1??