.NET Development and Framework

Modern .NET is a platform on a release rhythm — not the static framework that some teams still imagine when they hear the name. Once you accept the LTS-and-STS cadence, almost every architectural conversation inside a .NET shop changes. Lifecycle planning becomes a quarterly topic. Major version migrations become routine rather than projects. And the question stops being “which version are we on” and becomes “what is our story for the next two.”

A recurring theme in this collection is evolution over time. The runtime, the BCL, and the SDK each move on their own track, and the interesting work happens at the seams. Dynamic PGO, tiered compilation, and the steady improvements to the JIT have changed what performance-sensitive code looks like — patterns that were defensible in .NET Framework era are now actively slower than the idiomatic version. Articles trace these shifts release by release rather than treating any single version as the canonical reference.

The BCL has been quietly transformed by additions like SearchValues<T>, FrozenDictionary, Span<T>, Memory<T>, and the surrounding ecosystem of ref struct types. These are not niche features — they are the new defaults for anyone writing hot-path code. Articles cover when reaching for them pays back, when the older API is still the right answer, and the surprising corners where they interact badly with closures, async, or older library boundaries.

SDK ergonomics deserve their own attention. Central Package Management, project-level PackageReference graphs, source generators, AOT, and the slow but real maturing of the workload model all shape what a maintainable solution looks like. Articles cover the project-system trade-offs that compound silently across a multi-year codebase.

The LTS/STS rhythm itself is treated as a planning concern. Articles cover how to schedule upgrades against a real release window, when to skip an STS release, and how to keep the upgrade muscle exercised so that the next migration is not the one that breaks things.

Structured Logging Patterns That Actually Survive Production

Structured Logging That Survives

Every pattern here addresses a failure mode I have either shipped or inherited. Source generators on hot paths, scope opt-in per provider, end-to-end correlation ID propagation, log levels as an ops contract, sink selection as an architecture decision, and OpenTelemetry Logs for greenfield services: six concrete changes that make structured logging trustworthy in production.

TimeProvider Test Patterns That Hold Up in CI and Production

FakeTimeProvider gives you a clock you control. That solves the easy 30%. The hard part is everything that interacts with that clock: async callbacks, PeriodicTimer, CancellationTokenSource.CancelAfter, BackgroundService loops, and DI lifetime traps that turn deterministic bugs into apparently flaky tests.

Standardize or Drift: One Defaults Package for All Your Solutions

Directory.Build.props drift is the quiet tax every multi-repo .NET org pays. NetEvolve.Defaults ships MSBuild properties, .editorconfig, NuGet Audit, and ten Roslyn diagnostics as a private-asset NuGet package. Bump the version once, every repo gets the upgrade.

.NET 11: The STS Release With C# 15 Union Types and Runtime-Async

STS releases are supposed to be quiet bridges to the next LTS. .NET 11 is not. The union keyword landed in Preview 2, runtime-async is now the default for the BCL and ASP.NET Core shared framework, System.Diagnostics.Process ships a major overhaul, and EF Core gains approximate vector search against SQL Server 2025. All facts sourced from the .NET repositories.

TUnit.Mocks: No Castle, No Reflection, No Drama

Most .NET test projects rely on NSubstitute and Castle.DynamicProxy. That foundation is cracking: NativeAOT breaks it, trimming strips it, cold-start costs accumulate. TUnit.Mocks takes a different route: a source generator emits typed mocks at compile time, IService.Mock() (or Mock.Of<T>()) is the entry point, runtime reflection is gone.