Different types registered with the same name

[bollhals]

Hi

I'm investigating whether I can use stashbox as a replacement for the deprecated unity container and I have a "special" setup that I can't seem to get right with stashbox.

Context:
I have a type Foo, which has a Bar property of type IBar. Each type (Foo & IBar) is registered in the container. (Foo as singleton, and IBar as factory which resolves Foo and then calls the property to return)

Now since I can have multiple Foos (and therefore also IBars), I used to register them with a name in Unity, So I was able later to decide when I resolved them, which one I get.

If I do the same with Stashbox, the result is that I get a InvalidCastException when resolving a named IBar. (Since Foo isn't implementing IBar directly). So somehow when resolving it returns the Foo object instead of calling my factory method (also when debugging it doesn't get hit)

So my question therefore is, is the construct of "name" in Stashbox different as such that they're unique? (E.g. registering a different type with the same name will result in a silent exception?) Or am I have I overlooked something 🤔

[z4kn4fein]

Hello,

Names are not supposed to be unique, could you please paste here your configuration? I'd like to take a look at what goes wrong, thanks!

[bollhals]

Ah yes, one case to add here

If you resolve the Foo type before the Bar, then it reproduces what I had originally:

So add container.Resolve<Foo>(Name1); before the other resolve, then the exception changes to:

System.InvalidCastException: Unable to cast object of type 'StashboxTest.Foo' to type 'StashboxTest.Bar'.
   at Stashbox.DependencyResolverExtensions.Resolve[TKey](IDependencyResolver resolver, Object name)
   at StashboxTest.Foo.Main() in C:\x800\StashboxTest\Class1.cs:line 27

[z4kn4fein]

I think I know what goes wrong with the name conflict. The delegate cache could make them unique which I'm going to fix. Regarding the first issue, I'm not sure what's the root cause but I'll investigate it further.

Thank you for the details!

[bollhals]

Thanks for looking into it, the library really looks nice and I'm eager to use it. (Btw, it's one of the best and cleanest documentation that I've seen, good job an that)

[z4kn4fein]

Thank you for your appreciation! :)

I've published a new pre-release 5.4.2-preview-759 package that fixes both issues (both were the symptom of the same malfunction).
Could you please check, that this version works on your side as expected? Thanks!

[bollhals]

Very nice, yes, this fixes the problem!

[bollhals]

One other thing that I encountered,

The resolve method has one overload without a name parameter and one with object name parameter.
On the other hand for CanResolve there is one with object? name parameter as well as for options.WithName(object? name).

Since the name in the resolve method is not nullable, it forces me to write code like:

                        { if (registrationName is null)
                        {
                            options.WithFactory(resolver => resolver.Resolve<Foo>().Bar);
                        }
                        else
                        {
                            options.WithFactory(resolver => resolver.Resolve<Foo>(registrationName).Bar);
                        }

Is this intended as such? (Just an minor inconvenience)

Context: My application has the option to register them via a name or without, hence there's this if now required on different places

[z4kn4fein]

Yes, it's a kinda legacy stuff, the previous API had optional parameters but I had to make a transition out of that API due to parameter changes. I can't recall the exact situation but as far as I can remember there was a case where the optional object name was conflicting with another parameter in a different overload. But I think now as each deprecated function is cleared out I can consolidate the API with optional parameters again. I'll take look at it for sure.

[z4kn4fein]

For now, I did not change the API much, but I set the name nullable on the resolve APIs, could you please check whether it's ok for your cases? It's in the package 5.4.2-preview-760. Thanks!

[bollhals]

Yes, that solves it as well 👍

[z4kn4fein]

I've released the fixes in 5.4.2.