AppDomain, running an assembly .exe or .dll?

While writing this quest开发者_如何转开发ion: AppDomain, handling the exceptions I also thought of a different question.

If you would write a plugin app like I wrote above. Would you go about writing the plugins as executables or as libraries?

How much control would you have over a dynamically loaded executable that is run through the AppDomain.ExecuteAssembly(String) method? instead of creating an instance of an object using AppDomain.CreateInstanceAndUnwrap(String, String).

Where I currently have an interface which features a Start/Run + Stop + Init method that is called after CreateInstanceAndUnwrap. Would you have the same type of control over the executed assembly version? If I would use the latter, how can I achieve such functionality to dynamically stop that plugin?

Or am I thinking in the totally wrong direction?

[edit-after-question]

Basicly we got 'one' application, and multiple functions.

• Burning a (video) DVD)
• Printing photo's
• downloading images from a photo/videocamera
• a POS
• a storage server, functioning as a backup/configsettings/image+video repository
• displaying said photos/videos on a multiple displays
• and a few others, but these were the main 'functions'

A computer can run multiple tasks/plugins. For instance, we can choose to have one computer handle the whole image download/display/print system. Or have one centralized printing computer with multiple download/display systems.

Everything is communicating over sockets

If a plugin crashes for whatever reason it needs to be restarted and a mail should be send to the office. If the same crash occurs multiple times in a short timeframe then it should send some kind of emergency e-mail and shutdown that plugin and notify the operator.

Some of these functions use thirdparty unmanaged code, some are written in C++/Native and some in C++/CLI others are written in C#, all will be written within the same solution as different projects.

edit2 There is also this additional feature we would like to add to the system. It is to automatically update a plugin as soon as there is a newer version of that plugin available. The parent AppDomain/thread should periodically check for updates and if an update is found it should unload that plugin, download the new version and start it again. For this specific reason I think we need to use AppDomain's

I would certainly go with using CreateInstanceAndUnwrap(). You have much more control that way and you can reasonably communicate with the plugin. When you use ExecuteAssembly(), you can pretty much start it and then read the return value (an int).

Also, when using CreateInstanceAndUnwrap(), there is nothing stopping you from using an exe anyway, if you have a good reason to do it.

Basically, you have a working solution and there is no need to change it (at least not in this direction).

You should also consider alternative design. Based on this information:

Where I currently have an interface which features a Start/Run + Stop + Init method

...

A computer can run multiple tasks/plugins. For instance, we can choose to have one computer handle the whole image download/display/print system. Or have one centralized printing computer with multiple download/display systems.

...

Everything is communicating over sockets

Communication is already done by sockets, the only missing feature is 'management':

1. Isolate crashes in one plugin from others.
2. Start/Stop plugin
3. Restart plugin on crash
4. Notify admins about crashes by email
5. Auto update

You can simply utilize whats already there - windows services. If you deploy plugins as windows services you already have 1, 2 and 3 implemented. You don't have to worry about AppDomains, crashes in native code etc. The implementation is robust, tested and well understood by admins. You can manage windows services programaticaly. The only thing you need to do is write one 'WatchDog' service that will send emails and handle auto updates.