AppDomain, запускающий сборку .exe или .dll?

Question

При написании этого вопроса: AppDomain, обработка исключений Я также подумал о другом вопросе.

Если бы вы написали приложение для плагинов, как я написал выше. Вы хотите написать плагины как исполняемые файлы или библиотеки?

Какой контроль вы бы имели над динамически загружаемым исполняемым файлом, который запускается с помощью метода AppDomain.ExecuteAssembly(String)? вместо создания экземпляра объекта с помощью AppDomain.CreateInstanceAndUnwrap(String, String).

Там, где у меня есть интерфейс, в котором есть метод Start / Run + Stop + Init, который вызывается после CreateInstanceAndUnwrap. Будет ли у вас такой же тип контроля над исполненной версией сборки? Если бы я использовал последнее, как я могу добиться такой функциональности, чтобы динамически остановить этот плагин?

Или я думаю в совершенно неверном направлении?

[редактировать-после-вопрос]

В основном мы получили «одно» приложение и несколько функций.

• Запись (видео) DVD)
• Печать фотографий
• загрузка изображений с фото / видеокамеры
• POS
• сервер хранения, выполняющий функции резервного копирования / configsettings / image + video хранилище
• отображение указанных фото / видео на нескольких дисплеях
• и несколько других, но это были основные «функции»

Компьютер может запускать несколько задач / плагинов. Например, мы можем выбрать один компьютер для управления всей системой загрузки / отображения / печати изображений. Или иметь один централизованный печатный компьютер с несколькими системами загрузки / отображения.

Все общается через сокеты

Если плагин выходит из строя по какой-либо причине, его необходимо перезапустить и отправить письмо в офис. Если один и тот же сбой происходит несколько раз за короткий промежуток времени, то он должен отправить какое-то экстренное электронное письмо и завершить работу этого плагина и уведомить оператора.

Некоторые из этих функций используют неуправляемый код третьей стороны, некоторые написаны на C ++ / Native, а некоторые на C ++ / CLI, другие написаны на C #, все они будут написаны в том же решении, что и разные проекты.

edit2 Есть также эта дополнительная функция, которую мы хотели бы добавить в систему. Он должен автоматически обновлять плагин, как только появится более новая версия этого плагина. Родительский домен AppDomain / thread должен периодически проверять наличие обновлений, и, если обновление найдено, он должен выгружать этот плагин, загружать новую версию и запускать ее снова. По этой конкретной причине я думаю, что мы должны использовать AppDomain's

Answer 1

Я бы, конечно, пошел с использованием CreateInstanceAndUnwrap().Таким образом, вы имеете намного больше контроля и можете разумно общаться с плагином.Когда вы используете ExecuteAssembly(), вы можете запустить его, а затем прочитать возвращаемое значение (int).

Кроме того, при использовании CreateInstanceAndUnwrap() ничто не мешает вам использовать exe в любом случае, если у вас есть веская причина для этого.

По сути, у вас есть рабочее решение, и вам не нужно его менять (по крайней мере, не в этом направлении).

Answer 2

Вы должны также рассмотреть альтернативный дизайн.Основываясь на этой информации:

Где у меня в настоящее время есть интерфейс, который имеет метод Start / Run + Stop + Init

...

Компьютер может работатьнесколько задач / плагинов.Например, мы можем выбрать один компьютер для управления всей системой загрузки / отображения / печати изображений.Или иметь один централизованный печатный компьютер с несколькими системами загрузки / отображения.

...

Все общается через сокеты

Связь уже осуществляется через сокеты,единственная отсутствующая функция - «управление»:

1. Изолировать сбои в одном плагине от других.
2. Запуск / останов плагина
3. Перезапуск плагина при сбое
4. Уведомлять администраторов о сбоях по электронной почте
5. Автообновление

Вы можете просто использовать то, что уже есть - службы Windows.Если вы развертываете плагины как службы Windows, у вас уже есть реализованные 1, 2 и 3.Вам не нужно беспокоиться о доменах приложений, сбоях в нативном коде и т. Д. Реализация надежна, проверена и хорошо понятна администраторам.Вы можете управлять службами Windows программно .Единственное, что вам нужно сделать, это написать один сервис «WatchDog», который будет отправлять электронные письма и обрабатывать автообновления.