.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.

Stop Parsing the Same String Twice: CompositeFormat in .NET

Stop Parsing the Same String Twice: CompositeFormat in .NET

Every time you call string.Format() with the same format string, .NET parses it again. And again. And again. CompositeFormat changes that: parse once, reuse forever. The result? Up to 30% faster formatting, fewer allocations, and a one-line code change. Here’s why this matters and how to use it.
How SearchValues Saved Us From Scaling Hell

How SearchValues Saved Us From Scaling Hell

While you’re busy optimizing database queries and adding cache layers, thousands of string searches per second are quietly eating your CPU budget. The problem isn’t visible in your APM dashboard because it’s distributed across every request. But it’s there. Compounding. Scaling linearly with load.

I discovered this the hard way when a log processing API started choking under production traffic. The bottleneck? String validation and sanitization. The fix? A .NET 8 feature that delivered a 5x performance improvement and let us shut down servers instead of adding them. And it’s gotten even better in .NET 9 and 10.

Clean Code: A Lip Service, Not a Standard

Clean Code: A Lip Service, Not a Standard

Clean Code is often praised but rarely practiced effectively. This article explores how misunderstood ideals and over-engineering harm .NET systems, how to recognize such failures early, and which C# best practices and official guidelines truly support maintainable software.
ConstantExpectedAttribute: Compile-Time Performance

ConstantExpectedAttribute

The ConstantExpectedAttribute, introduced in .NET 7, provides a powerful mechanism to signal compiler expectations about constant values. This enables better performance optimizations, enhanced IDE tooling, and clearer API contracts. Learn how to leverage this attribute to build more efficient and maintainable .NET applications.
Retiring Legacy .NET Projects: Risk, Cost, Forward Motion

Retiring Legacy .NET

In every mature .NET landscape, legacy projects represent both heritage and hazard. They once powered entire business models — now they silently consume time, budget, and attention. The decision to retire or modernize them isn’t about technology fashion. It’s about sustaining the organization’s capacity for value creation.