Service lifetimes

Services can be registered with a transient, scoped, or singleton lifetime. Choose an appropriate lifetime for each registered service.

Transient

A service with a transient lifetime is created each time it's requested from the service container. To register a service as transient, call AddTransient.

In apps that process requests, transient services are disposed at the end of the request. This lifetime incurs per-request allocations, as services are resolved and constructed every time. For more information, see IDisposable guidance for transient and shared instances.

Scoped

For web applications, a scoped lifetime indicates that services are created once per client request (connection). In apps that process requests, scoped services are disposed at the end of the request. Register scoped services by calling AddScoped.

A scoped service should always be used from within a scope–either an implicit scope (such as ASP.NET Core's per-request scope) or an explicit scope created with IServiceScopeFactory.CreateScope().

Do not resolve a scoped service directly from a singleton using constructor injection or by requesting it from IServiceProvider in the singleton. Doing so causes the scoped service to behave like a singleton, which can lead to incorrect state when processing subsequent requests.

It's acceptable to resolve a scoped service within a singleton if you create and use an explicit scope with IServiceScopeFactory.

It's also fine to:

• Resolve a singleton service from a scoped or transient service.
• Resolve a scoped service from another scoped or transient service.

By default, in the development environment, resolving a service from another service with a longer lifetime throws an exception. For more information, see Scope validation.

Singleton

Singleton lifetime services are created either:

• The first time they're requested.
• By the developer, when providing an implementation instance directly to the container. This approach is rarely needed.

Every subsequent request of the service implementation from the dependency injection container uses the same instance. If the app requires singleton behavior, allow the service container to manage the service's lifetime. Don't implement the singleton design pattern and provide code to dispose of the singleton. Services should never be disposed by code that resolved the service from the container. If a type or factory is registered as a singleton, the container disposes the singleton automatically.

Register singleton services with AddSingleton. Singleton services must be thread safe and are often used in stateless services.

In apps that process requests, singleton services are disposed when the ServiceProvider is disposed on application shutdown. Because memory isn't released until the app shuts down, consider memory use with a singleton service.