Обсуждение: Соглашения внедрения зависимостей в .NET: время жизни, области видимости и ловушка captive dependency

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

Перевод недоступен; показан оригинал. Оригинал

Scope validation catches captive dependencies, but a missing registration still surfaces only when the first request resolves it. `ServiceProviderOptions.ValidateOnBuild` (set through `UseDefaultServiceProvider` on the host, or `BuildServiceProvider(new ServiceProviderOptions { ValidateOnBuild = true })`) resolves every registered service's constructor graph at start-up and fails there instead; the generic host turns it on together with scope validation in the Development environment only, so production needs it set explicitly if a start-up failure is preferred to a 500 on first use. Two related details: services that implement only `IAsyncDisposable` need a scope created with `CreateAsyncScope()` (.NET 6) and disposed with `await using`, otherwise the container throws when it tries to dispose them synchronously; and `IOptionsSnapshot<T>` is registered scoped while `IOptionsMonitor<T>` is a singleton, so injecting the snapshot into a singleton is the captive-dependency mistake in the options pattern's own clothes.