c# - LightInject IoC 容器在解析类型时抛出 stackoverflow

Question

试用 LightInject IoC 容器时 http://www.lightinject.net/它在解析 ISomeService 类型时抛出一个 stackoverflow 异常:

所有类型都在App_Start中注册:

container.RegisterAssembly("MyApp*.dll");

然后当我尝试在 Controller 中解决它时它失败并抛出一个 stackoverflow 异常:

    public SomeController(ISomeService someService)
    {
         _someService = someService;
    }

在使用ServiceLocator时也出现同样的错误:

ServiceLocator.Current.GetInstance<ISomeService>();

我已经对其进行了追踪，我可以看到它在此处的 LightInject ServiceContainer 类中失败了，但我还不明白为什么会失败。

public object GetInstance(Type serviceType)
{
    return GetDefaultDelegate(serviceType, true)(constants.Items);
}

调用GetDefaultDelegate后，执行路径再次回到GetInstance结束，造成死循环，堆栈溢出。

编辑 2 - 进一步追踪，它似乎是由 SomeService 同时具有构造函数和属性注入(inject)引起的:

public class SomeService : ISomeService 
{
    public IAnotherService AnotherService { get; set; }
    public SomeService(IAnotherService anotherService)
    {
        AnotherService = anotherService;
    }
}

正在通过构造函数和属性注入(inject)依赖项 IAnotherService AnotherService，但无意使用属性注入(inject)器。

编辑 3

应用程序中有几个层都使用 ServiceLocator，所以我最初使用 NuGet 将 LI 添加到它自己的项目中，所以我有:

MyApp.IoC.LightInject
MyApp.Repositories
MyApp.Services
MyApp.Web.UI

但实际上并不需要将其添加到自己的项目中，因为可以在UI层设置服务定位器提供者:

var serviceLocator = new LightInjectServiceLocator(container);
ServiceLocator.SetLocatorProvider(() => serviceLocator);

所以我刚刚删除了额外的项目并将 NuGet 包放入 UI 层。我还安装了 LightInject.Annotation 并故意不调用 container.EnableAnnotatedPropertyInjection() 方法，以确保仅使用构造函数注入(inject)。它仍在抛出 stackoverflow。

为了测试解析是否有效，我只是在我的 HomeController.Index() 方法中这样做:

public ActionResult Index()
{
    var a = ServiceLocator.Current.GetInstance<ISomeService>();
}

我向 ServiceController.GetInstance 方法添加了一些控制台日志记录，以便我可以查看导致 stackoverflow 的方法调用流程。这是日志，结果有点出乎意料。您可以看到，当它为 ISomeService 调用 CreateDelegate() 时，它最终会首先尝试获取 HomeController 的实例 - 这是为什么？

DoGetInstance: ISomeService. Key = ''
GetInstance: ISomeService
TryGetValue: ISomeService not found
TryAddValue: trying to add ISomeService now
CreateDynamicMethodDelegate: ISomeService
CreateDynamicMethodDelegate: calling CreateDelegate() for ISomeService
DoGetInstance: HomeController. Key = ''
GetInstance: HomeController
TryGetValue: HomeController not found
TryAddValue: trying to add HomeController now
CreateDynamicMethodDelegate: HomeController
CreateDynamicMethodDelegate: calling CreateDelegate() for HomeController
DoGetInstance: ISomeService. Key = ''
GetInstance: ISomeService
TryGetValue: ISomeService not found
TryAddValue: trying to add ISomeService now
CreateDynamicMethodDelegate: ISomeService
CreateDynamicMethodDelegate: calling CreateDelegate() for ISomeService
DoGetInstance: HomeController. Key = ''
GetInstance: HomeController
TryGetValue: HomeController not found
TryAddValue: trying to add HomeController now
CreateDynamicMethodDelegate: HomeController
CreateDynamicMethodDelegate: calling CreateDelegate() for HomeController
DoGetInstance: ISomeService. Key = ''
GetInstance: ISomeService
TryGetValue: ISomeService not found
TryAddValue: trying to add ISomeService now
CreateDynamicMethodDelegate: ISomeService
CreateDynamicMethodDelegate: calling CreateDelegate() for ISomeService
DoGetInstance: HomeController. Key = ''
GetInstance: HomeController
TryGetValue: HomeController not found
TryAddValue: trying to add HomeController now
CreateDynamicMethodDelegate: HomeController
CreateDynamicMethodDelegate: calling CreateDelegate() for HomeController
DoGetInstance: ISomeService. Key = ''
GetInstance: ISomeService
TryGetValue: ISomeService not found
TryAddValue: trying to add ISomeService now
CreateDynamicMethodDelegate: ISomeService
CreateDynamicMethodDelegate: calling CreateDelegate() for ISomeService

当我注释掉服务的构造函数时，解析起作用并且所有依赖项都通过属性注入(inject)来解析。如果包含构造函数，则会抛出 stackoverflow 异常。

虽然解析 ISomeService 仅在使用属性时有效，但如果该服务在其依赖项中包含 ISomeService，我将无法解析 IAnotherService。我希望上面的日志能说明问题。到目前为止LightInject的性能已经明显好于Unity

Answer 1

作为 LightInject 的作者，我会尽力回答。

首先，LightInject 永远不应抛出 StackOverflowException，因此需要根据您在此处描述的内容进行调查。

而且我清楚地了解属性注入(inject)不是您的意图，因为两次注入(inject)服务(构造函数和属性)毫无意义。

实际上我们可以做几件事来避免将依赖注入(inject)到属性中。

1. 通过删除公共(public) setter 将属性设置为只读。

2. 使用文档中称为“显式”服务注册的方式注册服务。

   container.Register<ISomeService>(f => new SomeService(f.GetInstance<IAnotherService>())); 
   

   这将导致公共(public)属性被忽略，因为我们现在已经明确了如何解决 SomeService 类的依赖关系。

3. 利用LightInject.Annotation

   这将确保只有标有 InjectAttribute 的属性才会注入(inject)其依赖项。在您的特定情况下，这意味着只保留没有属性的属性。在组合根目录下，我们可以通过进行这个简单的配置来启用它。

   container.EnableAnnotatedPropertyInjection(); 
   

如前所述，我将进一步调查 StackOverflowException 并针对此案例进行适当的调整。我的第一个想法是，如果容器发现有资格作为构造函数依赖项和属性依赖项进行注入(inject)的依赖项，则抛出异常。

希望这对您有所帮助。

最好的问候

伯恩哈德·里希特

编辑

虽然您的问题似乎已解决，但我仍然希望能够在测试中重现此问题。您获得异常的原因可能并不像服务同时具有相同类型的构造函数依赖项和属性依赖项那么简单。

考虑这项服务

public class FooWithConstructorAndPropertyDependency : IFoo
{
    public FooWithConstructorAndPropertyDependency(IBar bar)
    {
        Bar = bar;
    }

    public IBar Bar { get; set; }
}

LightInject 将愉快地注入(inject)依赖项。

container.Register<IBar, Bar>();
container.Register<IFoo, FooWithConstructorAndPropertyDependency>();

container.GetInstance<IFoo>();

所以一定有其他原因导致了异常。如果您能想出最小的例子来重现异常以便处理这个问题，我将不胜感激。对我来说，在没有任何失败的情况下进行进一步调查有点困难:) 如果您选择进行这项工作，您可以将其张贴在这里或发邮件至 bernhard.richter@gmail.com。