16 posts tagged with "Configuration"

builder.Services.AddDbContext(...), options binding, validation, retries, health checks: Program.cs fills up fast, and the database setup ends up scattered between other features. ASP.NET Core's own answer is the AddXyz method: AddControllers, AddHealthChecks, AddOpenApi. You can write your own the same way, as an extension method on IServiceCollection. This guide builds one for an EF Core database, calls it with one line, and shows its startup checks catching mistakes.

A new ASP.NET Core project listens on a port the template picked at random, such as 5255. That's fine until you write it into a .http file, a README or another app's settings, and a teammate's copy uses a different one. There are three ways to choose the port, for different situations. This guide tries each one on the same .NET 10 Web API and shows which one wins.

Sometimes an analyzer rule is right for your code and wrong for one folder of it: generated files, migrations, a third-party snippet. Turning the rule off for the whole project throws away its value everywhere else. .editorconfig can set a rule's severity for files that match a pattern, so the rule stays on everywhere except where it doesn't apply. This guide does it for CA1861 in EF Core migrations, and proves the rule still works outside that folder.

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.