You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

ASP.NET Core 2.0注入BLL服务时出现依赖注入异常求助

Hey there, let's walk through the common issues that might be causing your dependency injection failure when using your BLL service in the controller. Since your project compiles fine but blows up at runtime, it's almost always related to how you've registered or referenced your services in the DI container. Here's a step-by-step troubleshooting guide:

1. Double-check if your service is registered in the DI container

ASP.NET Core won't automatically discover your BLL services—you have to explicitly register them.

  • Open your Startup.cs file (this is the configuration hub for ASP.NET Core 2.0 projects)
  • Navigate to the ConfigureServices method, and make sure you've added your service and its interface like this:
    // Choose the right lifetime based on your business needs
    services.AddTransient<ITestService, TestService>(); // Creates a new instance per request
    // OR
    services.AddScoped<ITestService, TestService>(); // Reuses instance within a single request
    // OR
    services.AddSingleton<ITestService, TestService>(); // Single instance for the app's lifetime
    
  • Don't forget: Ensure your Web API project has a direct reference to your BLL class library, and you've imported the correct namespace for ITestService and TestService in Startup.cs.
2. Verify your controller's constructor injection is set up correctly

Your controller needs to accept the interface (not the concrete service class) via a public constructor for DI to work. Here's the correct pattern:

public class TestController : ControllerBase
{
    private readonly ITestService _testService;

    // Public constructor with interface injection
    public TestController(ITestService testService)
    {
        _testService = testService ?? throw new ArgumentNullException(nameof(testService));
    }

    [HttpGet]
    public IActionResult Get()
    {
        var result = _testService.DoSomething();
        return Ok(result);
    }
}

Common mistakes to avoid:

  • Using a private/protected constructor (DI container can't access it)
  • Injecting the concrete TestService class instead of ITestService (breaks dependency inversion and fails if you didn't register the concrete class)
  • Forgetting to handle null parameters (leads to null reference exceptions later)
3. Check for missing dependencies in your BLL service

If your TestService depends on other services (like a DB context, another BLL service, etc.), those dependencies also need to be registered in the DI container. For example:

public class TestService : ITestService
{
    private readonly IAnotherService _anotherService;

    // TestService depends on IAnotherService
    public TestService(IAnotherService anotherService)
    {
        _anotherService = anotherService;
    }

    // ... your service logic
}

You must register IAnotherService too:

services.AddTransient<IAnotherService, AnotherService>();

If any nested dependency is missing, the DI container can't resolve TestService and will throw an activation error.

4. Get the exact error message (this is critical!)

You mentioned an error occurs when calling the Get method, but without the specific exception details, it's hard to pinpoint the issue. Here's how to get it:

  • In debug mode, check the Visual Studio Output window for the full exception stack trace
  • Look at the HTTP response from your API (usually a 500 Internal Server Error) — it will include a message like:

    Unable to resolve service for type 'YourBllNamespace.ITestService' while attempting to activate 'YourApiNamespace.Controllers.TestController'.
    This message will tell you exactly what the DI container can't find.

5. Confirm namespace and class library references
  • Make sure your Web API project has added a reference to your BLL class library (right-click the Web API project → Add → Reference → Select your BLL project)
  • Ensure you've imported the correct namespace for your service and interface in both Startup.cs and TestController (using YourBllProjectNamespace;). A wrong namespace can lead to the DI container looking for the wrong type.
6. Rule out naming conflicts or multiple implementations

If there are multiple classes in your solution that implement ITestService, the DI container won't know which one to use. ASP.NET Core 2.0 doesn't support named services natively, so you'll need to either:

  • Remove the conflicting implementations
  • Use a custom factory to resolve the correct service

内容的提问来源于stack exchange,提问作者Arkadi

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.05.19 07:49:10