标签：#dotnet

I built CreditMeter, a small Windows tray app that shows GitHub Copilot AI-credit usage like a taxi meter. Why I built it Agentic coding makes AI usage feel invisible until you look at the bill. Constraints no WinForms no WPF no backend no telemetry no dependency-heavy architecture Tech stack C# / .NET 9 Native AOT raw Win32 / PInvoke GitHub REST API DPAPI for local PAT storage What I learned For tiny tools, architecture is also about knowing what not to add. Repo https://github.com/cdilorenzo/CreditMeter

If you've ever written test data by hand, you know the ritual: a PersonBuilder , an OrderBuilder , an AddressBuilder … one hand-written builder per class, each one a wall of WithX(...) methods you have to maintain forever. The Test Data Builder and Object Mother patterns are great — the boilerplate is not. XModelBuilder gives you a fluent builder for any C# class out of the box. No per-class builder required. It handles constructor parameters, init-only properties, read-only members, even private backing fields — via reflection, deterministically. Install dotnet add package XModelBuilder 30-second example You can use it fully standalone (no DI container) through a small static facade: using XModelBuilder.Default ; var order = For . Model < Order >() . With ( x => x . OrderDate , new DateTime ( 2026 , 7 , 1 )) . With ( x => x . Lines [ 0 ]. Product , "Widget" ) // deep paths + indexers just work . With ( x => x . Lines [ 0 ]. Quantity , 3 ) . Build (); No OrderBuilder , no OrderLineBuilder . The Lines[0].Product path drills into a nested collection element and sets it for you. Need a whole list? Create.Models<Order>(10) . Deterministic fakers, seeded once Random test data that changes every run is a debugging nightmare. XModelBuilder ships a seeded, dependency-free faker (and a Bogus integration if you prefer). Register it once: services . AddXModelBuilder () . AddXFaker ( seed : 12345 ); // reproducible values, every run Then let it fill in the noise while you set only what your test actually cares about: var order = xprovider . For < Order >() . With ( x => x . Id , p => p . XFake (). NewGuid ()) . With ( x => x . Customer . Name , p => p . Bogus (). Company . CompanyName ()) . With ( x => x . Lines [ 0 ]. Quantity , 3 ) . Build (); XFake().NewGuid("customer-acme") even gives you a stable GUID from a name — same key, same GUID, regardless of call order or parallelism. Deterministic by design. Build a whole list: BuildMany Need ten of something, each slightly differ

This post was originally published on MatrixTrak.com — the production reliability toolkit for trading bot operators and .NET engineers. When requests hang forever and recycling releases stuck work: why missing timeouts create backlog, how to add budgets safely, and the rollout plan that prevents new incidents.. Most production incidents do not start as "down." They start as waiting. At 09:12 a dependency slows down. Your ASP.NET instances look healthy. CPU is fine. Memory is fine. But requests stop finishing. In-flight count climbs. Connection pools stop turning over. You scale out and it does not help because the new instances just join the waiting. The cost is not subtle. Backlog grows, SLAs fail, and on-call starts recycling processes because it is the only thing that releases the stuck work. Then the incident repeats next week because nothing changed about the waiting. This post gives you a production playbook for .NET: how to set time budgets, wire cancellation, and roll it out without triggering a new outage. Rescuing an ASP.NET service in production? Start at the .NET Production Rescue hub . If you only do three things Write down a total budget per request/job (then enforce it). Set per-attempt timeouts for each dependency and log elapsedMs , timeoutMs , and the decision (retry/stop/fallback). Propagate cancellation end-to-end so work stops (no zombie work after timeouts). Why requests hang forever: infinite waits capture capacity Missing timeouts are not a performance problem. They are a capacity problem. When a call can wait forever, it will eventually wait longer than your system can afford. While it waits, it holds something your service needs to operate: a worker slot, a thread, a connection, a lock, or a request budget. Once enough requests or jobs are holding those resources, the system stops behaving like a service and starts behaving like a queue you did not design. From the outside it looks like "everything is slow." Underneath, you are accumulating

I'm launching SmartTaxCalc.in on Product Hunt on Tuesday, 14 July 2026 . It's a 38-tool Blazor WebAssembly tax + finance calculator I've written about here before ( the SEO/schema saga , and dropping mobile LCP from 6-8s to under 2s ). The Product Hunt launch algorithm heavily rewards products that arrive with a real coming-soon follower base — day-of upvotes correlate strongly with pre-launch "Notify me" clicks. My PH page started with 1 follower . I had 9 days to get to 50+. The obvious answer: post on LinkedIn, ask friends, DM your network. All of that has ceilings (you can only ask a favor once). The non-obvious answer that has no ceiling: convert your own organic search traffic into PH followers automatically. This is the ~100 lines of Blazor code that does that, plus the design decisions I made along the way. It's also self-cleaning — after the launch date, the banner disappears with no manual work required. Steal the pattern for your own launch. The problem SmartTaxCalc gets modest but real organic traffic — mostly from Google Search Console impressions on tax-season queries. That traffic is the warmest possible audience for a PH launch (they already found the site, they're in the target demo). But how do you route them to a PH page without: Disrupting the tax content (they came for a tax calculator, not a marketing pitch) Cannibalizing the existing tax-season banner (which drives users to /tax-calendar/ — a real retention lever) Leaving code debt after 14 July (a dead PH banner still on the site in September) Losing the dismiss preference across page navigations (SPA reality — no page refresh) Those constraints ruled out a modal, a full-width interrupt, and a "hardcoded remove after launch" approach. The design Slim horizontal bar at the top of every page. Sits ABOVE the existing tax-season banner. PH-brand orange, different from the tax-season banner's yellow/red so both are visually distinguishable when stacked. Dismissible per-user via localStorage . Auto

ASP.NET Core: Building High-Performance Web Applications and APIs A practical guide to ASP.NET Core — the cross-platform framework for building REST APIs, MVC applications, and backend services on .NET, covering architecture, minimal APIs, middleware, performance, and modern patterns. Table of Contents Introduction Architecture Overview Minimal APIs MVC and Controllers Middleware Pipeline Dependency Injection Configuration and Options Authentication and Authorization Performance Features Testing and Observability Quick Reference Table Conclusion Introduction ASP.NET Core is a free, open-source, cross-platform framework for building web apps, APIs, and backend services. It's a ground-up rewrite of the original ASP.NET, designed around three priorities: Performance — it's consistently one of the fastest mainstream web frameworks in independent benchmarks (e.g., TechEmpower). Modularity — you opt into only the middleware and services your app actually needs, instead of a fixed, heavyweight pipeline. Cross-platform — runs identically on Windows, Linux, and macOS, and deploys to containers, serverless, or bare metal. This guide covers the core building blocks you'll use in almost any ASP.NET Core project, from a five-line minimal API to a full MVC application with authentication and background services. 1. Architecture Overview Every ASP.NET Core app starts from a unified entry point — Program.cs — using the minimal hosting model introduced in .NET 6. var builder = WebApplication . CreateBuilder ( args ); // Register services (dependency injection container) builder . Services . AddControllers (); builder . Services . AddEndpointsApiExplorer (); builder . Services . AddSwaggerGen (); var app = builder . Build (); // Configure the HTTP request pipeline (middleware) if ( app . Environment . IsDevelopment ()) { app . UseSwagger (); app . UseSwaggerUI (); } app . UseHttpsRedirection (); app . UseAuthorization (); app . MapControllers (); app . Run (); Two phases matter here:

🎲 A Tale of Inference Woes 🎲 Thy context window overflows with dread, Thy API keys scattered 'cross thy thread. Thou switchest providers mid-conversation, And pray thy tokens find the right foundation. No ward stands guard when tools go rogue, No grimoire saves a session from the fog. Thy agents wander, masterless and blind, Thy prompts untested—leaving truth behind. Thy wallet weeps. Thy latency doth creep. Thy model's fine. Thy infrastructure? Not so deep. Sound familiar? I'm excited to share the public README for Arcanum — a .NET 10, single-binary, Native AOT, local-first AI inference hub that treats your infrastructure with the seriousness of a dungeon master and the organization of a well-kept grimoire. Arcanum is one self-contained native executable. No runtime prerequisite. No "install the framework first." Just arcanum serve and you're running a full inference platform on loopback. What's in the bag of holding: 🏰 Local-first & encrypted — SQLCipher-encrypted Grimoire persists every session, entry, and memory. Your data never leaves your machine unless you tell it to. ⚔️ Multi-provider native engine — Any OpenAI-compatible API (DeepSeek, Groq, Ollama via /v1, LM Studio, etc.) plus local GGUF models via a managed llama-server lifecycle. One hub, zero vendor lock-in. 🔮 OpenAI API compatible — POST /v1/chat/completions and GET /v1/models work with existing OpenAI clients out of the box. Drop-in replacement for your local stack. 🛡️ Wards & Sanctum — High-risk tools require operator approval before execution. Per-campaign sandboxes enforce path containment, network policy, and OS-level CPU/memory/FD limits via cgroups v2 and setrlimit. 📜 Spells, not prompts — Versioned markdown workflows with dependency resolution, tool allowlisting, and semantic routing. Dry-run cast previews before spending a single token. 🧙 Autonomous Apprentices — Goal-driven agents with plan generation, retry/backoff, autonomous plan revision, DM escalation, and parallel step execution. 🏰 The

Bolting an LLM onto your pull requests is a weekend project. Building AI code review that your engineers don't disable within two weeks is the actual problem. The failure mode isn't missing bugs — it's crying wolf. Post twenty nitpicks and three hallucinations on someone's PR and they'll mute the bot forever. This is the pipeline we built on Mattrx to earn — and keep — that trust. Mattrx is our multi-tenant marketing-analytics SaaS: ~95k lines of C#, 11 engineers, and enough pull requests that senior-reviewer time was the bottleneck. We tried the naive thing first — pipe the changed file into a model, post the output — and watched the team stop reading it in nine days . TL;DR Dimension Human-only / naive AI (before) AI review pipeline (after) Coverage selective / whole-file dump every PR, diff-focused First-review latency ~6 hours (wait for a human) ~3 minutes (AI first pass) Context none / a naked file diff + call sites + conventions Reviewers one mega-prompt specialized dimensions, in parallel False positives ~35% (so it gets ignored) ~6% (adversarially verified) Merge control human, or nothing severity gate; human always decides Governance none gateway: audit, cost, secret redaction ~90 PRs/week across 11 engineers; the pipeline reviews 100%. First-pass review latency 6h → 3 min. False-positive rate ~35% → ~6% — the single number that decides whether the bot lives or dies. Escaped defects to production down ~40%; senior-reviewer time down ~30%. ~$0.05 per PR (cheap model for style, frontier only for correctness). The one mental shift: AI code review is not about finding issues — models find plenty. It's about not crying wolf . The product is trust, and trust is a false-positive-rate problem. Verify before you comment; let the AI propose and the human dispose. The naive approach — and why it collapses // BEFORE: dump the whole changed file into one prompt, post whatever comes back. foreach ( var file in pr . ChangedFiles ) { var text = await File . ReadAllTextAsyn

Author: Erwin Wilson Ceniza Published: July 2, 2026 Tags: GraphQL | HotChocolate | BatchDataLoader | CQRS | Outbox Pattern | Apollo Federation | .NET | Architecture | EMR | API Design GraphQL Query & Mutation Architecture - A Production Deep Dive Code-first GraphQL with HotChocolate, BatchDataLoader, CQRS, and a transactional outbox pattern, with real examples from a production EMR system serving three portals from a single schema. Table of Contents Interactive Data Traversal The Architecture at 30,000 Feet Why GraphQL Won for Healthcare Data Shapes Simple Queries vs. Complex REST, The Comparison That Sold Me The Resolver Layer, Code-First, Schema-Last How GraphQL Smoothly Orchestrates the Application Services N+1 Is the Silent Killer, How BatchDataLoaders Eliminate It Mutation Architecture - CQRS + Transactional Outbox Security at the Resolver Level, Custom Middleware Attributes Type Extensions, Why I Stopped Writing DTO Mappers Projections, Filtering, Sorting, and Paging Apollo Federation, Future-Proofing the Graph GraphQL Client on Mobile, Sharing Query Logic Across Portals Why I Chose Ionic for the Patient Mobile App The Retrospective, What I'd Keep and What I'd Change A step-by-step walkthrough of how the app consumes (reads) and creates (writes) data through the services. interactive <script type="module"> const C = document.currentScript.parentElement; C.style.cssText='width:100%;font-family:system-ui,-apple-system,sans-serif'; const S = document.createElement('style'); S.textContent=` .gv *{box-sizing:border-box;margin:0;padding:0} .gv{background:var(--bg-secondary,#111);border-radius:12px;overflow:hidden;border:1px solid var(--border,#333);min-height:440px} .gv-tabs{display:flex;border-bottom:1px solid var(--border,#333);background:var(--bg-card,#1a1a1a)} .gv-tab{flex:1;padding:12px 8px;font-size:11px;font-weight:700;text-transform:uppercase;letter-spacing:.5px;cursor:pointer;border:none;background:none;color:var(--text-muted,#666);transition:all .2s;border

Hello everyone! For many years, I have been developing equipment control software and long-term support products using .NET/C#. Based on the experiences gained through working with various development teams, I would like to talk about why I created CALM (Cooperative Async Lock-free Messaging) , an open-source library for .NET. The Magic of UI Thread + Event-Driven + async/await My journey with .NET/C# began around the days of .NET Framework 4.0. At the time, code-behind in Windows Forms was incredibly intuitive. It allowed me to join the development team and become productive in a very short period. Back then, executing time-consuming operations on a separate thread and returning the results to the UI thread via callbacks was painful and error-prone. However, the introduction of async/await in .NET Framework 4.5 completely shifted the paradigm. The SynchronizationContext magically handled thread marshaling behind the scenes, and our code became amazingly simple. "Running asynchronous operations safely on a single thread (the UI thread) via an event-driven approach" — this seamless developer experience was my starting point. Divide and Conquer, Dependency Management, and CQS As our product evolved, the codebase grew, and the development team expanded beyond a certain size. Suddenly, the software became exponentially complex. Following industry best practices, we introduced MVP and MVVM patterns to separate the UI from the business logic. We also refactored our domain models based on Domain-Driven Design (DDD) and Clean Architecture principles, alignment with the team's domain knowledge. While this helped organize the logic within individual models, it introduced a new nightmare: complex dependencies between models. We struggled heavily with initialization, especially with models that had circular or mutual dependencies. To break this web of tight coupling, we introduced a mechanism that combined the Observer pattern (inspired by Android's EventBus) with the philosoph

Prefer immutability What: Make data read-only after construction. Instead of editing objects, create new ones. Why: If nothing changes, many threads can read safely with no locks . How (.NET): public readonly record struct Money ( decimal Amount , string Currency ); public record Order ( Guid Id , IReadOnlyList < OrderLine > Lines ) { public Order AddLine ( OrderLine line ) => this with { Lines = Lines . Append ( line ). ToList () }; } Use record / readonly struct , IReadOnlyList<> , and with (copy-on-write). Keep collections immutable ( ImmutableList<T> , ImmutableDictionary<K,V> ). Avoid shared state What: Don’t let unrelated code touch the same mutable object. Why: If each operation owns its data, there’s nothing to synchronize. How: Per-request scope : create new service instances that hold request-specific state. No static mutable fields; if you must cache, use ConcurrentDictionary : private static readonly ConcurrentDictionary < string , Widget > _cache = new (); var widget = _cache . GetOrAdd ( key , k => LoadWidget ( k )); Use lock / SemaphoreSlim cautiously What: Synchronization primitives that serialize access to critical sections. When: Short, minimal critical sections where mutation is unavoidable. lock for synchronous code; SemaphoreSlim when await is involved (never block in async code). Patterns & pitfalls: private readonly object _gate = new (); void Update () { lock ( _gate ) // keep work tiny inside { // mutate a small piece of shared state _count ++; } } private readonly SemaphoreSlim _sem = new ( 1 , 1 ); async Task UpdateAsync () { await _sem . WaitAsync (); try { _count ++; } finally { _sem . Release (); } } Never lock(this) or a public object (external code could deadlock you). Keep lock duration short; avoid I/O under locks. If multiple locks are needed, fix a global order to prevent deadlocks. Atomic counters (avoid locks entirely): Interlocked . Increment ( ref _count ); Leverage actor-style or message queues What: Push work as messages to

Rule of thumb If your action waits on something external , make it async . If it’s instant CPU , keep it sync ; for expensive CPU , offload . The core idea Async shines for I/O-bound work (DB calls, HTTP calls, queues, files). It frees the request thread while waiting, so the server can serve more requests with the same thread pool . Sync is fine for trivial, short CPU work (formatting, small calculations) where you’re not awaiting anything and the handler returns in a few milliseconds. When to choose async You call EF Core ( SaveChangesAsync , ToListAsync ), HttpClient , Azure SDK ( ServiceBusClient , BlobClient ), file I/O, or any API with Async methods. You expect latency from a dependency (tens–hundreds of ms). You need cancellation and timeouts (propagate HttpContext.RequestAborted ). When sync is acceptable The action is pure CPU and trivial (e.g., quick math, mapping, input validation) and returns immediately. There are no I/O waits and no benefit from freeing the thread. If it’s CPU-heavy (image processing, big JSON transforms), do not just make it async—offload to a background queue/worker or a separate compute service. Async won’t make CPU faster. Pitfalls to avoid Don’t block async : never use .Result / .Wait() on Tasks (deadlocks/thread-pool starvation). Async all the way down : if the controller is async, downstream calls should be too. Don’t fake async : returning Task.Run around synchronous I/O just burns threads. Keep concurrency bounded when fanning out to multiple I/O calls. Mini decision checklist Any I/O? → Use async (end-to-end). Pure CPU? Tiny (≤ a few ms) → Sync is fine. Heavy/variable → Offload to background worker; controller returns 202/Location or uses a queue. ASP.NET Core examples Async (I/O-bound) — recommended [ ApiController ] [ Route ( "orders" )] public class OrdersController : ControllerBase { private readonly OrdersDbContext _db ; private readonly HttpClient _http ; public OrdersController ( OrdersDbContext db , IHttpClientFactory

This article is part of the Comprehensive Guide to Microservices Architecture in .NET Core, Cloud and Azure series. Service Discovery in Kubernetes How Kubernetes DNS Works Kubernetes automatically creates DNS entries for services, enabling simple name-based discovery. A service named order-service in the production namespace becomes accessible at order-service.production.svc.cluster.local . For services within the same namespace, you can use the short name order-service . Service Definition: apiVersion : v1 kind : Service metadata : name : order-service namespace : production labels : app : order-service version : v1 spec : selector : app : order-service ports : - name : http protocol : TCP port : 80 targetPort : 8080 type : ClusterIP Native Service Discovery in .NET 9 .NET 9 introduces enhanced service discovery capabilities with improved configuration and resilience features. Basic Configuration: // Program.cs var builder = WebApplication . CreateBuilder ( args ); // Add service discovery with .NET 9 enhancements builder . Services . AddServiceDiscovery (); // Configure HTTP client with service discovery builder . Services . AddHttpClient < IOrderServiceClient , OrderServiceClient >( client => { // Use service name - discovery resolves to actual endpoint client . BaseAddress = new Uri ( "http://order-service" ); }) . AddServiceDiscovery () . AddStandardResilienceHandler (); // .NET 9 resilience patterns var app = builder . Build (); Advanced Configuration with appsettings.json: { "ServiceDiscovery" : { "Providers" : { "Kubernetes" : { "Namespace" : "production" , "RefreshPeriod" : "00:01:00" } }, "Services" : { "order-service" : { "Scheme" : "https" , "EndpointNames" : [ "http" , "https" ], "HealthCheckPath" : "/health" }, "payment-service" : { "Scheme" : "http" , "AllowAllHosts" : false } }, "AllowAllHosts" : true , "AllowedHosts" : [ "*.svc.cluster.local" ] } } Service-to-Service Communication Patterns Using Typed HTTP Clients: public interface IOrderServiceCli

This article is part of the Comprehensive Guide to Microservices Architecture in .NET Core, Cloud and Azure series. Asynchronous Messaging with Azure Service Bus Azure Service Bus provides enterprise-grade messaging infrastructure with advanced features for reliable message delivery, ordering guarantees, and complex routing scenarios. Service Bus vs Azure Queue Storage Azure Service Bus offers enterprise messaging capabilities including: Topics and subscriptions for pub/sub patterns Message sessions for ordered processing Transaction support across operations Dead-letter queues for failed messages Messages up to 100MB (premium tier) Advanced routing with filters and actions Azure Queue Storage provides: Simple FIFO queue operations Lower cost for basic scenarios Messages up to 64KB Best for simple point-to-point messaging When to Choose Service Bus Use Azure Service Bus when you need: Publish-subscribe patterns with multiple subscribers Guaranteed message ordering with sessions Transactional message processing Message size beyond 64KB Advanced routing and filtering Integration with hybrid or on-premises systems Implementation with .NET 9 .NET 9 introduces improved performance and simplified APIs for working with Azure Service Bus: // Producer using .NET 9 with improved performance public class OrderCreatedPublisher { private readonly ServiceBusSender _sender ; public OrderCreatedPublisher ( ServiceBusClient client ) { _sender = client . CreateSender ( "order-events" ); } public async Task PublishOrderCreatedAsync ( Order order , CancellationToken cancellationToken = default ) { var message = new ServiceBusMessage ( JsonSerializer . Serialize ( order )) { MessageId = order . OrderId . ToString (), Subject = "OrderCreated" , ContentType = "application/json" , // .NET 9: Better support for distributed tracing ApplicationProperties = { [ "CorrelationId" ] = Activity . Current ?. Id ?? Guid . NewGuid (). ToString (), [ "OrderDate" ] = order . CreatedAt . ToString ( "O" )

This article is part of the Comprehensive Guide to Microservices Architecture in .NET Core, Cloud and Azure series. API gateways serve as the entry point for client applications in distributed architectures, handling request routing, composition, and protocol translation. As systems grow more complex with multiple client types and backend services, choosing the right gateway pattern becomes crucial for maintaining performance, scalability, and developer productivity. This article explores two powerful API gateway patterns in .NET: the Backend for Frontend (BFF) pattern, which creates client-specific gateways, and GraphQL, which offers flexible, query-driven data fetching. Both patterns address the challenge of efficiently serving diverse clients while maintaining clean architecture and optimal performance. Backend for Frontend (BFF) Pattern Web BFF Implementation The web BFF returns detailed, enriched data suitable for desktop browsers with higher bandwidth and processing power: [ ApiController ] [ Route ( "api/web/[controller]" )] public class OrdersController : ControllerBase { private readonly IOrderServiceClient _orderClient ; private readonly ICustomerServiceClient _customerClient ; private readonly IInventoryServiceClient _inventoryClient ; [ HttpGet ( "{id}" )] public async Task < WebOrderDto > GetOrder ( Guid id ) { // Execute parallel calls to improve response time var orderTask = _orderClient . GetOrderAsync ( id ); var customerTask = _customerClient . GetCustomerAsync ( id ); var inventoryTask = _inventoryClient . GetInventoryStatusAsync ( id ); await Task . WhenAll ( orderTask , customerTask , inventoryTask ); return new WebOrderDto { Order = orderTask . Result , Customer = customerTask . Result , InventoryStatus = inventoryTask . Result , // Include additional rich data for enhanced web UI experience RecommendedProducts = await GetRecommendationsAsync ( id ) }; } } Mobile BFF Implementation The mobile BFF provides optimized, lightweight responses to min

It is clear that Vyshyvanka is more than just code — it is an ecosystem. The true power of an open-source workflow engine lies in its community. Today, we want to talk about how you can get involved, whether you are interested in pushing the boundaries of the core engine or building specialized solutions with custom plugins. The Core Engine vs. The Plugin Ecosystem A common question we get is: 'Should I contribute a PR to the core engine, or should I build a separate plugin?' The answer depends entirely on the scope of your contribution. When to Contribute to Core The core engine ( Vyshyvanka.Core , Vyshyvanka.Engine , Vyshyvanka.Api , Vyshyvanka.Designer ) should be reserved for changes that benefit every user of the platform. Good candidates for core contributions: Performance improvements to the execution pipeline New fundamental port types or expression functions Bug fixes in the engine, validation, or persistence layers Enhancements to the Designer UI (canvas, node editor, property editors) Improvements to the API surface (new endpoints, better error responses) Documentation improvements These changes require careful review and testing because they impact every installation. We encourage PRs here, but we also ask that you open an issue first so we can discuss the architectural impact. When to Build a Plugin Plugins ( ./plugins/ ) are the best way to extend functionality without increasing the maintenance burden of the core. Good candidates for plugins: Integration with a specific third-party SaaS tool (CRM, CI/CD, monitoring) Custom nodes specific to your industry or use case Experimental node behaviors that are not yet ready for core Proprietary integrations you want to keep separate from the open source project Plugins are independent, versionable, and can be maintained outside the core release cycle. They empower you to solve your specific problems immediately without waiting for a core release. Project Structure at a Glance Understanding where things live i

Every identity migration guide eventually reaches the same paragraph, and it's always a little apologetic: "users will need to reset their passwords." It gets treated like a law of nature. It isn't. It's a choice, usually forced by a tool that didn't want to do the harder thing. The harder thing is verifying your users' existing password hashes in place, so they sign in after the move with exactly the credentials they had before and never notice anything happened. Whether you can do it comes down to one question: can you get the old hashes, and can the new system verify them? Password hashes are more portable than people think A password hash isn't a secret algorithm. bcrypt is bcrypt. A bcrypt hash carries its own cost factor and salt inside the string, so anything that implements bcrypt can verify a hash any other bcrypt system produced. The same is true of the PBKDF2 format ASP.NET Identity uses: documented, versioned, self-describing. If you know what you're holding, you can check a password against it without ever knowing the password. So a migration that preserves logins doesn't need the plaintext (nobody has it) and doesn't need to re-hash everyone up front. It needs to obtain the stored hashes and verify against them on sign-in, upgrading each one to its own format quietly the first time a user logs in. That last part is lazy migration: carry the old hash, verify it once, replace it transparently. Over a few weeks of normal logins your user table re-hashes itself and the legacy formats age out, with zero resets and zero support tickets. The dual-path bit The wrinkle is that different sources hand you different formats, and a good importer verifies both: From self-hosted Duende / ASP.NET Identity: the V3 PBKDF2 hashes (and any legacy bcrypt) verify natively and rehash on first sign-in. This is the easy case, because it's the same scheme the destination already uses. Most teams are surprised it's that clean. From Auth0: bcrypt hashes verify verbatim. The catch

Data-Oriented Design in C#: Why Objects Are Slowing You Down In my previous article, we talked about starving the Garbage Collector by moving away from heap-allocated class types and leaning heavily into struct , Span<T> , and ArrayPool<T> . That’s a critical first step, but it only solves half the problem. You’ve stopped the GC from pausing your app, but you might still be leaving massive amounts of CPU performance on the table. Why? Because of how your data is structured. It’s time to talk about Data-Oriented Design (DoD) . The Object-Oriented Trap We are taught from day one to model our code after the real world. If you are building a social network graph, you might write something like this: public class UserNode { public int Id { get ; set ; } public string Name { get ; set ; } public List < Edge > Connections { get ; set ; } } public class Edge { public UserNode Target { get ; set ; } public int Weight { get ; set ; } } This makes perfect logical sense. A user has connections, and those connections point to other users. But modern CPUs don't care about your logical models. A CPU only cares about reading data from memory into its L1/L2 caches as fast as possible. When a CPU reads a byte from RAM, it doesn't just read that one byte; it pulls a whole 64-byte "cache line" under the assumption that you will probably want the neighboring bytes next. When you loop through a List<UserNode> , traversing from object to object, you are jumping randomly across the heap. The CPU pulls a cache line, reads your data, and then has to go fetch a completely different block of RAM for the next node. This is called pointer chasing , and the resulting cache misses are devastating to performance. Enter Data-Oriented Design: Struct of Arrays (SoA) Data-Oriented Design says: Stop modeling the real world. Model the data the way the hardware wants to consume it. Instead of an Array of Structs (AoS) (or an array of objects), we invert the architecture to a Struct of Arrays (SoA) . If we

There's a version of dogfooding that's a slogan, and a version where your own employees can't ship code until the bug is fixed. We run the second kind. The Authagonal staff console, the one we use to manage every tenant, authenticates through Authagonal itself: SAML single sign-on from our Entra directory, with SCIM deciding who gets in and what they can do. There is no separate admin password table. We deleted it. If our own SAML is broken, we are locked out of our own product. That's uncomfortable in exactly the useful way. It turns "SSO is an enterprise feature we support" into "SSO is the only way the people who built this get to work today." Here's what being our own customer caught. A trimmed build that broke signature verification We publish the auth server trimmed, to keep the image small. Trimming aggressively deletes code it can't prove is used, and reflection hides usage from it. .NET resolves its XML-signing crypto algorithms by name, reflectively, through CryptoConfig . The trimmer couldn't see those types were needed, removed them, and SignedXml quietly came back unable to build the algorithm. SAML signature verification, the step that proves the login is real, threw a null reference at runtime. The unit tests passed, because they ran against the untrimmed build where the types still existed. Only the trimmed production artifact failed, and it failed at the exact moment a human tried to sign in. We ship the auth server untrimmed now, with a healthy distrust of trimming anything near reflection-based crypto. If we only supported SAML rather than living on it, this is a customer's incident report instead of ours. Provisioning is the actual login Authenticating a user is the easy half of SSO. The hard half is deciding what they're allowed to do and keeping it in sync as people join and leave. We drive that with SCIM: Entra group membership maps to roles, resolved at the moment a token is issued, not copied once at account creation. Add someone to the righ

I have written some version of "never hardcode secrets, store them in Key Vault instead" in at least five of my last nine posts on this blog. I never actually stopped to explain what that means in practice. This post fixes that, using the real secrets this very blog depends on: a database connection string, an admin panel password, and a set of GitHub deployment credentials. What Azure Key Vault Actually Is Azure Key Vault is a managed service for storing secrets, encryption keys, and certificates securely in the cloud. Instead of a password sitting in a configuration file or a public GitHub repository where anyone with read access can see it, the password lives in Key Vault - encrypted, access-controlled, and logged every single time it is read. Picture your code as a house with see-through walls - anyone looking at the repository can see everything inside, including any password left lying on the kitchen table. Key Vault is a bank vault a few streets away. Your code does not hold the password directly; it holds a key card that lets it walk over and request the password at the exact moment it is needed. Lose the key card, and you still cannot get into the vault without proper identity verification on top of it. Three Things Key Vault Stores Secrets are plain string values - passwords, connection strings, API keys, tokens. Keys are cryptographic keys used for encrypting and decrypting data, or for signing and verifying it. Certificates are X.509 certificates used for TLS or client authentication between services. Most applications, including this one, primarily use the Secrets feature. An Honest Admission About TechStackBlog's Own Setup This blog does not actually use Key Vault directly today. The database password lives in Azure App Service Configuration. The admin panel password and deployment credentials live in GitHub Secrets. For a single-application personal project, this is a perfectly reasonable and secure setup. Key Vault earns its place once you have multi

I joined a team where the controller was 800 lines long, the business rules were scattered between the controller and the DbContext , and "to run the tests, spin up a SQL Server in Docker" was a sentence I heard every week. The fix was Clean Architecture. The argument I had with the team lead was about how to actually structure it. We argued for two weeks. Then I built this template so the next person wouldn't have to. This is the Clean Architecture .NET 8 starter template I wish someone had handed me on day one. Four projects, strict dependency direction, domain entities that own their own invariants, and an Application layer you can unit test with Moq — no database required. The whole repo is on GitHub , MIT-licensed, runs with dotnet run , and ships with xUnit tests, JWT auth, Swagger, Docker, and CI. This post is the explanation of why each project exists, what goes in it, and what I learned the hard way about getting Clean Architecture right in .NET. The problem Clean Architecture solves The naive way to build a .NET Web API is one project, one folder structure, and "everything talks to everything": MyApp/ Controllers/ ProductsController.cs ← HTTP stuff OrdersController.cs ← HTTP stuff + business rules Services/ ProductService.cs ← business rules + DbContext.SaveChanges Data/ AppDbContext.cs ← EF Core, entities Models/ Product.cs ← POCO with public setters This works for the first 1,000 lines. By 5,000 lines, the controller is doing five things at once. By 10,000, "to test this, I need a database" is the answer to every test question, and your CI takes 20 minutes because every test run spins up SQL Server. Clean Architecture says: separate the business rules from the HTTP boundary, separate the database from the business rules, and enforce it with project references. A controller is allowed to call a service. A service is allowed to call a repository. A repository is allowed to know about EF Core. Nothing is allowed to know about anything "above" it in the chai