Newest first, grouped by year. Search or filter by topic.
Mappers, validators, processors, even the Resolve<T>() you call in a handler - almost none of it goes through your DI container the way you assume. A static ServiceResolver with two caches sits behind everything, and reading it explains both the speed and the sharp edges. Part 5 of FastEndpoints — The Missing Chapters.
Twenty-two registrations, zero scoped, zero transient - a lifetime decision that buys a genuinely fast request path and enables exactly three bugs, all of them the same mistake.
services.BuildServiceProvider() inside ConfigureServices - what it actually costs, why it does not leak here, and how a zero-parameter extension method signature forced it.
The whole RabbitMQ adapter that makes Inflow's monolith talk to an extracted service is five files in one folder. Reading them shows how small a real transport swap can be - and where the fan-out quietly narrowed from every handler to exactly one.
Inflow reads every configuration section by building and disposing an entire service provider - twenty-two of them during startup. Two of those calls do not read anything; they mutate a registry, and they only work because of how three singletons were registered.
Inflow registers every handler by assembly scan and then wraps them in decorators. Those two techniques are incompatible unless something tells the scanner to skip the decorators - and in this codebase that something is a marker attribute with no tests and no comment explaining what it prevents.
Trill's hand-rolled framework follows the ASP.NET Core registration convention with unusual discipline, then breaks it twice on purpose - and the exceptions turn out to be more instructive than the rule.
Trill wraps every command handler in logging, metrics, tracing and an outbox using Scrutor's TryDecorate - and the whole arrangement only works because a single attribute keeps the decorators out of the assembly scan that registers handlers.
The tick that makes eventual consistency watchable in a console, the four-hop chain that takes twenty seconds because of it, and the DI-scope trap the estate is one refactor away from firing.
Conferences registers in-memory and EF repositories for the same interfaces and lets last-registration-wins pick - a live lesson in DI as strategy selector, dead registrations as fossils, and a no-op UpdateAsync nobody deleted.
The last commit of ModularMonolith moves one line of Startup from first to last - and the whole cross-module event system depends on it. Assembly scanning, throwaway service providers and migrations inside ConfigureServices.
Every module in ModularMonolith plugs in through the same Add/Use extension pair - a recipe small enough to memorise, complete enough to be a mini-framework, and visible even where a module registers nothing at all.
Redis registered in nine services and read in one, discovery stacks in services that never call anyone, an outbox package referenced but never wired, and versions that float by construction - an inventory of everything Pacco wires up and never uses.
Each concern in DShop.Common builds a throwaway DI container just to read config - nine per service, atop three coexisting container frameworks and a vendored config parser.
DShop.Common's Consul registry tracks which service instances it has used to spread load evenly - then registers as transient, discarding that memory on nearly every request.
DShop.Common ships its own in-process command and query dispatch - marker interfaces, a handler triple, and one dynamic double-dispatch standing in for a library.
FeedR moves every tick between services through a two-method streaming abstraction with a no-op default and a Redis implementation - which, despite the namespace, is pub/sub rather than streams. What that seam buys, how DI last-wins overrides it, and what you lose when nobody is listening. Part 4 of the FeedR deep dive.
The hundred lines of code that let an entire microservices toolkit compose from one fluent chain — a named registry, a list of build actions, and two hard lessons about doing work at startup.
services.AddChronicle() registers sagas you never mentioned, and one ProcessAsync call can run five of them in parallel. Inside Chronicle's Scrutor scan, the seeker's dedupe trick, and the ref-counted lock that serializes each saga id.
One static registration method wires the whole discovery subsystem into an Azure Functions host, and one CI pipeline packs it as a private NuGet package. The lifetime choices in those few lines quietly decide the caching semantics of the entire estate - and a duplicate registration teaches how DI forgives. Part 5 of Service Discovery Without a Service Mesh.
Above raw resolution sits a convention layer - an abstract endpoint base class that derives its Key Vault lookup key from its own type name, a template method separating the call from the interpretation, and a generic proxy that routes by name across every endpoint the DI container knows. Part 4 of Service Discovery Without a Service Mesh.
How ArchiveKit wires itself up - the [Archivable] attribute's three knobs, an assembly scanner that fails fast at startup instead of quietly at delete time, the static registry behind every lookup, and the AddArchiveKit configuration surface. Plus an honest note about the source generator that doesn't exist yet. Part 5 of the Archive-on-Delete with ArchiveKit series.
