Question

I am developing a large application which consists of many smaller plugins/applications.

They are not big enough to be a full process, but are too small to be run in a thread, under one process, along with that I want to have it based on a plugin-basis.
If a newer version of that plugin is available it should be unloaded, updated and started again.

During my search for a solution I can accross the magic word AppDomain, and I quote:

“Use application domains to isolate tasks that might bring down a
process. If the state of the AppDomain that’s executing a task becomes
unstable, the AppDomain can be unloaded without affecting the process.
This is important when a process must run for long periods without
restarting. You can also use application domains to isolate tasks that
should not share data.”

Thus that is exactly what I want. However, I guess their ‘State becomes unstable’ is a different point of view than mine. I am thinking of a problem where one of the plugins throws an exception, for whatever reason. I would like that be catched, e-mailed, unloaded and restart (if possible).

So I created an application that starts up, looks for all .dll’s in its folder. Checks if the dll consists of a plugin. Creates a new AppDomain for that plugin, and once everything is loaded it will start each plugin. (Where each plugin can consist of multiple threads, co-existing happily next to ech other).

So I also added a time-out in there, that fires after 5seconds to throw a new Exception(); Added a UnhandledException event on the AppDomain to handle it. But, it catched it, and after cathing, still ‘crashed’ the whole process including all the extra child-AppDomains.

But it clearly states in the quote ‘to isolate tasks that “might” bring down a process’. So am I missing something vital? Is my view on the quote wrong?

Answer 1

Since .NET 2.0 unhandled exceptions crash the process. From AppDomain.UnhandledException event documentation:

This event provides notification of uncaught exceptions. It allows the
application to log information about the exception before the system
default handler reports the exception to the user and terminates the
application.

The same goes for AppDomain.FirstChanceException:

This event is only a notification. Handling this event does not handle
the exception or affect subsequent exception handling in any way.

You need to think about how you will handle exceptions just like you will do it in normal app. Just using AppDomains will not help. If the exception has not been handled within given AppDomain it will get rethrown in calling AppDomain until it either get handled or crashes the process. It is perfectly fine to handle some exceptions and don’t let them crash your process.

AppDomain is a logical container for assemblies and memory (not for threads). Isolation for AppDomain implies:

• Objects created in domain A can not be accessed directly by domain B (without marshaling). This allows for domain A to be unloaded without affecting anything in domain B. These objects will get automatically deleted when ‘owning’ domain gets unloaded.

• Assemblies can be automatically unloaded with AppDomain. This the only way you can unload managed dll from process. This is useful for DLL hot-swapping.

• AppDomain security permissions and configuration can be isolated from other AppDomains. This can be helpful when you load untrusted third party code. It also lets you override how assemblies will be loaded (version binding, shadow copying etc).

Most common reasons for using AppDomain is when you run untrusted third party code. Or you have unmanaged code and want to host CLR or need dll hot swapping. I think that in CLR hosting scenario you can save your process from crashing when thirdparty code throws unhandled exception.

Also instead of rolling your own infrastructure you might want to look at System.Addin or MEF.