Introduction
The “Unable to resolve service for type” error in .NET Core occurs when the built-in Dependency Injection (DI) container fails to instantiate a required service at runtime. This exception is one of the most common issues developers face while working with ASP.NET Core, Web API, Minimal APIs, background services, or microservices architecture.
This error typically appears as:
InvalidOperationException: Unable to resolve service for type 'X' while attempting to activate 'Y'.
In simple terms, the framework is trying to create an object (Y), but one of its dependencies (X) has not been registered in the Dependency Injection container.
To fix this issue correctly, it is essential to understand how Dependency Injection works internally in .NET Core.
Understanding Dependency Injection in .NET Core
Dependency Injection (DI) is a design pattern that enables loose coupling between components. In ASP.NET Core, services are registered in the IServiceCollection inside Program.cs (or Startup.cs in older versions). The framework automatically resolves dependencies 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 “Unable to resolve service” error at runtime.
Root Causes of the Error
There are several common causes behind this exception in .NET Core applications.
1. Service Not Registered in DI Container
This is the most frequent reason.
Problem:
IProductService is injected but not registered.
Solution:
Register it in Program.cs:
builder.Services.AddScoped<IProductService, ProductService>();
Choose the appropriate lifetime:
AddTransient → New instance per request
AddScoped → One instance per HTTP request
AddSingleton → Single instance for entire application lifecycle
2. Incorrect Service Lifetime Configuration
Sometimes services are registered but with incompatible lifetimes.
Example Problem:
A Singleton service depends on a Scoped service.
This causes runtime failures because a longer-lived service cannot depend on a shorter-lived service.
Solution:
Align service lifetimes correctly or refactor dependencies.
3. Missing Concrete Implementation
If only an interface is injected but no implementation exists, DI cannot resolve it.
Incorrect:
builder.Services.AddScoped();
Correct:
builder.Services.AddScoped<IOrderService, OrderService>();
4. Typo or Namespace Mismatch
In large enterprise solutions with multiple projects, it is common to accidentally register the wrong interface or implementation from a different namespace.
Always verify:
5. Constructor Injection Misconfiguration
If a constructor has parameters that are not registered services, the DI container fails.
Example:
public ProductService(IRepository repository, string connectionString)
Here, string connectionString is not registered as a service.
Solution:
Use IConfiguration or Options pattern instead of injecting primitive types directly.
Example fix:
public ProductService(IRepository repository, IConfiguration configuration)
{
var connectionString = configuration.GetConnectionString("Default");
}
6. Circular Dependency
If Service A depends on Service B and Service B depends on Service A, the DI container cannot resolve the dependency graph.
Example:
ServiceA → ServiceB
ServiceB → ServiceA
Solution:
Refactor architecture, introduce interfaces properly, or apply mediator pattern to break circular references.
7. Forgetting to Register External Services
When using external libraries such as AutoMapper, MediatR, FluentValidation, or custom middleware, their services must be registered.
Example:
builder.Services.AddAutoMapper(typeof(Program));
If not registered, injection will fail.
Real-World Scenario
Consider an enterprise e-commerce Web API project structured into:
API Layer
Application Layer
Infrastructure Layer
If the Infrastructure layer contains the repository implementation but is not registered in the API layer’s DI container, controllers depending on repositories will fail during activation.
Correct approach:
builder.Services.AddInfrastructureServices();
And inside Infrastructure project:
public static IServiceCollection AddInfrastructureServices(this IServiceCollection services)
{
services.AddScoped<IProductRepository, ProductRepository>();
return services;
}
This ensures proper separation of concerns while resolving dependencies correctly.
Step-by-Step Troubleshooting Checklist
Verify the service is registered in Program.cs.
Confirm correct lifetime configuration.
Ensure correct interface-to-implementation mapping.
Check for circular dependencies.
Validate constructor parameters.
Confirm project references are added.
Rebuild the solution to refresh dependency graph.
Common Causes and Fixes Table
| Cause | Why It Happens | How to Fix |
|---|
| Service not registered | Missing AddScoped/AddTransient/AddSingleton | Register service in DI container |
| Wrong lifetime | Singleton depends on Scoped | Align lifetimes properly |
| Missing implementation | Interface registered without concrete class | Provide implementation mapping |
| Circular dependency | Services depend on each other | Refactor architecture |
| Primitive type injection | DI cannot resolve raw types | Use IConfiguration or Options pattern |
| Namespace mismatch | Wrong interface reference | Verify correct project and namespace |
| External library not registered | Required services missing | Add required service registration |
Advanced Debugging Techniques
Enable detailed logging to inspect DI behavior:
builder.Logging.SetMinimumLevel(LogLevel.Debug);
Use dependency validation during startup:
builder.Services.BuildServiceProvider(new ServiceProviderOptions
{
ValidateScopes = true,
ValidateOnBuild = true
});
This helps detect scope issues early in development.
Best Practices to Avoid This Error
Follow clean architecture principles
Group service registrations using extension methods
Keep constructors minimal
Avoid injecting primitive types
Use the Options pattern for configuration
Maintain consistent service lifetimes
Write integration tests to validate DI setup
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 registrations, incorrect lifetimes, circular dependencies, or misconfigured constructors. Resolving this issue involves verifying service registration in the IServiceCollection, ensuring correct interface-to-implementation mapping, aligning service lifetimes, avoiding primitive type injection, and maintaining clean architectural boundaries. By understanding how the built-in DI container works and applying structured troubleshooting practices, developers can quickly diagnose and fix this common runtime exception in ASP.NET Core and distributed .NET applications.