mjrousos
commented
2 years ago The ability to plug in arbitrary analyzers and code fix providers is already present in UA. The piece that's missing here, I think, is the ability to scope analyzers to specific TFMs.
For example, if there's a breaking change in ASP.NET Core 7, we will need a way for the author of the analyzer that detects the break to somehow indicate that the analyzer should be used when the end-user is upgrading to .NET 7+ but not when they're upgrading to .NET 6.
We should spend some time designing how to do that well, but perhaps some attributes that can be applied to analyzers to limit their scope in UA or something like that would fit the bill.
Summary
When upgrading an existing .NET project to a newer version (version-to-version upgrade) it would be great to have a way to detect the impact of breaking changes in .NET and to provide code fixes for those breaking changes.
Motivation and goals
Upgrading a .NET app to the latest Current or LTS release is a manual and error-prone process. We provide docs on how to migrate from version to version, but there is no automation around handling breaking changes. Other frameworks, like Angular, do a better job of providing tooling for dealing with changes needed for version-to-version upgrade (see https://update.angular.io/).
In scope
Update a .NET project from:
Enable .NET teams to implement and contribute warnings or code fixes for known breaking changes.
Out of scope