Can't resolve some controller parameters if scanning in the registry

[mcliment]

When scanning for things in the registry, some types can't be resolved in the controller constructor (in the case of the example IOptions but I don't think it's exclusive to this type).

I have pushed some code to reproduce the issue:
https://github.com/mcliment/StructureMap.Microsoft.DependencyInjection/tree/issue-demo

To reproduce, run the sample site and go to /Bad. This should throw an exception because the type IOptions<MySettings> can't be resolved. Then go to /Good and should work, loading the same type through a wrapper. Then "/Bad" works perfectly.

The thing it that TryGetInstance can't resolve the type the first time (GetInstance works properly).

If the registry.Scan is removed from ConfigureContainer and the type MySettingsWrapper is added as services.AddTransient<IMySettingsWrapper, MySettingsWrapper>(); then /Bad works the first time.

As well, if the Scan has the clause a.Exclude(t -> true); instead of the Include(...) also works the first time.

[khellang]

Hmm. That's really weird. I'll take a look at it when I get home from work. What happens if you set a breakpoint in ConfigureContainer and inspect the registry? Does it have the IOptions <MySettings> registration?

[khellang]

I'm not sure what you mean by

As well, if the Scan has the clause a.Exclude(t -> true); instead of the Include(...) also works the first time.

How can that work? The wrapper registration won't get registered then.

@jeremydmiller If you call Scan on a Registry, will it lose all its existing registrations?

[mcliment]

@khellang Actually it does not lose the registrations because the MySettingsWrapper in the example wraps the IOptions<MySettings> and resolves properly.

OTOH, calling GetInstance instead of TryGetInstance resolves properly.

[jeremydmiller]

@mcliment Check your WhatDoIHave() output for that type that's not behaving correctly. And no, the Scan() doesn't throw away any of your other registrations.

[mcliment]

@jeremydmiller I don't see any major difference in any case, the results are on this gist: https://gist.github.com/mcliment/c3ae3e08c978996be1f390004fdde971

I also tried to add the MySettingsWrapper in the ConfigureContainer but works properly.

[jeremydmiller]

@mcliment I need a little more context. What exactly isn't working correctly?

[mcliment]

@jeremydmiller If you have some time to check out this repository (https://github.com/mcliment/StructureMap.Microsoft.DependencyInjection/tree/issue-demo) and run the demo site you'll see the error live. Just go to ~/Bad to see the error. The other url ~/Good always works and once it loads then the ~/Bad controller also works. I hope this helps.

[khellang]

Something leads me to believe that this is a StructureMap bug related to TryGetInstance and open generics. The open generic registration is there all along, but it won't "materialize" until it's resolved as a constructor argument or a call to GetInstance. After that, it works fine.

[jeremydmiller]

That's not a bug, that's behavior as designed. To keep the performance within reasonable limits with TryGetInstance, StructureMap uses a very small subset of its auto-resolution rules to magically resolve whether or not it could resolve that service, and the magic open-generic resolution isn't part of that subset. My thinking is that TryGetInstance should only apply to things you've explicitly registered.

I never use TryGetInstance in my own development and constantly recommend against using it, but the clowns on the ASP.Net team insist upon it for their goofy fallback mechanism.

[khellang]

Haha. Right. I think we're getting somewhere... Now we just need to figure out what we can do about this. I'm afraid this will get very hairy.

[mcliment]

@khellang Hmmm, I understand that but I can't see why not scanning things overcomes the problem if the same stuff is registered

[jeremydmiller]

If it's scanning, can you look at the WhatDoIHave() and see if there are multiple registrations for whatever service this is? Because in that case, StructureMap doesn't automatically select the first or last one like Windsor or Autofac does. In the case of the TryGetInstance, SM just punts because there's no explicit default.

[jeremydmiller]

@mcliment @khellang Not doing anything until January, but I'm gonna propose a new AspNetCoreCompatibility switch in 4.5 that can flip the transient disposal and open generic auto-resolution inside of the Container in one fell swoop -- plus whatever other wacky issues like this come up later.

Might add something to the diagnostics to assert when there's multiple registrations, or maybe something that can verify that there is a default for everything expected. Or something......

[upta]

@jeremydmiller Any new thoughts on this, or work-arounds? I'm trying out core 2.0 and deciding on a DI framework and ran into this issue.

We currently use Ninject (which has basically nothing going in the core arena) and rely heavily on being able to instantiate concrete classes without explicit registration.

My experience has been much the same:

1. Setup using .UseStructureMap()
2. Add concrete Dummy class to my Controller's constructor
3. Run as-is with no config: "Unable to resolve service for type 'Dummy'"
4. ConfigureServices -> services.AddTransient<Dummy>(): Works
5. ConfigureContainer -> registry.ForConcreteType<Dummy>(): Works
6. container.GetInstance<Dummy>() to "prime" it (when I had it setup the IServiceProvider ConfigureServices( IServiceCollection services ) way): Works

Thanks for any insight!

[jeremydmiller]

You can thank the ASP.Net <http://asp.net/> team for this one. If you were using StructureMap idiomatically, that would have worked just fine. The ASP.Net <http://asp.net/> Core adapter is the equivalent to StructureMap’s Container.TryGetInstance(), which will return a null because you don’t have any explicit registration. Container.GetInstance() would work as well. If necessary, I could show you how to toss in an IFamilyPolicy that would force SM to resolve missing concrete types in the TryGetInstance() logic. - Jeremy

…

On Oct 4, 2017, at 2:41 PM, Brian ***@***.***> wrote: @jeremydmiller <https://github.com/jeremydmiller> Any new thoughts on this, or work-arounds? I'm trying out core 2.0 and deciding on a DI framework and ran into this issue. We currently use Ninject (which has basically nothing going in the core arena) and rely heavily on being able to instantiate concrete classes without explicit registration. My experience has been much the same: Setup using .UseStructureMap() Add concrete Dummy class to my Controller's constructor Run as-is with no config: "Unable to resolve service for type 'Dummy'" ConfigureServices -> services.AddTransient<Dummy>(): Works ConfigureContainer -> registry.ForConcreteType<Dummy>(): Works container.GetInstance<Dummy>() to "prime" it (when I had it setup the IServiceProvider ConfigureServices( IServiceCollection services ) way): Works Thanks for any insight! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAK8C7NJ8MnlXmQKXA8cBMoZ1eqdk1mjks5so99sgaJpZM4LTENG>.