Laufzeit-Erweiterung in .NET — ein Widerspruch in sich?

8. April 2026

Laufzeit-Erweiterung ist in .NET bewusst schwer gemacht. Das hat gute Gründe: Typsicherheit, Lebenszyklus-Garantien und testbare Abhängigkeitsgraphen setzen voraus, dass der Container zum Startzeitpunkt vollständig konfiguriert ist. Wer das aufweicht, verliert genau die Eigenschaften, die Dependency Injection wertvoll machen.

Trotzdem gibt es Situationen, in denen diese Grenze zum echten Problem wird. Bestehende Anwendungen sollen KI-Funktionen nachträglich integrieren, ohne dass die Codebasis grundlegend umgebaut wird. Genau hier scheitert es in der Praxis oft nicht an der KI, sondern an der Architektur darunter.

Für dieses Problem habe ich BrixWare DDI entwickelt, eine Erweiterung für Microsoft Dependency Injection mit einem sekundären Container. Der DDI-Container verwaltet einen eigenen Dependency-Graphen und erlaubt kontrollierten Cross-Zugriff auf den Basis-Container. Bestehende Services bleiben unberührt. Neue Funktionen werden isoliert registriert und lassen sich zur Laufzeit hinzufügen, abfragen und wieder entfernen.

Ein konkreter Fall zeigt, was damit möglich wird: Ein KI-Agent generiert C#-Code aus einer natürlichsprachlichen Beschreibung, kompiliert ihn und registriert das Ergebnis als Keyed Service im 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

Wichtig dabei: Die KI ist austauschbar und nur der Auslöser. Der interessante Teil ist die Architektur darunter — ein Container, der Laufzeit-Registrierung erlaubt, ohne die Garantien des Basis-Containers zu kompromittieren.

Ob dieser Ansatz für jede Modernisierung passt, bezweifle ich. Für Szenarien mit klarer Isolation und kontrollierten Erweiterungspunkten ist er aber eine ernsthafte Option.

Quelle: Dynamic DependencyInjection