.NET SDK 10 breaking change: Microsoft.DotNet.ApiCompat.Tool CP0012 : Cannot remove 'abstract' keyword from member

[AArnott]

In updating .NET SDK from 9.0.307 to 10.0.100, our build broke with this error:

Error CP0012: Cannot remove 'abstract' keyword from member 'Microsoft.VisualStudio.Extensibility.Editor.TextViewTagger<T>.RequestTagsAsync(Microsoft.VisualStudio.Extensibility.Editor.NormalizedTextRangeCollection, bool, System.Threading.CancellationToken)'

We were already applying package validation in our build, and apparently .NET 10 SDK finds issues that .NET 9 SDK did not.

I'm glad you catch more issues than you used to. And because we use global.json to pin the SDK that we use, we're able to very easily determine why the error shows up now, and we can contain the build break in just a PR that updates the SDK until we can mitigate it and merge it into our main branch together so that we never have downtime as a team. I'm merely filing this issue as requested by the .NET team to track times that .NET SDK updates break our builds.

[dotnet-policy-service[bot]]

@dotnet/area-infrastructure-libraries a new issue has been filed in the ApiCompat area, please triage

[ericstj]

API Compat finding new issues in new major versions is an expected thing. We typically treat that as a desirable feature. It has it's own baselining system to ignore those.

I do see how these can create some friction for folks expecting the SDK upgrade to always "just work".

Do you think we should hide those new issues behind a flag? That feels worse since these aren't typically opinionated issues like analyzers raise. We could add a document that reminds folks that new API compat versions will find new issues. Thoughts @baronfel @marcpopMSFT

[AArnott]

If you hide the new issues behind a flag, my worry is I wouldn't know about the flag so I wouldn't set it and I'd never see the new issues. I want to see the new issues. My "flag" that I set is pinning the SDK, so this is all expected for me.

If other customers tend to treat warnings as errors in their builds/pipelines, and the SDK isn't pinned for them, this would likely become and untimely and confusing failure appearing "out of nowhere". That's why I pin SDKs. But if you like customers to not pin SDKs, consider another solution to this.

[marcpopMSFT]

@ericstj is it possible to tie these to a TFM update rather than an SDK update? Not all SDK updates are user controlled (updating VS can bring a new SDK and be just part of the typical update process) as not everyone understands and uses global.json like aarnott does. As such, we tend to try to tie new warnings or behavior changes (like pruning) to TFM updates when we can as that's typically a customer chosen action.

The alternative is to use SDKAnalysisLevel though that's more of letting customers opt out and it's more niche than a TFM update.

[ericstj]

IMO tying this to TFM update is not a good user experience. APICompat rules have nothing to do with the TFM. They are more functions of the language / metadata. It's more confusing to see real problems appear only when targeting a new TFM. The type of problems we raise in APICompat are not hypothetical or pedantic - they're real compatibility issues. New behaviors make sense to tie to a TFM (like NuGet Audit, or Pruning) but not checks that are applicable regardless of framework.

Analysis level makes more sense. That gives folks a common knob to use to rollback new validations -- https://github.com/dotnet/designs/blob/main/proposed/sdk-analysis-level.md

I think we could adopt that in APICompat.

[marcpopMSFT]

@ericstj Unfortunately, we've found when teams don't tie warnings to TFM, we get customer complaints. New analyzers are real issues too but customers complain nonetheless. Please do start with sdk analysis level but lets take this offline as our customer signal on this is pretty strong on no new warnings not tied to TFM.

[AArnott]

Please always have and document a way to opt into a specific version set of warnings without requiring a TFM change. I'm locked into targeting old frameworks in many of my repos, but I'd still like to update some 'pin' periodically to get the latest warnings.