Runtime extension in .NET — a contradiction in terms?

April 8, 2026

Runtime extension is deliberately hard in .NET, and for good reasons. Type safety, lifecycle guarantees and testable dependency graphs all assume that the container is fully configured at startup. Soften that, and you lose exactly the properties that make Dependency Injection worthwhile.

Still, there are situations where this boundary becomes a real problem. Existing applications need to integrate AI features after the fact, without a fundamental rebuild of the codebase. In practice this often fails not because of the AI, but because of the architecture underneath.

For this problem I built BrixWare DDI, an extension for Microsoft Dependency Injection with a secondary container. The DDI container manages its own dependency graph and allows controlled cross-access to the base container. Existing services stay untouched. New functionality is registered in isolation and can be added, queried and removed at runtime.

One concrete case shows what becomes possible: an AI agent generates C# code from a natural-language description, compiles it, and registers the result as a keyed service in the DDI container.

> Describe the service you want to generate:
> "German date/time greeting, like Guten Morgen! Es ist Mittwoch..."

Generating... Compiling... Registered as "gen-1"
Output: Guten Morgen! Es ist Mittwoch, der 8. April 2026, 10:30 Uhr

The key point: the AI is interchangeable and only the trigger. The interesting part is the architecture underneath — a container that allows runtime registration without compromising the guarantees of the base container.

Whether this approach fits every modernization, I doubt. But for scenarios with clear isolation and controlled extension points, it is a serious option.

Source: Dynamic DependencyInjection