Microsoft MEF contains a surprise

Microsoft's Managed Extensibility Framework (MEF) is a shiny new technology for building applications that bind to components at run-time. The stated purpose is to let you build flexible applications and change them at run-time.

I think there is more to it.

First, a short overview of MEF:

The Managed Extensibility Framework is a library that lets you build components and applications and connect the two at run-time. (Kind of like explicitly loading a DLL in the old Windows days.) You must add several assemblies and code to your application, and you must specifically design your components to plug in to the MEF way of doing things.

MEF uses the concept of catalogs, collections of assemblies that can be loaded for your application. You request an assembly by instantiating an object of an exported type (with some attribute syntax in your code) and MEF searches the catalog for the assembly that matches your request. You have, of course, populated your catalog with assemblies, each with the proper attribute syntax to describe their exported classes and methods.

Catalogs may be included in your executable, or as a separate component, or even accessed across the internet, so (I think) you can distribute a small application file that connects to your server for the special bit of logic that only you have. More on this later.

Microsoft advertises the Managed Extensibility Framework as a tool that "enables greater reuse of applications and components". And I'm sure it does, although building the plumbing for dynamic loading of components and then including those same components in the EXE file seems to be the long way around for the problem. And that is the clue for the surprise in MEF.

MEF loads components from a catalog. A catalog holds assemblies, although some catalogs hold not assemblies but other catalogs. In this way, an application can search multiple catalogs for components.

Catalogs are located by URI, which means that they can be anywhere on the internet. They do not have to be on your local PC. So you could deploy a server and host commonly used components, build applications, and configure them to use a combination of local components and server-based components.

Here's what I think Microsoft has in mind: A new generation of PC applications (say, MS Office version 14) with small PC applications that connect to Microsoft servers for key functionality. Only the Microsoft servers will host these key classes, and you will have to talk to their servers to get them. This gives Microsoft two opportunities.

First, Microsoft can use a paywall to force people to pay for their applications. Rather than buy a shiny disc with MS Office, the starter kit will be free, but any important functionality (like printing) will cost you every time you use it. (Or possibly a monthly subscription.)

Second, Microsoft can provide different levels of functionality to people who pay different amounts. They can provide basic functionality to people who pay for "basic" services and enhanced functionality to people who pay more. Premium users will have more fonts, more charting options, bigger spreadsheets, longer documents, automatic indexing, and goodness knows what else.

Such a model gives Microsoft a constant revenue stream, lets them compete with Google Docs and Open Office, eliminates the upgrade headaches for both themselves and their users, and locks people into Windows (since there won't be an MEF-based app for Macintosh or Linux). Microsoft would be foolish to not take advantage of such a technology.

Managed Extensibility Framework purports to offer reuse and a standard plug-in model. It also, quietly, offers Microsoft a future on the internet.