How we enforce .NET coding standards to improve productivity

Title should be C# not .Net

If you’re working in the .net ecosystem, you need to grok msbuild. Is not exactly painless or elegant, but is incredibly powerful. Creating a nuget package that applies settings and configuration files to consuming projects is the tip of a very deep iceberg.

I’m the author and owner of a similar code style/code quality package in a fairly large company and went through a very similar process, culminating with writing our own Roslyn-based analyzers to enforce various internal practices to supplant the customized configuration of the Microsoft provided analyzers. Also, we discovered that different projects need different level of analysis. We’re less strict with e.g test projects than core infrastructure. But all projects need to have the same formatting and style. That too can be easily done with one nuget using msbuild.

Pretty long article with not a great deal of substance beyond what is mentioned early on. Would be interested to know how much input teams had in the rule configuration before this was foisted on them.

You could almost think of F# is an extremely strict set of conventions for C# … ;)

The article does mention they only turn on “TreatWarningAsErrors” in production builds.

It’s definitely a tough balance to strike. I go back and forth on this myself.

Maybe the happy medium is to have everything strictly enforced in CI, relatively relaxed settings during normal dev loop builds and then perhaps a pre-commit build configuration that forces/reminds you to do one production build before pushing… (which if you miss, just means you may end up with a failed CI build to fix…)