Динамическая загрузка, эксплуатация и выгрузка сборок в .NET

[syrompe]

Вот уже раза три сталкивался с этим велосипедом…
Коллеги всегда настаивали мол давай напишем «правильно» — то есть через AppDomain.
И тут начинают вылезать подводные камни пачками:

1. Код выполняемый в созданном домене имеет урезанные права (Code Access Security, что там в .Net 4.0 поменяли — не вкурсе).
Как правило при создании домена приходится настраивать ему права в Full trust.

2. У вас объект унаследован от MarshalByRefObject. А как GC созданного домена узнает, что объект еще нельзя собирать? Гуглим по InitialeLifeTimeService…

3. А значение GetExtensionName вернется по значению или по ссылке? Так как строка не MarshalByRef, то она будет сериализовываться при передаче между доменами со всеми вытекающими…

4. В 90% случаев время жизни плагина (extension) совпадает со временем жизни всего приложения — соответсвенно Unload нам никогда не потребуется.

Вобщем, если вы не пишете что-то типа IIS, то используйте MEF или что-то подобное для этих целей.

[AndyGrom]

1. Ничто не даётся даром.
2 и 3. Данное решение не «гуглится», а bing`уется в msdn. Я так понимаю, что если проникнутся забытой технологией remouting, то можно получить ответы на Ваши вопросы. К тому же станут ясны многие «тонкие» моменты.
4. Сожалею, но таково ТЗ. Условия эксплуатации алгоритма неизвестны. Но возможность выгрузки сборок — основное условие.

Насчёт MEF — спасибо. Обогатился почитав статьи на хабре, возьму на заметку.

[dokwork]

Забавно, свою первую (и пока крайнюю) статью я тоже посветил теме велосипеда с расширениями в .Net. Хоть и писалось все еще в эпоху 3.5, но все равно на Хабре законно дали понять что это таки велосипед. В общем, ждите еще много интересного и нового в комментариях. Полезные комментарии — это одно из главных достоинств Хабра.

[bobermaniac]

Поздравляю, вы написали свой MEF

[hotach]

MEF не умеет выгружать сборки

[bobermaniac]

У дотнета вообще очень плохо с выгрузкой. Вы уже решили эту проблему аппдоменом.

[onikiychuka]

Хм неплохо :) Но я бы вынес код загрузки и работы с интерфейсом в тот же домен где реализация интерфейса живет. Так решается очень много проблем со временем жизни объектов и междоменным взаимодействием, да и разработчику плагина не надо парится с MarshalByRef.

[OrdJONY]

Стоп, стоп. Сборка с плагином на самом деле загрузиться в ваш основной домен вот здесь Type[] types = asm.GetTypes(). Я тоже когда-то таким игрался, единственный путь которым мне удалось обойти, это грузить в новый домен свою сборку с классом хелпером, который уже подгружал сборки с плагинами и искал уже там типи и при необходимости их создавал.
Да это велосипед, но хотел сделать безопасную среду для исполнения плагинов. Моя статья на эту тему

[andreycha]

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

[borv]

Habrahabr — мы придумали 10001 способ реализации MEF.

[ApeCoder]

Хотелось бы еще теста насколько просела производительность вызовов при использовании домена. Когда-то на rsdn.ru писали что 20х

[muradovm]

Автор может справедливо счесть это брюзжанием, но мне почему-то в глаза бросилось
if (fileNames != null)
На самом деле эту проверку можно не выполнять, так как EnumerateFiles либо выбросит исключение, либо вернет таки набор с именами файлов (может даже пустой) в виде итератора
new FileSystemEnumerableIterator(path, originalUserPath, searchPattern, searchOption, new StringResultHandler(includeFiles, includeDirs));
(подсмотрено Reflector'ом)