CODEWITHSUNDEEP
roslynvisual-studio-2019editorconfig
Hugo Quintela Ribeiro
Hugo Quintela Ribeiro

Reputation: 779

Problem with using common .editorconfig file (imported in csproj) in Visual Studio 2019 Preview 4

I want to streamling code analysis and the respetive rules accross multiple projects and teams.

We used to do that by having a NuGet package that imported analyzers to projects (Microsoft.CodeAnalysis.FxCopAnalyzers and StyleCop.Analyzers) and defined a ruleset to define how each rule was handled by VS (error, warning, etc.).

I have been trying to setup this using a common .editorconfig file instead of the ruleset. The problem is that settings like the following just seem to be ignored when the .editorconfig file is imported from a shared folder.

dotnet_diagnostic.CA1062.severity = error

For the purpose of testing this, I have a very simple scenario that illustrates the problem.

The .editorconfig file is as follows:

[*.cs]
dotnet_diagnostic.CA1062.severity = error
#dotnet_code_quality.null_check_validation_methods = NotNull

Now this file is imported in a csproj like this:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>netstandard2.0</TargetFramework>
    </PropertyGroup>
    <Import Project="..\..\_Shared\Build.props" />
    <ItemGroup>
        <PackageReference Include="Microsoft.CodeAnalysis.FxCopAnalyzers" Version="2.9.4">
            <PrivateAssets>All</PrivateAssets>
        </PackageReference>
    </ItemGroup>
</Project>

Build.props is like this:

<Project>
    <PropertyGroup>
    <SkipDefaultEditorConfigAsAdditionalFile>true</SkipDefaultEditorConfigAsAdditionalFile>
    </PropertyGroup>
    <ItemGroup Condition="Exists('$(MSBuildThisFileDirectory)\.editorconfig')" >
        <AdditionalFiles Include="$(MSBuildThisFileDirectory)\.editorconfig" />
    </ItemGroup>
</Project>

The following code is supposed to trigger an error on CA1062:

public int Calculate(InputData input)
{
    SmartGuard.NotNull(nameof(input), input);
    if (this.Multiply)
    {
        return input.Value * 2;
    }
    else
    {
        return input.Value + 2;
    }
}

But the result is a warning:

errors list

Now, if I change .editorconfig and uncomment the second line:

[*.cs]
dotnet_diagnostic.CA1062.severity = error
dotnet_code_quality.null_check_validation_methods = NotNull

The error goes way which means that null_check_validation_methods is being considered.

Why is that dotnet_diagnostic.CA1062.severity = error is being ignored?

Upvotes: 5

Views: 3462

Answers (4)

aseman arabsorkhi
aseman arabsorkhi

Reputation: 362

as Chris Sienkiewicz said, you should set the generated file output path explicitly by adding the following to your project file:

<GenerateMSbuildeditorConfigFile>$(IntermediateOutputPath)\$(MSBuildProjectName).GeneratedMSBuildEditorConfig.editorconfig</GenerateMSbuildeditorConfigFile>

Upvotes: 0

Henrik
Henrik

Reputation: 1937

I use Visual Studio version 16.11.2 and my experience is that the problem you describe appears, as a bug, when editing a project file in Visual Studio AFTER you have added a link to it to a it as a solution item. After such an action StyleCop does not any longer listen to the .editorconfig-file of the project.

To re-trigger StyleCop errors as build errors I then have to:

  1. Remove the link to the .editorconfig for the project.
  2. Add a copy of .editorconfig to the project.
  3. Remove the copy of the .editorconfig to the project.
  4. Re-add the link to the .editorconfig.

Quite akward yes, but the above DOES trigger the errors to appear as build errors again.

Moreover, in the version of Visual Studio above, I need to have the line below in the .csproj-file:

<PropertyGroup>       
   <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
</PropertyGroup>

For previous versions of Visual Studio I had to have the lines below instead:

<PropertyGroup>       
  <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
  <WarningsAsErrors></WarningsAsErrors>
</PropertyGroup>

Upvotes: 0

Hugo Quintela Ribeiro
Hugo Quintela Ribeiro

Reputation: 779

This and other issues with the .editorconfig mechanics were reported in the following issues:

These have been solved and the original question is answered by implementing the recommendations referenced in those issues.

Upvotes: 2

Hilarion
Hilarion

Reputation: 870

The problem you have comes from the fact, that the ".editorconfig" file mechanics (which is not defined by Visual Studio or Microsoft - it's pre-existing standard) is based on where the files are located in the folder structure. It has nothing to do with the mechanics of the Visual Studio projects.

See here on Microsoft's mention of this:

When you add an .editorconfig file to a folder in your file hierarchy, its settings apply to all applicable files at that level and below. You can also override EditorConfig settings for a particular project, codebase, or part of a codebase, such that it uses different conventions than other parts of the codebase. This can be useful when you incorporate code from somewhere else, and don’t want to change its conventions.

To override some or all of the EditorConfig settings, add an .editorconfig file at the level of the file hierarchy you want those overridden settings to apply. The new EditorConfig file settings apply to files at the same level and any subdirectories.

[ hierarchy image here ]

If you want to override some but not all of the settings, specify just those settings in the .editorconfig file. Only those properties that you explicitly list in the lower-level file are overridden. Other settings from higher-level .editorconfig files continue to apply. If you want to ensure that no settings from any higher-level .editorconfig files are applied to this part of the codebase, add the root=true property to the lower-level .editorconfig file:

# top-most EditorConfig file
root = true

EditorConfig files are read top to bottom. If there are multiple properties with the same name, the most recently found property with that name takes precedence.

Or here for the EditorConfig project.

Or here for the EditorConfig specification:

File Processing

When a filename is given to EditorConfig a search is performed in the directory of the given file and all parent directories for an EditorConfig file (named “.editorconfig” by default). Non-existing directories are treated as if they exist and are empty. All found EditorConfig files are searched for sections with section names matching the given filename. The search shall stop if an EditorConfig file is found with the root key set to true in the preamble or when reaching the root filesystem directory.

Files are read top to bottom and the most recent rules found take precedence. If multiple EditorConfig files have matching sections, the rules from the closer EditorConfig file are read last, so pairs in closer files take precedence.

Upvotes: 0

Related Questions