AddTransient vs AddScoped vs AddSingleton in ASP.NET Core Dependency Injection

By the end of this page, you will understand service lifetimes in ASP.NET Core dependency injection: Transient, Scoped, and Singleton. You will learn how often each service instance is created, when to use each one, what problems can happen if you choose the wrong lifetime, and how these lifetimes are used in real ASP.NET Core applications.

ASP.NET Core has a built-in dependency injection container. When you register a service, you are not only saying what implementation to use, but also how long that object should live.

The three main service lifetimes are:

• AddTransient: create a new instance every time the service is requested.
• AddScoped: create one instance per scope. In web apps, that usually means one instance per HTTP request.
• AddSingleton: create one instance for the entire application lifetime.

That means these registrations are not equivalent:

services.AddTransient<IEmailSender, AuthMessageSender>();
services.AddScoped<IEmailSender, AuthMessageSender>();
services.AddSingleton<IEmailSender, AuthMessageSender>();

They all resolve IEmailSender to AuthMessageSender, but they differ in instance reuse.

Why this matters

Choosing the right lifetime affects:

• Correctness: some services must keep request-specific data, while others must not.
• Performance: creating too many objects can be wasteful.
• Safety: sharing the same object across requests can cause bugs if it holds mutable state.
• Resource management: database contexts and request data usually need a scoped lifetime.

Typical meaning of each lifetime

Think of service lifetimes like getting tools from a workshop:

• Transient: every time you ask for a screwdriver, the workshop gives you a brand new screwdriver.
• Scoped: during one job, everyone on your team shares the same screwdriver for that job only. For the next job, you get a different one.
• Singleton: the entire workshop shares one screwdriver forever.

Now imagine that screwdriver keeps notes written on it:

• If it is Transient, each user gets a fresh clean tool.
• If it is Scoped, everyone working on the same task sees the same notes.
• If it is Singleton, all tasks across the whole workshop share the same notes, which can become dangerous unless that shared state is intentional and safe.

This is why service lifetime is really about how much sharing you want.

Core syntax

services.AddTransient<IMyService, MyService>();
services.AddScoped<IMyService, MyService>();
services.AddSingleton<IMyService, MyService>();

You can also register concrete types directly:

services.AddTransient<MyService>();
services.AddScoped<MyService>();
services.AddSingleton<MyService>();

Example: seeing the difference

public interface IOperationService
{
    Guid OperationId { get; }
}

public class OperationService : IOperationService
{
    public Guid OperationId { get; } = Guid.NewGuid();
}

Register it:

services.AddTransient<IOperationService, OperationService>();

Use it in a controller:

public class HomeController : Controller
{
    private readonly IOperationService _service1;
    private readonly IOperationService _service2;

    public ()
    {
        _service1 = service1;
        _service2 = service2;
    }

    
    {
         Content();
    }
}

Consider this code:

public interface IRequestTracker
{
    Guid Id { get; }
}

public class RequestTracker : IRequestTracker
{
    public Guid Id { get; } = Guid.NewGuid();
}

Registration:

services.AddScoped<IRequestTracker, RequestTracker>();

Controller:

public class DemoController : Controller
{
    private readonly IRequestTracker _tracker1;
    private readonly IRequestTracker _tracker2;

    public DemoController(IRequestTracker tracker1, IRequestTracker tracker2)
    {
        _tracker1 = tracker1;
        _tracker2 = tracker2;
    }

    public IActionResult Index()
    {
        return Content($"Tracker1: {_tracker1.Id}\nTracker2: {_tracker2.Id}");
    }
}

What happens step by step

When to use Transient

Use transient for lightweight services that:

• do not keep state between calls
• are cheap to create
• behave like helpers or formatters

Examples:

• email body formatter
• string manipulation service
• simple mapper
• calculation helper

When to use Scoped

Use scoped for services that should stay consistent during one request.

Examples:

• Entity Framework DbContext
• unit-of-work style services
• current user context
• request-specific business services
• validation pipelines that use request data

In a web request, you usually want all code in that request to share the same database context and request-scoped services.

When to use Singleton

Use singleton for services that:

• are shared globally
• are expensive to create
• are stateless or carefully thread-safe

Examples:

• configuration providers
• in-memory caching services
• reusable metadata providers
• background coordination services

Example from a web app

services.AddScoped<AppDbContext>();
services.AddScoped<IProductService, ProductService>();
services.AddTransient<IEmailTemplateRenderer, EmailTemplateRenderer>();
services.AddSingleton<IClock, SystemClock>();

In real projects, service lifetimes are usually chosen based on state and dependency rules.

Common patterns

Guard clause thinking

A useful rule is:

• if the service holds request data, it is probably scoped
• if the service is stateless and cheap, it is probably transient
• if the service is shared application-wide, it may be singleton

Database access

A common pattern is:

services.AddDbContext<AppDbContext>();
services.AddScoped<IUserRepository, UserRepository>();
services.AddScoped<IUserService, UserService>();

This works well because repositories and services often depend on AppDbContext, which is scoped.

Validation and business logic

Many business services are scoped because they:

• read the current user
• use a scoped DbContext
• participate in one request's transaction or workflow

Stateless helpers

Formatting or transformation classes are often transient:

services.AddTransient<ISlugGenerator, SlugGenerator>();
services.AddTransient<IEmailFormatter, EmailFormatter>();

Shared app-wide services

Singleton is common for:

• caching abstractions

1. Using Singleton for a service with request-specific state

Broken example:

public class CurrentUserService
{
    public string? UserId { get; set; }
}

services.AddSingleton<CurrentUserService>();

Why this is a problem:

• all users and requests share the same instance
• one request can overwrite another request's data

Use Scoped instead if the state belongs to one request.

2. Injecting a scoped service into a singleton

Broken example:

public class ReportCacheService
{
    private readonly AppDbContext _db;

    public ReportCacheService(AppDbContext db)
    {
        _db = db;
    }
}

services.AddDbContext<AppDbContext>();
services.AddSingleton<ReportCacheService>();

Why this is a problem:

• AppDbContext is scoped
• ReportCacheService is singleton

Transient vs Scoped

// New instance every time the service is requested
services.AddTransient<IMyService, MyService>();

// One instance per HTTP request (in most ASP.NET Core apps)
services.AddScoped<IMyService, MyService>();

// One instance for the whole application lifetime
services.AddSingleton<IMyService, MyService>();

Quick rules

• Transient = fresh object each time
• Scoped = same object during one request
• Singleton = same object for all requests

Good defaults

• Stateless helper: Transient
• Database context: Scoped
• Request business service: Scoped
• Shared cache/config provider: Singleton

Important dependency rule

Prefer depending on the same or longer lifetime, not a shorter one.

Safe direction examples:

• Scoped -> Scoped
• Scoped -> Singleton

What is the difference between AddTransient and AddScoped in ASP.NET Core?

AddTransient creates a new instance every time the service is requested. AddScoped creates one instance per scope, which is usually one HTTP request in ASP.NET Core web apps.

When should I use AddScoped?

Use AddScoped for services that should stay consistent during a single request, especially services that use DbContext or request-specific data.

When should I use AddSingleton?

Use AddSingleton for shared application-wide services that are stateless or thread-safe, such as caches, configuration helpers, or metadata providers.

Is Entity Framework DbContext transient, scoped, or singleton?

It is typically scoped. That allows one context per request and avoids sharing it across unrelated requests.

Can I inject a scoped service into a singleton?

Usually no. This causes lifetime mismatch problems because the singleton lives longer than the scoped service.

Why do both registrations seem to work in my example?

Because both are valid registrations. But they do not behave the same way. Also, if you register the same service twice, the final resolved registration is typically the last one for normal single-service injection.

• Dependency injection — Service lifetimes are part of how dependency injection works.
• Inversion of control — DI containers manage object creation and wiring for you.
• ASP.NET Core middleware — Middleware often interacts with scoped services during a request.
• Entity Framework DbContext lifetime — DbContext is one of the most common scoped services.
• Constructor injection — ASP.NET Core usually supplies services through constructors.
• Service registration — Lifetimes are chosen when services are added to IServiceCollection.
• Thread safety — Singleton services often need to be thread-safe.
• IServiceScopeFactory — Used when singleton/background services need to create scoped dependencies.