Your .editorconfig says a rule is a warning, your editor underlines the code, and dotnet build says nothing at all. That's by design: code-style rules, the ones with IDs like IDE0044, don't run on command-line builds unless you ask. One property, EnforceCodeStyleInBuild, asks. This guide shows the same code before and after, and the fix that makes it pass.

An .editorconfig file holds a project's formatting and code-style rules: indentation, var or explicit types, readonly fields, naming. Editors such as Visual Studio and VS Code read it, so everyone gets the same style, and the .NET compiler reads it for analyzer settings. dotnet new editorconfig writes Microsoft's defaults for .NET in one command. This guide creates it, explains how to read it, and shows the part most people miss: the build ignores most of it unless you ask.

Every .NET project already runs Microsoft's code analyzers, but out of the box only a handful of their rules report anything. One property, AnalysisLevel, turns on a bigger set, from "recommended" to "all". This guide sets it on a real solution, shows exactly which new warnings appeared, and how to choose the level.

A warning that doesn't stop the build gets ignored, then joined by another, until nobody reads the build output at all. TreatWarningsAsErrors turns every warning into an error, so a new problem stops the build the day it appears. This guide turns it on for a whole solution, shows the exceptions you'll need, and what it does to NuGet's warnings, not only the compiler's.

A solution with several projects usually wants the same rules in all of them: warnings as errors, the same analysis level, the same language settings. Copying them into every .csproj works until someone adds a project and forgets. Directory.Build.props is a file MSBuild picks up automatically for every project below it, so the rules live in one place. This guide creates one, proves each project reads it, overrides it in one project, and shows the trap with a second file further down.

You don't only get the packages you reference: each one brings its own dependencies, the transitive packages, in whatever version it asked for. Oracle's MySQL provider for EF Core asks for EF Core 10.0.12 or later, and NuGet gives it exactly 10.0.12, even though 10.0.14, with two patch releases of fixes, is out. With Central Package Management, one setting lets you raise that version from the central file. This guide finds the transitive version, raises it, and checks the result.

In a solution with several projects, NuGet package versions drift: one project on EF Core 10.0.12, another on 10.0.14, and nobody notices until something breaks. Central Package Management moves every version into one file at the root, Directory.Packages.props, so each package has one version for the whole solution. This guide sets it up, moves existing versions into it, and shows the CLI commands that maintain it.

NuGet packages are how .NET C# projects use code that other people wrote: EF Core, a database driver, a JSON library. dotnet package add downloads a package and records it in your project file, so the next build, on any machine, gets the same version. This guide adds a package, pins a version, lists what's installed, tries a prerelease, and removes it again, showing what each command writes.

A web API that keeps its database code in a class library needs one line to use it: a project reference. Without it, the API can't see a single type from the library. The .NET CLI adds, lists and removes references for you, so you never edit the .csproj by hand. This guide does all three, and shows what the build says when the reference is missing.

A solution file lists the projects that belong together, so one dotnet build builds them all and Visual Studio opens them as a set. Since .NET 10, dotnet new sln creates the newer .slnx format, a short XML file you can read and review, instead of the old .sln. This guide creates one, adds projects in two ways, lists them, and converts an existing .sln.