StyleCopAnalyzers VS ExpressionPowerTools

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

- StyleCopAnalyzers but I wasn't able to find an official CLI tool?

Check out Jeremy Likness' ExpressionPowerTools

It quickly became evident I needed a dependency injection system. Instead of taking a dependency on an external provider, I decided to implement my own. Again, this was mostly a learning experience, but I also wanted to minimize dependencies and make it more self-contained so that overriding defaults is the exception, not the null. The system allows for registering types that are implemented on the fly, and singletons. I may have made a bad decision when I chose to implement the solution as a static host, but it was the easiest way to make it globally available. The caveat is that I have to run tests in single-threaded to avoid conflicts with the services mutating as part of test runs. I am considering refactoring to allow partitions as part of Issue #20 but for now I haven’t encountered major issues outside of testing.