Modern C# 14 .editorconfig

Use when setting up (or overhauling) code style, naming, formatting, and analyzer severities for a modern C# codebase — one that targets .NET 10 / C# 14, or any C# 10–13 project that wants to adopt the same modern conventions.

The output is a single .editorconfig dropped into the current folder, tuned to promote:

• Conciseness — expression-bodied members, target-typed new(), collection expressions [ ], primary constructors, file-scoped namespaces, and other C# 12–14 idioms
• Readability — consistent spacing, braces, and using ordering
• Latest language features — analyzer severities flipped on for modern-idiom diagnostics

Scope covers formatting, code style, naming style, and analyzer severities — all in one file.

1. When to use this skill

Apply when any of the following is true:

• Starting a new .NET 10 / C# 14 repo and want an opinionated style baseline
• Adding a repo-root .editorconfig to an existing solution that currently has none
• Replacing an aging .editorconfig with one that flips on preview analyzers and modern-feature diagnostics
• Standardizing style across a multi-project solution — drop at the repo root, every project inherits
• Combining with other mcs-* templates that already trigger this generation (pass -s to skip the standalone blurb)

If the repo already has an .editorconfig in the target folder, do NOT edit, merge, patch, or add the template URL to the existing file. Ask the user whether to replace it with the generated Modern C# baseline. If the user says no, STOP. If the user says yes, run dotnet new mcs-editorconfig --force in the target folder.

2. Prerequisites

.NET CLI on PATH. First-time install of the template package:

dotnet new install Modern.CSharp.Templates

Confirm availability:

dotnet new list mcs

3. Generate the file

Run in the folder where the .editorconfig should live (typically repo root so every project inherits):

dotnet new mcs-editorconfig

Options:

4. Required .csproj settings

The .editorconfig alone does not enforce style on dotnet build. Add this PropertyGroup to Directory.Build.props in the same folder as .editorconfig so it applies in all .csproj files in or below that folder:

<PropertyGroup>
  <Nullable>enable</Nullable>
  <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
  <AnalysisLevel>preview-All</AnalysisLevel>
  <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>

  <!-- GenerateDocumentationFile is true to enable IDE0005 (Remove unnecessary usings/imports) on build.
       This also enables CS1591 (Missing XML comment for publicly visible type or member);
       for projects that do not require comprehensive XML documentation,
       exclude CS1591 with the MSBuild NoWarn property to prevent XML doc slop. -->
  <GenerateDocumentationFile>true</GenerateDocumentationFile>
</PropertyGroup>

In ALL .csproj files in or below the folder where the .editorconfig resides, ensure that CS1591 is excluded with NoWarn to prevent XML doc slop. For example, to exclude CS1591:

<PropertyGroup>
  <!-- Exclude CS1591 to prevent XML doc slop if this project does not require comprehensive XML documentation.
       Do NOT set GenerateDocumentationFile to false; it is required for the 
       IDE0005 (Remove unnecessary usings/imports) analyzer to function. -->
  <NoWarn>$(NoWarn);CS1591</NoWarn>
</PropertyGroup>

This MUST be in .csproj files; it cannot be in the Directory.Build.props file because some projects may require comprehensive XML documentation while others do not; excluding CS1591 must be an explicit choice per project. By excluding CS1591 in all project files initially, we enable opt-in to comprehensive XML documentation on a per-project basis by removing CS1591 from that project's NoWarn list.

5. Opinionated choices worth calling out

• No underscore prefix on private fields. Naming rules permit camelCase for private instance fields and reject _camelCase. This is a deliberate divergence from the common underscore-prefix convention — if your repo has existing _field code, a repo-wide rename is implied.
• Rationale for every non-default setting is documented inline inside the generated .editorconfig. Read the file comments before editing, and update the comment if you change a rule.

6. Combining with other mcs templates

Other mcs-* templates may generate their own .editorconfig already based on this one. In particular:

• mcs-orleans-multiservice writes an extended .editorconfig at the solution root that builds on this baseline and layers Orleans-specific rules on top. Do not run mcs-editorconfig separately in that solution — the extended file is already there. See the orleans-multiservice-pattern skill.

When this template is chained into a custom project-generation flow (not superseded by another template that already includes it), suppress the standalone instructions blurb:

dotnet new mcs-editorconfig -s

7. Build diagnostic handling

Before building, check whether AGENTS.md (or AGENTS.MD) in the current working folder or any parent folder up to the repository root contains <!-- dotnet-build-errors-and-warnings:start -->. If the marker is absent, do not build. Ask the user to exit this agent session, run dna check (or dnx agentic.check) in the folder that holds the AGENTS.md to update (usually the repository root), and restart or resume the session, because the updated AGENTS.md only loads at session start. Stop until that is done.

Use the installed dotnet-build-errors-and-warnings directive for build verification and diagnostic fixes. That directive governs when to run dotnet format, how to fix build errors and warnings, and when suppressions are allowed.

8. Verification

After generation and csproj wiring, confirm the rules take effect at build:

dotnet build

A clean build with no IDE* / CA* diagnostics confirms the editorconfig + csproj combination is active. If you expect diagnostics to fire and none appear, re-check EnforceCodeStyleInBuild and, on .NET 8, AnalysisLevel.

References

• Modern.CSharp.Templates — Editorconfig.md
• NuGet: Modern.CSharp.Templates