{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"What is the main difference between Singleton, Scoped, and Transient lifetimes?","acceptedAnswer":{"@type":"Answer","text":"Singleton creates a single instance for the entire application lifetime, Scoped creates one instance per HTTP request (or scope), and Transient creates a new instance every time it's injected. These lifetimes determine when and how many times the DI container instantiates a service. Use Singleton for stateless shared services, Scoped for request-bound services (like DbContext), and Transient for lightweight stateless services."}},{"@type":"Question","name":"Which lifetime should be used to register an Entity Framework Core DbContext?","acceptedAnswer":{"@type":"Answer","text":"DbContext should be registered with Scoped lifetime because it's not thread-safe and maintains entity tracking state. Each HTTP request should have its own DbContext instance to avoid concurrency issues. Registration is done with AddDbContext which automatically configures Scoped lifetime. Using Singleton would cause concurrency errors, and Transient would waste resources by creating too many instances."}},{"@type":"Question","name":"How to register a service with an interface and its implementation?","acceptedAnswer":{"@type":"Answer","text":"Service registration is done with AddSingleton, AddScoped, or AddTransient methods by specifying the interface as the service type and the concrete class as the implementation. The syntax is services.Add{Lifetime}(). This approach respects the dependency inversion principle and facilitates testing by allowing implementation substitution. The DI container will automatically resolve the concrete implementation when injecting the interface."}},{"@type":"Question","name":"When should AddSingleton be preferred over AddScoped?","acceptedAnswer":{"@type":"Answer","text":"AddSingleton is suitable for stateless services shared across the entire application (configuration, cache, logging) as they are created once and shared between all requests. AddScoped is preferable for services that maintain state tied to a specific request (DbContext, business services with user context). Singleton improves performance by avoiding repeated allocations but requires the service to be thread-safe. Avoid Singleton for services with mutable state or dependencies on Scoped services."}},{"@type":"Question","name":"What is the role of IServiceProvider in the DI system?","acceptedAnswer":{"@type":"Answer","text":"IServiceProvider is the service container that resolves and provides instances of registered services. It exposes GetService and GetRequiredService methods to retrieve instances. The container automatically manages service creation, lifetime, and disposal according to their lifetime. It's built via ServiceCollection.BuildServiceProvider() and automatically injected into services that need it. Avoid injecting it directly (Service Locator anti-pattern) except for specific cases like factories."}},{"@type":"Question","name":"How to manually resolve a service from IServiceProvider?","acceptedAnswer":{"@type":"Answer","text":"Use GetService() for optional resolution that returns null if the service doesn't exist, or GetRequiredService() which throws an exception if the service is not found. Manual resolution is discouraged in constructors (use constructor injection instead) but acceptable in factories or specific cases. For Scoped services, create a scope with CreateScope() before resolving. Always prefer constructor injection to follow DI best practices."}},{"@type":"Question","name":"What is the difference between GetService and GetRequiredService?","acceptedAnswer":{"@type":"Answer","text":"GetService() returns null if the service is not registered, allowing optional resolution with null handling. GetRequiredService() throws an InvalidOperationException if the service is not found, guaranteeing a non-null instance. Use GetRequiredService for critical required dependencies, and GetService for optional dependencies. GetRequiredService avoids null reference exceptions and explicitly documents required dependencies. In practice, prefer GetRequiredService unless there's an explicit need for optional dependency."}},{"@type":"Question","name":"How to register multiple implementations for the same interface?","acceptedAnswer":{"@type":"Answer","text":"Register each implementation separately with AddSingleton/Scoped/Transient. To retrieve all implementations, inject IEnumerable which will contain all registered instances. If GetRequiredService is called with a single Add, only the last registered implementation will be resolved. This pattern is useful for plugins, multiple strategies, or handlers. Implementations are resolved in registration order."}},{"@type":"Question","name":"What is a captive dependency and why is it a problem?","acceptedAnswer":{"@type":"Answer","text":"A captive dependency occurs when a service with a long lifetime (Singleton) depends on a service with a shorter lifetime (Scoped or Transient). The Scoped service becomes captive of the Singleton and lives as long as the Singleton, losing its lifetime behavior. This causes subtle bugs like reusing a DbContext across multiple HTTP requests, leading to concurrency errors. The .NET DI container can detect this issue at startup with ValidateOnBuild and ValidateScopes enabled."}},{"@type":"Question","name":"How to use IServiceScopeFactory in a BackgroundService?","acceptedAnswer":{"@type":"Answer","text":"In a BackgroundService (Singleton), inject IServiceScopeFactory instead of Scoped services directly to avoid captive dependencies. Create a scope with CreateScope() in ExecuteAsync, then resolve Scoped services from scope.ServiceProvider. Dispose the scope after use (using statement). This pattern ensures each iteration of the background worker gets fresh instances of Scoped services like DbContext. Without a scope, Scoped services would become captive of the Singleton."}},{"@type":"Question","name":"What is the Options Pattern and how to use it with DI?","acceptedAnswer":{"@type":"Answer","text":"The Options Pattern allows injecting strongly typed configuration from appsettings.json. Configure with services.Configure(configuration.GetSection(\"MySection\")), then inject IOptions in services to access configuration via the Value property. Use IOptionsSnapshot for values refreshed per scope (HTTP request), or IOptionsMonitor for real-time changes. This pattern provides automatic validation, strong typing, and improved testability compared to using IConfiguration directly."}},{"@type":"Question","name":"Why is the Service Locator considered an anti-pattern?","acceptedAnswer":{"@type":"Answer","text":"Service Locator (injecting IServiceProvider to resolve services) hides the real dependencies of a class, making code hard to test and understand. Dependencies are not visible in the constructor, violating the dependency inversion principle. This can cause runtime exceptions if a service is not registered, while constructor injection fails at startup. Use explicit constructor injection to clearly document dependencies. Service Locator is acceptable only in specific cases like factories or plugins."}},{"@type":"Question","name":"What is the difference between constructor injection and property injection?","acceptedAnswer":{"@type":"Answer","text":"Constructor injection passes dependencies via the constructor, ensuring the object is always in a valid state with all its required dependencies. Property injection sets dependencies via public properties after instantiation, used for optional dependencies. The standard .NET DI container does not natively support property injection (unlike other frameworks). Constructor injection is strongly recommended as it makes dependencies explicit, improves testability, and ensures immutability."}},{"@type":"Question","name":"How to create and use a scope manually to resolve Scoped services?","acceptedAnswer":{"@type":"Answer","text":"Use IServiceScopeFactory.CreateScope() to create a new scope, then resolve services from scope.ServiceProvider.GetRequiredService. Dispose the scope after use with using statement to free resources and call Dispose on Scoped services. This pattern is useful in BackgroundService, unit tests, or any code running outside the HTTP pipeline. The scope ensures Scoped services have an isolated lifecycle and are properly disposed."}},{"@type":"Question","name":"What happens to IDisposable services registered in the DI container?","acceptedAnswer":{"@type":"Answer","text":"The DI container automatically tracks all IDisposable services and calls Dispose() when the scope or service provider is disposed. Singletons are disposed when the application stops, Scoped at the end of the HTTP request, and Transient at the end of the scope that created them. Avoid creating Transient IDisposable services as they remain in memory until the root scope ends. The container guarantees disposal in reverse creation order to respect dependencies."}},{"@type":"Question","name":"How to register a service with a factory method?","acceptedAnswer":{"@type":"Answer","text":"Use the AddSingleton/Scoped/Transient overload accepting a Func as factory. The factory receives the IServiceProvider to resolve dependencies and returns the service instance. Useful for complex creation logic, conditional initialization, or resolving multiple dependencies. The factory is called according to the configured lifetime. Example: services.AddScoped(sp => new MyService(sp.GetRequiredService(), \"config\")). This pattern provides full control over instantiation."}},{"@type":"Question","name":"What happens if a Singleton service depends on a Transient service?","acceptedAnswer":{"@type":"Answer","text":"The Transient service becomes captive of the Singleton and lives as long as the Singleton instead of being recreated on each injection. This violates the expected Transient behavior and can cause bugs if the Transient maintains state. The DI container can detect this violation with ValidateOnBuild and ValidateScopes enabled at startup, throwing an exception. To fix, use IServiceScopeFactory in the Singleton to create a scope and resolve the Transient when needed. Absolutely avoid injecting services with shorter lifetimes into services with longer lifetimes."}},{"@type":"Question","name":"How to use ServiceDescriptor to create a custom registration?","acceptedAnswer":{"@type":"Answer","text":"ServiceDescriptor is the low-level class to describe a registered service. Create a descriptor with new ServiceDescriptor(serviceType, implementationType, lifetime) or with a factory. Add the descriptor with services.Add(descriptor). Useful for conditional, dynamic, or metadata-based registrations. The AddSingleton/Scoped/Transient methods use ServiceDescriptor internally. Example: var descriptor = new ServiceDescriptor(typeof(IService), sp => CreateService(sp), ServiceLifetime.Scoped). This pattern provides more flexibility than standard extension methods."}},{"@type":"Question","name":"What is the Service Provider Root and why is it important?","acceptedAnswer":{"@type":"Answer","text":"The Service Provider Root is the root container created by BuildServiceProvider() that lives for the entire application lifetime. It contains all Singleton services and tracks Transient IDisposable services created in the root scope, causing memory leaks if many Transient IDisposable are resolved directly from the root. In ASP.NET Core, each request creates a child scope to isolate Scoped services. Avoid resolving services from the root provider except at application startup. Use scopes to manage lifecycle correctly."}},{"@type":"Question","name":"How to test code that uses Dependency Injection?","acceptedAnswer":{"@type":"Answer","text":"Create a test ServiceCollection, register real dependencies or mocks (Moq, NSubstitute), build the ServiceProvider and resolve the service under test. For unit tests, directly inject mocks into the constructor without using the DI container. For ASP.NET Core integration tests, use WebApplicationFactory which provides a pre-configured DI container with the ability to replace services via ConfigureTestServices. Constructor injection facilitates testing because dependencies are explicit and easily replaceable."}},{"@type":"Question","name":"What is the difference between TryAdd and Add for registering a service?","acceptedAnswer":{"@type":"Answer","text":"TryAddSingleton/Scoped/Transient registers the service only if it doesn't already exist for the same service type. If a service is already registered, TryAdd does nothing. Add always registers the service, potentially creating multiple registrations for the same interface. TryAdd is useful for default registrations that can be overridden, or to avoid duplicates in reusable modules. With GetRequiredService, only the last registration is resolved. With IEnumerable, all registrations are returned."}},{"@type":"Question","name":"How to replace a service already registered in the DI container?","acceptedAnswer":{"@type":"Answer","text":"Use services.Replace(ServiceDescriptor.Scoped()) to replace the existing registration. The Replace method searches and replaces the first service of the specified type. Alternatively, remove the old registration with services.RemoveAll() then add the new one with Add. In ASP.NET Core, ConfigureTestServices in WebApplicationFactory automatically replaces services for tests. Replacement is useful for substituting implementations in tests or configuring different behaviors based on environment."}},{"@type":"Question","name":"What are Keyed Services introduced in .NET 8?","acceptedAnswer":{"@type":"Answer","text":"Keyed Services allows registering multiple implementations of an interface with distinct keys. Register with services.AddKeyedSingleton(\"key\") and resolve with [FromKeyedServices(\"key\")] IService or GetKeyedService(\"key\"). Useful for multiple strategies (card payment, PayPal), named HTTP clients, or environment-based configurations. Before .NET 8, factories or wrappers were needed. Keyed Services simplifies this common pattern by offering native DI container support."}},{"@type":"Question","name":"How to handle circular dependencies in the DI system?","acceptedAnswer":{"@type":"Answer","text":"Circular dependencies (ServiceA depends on ServiceB which depends on ServiceA) cause a runtime exception during resolution. Solutions: refactor to eliminate circularity (extract common logic into a third service), use an interface or factory for lazy loading, or inject IServiceProvider to manually resolve a dependency. The best solution is always to refactor the architecture to avoid circular dependencies. The .NET DI container detects simple circular dependencies but not always complex chains."}}]}