Migrate DI from Microsoft.VisualStudio.Composition to Microsoft.Extensions.DependencyInjection

[tom-englert]

This PR only migrates the DI engine

Migrating the Export attributes to Microsoft.Extensions.DependencyInjection.Abstractions will be done in a separate PR, to not overload this PR.

[siegfriedpammer]

Can you provide some explanation why the DI engine needs to be changed?

[tom-englert]

Mainly to get rid of technical debt.
Microsoft has abandoned Mef1 and Mef2, and replaced it with the new, lightweight and faster DependencyInjection framework that is now used in every modern DotNet application.
Same reason why we use DotNet8, even though NetFramework is still working fine...

[christophwille]

Didn't we very much intentionally move from MEF to VS MEF?

Edit: yes, we moved for performance reasons. https://github.com/microsoft/vs-mef

[tom-englert]

DependencyInjection framework should be even more slim and faster

[tom-englert]

https://github.com/danielpalme/IocPerformance

So the performance improvement of VSMef is only when compared to MEF1!

[christophwille]

I concur that the original reason may no longer apply (and we are a small extensibility provider anyways).

Btw. is there a way to reduce the "package sprawl"? I mean some of the Toms.* are super-small and we now (w transitive dependencies) include quite a few of those.

[tom-englert]

I had no idea how, beside duplicating all of the source code.
However getting rid of three heavy ones in exchange for five small ones isn't a too bad deal, isn't it?

[tom-englert]

It's even one less after final migration (left) compared to 8.2 (right)!

[siegfriedpammer]

Thank you very much!

[christophwille]

@tom-englert @siegfriedpammer we plan to release Preview 3 on ~4th November evening. Any big ticket items missing on your end?

[tom-englert]

Just cleaning up the use of singletons, and replace them by DI services. This is just architectural cleanup, nothing that is required for the next release.