CODEWITHSUNDEEP
.netpluginsappdomain
Brandon Moore
Brandon Moore

Reputation: 8800

Do I really need to load plugins into a separate AppDomain (given my requirements)?

First let me say that for my scenario plugins will be loaded when the app starts up and won't be unloaded until the app closes, so it's totally okay if I can't unload them after they're loaded.

So then I know that loading plugins into their own AppDomain will protect my application if a plugin crashes, but assuming the plugins don't run unmanaged code then can't I just wrap calls to the plugins in try/catch blocks to avoid having my app crash? Or am I missing something here?

I was trying to use MAF to do this, however I am running into a problem with remoting my objects. That is, none of the available options I have for making them remotable seem very desirable at this point in time. So before I make the switch to a more primitive plugin architecture can anyone tell me if I'm forgetting any other significant reason why I should be loading plugins into a separate AppDomain (or whether I'm mistaken about being able to simply avoid crashes by using try/catch blocks around calls)?

Upvotes: 1

Views: 130

Answers (1)

usr
usr

Reputation: 171246

If you don't need to unload them, you don't need separate AppDomains.

AppDomains do not protect the process from being killed in case of unhandled exceptions. new Thread(() => { throw null; }).Start() is still deadly.

So you need try-catch around plugin entry points and you need them to cooperate (not have threads crash).

AppDomains are useful, though, if you want to abort some computation. They are a way to invoke Thread.Abort relatively safely, if you unload the entire AppDomain immediately afterwards.

Upvotes: 1

Related Questions