dotnet-apiport VS StyleCopAnalyzers

There are a few tools that can help in the process. Years back I used a tool named Project2015to2017: https://github.com/hvanbakel/CsprojToVs2017. Since then, Microsoft also released a tool: https://github.com/dotnet/upgrade-assistant. There was also this tool but it looks like it has been discontinued: https://github.com/microsoft/dotnet-apiport

Then why does it matter that .NET Framework 4.8.1 doesn't support old servers. You're already on borrowed time. .NET Framework will probably EOL somewhere around 2026-27. If the cost to migrate to .NET 6 isn't worth it, then you might as well start retiring the software because you're basically saying it's not important enough to keep updated. The migration from 4.6+ to .NET 6 really isn't difficult unless you've got some weird obscure dependencies that haven't been updated yet and aren't open source. Have you even tried the portability analyzer? I work in consulting, and we hear this a lot, "oh our code is just too old and it's too much effort to port it to .NET Core", and from what I've seen the last few years, unless your project is still running in VB.NET with Web Forms and ASP, you can most likely upgrade to .NET 6 with way less effort than you expect.

https://github.com/microsoft/dotnet-apiport for portability issues

By default, Renovate ignores preview versions of dependencies. For NuGet, a preview version is a package whose version contains a semantic suffix such as -alpha, -beta, -rc. There are some well-known NuGet packages that are only available in preview versions. For example, Aspire.Hosting will likely remain in preview until the release of .NET 9, StyleCop.Analyzers has been in beta for already 5 years, while OpenTelemetry.Instrumentation.GrpcNetClient and Azure.AI.OpenAI have never had a stable version.

Several well-known NuGet packages such as xUnit.net, FluentAssertions, StyleCop, Entity Framework Core, and others include by default a significant number of Roslyn analyzers. They help you adhere to the conventions and best practices of these libraries.

I created a StyleCopAnalysers.ruleset file at the root of my project, which contains the ruleset for analysis. The tool not only identifies issues but also attempts to fix them, providing a log of any unresolved problems. In addition to running the analyzer upon build, the dotnet format command also runs any external analyzers that it detects by default as well.

https://github.com/DotNetAnalyzers/StyleCopAnalyzers the successor to stylecop - most of the rules ported over

I'm a C# guy, so that is what I care about. For .NET we do have StyleCop analyzers. And EditorConfig exists to help at the IDE level across all languages. And git itself can be configured with such things as eol and autoclrf.

I'd also like to know how to clean up based on rules like SA1507 - never more than one blank line in a row, and related rules to remove blank likes after { and before }

StyleCop is from Microsoft: https://github.com/DotNetAnalyzers/StyleCopAnalyzers

Using their own APIs, Roslyn Analyzers verifies certain conditions about the source code and, if necessary, feeds back into the compiler in the form of compilation warnings and errors. An example would be StyleCop.

StyleCop.Analyzers