0

This is a copy of https://github.com/seesharper/LightInject/issues/173

I tried to automatically create concrete types using fallback and .Create() but it somehow loops itself and I don't understand why.

Here is my test code:

public class Foo
{
    public Foo(IBar bar, IBar2 bar2)
    {

    }
}

public interface IBar2
{
}

class Bar2 : IBar2
{
}

public interface IBar
{
}

class Bar : IBar
{
}

private ServiceContainer container = new ServiceContainer();


container.RegisterFallback((t, s) => true, Factory);
container.Register<IBar, Bar>();
container.Register<IBar2, Bar2>();
var foo = container.GetInstance<Foo>(); // Error here

private object Factory(ServiceRequest req)
{
    return container.Create(req.ServiceType);
}

Could you please advise?

It loops even if the Factory method looks like this:

private object Factory(ServiceRequest req)
{
    container.Register(typeof(Foo));
    return container.GetInstance<Foo>();
}

but works perfectly if I register Foo beforehand (which I obviously want to avoid)

container.Register(typeof(Foo));
var foo = container.GetInstance<Foo>(); //ok
John dow
  • 120
  • 8
  • I'm not experienced with LightInject, but it seems that LightInject calls the `Factory` method when you resolve `Foo`, but `Factory` calls back into the container requesting a `Foo`, which delegates to `Factory`, which calls back into the container requesting a `Foo`, which delegates to `Factory`, which calls back into the container requesting a `Foo`, which delegates to `Factory`, which calls back into the container requesting a `Foo`, which delegates to `Factory`, which calls back into the container requesting a `Foo`, which delegates to `Factory`, which calls back into the container... – Steven Mar 18 '15 at 08:16
  • But this is what was suggested here: https://github.com/seesharper/LightInject/issues/139 – John dow Mar 18 '15 at 08:57

2 Answers2

0

It's the bug that was confirmed in https://github.com/seesharper/LightInject/issues/173 and is looked after by author

John dow
  • 120
  • 8
0

I am the author of LightInject and the issue has been updated with a workaround that enables the container to resolve unregistered concrete classes.

https://github.com/seesharper/LightInject/issues/173

seesharper
  • 3,249
  • 1
  • 19
  • 23