Здравствуйте, xednay89, Вы писали:

X>Проблема в следующем: как быть с зависимостями этих самых плагинов? Как в современном мире решается эта проблема?

Вариант 1:
1 — подписка на AssemblyResolve и загрузка нужной сборки через Assembly.LoadFrom.
Начиная с net 4 можно узнать сборку, для которой подгружается зависимая сборка, см ResolveEventArgs.RequestingAssembly.

Плюс: Возможность динамически добавлять новые модули
Огромный минус: разнообразные грабли с загрузкой сборок в LoadFrom-контекст. В основном обходится проверкой ранее загруженных сборок в обработчике AssemblyResolve, пример можно глянуть здесь.

Примеры граблей
http://blogs.msdn.com/b/suzcook/archive/2003/05/29/57143.aspx (подробно расписано что есть что)
http://msdn.microsoft.com/en-us/library/1009fa28.aspx — см disadvantages
http://msdn.microsoft.com/en-us/library/ff527268.aspx — Нюансы с AssemblyReslove, особенно меня смущает вот этот момент:

In most cases, the assembly that is returned by the handler appears in the load context, regardless of the context the handler loads it into

На практике — увы, в FW 2 не работало.

http://msdn.microsoft.com/en-us/magazine/cc163606.aspx#S2 — способ отловить загрузку в LoadFrom при отладке.

Вариант 2:
Перечисление всех папок плагинов в PrivateBinPath
Плюс: работает само.
Минусы:
* PrivateBinPath текущего домена изменить нельзя (точнее, можно, но на свой страх и риск). Приходится изобретать хитрую схему запуска — домен по умолчанию создаёт новый домен (2) и для него прописывает PrivateBinPath. Само приложение работает в домене 2.
* Для добавления нового плагина нужно перезапустить приложение (ну, или выгрузить домен 2 и создавать новый. Для пользователя непринципиально).

Вариант 3:
System.Addin. На мой взгляд, проще застрелиться, чем использовать: