2

When I try to obtain instance of object, which depends on parameter registered by UseInstance, I get

DryIoc.ContainerException : Expecting the instance to be stored in singleton scope, but unable to find anything here. Likely, you've called UseInstance from the scoped container, but resolving from another container or injecting into a singleton.

Using xUnit:

    public interface IFooDao { }
    public class FooDao : IFooDao
    {
        public FooDao(ConnectionStringSettings connString) { }
    }
    [Fact]
    void CompositionRootWontThrowException()
    {
        var container = new Container();
        container.Register<IFooDao, FooDao>(Reuse.Singleton);

        ConnectionStringSettings connString = ConfigurationManager.ConnectionStrings["ConnectionString"];
        container.UseInstance(connString);
        IFooDao dao = container.Resolve<IFooDao>();
    }

So I have this exception message, but I can't find problem and solution with it:

1) I don't have scoped container, because I didn't create it by container.OpenScope(), right? I have just one container so I can't be resolving from a wrong one. And it's a container

without context (which is default)

as per project wiki

2) So, what does it mean I'm "injecting into a singleton"? I'd like to inject dependency into singleton while creating it - what's wrong with that? Am I doing it anyway?

3) As per docs again, the instance of conn string should be in singleton scope

When you call the UseInstance the instance will be *directly put into Open scope or Singleton scope based on whether the container is scoped (returned from OpenScope call) or not. In addition, the scoped and sington instances may coexist with each other.

I used similar code before, just used DryIoc.MEF extension with ExportManyAttribute and ImportAttribute. Usage of UseInstace was exactly the same as bellow. Everything worked. What am I missing here? Why is this exception thrown?

First I tought this code is so simple it can't fail :)

Igand
  • 1,161
  • 1
  • 15
  • 25
  • 1
    I tried the test code here: https://dotnetfiddle.net/oVI99R But everything is working just fine using DryIoc 2.12.7 May be something else is influencing, not sure what. – dadhi Feb 26 '18 at 19:24
  • I probably can't curse here, so I'll just state, that the fact that test passes when I use constructor led me to look into whats different and it's simple AF - I didn't name my conn.string correctly and consequently I was registering null. UseInstance should throw exception on that tough. Unless it's ment to support deregistering this kinda odd way. I should have had a rest and another look before posting... Thanks. Will post it as answer to warn future searchers unless you will. – Igand Feb 27 '18 at 07:44
  • Interesting supporting case for not registering null. Actually UseInstance may accept null in case you want to warm up the container, then use instance in scope, like some context/request. Need to re-check is this still a valid scenario. Btw, Feel free to post your answer. – dadhi Feb 27 '18 at 15:42
  • I see. I never felt a need to warm up container (and presumably open scope), but you are surely aware of more special use cases than me. So if this is required, I wonder if it may be cleaner to support warming up by suplying sort of Null Object into overloaded method or even beter parameter less variant of UseInstance, which will register this Null O. itself. User of API probably doesn't need or want to know about it's exact type anyway. Also, I'd suggest the exception message to contain name of the type of dependency it failed to find and if possible, which it tried to resolve. – Igand Feb 28 '18 at 08:03
  • 1
    I am open to suggestions. Actually this is an interesting idea to move argument null checks into container. At least to have such an option. Here is the open issue to discuss https://bitbucket.org/dadhi/dryioc/issues/565/option-for-null-checking-of-injected – dadhi Feb 28 '18 at 12:35

1 Answers1

1

Problem was in null being registered.

UseInstance is fine with being given null value, but when you need the actuall dependency, even if the actuall null was resolved, it probably would not be considered to be enough and exception is thrown.

ConnectionStringSettings connString = ConfigurationManager.ConnectionStrings["ConnectionString"];

returned null, since actuall connection name in config was misstyped.

Igand
  • 1,161
  • 1
  • 15
  • 25