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

Question

在尝试使用 LightInject IoC 容器 http://www.lightinject.net/ 时，它会在解析 ISomeService 类型时引发 stackoverflow 异常：

所有类型都在 App_Start 中注册：

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

然后，当我尝试在控制器中解决它时，它会失败并引发 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 同时具有构造函数和属性注入引起的：

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

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

编辑 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() 方法，以确保仅使用构造函数注入。它仍在抛出 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

当我注释掉服务的构造函数时，解析工作和所有依赖项都通过属性注入解决。如果包含构造函数，则会引发 stackoverflow 异常。

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

Answer 1

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

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

而且我清楚地知道，属性注入不是您的意图，因为两次注入服务（构造函数和属性）没有什么意义。

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

1. 通过删除公共设置器将属性设为只读。

2. 使用文档中所说的“显式”服务注册来注册服务。

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

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

3. 利用 LightInject.Annotation

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

   container.EnableAnnotatedPropertyInjection(); 
   

如前所述，我将进一步调查 StackOverflowException 并针对这种情况进行适当的调整。我的第一个想法是，如果容器发现一个可以作为构造函数依赖和属性依赖注入的依赖项，则抛出异常。

希望这会有所帮助。

最好的问候

伯恩哈德·里希特

编辑

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

考虑这项服务

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

    public IBar Bar { get; set; }
}

LightInject 将愉快地注入依赖项。

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

container.GetInstance<IFoo>();

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