| description | Drop-in opinionated .editorconfig for modern C# (C# 14 on .NET 10, also works with C# 10–13) that enforces concise, readable code leveraging the latest language features. Use when setting up code-style rules, naming conventions, formatting, and preview analyzer severities for a new or existing .NET repo. Also covers the required .csproj flags (Nullable, TreatWarningsAsErrors, AnalysisLevel=preview-All, EnforceCodeStyleInBuild) and the .NET 8 vs .NET 9+ build-respect-editorconfig distinction. Generated by the `mcs-editorconfig` template. |
| metadata | {"author":"https://github.com/VincentH-Net","category":"code-style","framework":"dotnet","github-path":"plugins/dotnet/skills/dotnet-modern-csharp-editorconfig","github-ref":"refs/tags/1.2.0","github-repo":"https://github.com/vincenth-net/dotnet-agentic-engineering","github-tree-sha":"3fa2ae9ca1f0c3e39c5af315668456b03edbff81","sources":["Modern.CSharp.Templates (mcs-editorconfig)","github.com/VincentH-Net/Modern.CSharp.Templates/blob/main/Editorconfig.md"],"version":"1.1.1"} |
| name | dotnet-modern-csharp-editorconfig |
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:
| Option | Effect |
|---|
-s, --skipmanualinstructions | Suppress the printed manual-setup blurb. Use when this template runs as part of another mcs-* template chain. |
--force | Overwrite an existing .editorconfig in the folder. |
-o <dir> | Write to a specific folder instead of the current directory. |
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>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>
<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 contains
<!-- dotnet-agentic-engineering:dotnet-build-errors-and-warnings:start --> or
<!-- dotnet-agentic-engineering:dotnet-build-errors-and-warnings:skip -->.
If neither marker is present, use the ensure-directives skill first.
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
