dependency-injection

Code hat einen Dienst aus einem bereits freigegebenen DI-Scope oder Root-Provider aufgelöst. Erfassen Sie IServiceScopeFactory statt IServiceProvider und erzeugen Sie dort einen neuen Scope, wo die Arbeit tatsächlich läuft.

AddDbContextPool liefert pro DI-Scope genau einen Scoped-DbContext und kann daher nicht zwei Abfragen gleichzeitig ausführen. AddDbContextFactory und AddPooledDbContextFactory liefern pro Aufruf einen Kontext, was parallele Abfragen brauchen. Gemessen mit EF Core 11 RC 1: Die gepoolte Factory erzeugt einen Kontext in 342 ns und 40 B gegenüber 17 us und 44 KB.

Vor Aspire 13.5.4 erzeugte jeder AppHost-Health-Check für eine AddKafka-Ressource einen neuen Confluent-Producer, den niemand freigab. Polling-Threads stapelten sich, und der AppHost verbrannte CPU. Der Fix und die HealthCheckRegistration.Factory-Falle dahinter betreffen auch eigene Health Checks.

Ein Singleton kann keinen DbContext injizieren, wohl aber IDbContextFactory<T>, denn AddDbContextFactory registriert die Factory standardmäßig als Singleton. Erzeugen und entsorgen Sie einen Kontext pro Aufruf und speichern Sie die Instanz niemals.

Implementieren Sie IValidateOptions<T>, registrieren Sie es in der Dependency Injection und hängen Sie ValidateOnStart an, damit eine fehlerhafte appsettings.json den Prozess beendet statt die erste Anfrage, die sie berührt. Behandelt die .NET-11-Überladung Validate<TValidator>(), asynchrone Validierung über IAsyncValidateOptions<T> und die drei Stellen, an denen ValidateOnStart stillschweigend nichts tut.

Verwenden Sie standardmäßig IOptions<T>. Greifen Sie zu IOptionsMonitor<T>, wenn ein Singleton Konfigurationsänderungen sehen muss, und zu IOptionsSnapshot<T> nur dann, wenn ein Scoped-Consumer einen für eine Anfrage stabilen Wert benötigt. Entscheidend ist die Lebensdauer des Consumers, nicht die Form der Einstellungen.

EF Core wirft dies, wenn AddDbContext nie lief, nach Build lief oder der Konstruktor des Kontexts die falschen DbContextOptions erhält. Registrieren Sie vor Build und verwenden Sie DbContextOptions<IhrKontext>.

Registrieren Sie mehrere Implementierungen desselben Diensttyps unter einem Schlüssel mit AddKeyedSingleton/Scoped/Transient und lösen Sie sie dann mit [FromKeyedServices], GetRequiredKeyedService oder KeyedService.AnyKey auf. Die Registrierungen mit und ohne Schlüssel sind getrennte Tabellen, und genau das ist die Stolperfalle für fast alle.

Ein BackgroundService ist ein Singleton und kann daher einen Scoped Service wie einen DbContext nicht direkt injizieren. Nehmen Sie IServiceScopeFactory, öffnen Sie pro Arbeitseinheit einen Scope mit CreateAsyncScope, lösen Sie darin auf und verwerfen Sie ihn nach getaner Arbeit.

Eine Schritt-für-Schritt-Checkliste, um MediatR 12-14 zu entfernen und IRequest-Handler, ISender, Pipeline Behaviors und INotification durch einfache Service-Klassen und Konstruktorinjektion zu ersetzen.