StyleCopAnalyzers VS Nerdbank.GitVersioning

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

i have been using Nerdbank GitVersioing https://github.com/dotnet/Nerdbank.GitVersioning

The https://github.com/Azure/ResourceModules repo (which I recommend strongly, if you are just starting with template specs/bicep modules) seems to be at least referencing https://github.com/dotnet/Nerdbank.GitVersioning though when I peeked at their pipelines I'm not sure if they are actually utilizing it for version numbers. For me it was a bit too complex approach, but might suit you.

So, is there a complexity with delivering a NuGet package? Yes. NuGet package versioning can be a big undertaking when it comes to manual deployments, much less CD; as there is a requirement of NuGet packages being immutable. Does this mean that for every check in, on every potential branch that will be pushed to NuGet, you need to update some text file or code to indicate the next built version? That was my initial thinking, but thankfully that is not the case with the help of Nerdbank.GitVersioning.

I would suggest you compare with the readme on https://github.com/dotnet/Nerdbank.GitVersioning (FD: this is what I use for versioning my projects, so I'm already very familiar with it), which has most of the details up front (i.e. I don't have to go browsing through multiple wiki pages). It clearly calls out: - What does the package accomplish? (it adds semver information based on git history) - What is it compatible with? ("[dotnet] assemblies, VSIX, NuGet, NPM, and more") - What sets it apart? (#1: every commit generates a unique version, and builds reproducibility is prioritized. #2-4: everything is automatic.) - Further down it talks about how it calculates versions, and how to calculate between versions and git commits (i.e. how does the automatic part work)

GitVersioning. Auto-increments based on commit. Integrates into your build and automatically adds AssemblyInfo. https://github.com/dotnet/Nerdbank.GitVersioning

How to adopt a versioning strategy using tools like Nerdbank GitVersion