One Source of Truth for Code Style: .editorconfig and Build-Time Enforcement in Visual Studio

The Problem: IDE Warnings That Disappear in CI

Your team agrees on a code style. Everyone installs the same Visual Studio extensions. Yet the CI build passes while a developer's Error List shows dozens of suggestions. The next pull request merges code that violates the agreed rules because the pipeline never saw them. This mismatch happens because Visual Studio's code-style analyzers run in the IDE by default, but many of them stay silent during dotnet build unless you opt in.

How .editorconfig Becomes the Single Source of Truth

.editorconfig is a cross-editor convention that Visual Studio reads to drive formatting, naming, and code-style analyzer behavior. A file with root = true at the repository root establishes the baseline; nested files in subfolders can override specific sections. Because the file lives in source control, every developer and every build agent reads the same rules—no extension sync required.

Code style rules surface as IDE diagnostic IDs (for example IDE0007 for "use var when type is apparent"). In .editorconfig you assign a severity per rule using the pattern dotnet_diagnostic..severity = suggestion|warning|error. You can also use the friendlier property names like csharp_style_var_when_type_is_apparent = true:suggestion; both forms are supported and map to the same underlying analyzers.

Making the Build See What the IDE Sees

By default, many IDE style analyzers run only inside Visual Studio. Setting the MSBuild property EnforceCodeStyleInBuild to true in a Directory.Build.props or a project file makes a subset of those analyzers execute during command-line and CI builds. The subset and exact behavior depend on the .NET SDK version, so verify against the SDK you pin in CI.

Worked Example: From Repository Root to CI Warning

Below is a minimal, complete setup you can drop into a new or existing .NET solution. Create the files exactly as shown, then run dotnet build from the solution root to confirm the diagnostic appears in the build output.

1. Repository-root .editorconfig

# .editorconfig at repo root
root = true

[*.cs]
# Prefer 'var' when the type is obvious
csharp_style_var_when_type_is_apparent = true:suggestion
# Also surface the same rule via diagnostic ID at warning level
dotnet_diagnostic.IDE0007.severity = warning

2. Directory.Build.props (beside your .sln)

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

3. Test file to trigger the rule

// TestClass.cs
public class TestClass {
    public void Method() {
        System.String s = "hello"; // IDE0007: use var
    }
}

4. Run the verification

# From the solution root (requires .NET SDK installed)
dotnet build

Expected result: the build output includes a warning for IDE0007 on the line that declares System.String s. Open the same project in Visual Studio and the Error List should show the same warning (or suggestion, depending on your IDE settings).

Trade-offs and Limitations

• IDE vs. build parity is not guaranteed. Some analyzers are IDE-only; others change severity or behavior between the Visual Studio version on your machine and the .NET SDK used by CI. A rule that errors locally may only warn—or not run at all—in the pipeline.
• Version drift matters. Diagnostic IDs, default severities, and the set of build-enforceable rules shift across Visual Studio and SDK releases. Pin the SDK in CI (e.g., via global.json) and record the Visual Studio version developers use.
• Staged migration beats big bang. Turning many rules to error at once blocks builds and creates noisy churn. Start with formatting and a few high-value rules at suggestion or warning, clean the codebase, then promote selected rules to error.
• Precedence surprises. A misplaced root = true in a subfolder silently disables inheritance from the repo root. Test nested overrides explicitly.

How to Verify Locally Before Committing

1. Create a throwaway C# project (dotnet new console -o VerifyStyle).
2. Add the .editorconfig and Directory.Build.props shown above.
3. Run dotnet build and confirm the warning appears.
4. Open the project in Visual Studio; compare the Error List severity with the build output.
5. Add a nested .editorconfig in a subfolder with dotnet_diagnostic.IDE0007.severity = error and rebuild to confirm precedence.
6. Run the same build in CI with your pinned SDK and compare logs.

Treat .editorconfig and Directory.Build.props as versioned source code. Review them in pull requests, and check Microsoft's current documentation for the properties and analyzer IDs you rely on—names and defaults evolve.