Csharp

.NET 8 and .NET 9 reached the end of support today with the release of .NET 11 as the STS, joining .NET 10 as the LTS. If you’re still on 8 or 9, you no longer have a choice about moving, only a choice of where you land. Some of what hurt you on 8 gets fixed in 11. Some of what worked fine on 8 quietly stops working the way you expect, and that second kind is worth more of your attention than the changelog gives it: a few of those changes break the build and tell you immediately, a few crash on startup, and a few compile, pass your tests, and just behave differently. That last group is the one that costs you money, because nothing tells you it happened. ...

I use EF Core almost exclusively for database access in my .NET projects. For the write side of almost any app, I want an aggregate that protects its own invariants, a repository that hides the database, and a unit of work that commits a transaction. EF Core gives me all of that without much ceremony. So when I say “here’s when I reached for Dapper,” I want to be clear up front: this isn’t a recommendation to replace EF Core, or even to use Dapper regularly. It’s a description of one place where EF Core’s own tools stopped being enough, and the rules I set for myself before I let a second data access library into the codebase. ...

TL;DR for leaders: on the same 1 vCPU / 2GB container, an ASP.NET Core endpoint written with correct async/await sustained roughly 9 times the request rate of an identical endpoint that blocks on the same call (.GetAwaiter().GetResult() instead of await), before the bad version collapsed entirely under load. At 2,000 requests/second, that’s the difference between 1 container and 9, or roughly $12/month versus $112/month on Azure App Service for the compute alone, scaling worse the more traffic you add. The code difference between the good and bad versions is a single line. This is a measured result from a benchmark you can run yourself, not a vendor estimate; see “Caveats” below for what it does and doesn’t tell you about your own system. ...

.NET 11 is currently in Release Candidate 1 (shipped September 8, 2026), with general availability expected at .NET Conf in November 2026. Everything below was built and tested against the .NET 11.0.100-rc.1.26425.128 SDK, running inside the official mcr.microsoft.com/dotnet/sdk:11.0.100-rc.1 Docker image. Some of this could still change before GA; see the companion code for the runnable version of every test referenced here. ...

EF Core 11 is still in development as of this writing (based on the Microsoft Learn docs for EF Core 11, last updated August 2026). Some of what’s below could change before release. I tested against the mcr.microsoft.com/dotnet/nightly/sdk:11.0-preview image (resolving to SDK 11.0.100-rc.1.26411.119) and Microsoft.EntityFrameworkCore.SqlServer 11.0.0-preview.6.26359.118; see the companion code for the runnable version of every SQL example below. EF Core 11 ships alongside .NET 11, and it requires the .NET 11 SDK to build and the .NET 11 runtime to run; there’s no running it on .NET 10 or earlier, and definitely not on .NET Framework. ...

Somewhere in your codebase there is a switch with a _ => arm that throws for anything it doesn’t recognize, because the type it’s switching on never told the compiler what “everything” meant. This is a story about that arm, and the C# 15 feature that retires it. 2:03 a.m. The pager goes off. Finance has noticed that bank transfers, the thing your team shipped last sprint, are being processed for exactly zero dollars in fees. Not a discount. Not a promotion. Just free, quietly, for every customer who picked that option. ...

This post answers two separate questions. First: why reach for Span<T> and ReadOnlySpan<T> at all? They’ve been performance powerhouses since C# 7.2 / .NET Core 2.1: zero-allocation, type-safe views over memory that show up all over modern .NET’s hot paths. Second: what does C# 14 change about getting into one? Shipping with .NET 10, it makes spans first-class language citizens, with new implicit conversions that cut ceremony and let the compiler infer types in places it used to give up. That second change is about ergonomics, not speed; it doesn’t make Span<T> any faster than it already was, it just makes it easier to reach for. ...

Introduction Polly is a .NET resilience and transient-fault-handling library. It lets you express strategies like retry, circuit breaker, timeout, rate limiting, hedging, and fallback around any piece of code, so a flaky downstream dependency doesn’t automatically become an outage in your own service. If you used Polly a few years ago and haven’t looked at it since, the library you remember is gone. Polly v8 was a ground-up rewrite, built in collaboration with Microsoft, and it changes both the API and the mental model. This post is a practical, current tour of what Polly looks like today: pipelines instead of policies, the built-in HTTP resilience handlers, hedging, chaos engineering support, and the one thing that’s changed about the license terms that maintainers of paid products should know about. ...

Introduction I have long waffled on whether a GUID or integer make for the best primary key. I wrote this with the goal of refining or challenging my current opinion. The identity, or primary key, uniquely identifies an entity or record. To be clear, ‘identity’ is a Domain Driven Design concept that describes an immutable identifying attribute of an entity (not to be confused with a SQL Server identity column, which is an automatically incrementing integer). A ‘primary key’ is a database concept that serves the same purpose for a record and enforces referential integrity. In this post, I will use the term ‘primary key’, since we are focusing on the database. The concept of an identity attribute is more than just a database concern, it is a domain concern, but it is important to consider where these concerns intersect. ...