Specify separate .editorconfig files between debug and release configurations

Question

I am using VS 2019 16.8.3 and I want to specify some code analysis rules (dotnet_diagnostic.CAXXXX.severity) in the solution .editorconfig file, only for release builds.

When I add rules in a .editorconfig file debug build time increases by a few minutes. All Analyzers checkboxes are not selected to "Run on build" in project properties.

So I want to exclude debug build from code analysis. Is it possible to specify a .editorconfig file only for release builds?

Or is it possible to disable this .editconfig for builds and only apply for manual code analysis?

Answer 1

TLDR

You can set your .editorconfig files in Directory.Build.props like this:

<Project>
    <ItemGroup Condition="'$(Configuration)'=='Debug'">  
        <EditorConfigFiles Include="xxx\debug.editorconfig" Link=".editorconfig"/>
    </ItemGroup>

    <ItemGroup Condition="'$(Configuration)'=='Release'">
        <EditorConfigFiles Include="xxx\release.editorconfig" Link=".editorconfig"/>
    </ItemGroup>
</Project>

---

Deep Dive

We had a same issue in our company. We wanted to set different severity to one specific rule on debug and release configuration. The reason we wanted this was because while the developer was getting a warning in the development environment(in his/her computer), the pull request was given an error at project or solution build phase in the Azure DevOps environment.

By the way, we have a repository named as CodingGuideline to store our .editorconfig files and to reference some analyzers like StyleCop. At the same time, this repository is a nuget package. And this package is referenced in all our repositories.

And we have some solutions as follows:

Solution 1

• We can store .editorconfig and review.editorconfig seperate files. Developers already have repository directory to keep company repositories and everyone put .editorconfig to inside this directory manually. (If you don't want to put config file manually, you can try solution 2) In this way, whole repositories will follow same code style and coding rules.

• If any developer create a pull request, CodingGuideline repository is being clone to the build directory automatically. After cloning, review.editorconfig file is copying named as .editorconfig. That's it. When dotnet build command is run and some rules that defined review.editorconfig is broken, pull request will throw error.

Solution 2

• If we don't want to put config file manually, we can deploy the config file through nuget package. In this option, we store development.editorconfig and review.editorconfig seperate files. We can't use file name as .editorconfig because we cannot deploy file that have this name.

• We should create CodingGuideline.targets(ProjectName.targets) file to CodingGuideline nuget package repository and put this code inside to copy development.editorconfig as .editorconfig.

  <Project>
      <Target Name="CodingGuidelineEditorConfig" AfterTargets="BeforeBuild" BeforeTargets="CoreBuild">
          <Copy SourceFiles="$(MSBuildThisFileDirectory)\development.editorconfig" DestinationFiles=".editorconfig" />
      </Target>
  </Project>
  

• When we add CodingGuideline reference to any repository with , CodingGuideline.targets will trigger automatically and copy .editorconfig file to the every project root directory.

• Pull request section is same as solution 1.

---

Summary

As you can see, we don't actually need to Directory.Build.props definition on both solutions. But of course, if you want to keep both config files in project, I cannot interfere with your business.

By the way, we decided to use .editorconfig instead of ruleset. Because this documentation says that ruleset is deprecated as you said and they recommend to use .editorconfig.

I think first solution is better than second solution. Because .editorconfig file is unique in directory level, none of the repositories/solutions/projects contain .editorconfig file. But developer have to put .editorconfig file to root repository directory by hand.

Just the opposite, second solution is more automated but whole repositories have to contain .editorconfig. Maybe there is a way to hide it from solution explorer but I couldn't research completely.

Answer 2

The .editorconfig file is not a good choice to add the custom analysis rules due to your configuration conditions.

The best way is to use MSBuild function Directory.Build.props file to add them which is more pure.

1) Create a ruleset file and add any code analysis which you want to use for Debug

2) add a file called Directory.Build.props under your project folder

3) add these under the file:

<Project>

  <PropertyGroup Condition="'$(Configuration)'=='Debug'">

    <!--the full path of your ruleset file for Debug mode-->
    <CodeAnalysisRuleSet>xxx\RuleSet1.ruleset</CodeAnalysisRuleSet>
  </PropertyGroup>


</Project>

So when you build your project with Release, the ruleset will skip due to the msbuild condition and only works for Debug mode.

You can also add another ruleset for Release mode. And add the code Analysis under the corresponding configuration in the respective ruleset files.