Command Line Interface Tools and Techniques
View All Tags
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.
A migration is applied, and you need it undone: it was a mistake, or you want to test it again from the start. EF Core reverts migrations with the same command that applies them, dotnet ef database update, pointed at an earlier migration. This guide reverts one migration, then all of them, and shows the two things to check before you do it on a database you care about: whether Down can undo the data, and what it deletes.
You ran dotnet ef migrations add, looked at the result, and it's wrong: a missing setting, a typo in the name, a change you didn't mean to include. dotnet ef migrations remove undoes it cleanly, as long as the migration hasn't been applied. This guide removes an unapplied migration, shows the error when it was applied, and the two ways forward from there.
