0

During development it can be tedious to make the code adhere to all the static code analysis rules we have. We'd love instead to then make all of the static code analysis rules be treated as warnings when doing locally building when developing, while when we push and the build runs on our CI, we want it to treat them as errors.

It would be great if there was a similar MSBuild option to the <TreatWarningsAsErrors/> just flipped e.g. <TreatErrorsAsWarnings/>, preferably in MSBuild since we have packaged up our rules into a common package used by all projects. Having to maintain a separate ruleset for this scenario is too much of a hassle.

Right now we are actually turning off all rules locally and only have them on for our CI. This then requires discipline from every developer to remember to build it locally for release to get the errors in the code before pushing. While warnings would be very visible all the time and a friendly reminder to fix them before pushing.

EinarI
  • 627
  • 1
  • 9
  • 14
  • https://learn.microsoft.com/en-us/visualstudio/code-quality/use-roslyn-analyzers?view=vs-2022#set-rule-severity-in-an-editorconfig-file maybe? (note that you can do this automatically from the light-bulb menu) and in particular, see the "multiple analyzer rules at once" section (https://learn.microsoft.com/en-us/visualstudio/code-quality/use-roslyn-analyzers?view=vs-2022#set-rule-severity-of-multiple-analyzer-rules-at-once-in-an-editorconfig-file) – Marc Gravell Oct 06 '22 at 10:18
  • Thanks for the suggestion. Problem is that we can't make this a specific IDE solution as we use a variety of VSCode, Rider, VS for Mac and some VS for Windows. I'm looking for a solution where I can do this within MSBuild typically so that I can package it up in our common package that holds the ruleset and custom rules and make it a thing that automatically applied to everyone without haveing to configure anything. On the other hand, if I could package the .editorconfig file, then your suggestion might work. – EinarI Oct 06 '22 at 14:08
  • a wide range of tooling supports .editorconfig - that's kinda the point of it – Marc Gravell Oct 06 '22 at 15:08
  • Something like this could work: https://stackoverflow.com/questions/17495278/how-can-i-treat-msb3245-could-not-resolve-reference-warning-as-an-error/17515854#17515854 – stijn Oct 10 '22 at 10:39

1 Answers1

0

Thanks @MarcGravell for the pointers. I believe it led me down the correct path. We've been meaning to switch to .editorconfig files from the XML based ones. And luckily it turns out one can package these up in a NuGet, like we do with the XML based rulesets.

So from what I can figure out, I could then add a conditional for Debug builds that sets all rules to warning with a global override in its own .editorconfig file.

Anyone looking to package up these rules into a NuGet package, I found this article: https://hackernoon.com/how-to-use-common-editorconfig-as-a-nuget-package

EinarI
  • 627
  • 1
  • 9
  • 14