Accessing Container instance with LighInject

Question

When using LightInject, how can you use access the Container instance in contexts other than initial registration/bootstrapping? I followed LightInject's getting started guide and google around, but didn't find anything like that.

For reference, I present how this is achieved in two other IoC frameworks.

Ninject

When using Ninject so I'm used to having the IKernel type automatically bound to the Kernel (Container on LighInject), so a class with a constructor like this:

public MyClass(IKernel kernel)
{
    var myInstance = kernel.Get<IMyType>();
}

will be able to use kernel to retrieve instances.

SimpleIoC

When using SimpleIoC, the framework that comes with MvvmLight, you can use a static property (SimpleIoC.Default) to achieve the same purpose:

var myInstance = SimpleIoc.Default.GetInstance<IMyType>();

[XY Problem](http://xyproblem.info/). It is [anti-pattern](http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/) to use the container outside of the [composition root](http://blog.ploeh.dk/2011/07/28/CompositionRoot/). What is it you are trying to do that makes you think you need to access the container? — NightOwl888, Mar 13 '18 at 16:04
@NightOwl888 I'm setting up a solution with MvvmLight which promotes the idea of a ViewModelLocator. I'm well aware of the common idea of ServiceLocator being an anti-pattern; my position about that is similar to this answer https://softwareengineering.stackexchange.com/a/317146/37007 — daniloquio, Mar 13 '18 at 16:29
If you don't mind the service locator, there is really nothing stopping you from putting the container into a static reference that you can access throughout your application. Many DI containers go out of their way to *not* include one to try prevent developers from tightly coupling their application to the container, but if that is what you want to do, go ahead. — NightOwl888, Mar 13 '18 at 16:48

score 0 · Answer 1 · answered Mar 14 '18 at 14:15

Short story

No such thing is provided out of the box by LightInject.

Elaboration

Doing this will imply a ServiceLocator kind of thing which most people, LightInject creator included, see as an anty-pattern that must be avoided. The idea is for the ServiceContainer (or Kernel as it's known on ninject) to be used exclusively during startup.

My take on it

In my case, I have a WPF application with MvvmLight. I want to follow the ViewModelLocator approach promoted by this library, which pretty much requires a ServiceLocator kind of thing.

On MvvmLight, ViewModelLocator is supposed to hold instances of each ViewModel and also is supposed to be set up as a resource on the App.xaml file. This implies ViewModelLocator absolutely needs to have a parameterless constructor, which makes using the IoC framework to bind references impossible.

My solution was to create a Singleton to expose the ServiceContainer so it can be referenced from the ViewModelLocator for providing instances fo the ViewModels.

The following discussion was very interesting and provided me with different points of view about this problem:

How to handle dependency injection in a WPF/MVVM application