Can Creation Policy be managed by the host/container?

May 29, 2009 at 3:21 PM


I'm planning on using MEF on a project where a host contains a couple of classes that import a specific part. In this particular project I'd like all of these classes to import a shared instance of the part. But at the same time, in future projects I might want to have one of these classes import the part differently - as non-shared.

It seems to me that the decision on how to instantiate the part should be made by each project's host (meaning by the container the host is using). This is becayuse different hosts will have different preferences on shared / non-shared instantiation for the part. Is there any way for me to delegate the choice of the Creation Policy to the host/container?


Thanks, urig.

May 29, 2009 at 4:37 PM

Currently there isn't really any way for the host to make this decision and arguably that is how it should be. In MEF we are trying to let the part self describe and configure itself based on what it needs.

That said I’m interested in the scenario you have where you think you may want to do this?

Also if you are really interested in doing something along these lines you might have a look at the following blog post it might give you some ideas.

May 29, 2009 at 9:41 PM

Thanks for the quick response Wes. I've taken a look at David Kean's blog post and yet I'm not sure if it's useful in my scenario.

Here's my scenario:

My host is a WCF service (itself hosted in IIS). It contains 2 "logic" components and these both share a dependency on an external data provider part. So for this host I need the imports to have CreationPolicy set to shared.

In the future, however, I might like to host one of the logic components in a different process and have it import the external data provider part as non-shared. Since the CreationPolicy is set inside the component, at the [Import] attribute, I cannot manage it from the host. But it's the host that "decides" how to instantiate the imported external data provider.

Does this make sense? Is there maybe a better way to formalize my dependencies so that instantiation is controlled not by the importing part but by the host?


Many thanks,

Uri Goldstein

May 31, 2009 at 12:37 AM

Based on your description it would appear that you are making the assumption that the ImportAttribute, via its RequiredCreationPolicy property, controls the CreationPolicy of a part (i.e. export) it imports. Actually the part itself controls its creation policy via the PartCreationPolicyAttribute. By default it is set to CreationPolicy.Any but if you wish it to be a specific creation policy then you can set it to either Shared or NonShared accordingly via the PartCreationPolicyAttribute.

Think of ImportAttribute.RequiredCreationPolicy as a filter that will only allow exports from parts that have the specified creation policy to be used to satisfy that import. Have a look at if you haven't already, that documentation is in need of some updating (i.e. CompositionOptions(CreationPolicy=...) as been replaced with PartCreationPolicy(CreationPolicy...)) but it gives you the basics.

So perhaps for your particular scenario above you don't want to specify a RequiredCreationPolicy on the Import but instead only expose the correct export in each of the two cases. Case one have an export of the data provider coming from an part that is Shared and in case two have it come from a part that is NonShared.

I hope that helps.

Jun 2, 2009 at 8:31 AM

Thanks for setting me straight Wes. I was indeed under the wrong impression that the Import can dictate the creation policy.

Are you suggesting that I will create two parts - one shared and the other non-shared - that wrap around my data provider class? Isn't that somewhat cumbersome? Doesn't it make sense to have the container have some degree of control over instantiation models?