280 posts tagged with "C#"

To use EF Core with MySQL you need a database provider, a NuGet package that teaches EF Core how to talk to MySQL. There are two serious choices: Oracle's MySql.EntityFrameworkCore and the community's Pomelo.EntityFrameworkCore.MySql. For a long time Pomelo was the usual answer. For EF Core 10, the deciding fact is simpler: only one of them has a release. Here's what I checked, from the package feed and the package files themselves, and what I learned building a .NET 10 Web API on Oracle's provider.

A package can be fine the day you add it and have a published security advisory the next month. .NET checks for that on its own, every time it restores packages, and dotnet package list --vulnerable gives you the full report on demand. This guide runs both on a clean solution, adds a package version with a known vulnerability, reads the report, and moves it to a safe version.

Packages get patch releases with bug and security fixes all the time, and nothing tells you unless you ask. dotnet package list --outdated asks: it compares every package a project references with the newest version on nuget.org. And since .NET 10, dotnet package update applies the update in one command. This guide finds an outdated package, updates it, and checks again.

Before adding a package, you usually want two answers: which package, and which version. dotnet package search gets both from nuget.org without leaving the terminal. This guide searches by keyword, lists every version of one package, includes previews, and switches to JSON, using a real question as the example: which EF Core providers for MySQL support EF Core 10?

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.