Incorporate IOC (dependency injection) throughout the toolkit

[StevenRasmussen]

I've worked a bit with dependency injection for quite some time now and see some huge benefits if we were to incorporate it into the toolkit. Asp.Net Core has this built-in and so many developers are already familiar with it. The commercial extension that I've built uses it extensively and it works really well. One of the difficulties with the current Visual Studio extension model via the ProvideService attribute is that all the services need to be known at design time, which reduces some of the benefits as you can't dynamically register items in the DI container. Perhaps my understanding about this is not quite right though... does anyone know if we have access to the service collection before the IServiceProvider is built?

One area that I think could benefit from this is with regards to commands. Commands will oftentimes take a dependency on other objects or services and so this might require you to pass in arguments to the constructor of the command. If both the command and its dependencies are registered in the DI container then you can simply grab an instance of the command from the container and not have to worry about manually instantiating the object with all of it's dependencies (which may have their own dependencies as well).

If we wanted to incorporate IOC into the toolkit, as I see it we have 2 options:

1. Try to leverage the built-in container using the ProvideService attribute - this limits us to only being able to register services at design time.
2. Provide our own container with hooks to be able to allow dynamically registering services at runtime. We could still register our DI container into the main Visual Studio container using the ProvideService attribute.

This ties into the discussion around whether or not to make all the major services interfaces (#85). Using DI doesn't "require" per-se that everything is an interface, but it definitely seems to be the "best practice" for purposes of unit testing/mocking etc.

If we were to implement DI, I feel that we'd want all of the services that are currently implemented as properties on the VS object to be interfaces and added to the DI container (they all seem to be singletons). We could still keep the VS paradigm if people want but we'd want the same instance of each interface to be returned whether from one of the VS.* properties or through the DI container.

Adding a DI container could possibly allow us to:

• Register commands by simply using an attribute applied to the command (this is already supported to some extent but doesn't work when the command has other dependencies that should be injected into the constructor). This would then allow us to instantiate and invoke a command by simply retrieving it from the DI container.
• Register custom WPF windows in the DI container and be able to show them by calling a generic method on a service, ie IWindowService.ShowDialog<TWindow>
• Take advantage of other patterns/libraries that use DI, ie MediatR. I use this in my extension and it's pretty amazing!

Thoughts?

[yannduran]

I agree 100% that introducing DI in the toolkit would be a huge benefit! I've also used MVVM Light in my extensions (which I need to replace with Microsoft's MVVM library). I inject service classes (my own not VS services) into my viewmodel logic a lot.

Would it be possible to use the same DI container that Asp.Net Core uses? As you point out many developers already use it.

[StevenRasmussen]

I currently use the Microsoft.Extensions.DependencyInjection package (same as Asp.Net Core) but it needs to be the 2.2 version as that is the only version I could get to work and be compatible with a Vsix. I can't remember the issue I was encountering, and looking at the packages now even the newer ones are compatible with .Net Framework 4.6.1 (which is the same as v2.2) but for some reason I couldn't get it to work with anything greater than v2.2. My extension targets VS2017+. So yes it's compatible but not the latest versions unfortunately. That being said, I haven't found any functionality that is different from 2.2 and later versions.

[StevenRasmussen]

Just created a POC for this here: #123