-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate DI from Microsoft.VisualStudio.Composition to Microsoft.Extensions.DependencyInjection #3308
Migrate DI from Microsoft.VisualStudio.Composition to Microsoft.Extensions.DependencyInjection #3308
Conversation
d969989
to
fd8dc53
Compare
Can you provide some explanation why the DI engine needs to be changed? |
Mainly to get rid of technical debt. |
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 |
DependencyInjection framework should be even more slim and faster |
https://github.com/danielpalme/IocPerformance So the performance improvement of VSMef is only when compared to MEF1! |
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. |
I had no idea how, beside duplicating all of the source code. |
…sions.DependencyInjection
fd8dc53
to
66544e6
Compare
…the lightweight System.Composition.AttributedModel
Thank you very much! |
@tom-englert @siegfriedpammer we plan to release Preview 3 on ~4th November evening. Any big ticket items missing on your end? |
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. |
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.