Lombiq .NET Analyzers

About

.NET code analyzers and code convention settings for Lombiq projects, for Orchard Core and any other .NET and .NET Framework apps. We use these to enforce common standards across all our .NET projects, including e.g. all of our open-source Orchard Core extensions. If you contribute to our open-source projects while using that solution you'll be guided by these rules, too. You can check out a demo video of the project here, and the Orchard Harvest 2023 conference talk about automated QA in Orchard Core here.

There is also support for non-SDK-style .NET Framework projects, as long as they use PackageReference for their dependencies (in contrast to packages.config).

Some other projects you may be interested in:

• Looking for something similar for JavaScript and SCSS? Check out the ESLint and Stylelint integrations of our Node.js Extensions project.
• Looking not just for static code analysis but also dynamic testing? Check out our UI Testing Toolbox and Testing Toolbox projects.
• Looking for a library that'll help you comply with analyzer rules? Check out our Helpful Libraries project.

We at Lombiq also used this module for the following projects:

• The new City of Santa Monica website when migrating it from Orchard 1 to Orchard Core (see case study).
• The new Smithsonian Folkways Recordings website when migrating it from Orchard 1 to Orchard Core (see case study).
• The new Lombiq website when migrating it from Orchard 1 to Orchard Core (see case study).
• The new client portal for WTW (see case study).
• It also makes DotNest, the Orchard SaaS better.

Do you want to quickly try out this project and see it in action? Check it out in our Open-Source Orchard Core Extensions full Orchard Core solution and also see our other useful Orchard Core-related open-source projects!

Analyzer packages used

We added and configured analyzers which are widely used and complement each other.

• .NET code style analysis
• .NET code quality analysis
• AsyncFixer
• DotNetAnalyzers.DocumentationAnalyzers
• Meziantou.Analyzer
• Microsoft.CodeAnalysis.NetAnalyzers
• Microsoft.VisualStudio.Threading.Analyzers
• SecurityCodeScan.VS2019
• StyleCop.Analyzers
• SonarAnalyzer.CSharp

Furthermore, the project also includes an .editorconfig file with additional configuration for compatible editors.

Guides

• Adding analyzers to your project
• Using the analyzers during development
• Using the analyzers during command line builds
• Configuring analyzers

Contributing and support

Bug reports, feature requests, comments, questions, code contributions and love letters are warmly welcome. You can send them to us via GitHub issues and pull requests. Please adhere to our open-source guidelines while doing so.

This project is developed by Lombiq Technologies. Commercial-grade support is available through Lombiq.

Publishing a new NuGet package

When publishing a new version of the NuGet package, even if it's just a pre-release, also update the package references under TestSolutions\Lombiq.Analyzers.PackageReferences to the new version. This is necessary to run the tests there.

Upgrading to a new version of the .NET SDK

When a new version of the .NET SDK comes out then to the following:

• Change the LangVersion and AnalysisLevel elements in the Build.props file to opt in to new language features and analyzers. This does not concern non-SDK-style .NET Framework projects.
• Wait for all analyzers to support the new SDK (primarily the new language features). Then update all packages to latest.
• Check if there are new code analysis categories that we need to surface warnings for by default in the Lombiq.Analyzers.globalconfig file.

Adding a new analyzer

When adding a new analyzer package, do the following:

• Check if the project is actively developed with issues addressed quickly.
• Check if it has any significant impact on build or editing performance.
• Go through all rules in the package and decide one by one whether we need them.
  • Check for rules that are already covered by some other analyzer and disable duplicates.
  • All rules that we need should be surfaced as Warnings. This allows to only break the build on analyzer violations when we need it, i.e. during CI builds but not during development.
  • Add rule configuration to the .globalconfig file of the relevant project, depending on which kind of applications they're applicable to. Editor-only configuration should be in .editorconfig files.
• Test it on multiple significant solutions. Using the Hastlayer SDK is a good example as it's a large C# solution.