Version 2.1.2.1 Causes Container to Spuriously Fail Resolutions

[jbuckmccready]

Note what I describe below does not apply to version 2.1.1, I have no issues using 2.1.1.

My issue is when using version 2.1.2.1 of Unity.Microsoft.DependencyInjection and Microsoft.AspNetCore.Mvc 2.2.0 (have not yet tested against 2.1.3).

After using the extension method UseUnityServiceProvider(_container) on the WebHostBuilder (similar to what is in the examples) my use of the Unity _container after that point seems to spuriously fail to resolve types just throwing a generic resolution failed exception. I have had it fail on different types (suggesting perhaps a race condition).

Here's the exception details for one failure (they all look the same with just different types).

Unity.Exceptions.ResolutionFailedException
  HResult=0x80131500
  Message=Resolution of the dependency failed, type = 'GenericMachineLine.ModuleCore.IMachineLineSchedulerSettings', name = '(none)'.
Exception occurred while: while resolving.
Exception is: ResolutionFailedException - Resolution of the dependency failed, type = 'GenericMachineLine.ModuleCore.IMachineLineSchedulerSettings', name = '(none)'.
Exception occurred while: while resolving.
Exception is: ResolutionFailedException - 
-----------------------------------------------
At the time of the exception, the container was: 
  Resolving GenericMachineLine.ModuleCore.IMachineLineSchedulerSettings,(none)

-----------------------------------------------
At the time of the exception, the container was: 
  Resolving GenericMachineLine.ModuleCore.IMachineLineSchedulerSettings,(none)

  Source=Unity.Container
  StackTrace:
   at Unity.UnityContainer.ThrowingBuildUp(IBuilderContext context)
   at Unity.UnityContainer.Resolve(Type typeToBuild, String nameToBuild, ResolverOverride[] resolverOverrides)
   at Unity.UnityContainerExtensions.Resolve[T](IUnityContainer container, ResolverOverride[] overrides)
   at GenericMachineLine.ModuleCore.GenericMachineLine.RegisterMachineLineController() in C:\Users\buckm\Documents\fresh_clone\OverlordEnsemble\GenericMachineLine\ModuleCore\GenericMachineLineModule.cs:line 87
   at System.Windows.Threading.DispatcherOperation.InvokeDelegateCore()
   at System.Windows.Threading.DispatcherOperation.InvokeImpl()

Inner Exception 1:
ResolutionFailedException: Resolution of the dependency failed, type = 'GenericMachineLine.ModuleCore.IMachineLineSchedulerSettings', name = '(none)'.
Exception occurred while: while resolving.
Exception is: ResolutionFailedException - 
-----------------------------------------------
At the time of the exception, the container was: 
  Resolving GenericMachineLine.ModuleCore.IMachineLineSchedulerSettings,(none)

Here's the snippet of code that produced the exception above (all executed after using the extension method with the WebHostBuilder):

 _container.RegisterInstance<IMachineLineSchedulerSettings>(settings);
 var machineLineSchedulerSettings = _container.Resolve<IMachineLineSchedulerSettings>();

For now I am just using the old version 2.1.1.

[pksorensen]

I am getting the same things.

I have not been able to figure out what is going on. It seems to be related to serviceprovider being disposed randomly.

I gave up and rolled back to 2.1.1

[pksorensen]

I noticed callstacks that included Finalizer and dispose calls.

Could there be a "bug" with the following deconstructor? (i dont really know if it can be called at times where its not expected, i would not think so - but its really the only change since 2.1.1 that i dont fully understand

 ~ServiceProvider()
        {           {
            IDisposable disposable = _container;                Dispose(false);
            _container = null;  
            disposable?.Dispose();  
        }           }

[ENikS]

Rolled back changes from last release. Please let me know if problem still persists

[pksorensen]

@ENikS Thanks for the effort, i know the following message is a bit disappointing/demotivating, but i have decided to go back to using the build in DI system where possible.

This means that I am not in a state where i can verify if the problem is gone.

The reason for me to taking these steps is that there keeps coming corner cases where i end up spending more time that i would looking into why things fail. Its not a unity problem, as i first ported my stuff to use autofac which solved my current problem but then there was just a new corner case that did not work as expected.

It might be application specific and not at all anything to do with unity/autofac, but when things work with the build in DI then i can free up time to create more value.

So while it might be demotivating, i just did felt that you deserved a response (and maybe a bit of reasoning) and not just silence. I have appreciated the time you have put into this project and it have made a difference to my developer experience, thank you.

[ENikS]

Thx, good luck