How we enforce .NET coding standards to improve productivity
14 comments
·August 4, 2025maltalex
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.
tailspin2019
I agree with you on MsBuild being powerful.
I often really hate certain technologies like MsBuild and use them begrudgingly for years, fighting with the tooling, right up until I decide once and for all to give it enough of my attention to properly learn, and then realise how powerful and useful it actually is!
I went through the same thing with webpack too.
MsBuild is far from perfect though. I often think about trying to find some sort of simple universal build system that I can use across all my projects regardless of the tech stack.
I’ve never really dug much into `make`… Maybe something like that is what I’m yearning for.
johnfonesca
>But all projects need to have the same formatting and style.That too can be easily done with one nuget using msbuild.
That's like using a car for "traveling" 3 meters. Why not just use dotnet format + .editorconfig , they were created just for this purpose.
nathanaldensr
It's a combination of practices, some at develop-time and some at CI-time. The general goal is to have code as clean and standardized as possible as early as possible, especially on larger teams where human enforcement doesn't scale as much.
null
tailspin2019
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…)
Kuraj
The original comment was about whether these things should be treated as errors during the local development process, or during CI for greenfield projects.
I deleted it after realizing that the article actually does address this. But I'm still relieved that I'm not the only one with the dillema.
> which if you miss, just means you may end up with a failed CI build to fix…
Honestly as a developer if I miss this up until CI, that's on me. The important part is that these issues are still visible during the local development, even if as warnings, and that the developer knows (maybe after making that mistake once or twice :-)) that they can't just be ignored because they will fail down the road.
graboid
At work, we use the .editorconfig of the .NET runtime, with slight modifications:
000ooo000
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.
tailspin2019
Plenty of substance in there for me. I’ve been building with dotnet since it existed and still learned a couple of new techniques/ideas from this article.
reverseblade2
Title should be C# not .Net
algorithmsRcool
I'm not sure i understand your comment, .editorconfig works just fine for VB files as well as F#
nickpeterson
You could almost think of F# is an extremely strict set of conventions for C# … ;)
Is there a 'prettier' equivalent for code formatting? In my opinion, it's the only thing missing for a truly scalable codebase.