Hinting target container for Exported services

[chkp-omeran]

I'm converting a Prism/MEF application to Prism/DryIoc application, which heavily uses MEF's [Export] attributes.
In the application we created several custom "Export" attributes (all derived from ExportAttribute) to denote different containers, which would then be created in a hierarchy of containers.
I noticed AttributedModel.Scan creates ExpoertedRegistrationInfo without keeping the original Export(-derived) attribute that created it.
I'd much rather not change all the instances of my custom export attributes, but changing their definition is fine.
I thought about adding meta-data to my custom Export attributes, but is there a better way?

[dadhi]

@chkp-omeran Hi. If registration info would keep the original attrs, will it help?

[chkp-omeran]

Yes, it would, but after some more thinking, I'm not sure I actually need it -
Suppose we have the application's main container, and a child container for each server connection ("Connection-Aware Container").
Some the parts are defined with "ApplicationExport" and some with "ConnectionAwareExport", and I register them all to the main container. (previously I registered the ConnectionAware parts only to the child container)
The ConnectionAware parts require an IConnection part in their Imports, but the only IConnection parts are registered (as an instances) in the Connection-Aware container.
I made a small test and resolving the ConnectionAware parts works on the ConnectionAware container and not on the main container (as expected). Is there any downside with this usage?

[dadhi]

@chkp-omeran

Is there any downside with this usage?

No, I don't think so, but I am not as much into context of your app ;)

Regarding losing Exports in registration info, I wonder if I mark the MyExportAttribute itself as Metadata..
Need to play with it.

[chkp-omeran]

This would probably work too, but it seems that even now it's enough to declare [MetadataAttribute] on MyExportAttribute to get this metadata created on the ExportedRegistrationInfo

[dadhi]

Great then ;) Nothing for me to resolve.

Sure you're welcome if you have the ideas how to improve further the MEF story of DryIoc :)

[chkp-omeran]

Sure you're welcome if you have the ideas how to improve further the MEF story of DryIoc :)

I'm so glad you asked :)
I still have a lot of places in the code that use MEF's CompositionContainer for resolving services.
Is there an adapter that exposes DryIoc's IContainer as a CompositionContainer?
I tried writing a DryIocExportProvider (derived from MEF's abstract ExportProvider) but this seems to require duplicating DryIoc's ExportRegistractionInfo objects into Mef's ExportDefinitions, so it can be later matched in ExportProvider.GetExportCore by definition.IsConstraintSatisfiedBy().
Is there (or could there be) a better way?

[dadhi]

No I don't have such an adapter and I don't know how to write one. Some examples may help.
I remember there was and Autofac MEF extension, maybe I need to look there.

[chkp-omeran]

Ok, if I manage to write something generic enough, maybe I'll have something to contribute.