The “Unable to resolve service for type” error in .NET Core is one of the most common runtime exceptions related to Dependency Injection (DI). It occurs when the built-in DI container fails to instantiate a required dependency while activating a controller, service, middleware, or background worker.
Typical error message:
InvalidOperationException: Unable to resolve service for type 'X' while attempting to activate 'Y'.
This means the framework tried to create object Y, but dependency X was not properly registered or could not be constructed.
Understanding how Dependency Injection works internally in ASP.NET Core is essential to fixing this issue correctly.
How Dependency Injection Works in .NET Core
ASP.NET Core uses a built-in IoC (Inversion of Control) container. Services are registered in Program.cs using IServiceCollection, and dependencies are resolved via constructor injection.
Example:
public class ProductController : ControllerBase
{
private readonly IProductService _productService;
public ProductController(IProductService productService)
{
_productService = productService;
}
}
If IProductService is not registered in the service container, the application throws the resolution error at runtime.
Root Causes and Fixes
1. Service Not Registered in DI Container
Most common cause: missing registration.
Incorrect:
// Missing registration
Correct:
builder.Services.AddScoped<IProductService, ProductService>();
Always ensure that interface-to-implementation mapping exists.
2. Incorrect Service Lifetime
Service lifetimes in ASP.NET Core:
Transient → New instance every request
Scoped → One instance per HTTP request
Singleton → One instance for entire application lifetime
Problem example:
A Singleton service depends on a Scoped service.
builder.Services.AddSingleton<MainService>();
builder.Services.AddScoped<ScopedService>();
If MainService injects ScopedService, it causes runtime failure.
Fix:
Align lifetimes or refactor dependencies.
3. Missing Concrete Implementation
Incorrect registration:
builder.Services.AddScoped<IOrderService>();
Correct registration:
builder.Services.AddScoped<IOrderService, OrderService>();
The DI container must know which concrete class implements the interface.
4. Constructor Injection Misconfiguration
If constructor contains unregistered primitive types or unsupported dependencies, resolution fails.
Problem example:
public ProductService(IRepository repository, string connectionString)
The DI container cannot resolve string automatically.
Correct approach using IConfiguration:
public ProductService(IRepository repository, IConfiguration configuration)
{
var connectionString = configuration.GetConnectionString("Default");
}
Or use the Options pattern:
builder.Services.Configure<DatabaseSettings>(
builder.Configuration.GetSection("DatabaseSettings"));
5. Circular Dependency
Circular dependencies occur when:
ServiceA → ServiceB → ServiceA
Example:
public class ServiceA
{
public ServiceA(ServiceB serviceB) { }
}
public class ServiceB
{
public ServiceB(ServiceA serviceA) { }
}
Fix:
Refactor architecture
Introduce mediator pattern
Break dependency chain
Circular references must be eliminated.
6. Missing Project Reference
In layered architecture:
API Layer
Application Layer
Infrastructure Layer
If Infrastructure is not referenced in API project, DI registration extension methods will not be available.
Ensure correct project references are added.
7. Middleware or Hosted Service Not Registered
If a custom middleware or background service depends on unregistered services, activation fails.
Example hosted service:
builder.Services.AddHostedService<WorkerService>();
Ensure WorkerService dependencies are also registered.
Advanced Troubleshooting Techniques
Enable Scope Validation
builder.Services.BuildServiceProvider(new ServiceProviderOptions
{
ValidateScopes = true,
ValidateOnBuild = true
});
This detects lifetime mismatches during application startup.
Enable Debug Logging
builder.Logging.SetMinimumLevel(LogLevel.Debug);
Review logs to identify failing service.
Inspect Inner Exception
Often the root cause appears in the inner exception chain.
Common Causes vs Solutions Table
| Cause | Description | Solution |
|---|---|---|
| Service not registered | Interface injected without registration | AddScoped/AddTransient/AddSingleton mapping |
| Wrong lifetime | Singleton depends on Scoped | Align lifetimes properly |
| Missing implementation | Interface without concrete class | Provide correct implementation mapping |
| Primitive injection | DI cannot resolve raw types | Use IConfiguration or Options pattern |
| Circular dependency | Services depend on each other | Refactor design |
| Missing project reference | Layer not referenced | Add correct project dependency |
| Middleware dependency missing | Custom middleware dependency unregistered | Register all required services |
Real-World Scenario
Scenario: Clean Architecture Web API
Controllers depend on Application services
Application services depend on Infrastructure repositories
If repository registration is missing:
services.AddScoped<IProductRepository, ProductRepository>();
Controllers fail during activation.
Correct solution: group registrations using extension methods.
public static class InfrastructureServiceRegistration
{
public static IServiceCollection AddInfrastructure(this IServiceCollection services)
{
services.AddScoped<IProductRepository, ProductRepository>();
return services;
}
}
Then register in Program.cs:
builder.Services.AddInfrastructure();
This maintains clean separation and prevents missing registrations.
Best Practices to Prevent This Error
Follow clean architecture principles
Keep constructors minimal
Avoid injecting primitive types
Validate service registrations at startup
Maintain consistent lifetimes
Group DI registrations logically
Write integration tests for dependency graph
Summary
The “Unable to resolve service for type” error in .NET Core occurs when the Dependency Injection container cannot construct a required dependency due to missing service registration, incorrect lifetime configuration, circular dependencies, constructor misconfiguration, or missing project references. Fixing this issue requires verifying interface-to-implementation mappings, aligning service lifetimes, avoiding primitive type injection, enabling scope validation, and maintaining proper architectural separation. By understanding how the ASP.NET Core DI container builds and resolves the dependency graph, developers can systematically diagnose and prevent this common runtime exception in enterprise .NET applications.

Join the conversation! Your thoughts help the community grow.