Why ExportTypeIdentity not Type

Dec 26, 2009 at 12:57 AM

What was the reason behind implementing ExportTypeIdentity metadata as string instead of Type object? It seems to make it harder to implement dynamic export catalog.

Dec 31, 2009 at 10:45 AM

the reason is that MEF design to be neutral to the part implenetation so

 you can use it with dynamic lagguages or even consume none object parts like file, picture, ext....

Dec 31, 2009 at 10:54 AM

MEF is designed to support lazy loading (though our attributed model does not currently lazy load). Having the actual type embedded in the metadata would force the type itself to be loaded. The additional reason was a bnaya said that we did not want to couple parts to type. However there is an API you can use called ReflectionModelServices which will let you inspect an import definition to see it's type such as in a catalog. If you look in MEF contrib, you will see my Open Generic catalog uses this in order to dynamically generate closed generic parts on the fly.


Jan 4, 2010 at 2:05 AM

Thanks for the reply.

- I thought when you specify the type in [Import] or [Export] attribute, it forces the specified type to be loaded anyway.

- When the type is converted into string, there is no safe way to convert it back as it doesn't have assembly information associated with it. Do you think it would be safe enough in term of type association/resolution?

- GenericCatalog is great by the way. But I can see your GenericCatalog doing some string manipulation in which you said you hated it anyway :)