Repository navigation
Any chance to integrate functionality from System.ComponentModel.Composition? #15362
Description
Activity
I just ran into this myself trying to interop between a MEF1 container and a MEF2 container. Without ComposeExportedValue I'm seemingly hosed.
I also use ComposeExportedValue to import my Mocks for unit testing. How should that work in MEF 2?
Wednesday's article suggests that the port-to-core label is what designates community interest in having an API ported to .NET core. What we're looking for on this issue (missing functionality from MEF1) is either a port of the old system or a functionally-equivalent migration path. This affects code that would otherwise be portable to .NET Core for me and possibly others.
The applicable porting guidelines to this issue seem to be the following:
- Do not port APIs of technologies we don't want to support moving forward (see list below).
- Do not port APIs marked as obsolete.
- Consider porting APIs even if considered legacy, problematic, or otherwise inadequate.
- Consider using extension methods and partial facades to accelerate bringing revised APIs to the .NET Framework.
- Avoid "franken-designs" with extension methods and partial facades purely for the sake of .NET Framework compatibility.
This suggests that adding
ComposeExportedValue<T>()to MEF 2 could be considered a form of porting, in addition to the direct port. So I'd like to request this be marked as port-to-core so it's not missed in the consideration of community interest. Based on what little information I have, it seems like there's no reason it shouldn't be considered for porting by some method.The fact that MEF is "versioned" despite not being functionally equivalent and that MEF1 was part of core .NET while MEF2 was a separate package puts this whole thing in a weird limbo where we don't really know how it's being treated. It's unknown if MEF1 is being obsoleted, if people don't want to support it, or if people consider it done because MEF2 is there. It would be nice to get some feedback on MEF plans. Knowing what's under consideration and what contributions would be accepted would help us to actually plan for it.
Thanks for your time.
Just a +1 request for System.ComponentModel.Composition. Loading types from .dll's in a folder seems to be the dotnet/corefx#1 reason to use MEF.
Reacted by David OsolkowskiWe are also very interested in having this functionality back in .NET Core. We use specifically some custom ExportProviders to be able to get advanced compositions.
There are several things being requested in this issue, so I'm going to break them down into separate, specific issues:
- dotnet/corefx#11856 Support equivalent of ComposeExportedValue in System.Composition
- dotnet/corefx#8348 Equivalent for DirectoryCatalog
- dotnet/corefx#11857 Port System.ComponentModel.Composition (MEF1) to .NET Core
As far as merging the namespaces (and functionality), I don't think that's feasible.
@tmsns Porting MEF1 to .NET Core would probably resolve your issue, but if you are interested in equivalent functionality in MEF2, feel free to file an issue with more details about what you're looking for and what your scenarios are.
Thanks!
- ghost locked as resolved and limited conversation to collaborators
on Jan 4, 2021
A lot of
System.Compositioncode has been merged recently, and lines up with the MEF 2 code from codeplex. Is any of the code fromSystem.ComponentModel.Compositionlikely to be integrated? I have an old codebase that I've been refactoring and splitting out into separate components, and for some scenarios, I've had to useSystem.ComponentModel.Compositioninstead of theSystem.Compositionpackage available from Nuget.The main justification behind our switch was that the
CompositionContainersupportsComposeExportedValue<T>(T exportedValue)while theCompositionHostdoesn't. Being able to explicitly export an existing object instance can be useful when the full architecture isn't adjustable. While it's not exactly the purest of approaches, in some scenarios a little flexibility goes a long way.System.Composition"has been optimized for static composition scenarios and provides faster compositions". There are some scenarios where the alternative structure is a better fit, if less streamlined. We've also considered making this project cross-platform, which makes its presence in the OSS .NET Core desirable for us.I bring this up because
System.ComponentModelis marked as "done" on the progress chart, butSystem.ComponentModel.Compositionisn't listed at all. With the integration ofSystem.Composition, I'm concerned that this is something that's not even being considered and it might end up ignored by default.This also brings up the concern of whether merging namespaces would be feasible. Having multiple namespaces around isn't exactly ideal from a usability perspective, but changing them would be a compatibility issue. It's also possible that there's some code duplication between the two, at least as far as the attributes go. Discarding the old namespace for us is feasible - we want it for the functionality, but we're not attached to the namespace and are open to recompiling.
If I've somehow missed the introduction of equivalent functionality, please enlighten me.