Cannot Fail Build due to IDE0003

[wsugarman]

Analyzer

Diagnostic ID: IDE0003 : this and Me preferences

Analyzer source

SDK: Built-in CA analyzers in .NET 5 SDK or later

Version: SDK 5.0.202

AND

NuGet Package: Microsoft.CodeAnalysis.NetAnalyzers

Version: 5.0.3 (Latest)

Describe the bug

Despite the settings in the .editorconfig file, I am unable to fail my build in both Visual Studio and on the command line due to rule IDE0003.

Steps To Reproduce

1. Create a new .NET 5 console application with the following .editorconfig, project file, and source file

# editorconfig.org

# top-most EditorConfig file
root = true

# C# files
[*.cs]

# this/me
dotnet_style_qualification_for_field    = false:error
dotnet_style_qualification_for_property = false:error
dotnet_style_qualification_for_method   = false:error
dotnet_style_qualification_for_event    = false:error

dotnet_diagnostic.IDE0003.severity = error

# readonly
#dotnet_style_readonly_field = true:error

#dotnet_diagnostic.IDE0044.severity = error

# Ignore CLS Compliance attribute
dotnet_diagnostic.CA1014.severity = none

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net5.0</TargetFramework>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
  </PropertyGroup>

  <!--ItemGroup>
    <PackageReference Include="Microsoft.CodeAnalysis.NetAnalyzers" Version="5.0.3" PrivateAssets="All" />
  </ItemGroup-->

  <PropertyGroup>
    <AnalysisLevel>latest</AnalysisLevel>
    <AnalysisMode>AllEnabledByDefault</AnalysisMode>
    <CodeAnalysisTreatWarningsAsErrors>true</CodeAnalysisTreatWarningsAsErrors>
    <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
  </PropertyGroup>

</Project>

using System;

namespace AnalyzerExample
{
    public static class Program
    {
        static void Main(string[] _)
        {
            Console.WriteLine(new Dog("Fido", 3).BarkBarkBark());
        }
    }

    internal class Dog
    {
        public event Action Barking;

        public string Name { get; }

        private int _age;

        public Dog(string name, int age)
        {
            // qualified property
            this.Name = name;

            // qualified field
            this._age = age;
        }

        public string Bark()
        {
            OnBark();
            return _age > 1 ? "WOOF" : "woof";
        }

        public string BarkBarkBark()
        {
            // qualified method
            return string.Join(' ', this.Bark(), this.Bark(), this.Bark());
        }

        protected virtual void OnBark()
        {
            // qualified event
            this.Barking?.Invoke();
        }
    }
}

2. run dotnet build <project file> -warnaserror
3. Observe no failure
4. Uncomment the "readonly" .editorconfig settings as a sanity check
   • I am unsure why I need to specify dotnet_diagnostic.IDE0044.severity = error in addition to dotnet_style_readonly_field = true:error for this to fail. Perhaps this is another problem?
5. run dotnet build <project file> -warnaserror
6. View errors

Expected behavior

A failed build whose errors mention rule IDE0003.

Actual behavior

A successful build.

Additional context

Visual Studio seems to recognize the errors in its error list, but the build still passes:

[Youssef1313]

It seems like you're describing two separate issues here:

• IDE0044:

  You need dotnet_diagnostic.IDE0044.severity = error in addition to dotnet_style_readonly_field = true:error because the option = value:severity syntax isn't understood by the compiler, and is respected by IDE only (currently). There are ongoing discussions to to see if there could be a compiler support for this syntax. This is clearly documented in the Code style language rules page. Quoting the relevant part:

  The second part of the rule specifies the severity level for the rule. When specified in this way, the severity setting is only respected inside development IDEs, such as Visual Studio. It is not respected during build.

• IDE0003

  This was unfortunately disabled in command-line builds for performance reasons. This is also clearly documented in Overview of .NET source code analysis. Quoting the relevant part:

  With the .NET 5.0 SDK and later versions, you can enable code-style analysis when building from the command-line and in Visual Studio. (However, for performance reasons, a handful of code-style rules will still apply only in the Visual Studio IDE.)

[wsugarman]

I see! This makes the current state of .editorconfig files much clearer. It seems that I didn't quite absorb some critical sections of the docs.

I understand the desire to remove certain, perhaps more expensive rules, during compilation when the user didn't explicitly opt-in for analysis like in the .NET 5 SDK and beyond. But if the user has chosen to leverage an analyzer for their code explicitly using a NuGet package, either 1st or 3rd party, it would seem reasonable to me that we would run the full gamut of rules expressed in the .editorconfig. Although this may be more of a question for the roslyn-analyzer repository where I first posted this issue.

[Youssef1313]

roslyn-analyzers is completely unrelated. It's for CAxxxx and RSxxxx diagnostics.

@mavasani @sharwell Is the reason for the performance issue known?

[mavasani]

@Youssef1313 @wsugarman Please see #18950.

[sharwell]

Is the reason for the performance issue known?

Yes. IDE0003 is part of the same analysis code that drives IDE0001 (either directly in the same diagnostic analyzer, or uses the same backing service). If it was separated (e.g. how SA1101 is a standalone analyzer), it could be added to the compile-time code style analysis.

[wsugarman]

I see. Thanks @mavasani and @sharwell. It would be great to have these sort of "common" rules handled out-of-the-box by the compiler/1st part analyzers without the need of including additional 3rd party analyzers.

#18950 details the performance issue for a number of the rules. Is there a work item tracking the re-addition of these rules to build-time analysis? Or is that the aforementioned issue?