12

Is there a way with a plugin system (I would use with an IoC container) to load one version of an assembly at runtime and then replace that DLL while the AppDomain is running? I don't want to restart the application.

Does MEF do something like this?

Daniel A. White
  • 187,200
  • 47
  • 362
  • 445

5 Answers5

4

This is essentially what NUnit does (or at least did, I haven't been in the code in a while). But it does it by loading the test assembly in another AppDomain, calling code in that domain using the DoCallback method of AppDomain and then reloads the test assembly if it is recompiled.

So while you can't unload or reload a dll, but you can unload and reload an appdomain and execute code in it.

Mike Two
  • 44,935
  • 9
  • 80
  • 96
1

It is impossible using pure .net, because there is no way to unload assembly from domain. Since MEF is written in managed code I doubt that it is possible. I solved this issue by loading assembly to separate domain and when I wanted to reload it I stoped it and started again.

Andrey
  • 59,039
  • 12
  • 119
  • 163
  • Can one appdomain access other code in other appdomains? Suppose I have it registered in my IoC container, could it resolve it? – Daniel A. White Feb 22 '11 at 16:32
  • @Daniel yes, but you need special code to access the code in the other [appdomain](http://msdn.microsoft.com/en-us/library/system.appdomain.aspx). – C. Ross Feb 22 '11 at 16:45
  • If I'm not mistaken, MEF can be configured to load plugins in separate AppDomains. – Steven Feb 23 '11 at 09:06
1

http://msdn.microsoft.com/en-us/library/ms173101(v=VS.90).aspx

http://people.oregonstate.edu/~reeset/blog/archives/466

Dustin Davis
  • 14,482
  • 13
  • 63
  • 119
  • I don't need it at design time. – Daniel A. White Feb 22 '11 at 16:51
  • I don't see how programming against interfaces helps in this case. I'm all for it, but if the dll needs to be reloaded for whatever reason you still have to handle that. I'm not sure what the reason is, but if it is a real reason than programming against interfaces isn't enough I think. – Mike Two Feb 22 '11 at 16:58
  • so you want to reload an assembly because it has changed? Like doing an update without any downtime? – Dustin Davis Feb 22 '11 at 17:23
  • How were you thinking of notifying the app that it has changed? Polling the directory, a SQL record, or what? I would suggest loading the assembly on startup as a plugin using Assembly.Load (or whatever it is) and once there is a new dll, just dispose of that assembly and load up the new one. You can create a singleton to do this. MyPlugin.Get() will do all the work in the background, either send the latest ver or dispose old one, get new one and return that. – Dustin Davis Feb 22 '11 at 22:01
0

You cannot unload dll in a running app domain. What you can do is use MEF and prepare your app to handle multiple implementations. In that case, you can copy a new dll (a new implementaion of an interface, module, etc.) into the MEF folder, recompose and use it. But, careful, it is gonna cost you memory.

You can read about it and download sample here.

Andras Sebo
  • 1,120
  • 8
  • 19
0

It looks like this CodeProject article explains how to do it. This question on the MSDN Forums seems similiar and this SO question shows how to do it. All of these links warn of leaks being created by problems disposing AppDomains properly, so buyer beware.

Community
  • 1
  • 1
JoeB
  • 2,743
  • 6
  • 38
  • 51
  • I'm interested if anyone has any experience doing this, or thoughts leaning toward using another mechanism to be able to update a plugin-enabled MVC website on the fly. – JoeB Feb 22 '11 at 23:45