This project has moved and is read-only. For the latest updates, please go here.

Controlling available "parts" by licensing model

Jan 5, 2009 at 9:13 PM
I was wondering what availability exists for overloading the catalog and controlling what the user can/cannot see by a licensing scheme?  We do work that including MEF into would be grand, but when/if we go this route, we'd need to control what the user could (not) run based on their license.  If we'd drop into this architecture of pluggable objects, I think that we'd not want to show them a module that doesn't exist for their license.

Any suggestions would be appreciated.  Thanks.
Jan 5, 2009 at 9:46 PM
I totally agree. In one of  my prev posts I had hinted that MEF is quite good for single user desktop apps than an enterprise wide application. In an desktop environment since the assemblies get copied to individual machines, licensing would not be that big an issue. But to create an enterprise application(Single application catering to many) with MEF does need lot more than discovery and instantiation. In fact the discovery would be a nightmare in such instance is my point of view.
Jan 5, 2009 at 10:07 PM
Edited Jan 5, 2009 at 10:08 PM
Thanks for the feedback. There are several different relatively easy approaches to addressing this today in MEF. There are also more sophisticated methods but they are much harder to implement.

1. Custom catalog which inspects assemblies - You can create your own custom directory part catalog that inspects assemblies as they are discovered to apply your own rules to determine loading. For example if the assembly represents a module, you could decide to not load that module.
2. Custom catalog which uses metadata - You can create a custom catalog which is a decorator for other catalogs (such as an aggregating) which filters which parts to return based on metadata in the parts. For example in this case the metadata might indicate which license is required,  and the custom catalog can match against the current license to determine what is returned. 
3. Custom Export Provider - Similar to the custom catalog, you can author a custom export provider which is passed to the container and which decorates Export Providers in the system (Export Providers talk to catalogs as well as other sources) to apply the same type of filtering. One advantage of this apporach over the catalog approach is that it applies the filter at a higher level which encapsulates more than just those exports returned from catalogs.

In all of the above cases you are applying custom logic to determine which parts / exports are made available to the container. The first approach (custom catalog which inspects) is appropriate for filtering at a very granular level, this assembly loads, this one doesn't. The last two approaches are for more fine grained control of parts and exports within those assemblies.