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

NuGet Packages: The Suppliers You Forgot to Audit

NuGet Packages: The Suppliers You Forgot to Audit

Every NuGet package is a supplier relationship under ISO 27001. Learn how to implement Central Package Management, automated vulnerability scanning, and package signature verification to transform your .NET dependency management from security liability into auditable compliance control.
Stop Hoarding Personal Data in Entity Framework

Stop Hoarding Personal Data in Entity Framework

The classic monolithic User entity—stuffed with birth dates, phone numbers, employment history, and marital status “just in case”—turns into a compliance nightmare the moment someone requests data deletion. You can’t delete without breaking referential integrity. You can’t keep the data without violating GDPR. You can’t anonymize without retaining fields that should never have existed. The solution isn’t complex: separate operational data from personal data, make consent-based fields nullable and purpose-documented, implement soft deletes with query filters, and validate your API boundaries with integration tests that fail when unnecessary fields leak through. Data minimization isn’t regulatory overhead—it’s architectural hygiene that makes your deletion logic straightforward and your audit responses honest.
Your Encryption Is Broken — .NET Data Protection Done Right

Your Encryption Is Broken — .NET Data Protection Done Right

Every developer who has tried simple encryption with XOR and hardcoded keys eventually faces the audit that exposes their house of cards. I’ve watched production systems fail compliance assessments because someone believed base64 encoding was good enough or that compilation obscures secrets. The .NET Data Protection API exists precisely because Microsoft’s cryptography team spent years solving problems most developers don’t know they have. This isn’t about learning yet another library—it’s about understanding why professional implementations outperform clever hacks, and how Azure Key Vault integration transforms theoretical security into auditable compliance.
Your appsettings.json Is a Compliance Violation

Your appsettings.json Is a Compliance Violation

Hardcoded secrets aren’t just bad practice—they’re ISO 27017 violations with real consequences: failed audits, denied insurance claims, contractual penalties. That connection string in your appsettings.Production.json? It represents a compliance gap your organization probably doesn’t even know exists. Azure Key Vault with Managed Identity isn’t an optional security enhancement—it’s the minimum viable implementation of standards you already claim to follow.
Audit Logging That Survives Your Next Security Incident

Audit Logging That Survives Your Next Security Incident

Your audit logs probably won’t survive a real security incident. Most implementations log too much, protect too little, and provide zero value when something breaks at 2 AM. Here’s how to fix that with structured logging that actually works.