MEF: DLL Versions and Multiple Exports for a Class

During my talk about the Managed Extensibility Framework (MEF) at Devscovery this past week, I had two very good questions asked by the audience and promised I’d get an answer.

The first one was about exporting in MEF. I was under the impression that a MEF part could have one export, but I was mistaken. The confusion came from this thread which doesn’t question multiple exports, but rather the shared policy (whether there is one export, or multiple instances of an export created). It’s one of those cases where I had read that and somehow got it in my head it wasn’t supported, and then simply didn’t have a reason to need it so I never investigated it further.

So, thanks for the great question.

Answer One: you can export a single class under multiple interfaces. Not a problem. And, depending on your creation policy, you can ensure only one instance is exported, or a separate interface for the different contracts.

The second one was a little more interesting. It was about versioning and DLLs. The question was if I import an assembly that has a part, then update the assembly on disk, can I pull in the new version?

Answer Two: no, you cannot reload a newer version of the assembly when it is updated on disk This isn’t a MEF limitation, but part of the CLR itself. If you think about it, you cannot do this without MEF, either. You might overwrite the DLL, but it will not get loaded (if it already is loaded) until you restart the application. Technically, you can unload the entire app domain or launch a new app domain, but you cannot unload the assembly within an app domain.

Wintellect’s Jeffrey Richter explains it well in this dot net rocks interview (PDF transcript). He says:

No you cannot and we will probably never offer that feature. If you think about it, if you load an assembly into an app domain and then you start executing code in that assembly, that may cause other assemblies to get loaded into that app domain as well. And then if you unloaded the first one, we don’t know to unload all the others that got loaded accidentally, if you will. So that is one of the reasons why we have app domains, is so that you can do this unloading and then all the other assemblies that got loaded as a side effect get unloaded at the same time. And we are probably going to keep that. We have heard that request from many people that if they want to unload an assembly, may be some day we’ll add it, but I think it’s very unlikely.

Thanks to everyone who attended and hope this answers your questions.

Jeremy Likness

Recent Posts

8-Step AWS to Microsoft Azure Migration Strategy

Microsoft Azure and Amazon Web Services (AWS) are two of the most popular cloud platforms.…

2 weeks ago

How to Navigate Azure Governance

 Cloud management is difficult to do manually, especially if you work with multiple cloud…

3 weeks ago

Why Azure’s Scalability is Your Key to Business Growth & Efficiency

Azure’s scalable infrastructure is often cited as one of the primary reasons why it's the…

1 month ago

Unlocking the Power of AI in your Software Development Life Cycle (SDLC)

https://www.youtube.com/watch?v=wDzCN0d8SeA Watch our "Unlocking the Power of AI in your Software Development Life Cycle (SDLC)"…

2 months ago

The Role of FinOps in Accelerating Business Innovation

FinOps is a strategic approach to managing cloud costs. It combines financial management best practices…

2 months ago

Azure Kubernetes Security Best Practices

Using Kubernetes with Azure combines the power of Kubernetes container orchestration and the cloud capabilities…

2 months ago