.NET code analyzers and code convention settings for Lombiq projects, predominantly for Orchard Core apps but also any .NET 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.
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 Gulp 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.
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!
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.
- Adding analyzers to your project
- Using the analyzers during development
- Using the analyzers during command line builds
- Configuring analyzers
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.
When a new version of the .NET SDK comes out then to the following:
- Change the
LangVersion
andAnalysisLevel
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 .editorconfig file.
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.
- Test it on multiple significant solutions. Using the Hastlayer SDK is a good example as it's a large C# solution.