.NET Development and Framework

.NET is Microsoft’s open-source, cross-platform development framework for building modern applications. From web APIs and cloud services to desktop and mobile apps, .NET provides a comprehensive ecosystem for software development across platforms and deployment targets.

.NET Platform Evolution

.NET 6+ unified the framework, bringing together .NET Core, .NET Framework, Xamarin, and Mono into a single platform with consistent APIs, performance improvements, and long-term support releases. Modern .NET emphasizes cross-platform compatibility, cloud-native architecture, and high-performance runtime characteristics.

ASP.NET Core powers web applications and APIs with minimal APIs, Blazor for interactive web UIs, SignalR for real-time communication, and gRPC for high-performance service communication.

Performance and Productivity drive .NET evolution. Each release brings runtime improvements, compiler optimizations, and language features that reduce boilerplate while maintaining type safety and performance.

.NET Ecosystem

Articles in this section explore .NET runtime features, framework updates, ASP.NET Core patterns, performance optimization, deployment strategies, and integration with cloud platforms. Topics include new language features, framework capabilities, migration paths, and best practices for .NET development.

The focus is practical .NET development: leveraging framework capabilities effectively, staying current with platform evolution, and building maintainable applications that scale.

Purpose Limitation in API Design: Leaking Data You Shouldn't

Purpose Limitation in API Design: Leaking Data You Shouldn't

Most APIs expose personal data based on database entities, not caller needs. When a password reset endpoint returns a user’s full profile, purchase history, and marketing preferences, that’s purpose drift. This article shows how to restructure ASP.NET Core APIs around caller purposes using resource-based authorization, consent validation, and field-level access control.
"We Store Secrets in appsettings.json": A Horror Story in Five Acts

"We Store Secrets in appsettings.json": A Horror Story in Five Acts

Every Azure subscription I’ve worked with has the same problem: connection strings with embedded credentials in appsettings.json, Service Principal secrets checked into Git history, storage account keys hardcoded everywhere. The credential sprawl is real. These aren’t careless developers. These are smart people applying on-premises patterns where they don’t belong. Azure Managed Identity flips the model entirely. Instead of your application proving identity by presenting a secret, Azure proves identity on your application’s behalf through cryptographic attestation. No secrets in code. No credentials in configuration. No rotation ceremonies. The Azure SDK’s DefaultAzureCredential handles authentication automatically, working identically in local development and production. Combined with RBAC, you scope permissions to exactly what each application needs. Not Contributor-level access to the entire subscription. Just the specific operations on specific resources that the application actually requires. This article walks through credential anti-patterns I encounter constantly, then shows the correct implementation using Bicep and .NET’s DefaultAzureCredential. The migration path is pragmatic: within weeks, not months, you can have zero static credentials in your codebase.
"Just Delete the User": Famous Last Words Before the GDPR Audit

"Just Delete the User": Famous Last Words Before the GDPR Audit

Your PM thinks erasure is a quick database DELETE. Three weeks later, you’ve found user data in seventeen places: production DB, analytics warehouse, Redis cache, Elasticsearch, backup tapes, and that legacy system nobody dares touch. “Delete” actually means orchestrating coordinated erasure across distributed systems, maintaining audit trails, notifying third parties, and proving it worked. This guide shows the fatal patterns I’ve seen fail spectacularly, then walks through proper orchestration with Azure Durable Functions, soft-delete with anonymization, verification checks, and immutable audit logs.
Privacy Health Checks: Beyond Database Connectivity

Privacy Health Checks: Beyond Database Connectivity

Your health checks verify database connectivity every 30 seconds. Great. But do they know that 15% of your users have expired consents? Privacy compliance isn’t a documentation exercise—it’s an operational discipline. Same IHealthCheck interface, different questions. Two queries, one ratio, three possible outcomes. Here’s how to build privacy health checks that turn audit questions into dashboard demos.
Green Dashboard, Dead Application

Green Dashboard, Dead Application

Your application just crashed in production. Azure App Service kept routing traffic to the failing instance for ninety seconds. Users saw timeouts. Your monitoring dashboard stayed green because the web server responded with HTTP 200 while the database connection pool was exhausted.

I’ve watched this exact scenario play out at three different organizations in the past year. Each time, the post-mortem revealed the same root cause: health checks that verified the process was breathing without checking whether it could actually do its job. ISO/IEC 27001 Control A.17.2.1 exists precisely for this reason—availability is a security control, not an operational afterthought.

Your Stack Traces Are Love Letters to Attackers

Your Stack Traces Are Love Letters to Attackers

Your exception handler returns detailed stack traces to be “helpful.” Congratulations, you’ve just handed attackers your internal file paths, database technology, and architecture details. This guide shows how to implement error handling that satisfies security audits: comprehensive internal logging paired with generic client responses, correlation IDs for support, and environment-aware middleware.
Your Logout Button Is Lying: ASP.NET Session Security Done Right

Your Logout Button Is Lying: ASP.NET Session Security Done Right

That StackOverflow answer suggesting Session.Timeout = Int32.MaxValue for “better UX”? It’s how security becomes checkbox theater. Sessions that never expire, logout buttons that don’t invalidate tokens, cookies transmitted over HTTP—auditors catch these patterns immediately. Here’s how to configure ASP.NET Core authentication that actually works.
Cookie Banners Won't Save You From ISO 27701

Cookie Banners Won't Save You From ISO 27701

That boolean column you call “consent”? Regulators will laugh at it.

ISO 27701 demands granular, auditable, expiring consent, not cookie theater. Here’s the complete .NET implementation with Entity Framework Core, middleware validation, and Azure Functions that survives an audit.

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.