Dependency injection lifetimes and scopes

A service lifetime defines an ownership boundary

Dependency injection lifetimes describe when a container creates and owns service instances. A scoped service normally belongs to one ASP.NET request scope, a transient is created for each resolution, and a singleton belongs to the root application lifetime. These rules are not a substitute for a concurrency design or an instruction to make every class globally shared. The portable companion demonstrates ordinary object identity under two owners. The external project uses the real service provider inside real requests, so observed resolution behavior comes from ASP.NET rather than a custom teaching container with borrowed framework names.

Compare identity within a request and across requests

The console borrows the first owner's object and compares it with that same owner's property, printing True. A new owner creates a new object, so the second comparison prints False. On the external server, two scoped parameters resolve to one request-owned marker, while the two transient parameters resolve to different markers. The response therefore reports sameScoped: true and sameTransient: false. A singleton counter advances from one to two across two sequential requests. Its increment is atomic so concurrent requests cannot lose increments, although that does not make every possible shared collection or operation automatically safe.

A request scope is broader than one parameter resolution

The scoped marker can be resolved by multiple collaborators during the same request and still represent the same scope-owned instance. A second request receives its own scope and its own marker. Do not assume that a singleton can safely retain that request's marker after the scope ends. Such a capture creates an ownership mismatch and can be rejected by scope validation. For background work that genuinely needs scoped services, create and dispose an appropriate explicit scope through the framework and avoid borrowing a request's HttpContext or disposed dependency. This lesson starts no background worker and claims no such integration.

Let the correct owner end the service lifetime

The built-in provider disposes services it owns at the appropriate scope boundary. A consumer receiving an injected service should not casually dispose that borrowed dependency while other collaborators still need it. Conversely, objects created outside registration factories may have different ownership obligations. The sample's marker classes are deliberately empty, allowing identity to be observed without inventing disposal side effects. When introducing a real database context, stream or subscription, inspect both its registration lifetime and its own API contract. Registration labels cannot make an unsafe dependency usable concurrently or keep a disposed request resource valid after the response.

Practice: change one registration lifetime

Change only ScopedMarker from scoped registration to transient registration, keeping the two endpoint parameters unchanged. Predict which boolean changes and which counter behavior remains the same. Restore the baseline, then register TransientMarker as scoped and predict the opposite observation. Use a freshly started server for independently specified counter expectations. The hint is to compare resolutions within one request rather than deriving identity from class names. Naming a class ScopedMarker has no effect on the provider; the actual registration and resolution scope determine its ownership behavior.

Practice: expose a scope-capture error

In a separate project copy, add a singleton that directly requires a scoped marker in its constructor. Resolve that singleton with scope validation enabled and observe the failure rather than disabling validation to suppress it. Then redesign the work so the request-scoped collaborator is used within its intended scope. Describe what would need to change for a genuine background job to own its own scope, without implementing a fake provider. Keep this experiment separate from the successful identity endpoint so an expected startup or resolution failure does not hide a regression in the baseline request behavior.

Review lifetime and thread safety independently

A useful design review asks who owns each instance, how long references are retained, whether callers can overlap, and who disposes any resources. The singleton request counter in this example has a deliberately narrow atomic operation; a larger stateful service needs a correspondingly explicit policy. Preserve within-request identity checks when changing registrations, and add cross-request behavior tests when introducing shared state. The console remains valuable for ordinary reference ownership, but only the real external project exercises the framework's request scope. Keep that distinction in the lesson's claims and in the names of its executable checks.

• Do not capture request-scoped dependencies in root-owned singletons.
• Test lifetime identity separately from concurrent-state correctness and resource disposal.