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

Your [Authorize] Attribute Is Compliance Theater

Your [Authorize] attributes give you a false sense of security. ISO 27001 auditors see right through it.

I’ve reviewed dozens of ASP.NET Core apps that authenticate flawlessly — then scatter role strings across business logic, skip audit logs, and wonder why they fail compliance. Here’s the pattern that kills audits, and how to actually fix it.

Why ISO Standards Actually Matter for .NET Developers

Cloud-native .NET development has transformed ISO/IEC 27001, 27017, and 27701 from abstract compliance requirements into concrete daily coding decisions. This guide shows .NET developers how security standards directly map to Azure Key Vault integration, Azure AD authentication, and proper logging—with real code examples demonstrating compliant vs. non-compliant implementations.

ISO/IEC 27001, 27017 & 27701 for .NET Developers — The Complete Series

ISO/IEC 27001, 27017, and 27701 compliance used to be something you handed off to a compliance team. Now you write the infrastructure, configure the secrets store, and decide what the API returns — and those decisions are the compliance. This series translates nearly 30 controls across three standards into working .NET code and Azure configuration, because the gap between certified and actually compliant lives in your codebase.

Real Professional Software Engineering in the AI Era

Throughout this series, we’ve established that AI-generated code without understanding creates productivity illusions that collapse in production (Part 1), and that the feedback loop between code and reality—compilation, testing, profiling, production—sharpens thinking in ways AI can’t replicate (Part 2). Now we confront the practical question: What defines professional software engineering when code generation becomes trivial? This final part examines the irreplaceable skillset: understanding execution characteristics (recognizing allocation patterns that cause GC pressure before deployment), asking questions AI can’t formulate (What’s the failure mode when this service is unavailable?), recognizing when plausible AI solutions diverge from correct ones, debugging production failures AI has no execution model to reason about, and evaluating maintainability for code that becomes tomorrow’s burden. We explore why prompt engineering optimizes for speed while architecture optimizes for survival, why “AI productivity” often means faster technical debt accumulation, and why the economic reality favors organizations that measure system reliability over lines of code generated. The feedback loop can’t be automated because closing it requires learning from production failures and applying that knowledge to prevent future ones—the irreplaceable discipline that defines real professionals in 2026 and beyond.

The Feedback Loop That AI Can't Replace

In the first part of this series, we established that AI-generated code without understanding creates an illusion of productivity that collapses under production load. The differentiator isn’t typing speed—it’s the feedback loop where code meets reality and exposes incomplete thinking. But what exactly is this feedback loop, and why can’t AI replicate it? Modern compilers validate logical consistency, catching gaps pure thought leaves unresolved. Profilers expose the 75x performance difference between “seems reasonable” and “actually performs.” Production environments reveal every assumption abstract thinking deferred—scale, concurrency, failure modes. This article explores the mechanisms that transform vague reasoning into concrete understanding: compilation validates logic instantly, testing catches behavioral mismatches, profiling measures what abstract analysis guesses, and production exposes the cost of every deferred decision. Real professionals don’t just write code—they master the iterative discipline of watching it fail, understanding why, and refining their thinking. AI participates in parts of this loop, but it can’t close it. That’s where professionals remain irreplaceable.