Есть приложение которое имеет поддержку pluginов
все плагины лежат в одной папке с исполняем файлом
как вы догадались в этой папке есть много не нужных библиотек
+ даже в нужных сборках помимо нужных типов содержиться можество не нужных
схема следующая
сначала грузиться сборка:
Assembly.LoadFile(...)
затем
Type[] types = dll.GetExportedTypes();
и в foreach смотряться все типы и ищется тот который унаследован от определенного базового класса береться его статический метод и формируется некоя информацию доступная пользователю который уже решает надо экземпляр этого класса ему или нет по полученным данным
что плохо:
Грузяться все без исключения библиотеки (я конечно понимаю что если они уже были загружены то они еще раз не грузяться но те которым еще рано загружаться уже в пути) а выгрузить ненужные уже не получиться (не считаю создания отдельного домена и тд но это лишние временные затраты)
Если в сборке не окзалось ни одного нужного мне типа то она мне фактически не нужна (в данный момент, так как если она лежит в папке она понадобиться)
можно ли как нить исследовать сборку загружая как бы не всю её а лишь данные о типах...
и после исследованиярешать надо ли её грузить или нет
Здравствуйте, Grammer, Вы писали:
G>можно ли как нить исследовать сборку загружая как бы не всю её а лишь данные о типах... G>и после исследованиярешать надо ли её грузить или нет
Есть библиотеки с функциональностью аналогичной reflection но, не требующие загрузки сборки. Например, одна из них есть в FxCop
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, Grammer, Вы писали:
G>Есть приложение которое имеет поддержку pluginов G>все плагины лежат в одной папке с исполняем файлом G>как вы догадались в этой папке есть много не нужных библиотек G>+ даже в нужных сборках помимо нужных типов содержиться можество не нужных
[Skipped]
G>что плохо: G>Грузяться все без исключения библиотеки ...
Для этого создаются конфигурационные файлы, в которых отмечаешь, что хочешь загрузить.
Если отталкиваешься от библиотек, то перечисляешь библиотеки на загрузку. Если отталкиваешься от классов, то классы.
Если необходимо динамически при каждой загрузке программы подгружать новые библиотеки/классы, то перечисляешь новые и спрашиваешь у пользователя, грузить их в дальнейшем или нет. После этого сохраняешь в конфигурационном файле список полностью, чтоб знать, какие новые библиотеки появились.
А зачем такие мучения?
Положите их в отдельную директорию
или назовите по особому, например, добавив расширение .plugin
или заведите конфиг файл, в котором будут имена плагинов...
Здравствуйте, stasukas, Вы писали:
S>Здравствуйте, Grammer, Вы писали:
G>>Есть приложение которое имеет поддержку pluginов G>>все плагины лежат в одной папке с исполняем файлом G>>как вы догадались в этой папке есть много не нужных библиотек G>>+ даже в нужных сборках помимо нужных типов содержиться можество не нужных S>[Skipped]
G>>что плохо: G>>Грузяться все без исключения библиотеки ... S>Для этого создаются конфигурационные файлы, в которых отмечаешь, что хочешь загрузить.
S>Если отталкиваешься от библиотек, то перечисляешь библиотеки на загрузку. Если отталкиваешься от классов, то классы.
S>Если необходимо динамически при каждой загрузке программы подгружать новые библиотеки/классы, то перечисляешь новые и спрашиваешь у пользователя, грузить их в дальнейшем или нет. После этого сохраняешь в конфигурационном файле список полностью, чтоб знать, какие новые библиотеки появились.
S>[Skipped]
Я когда-то писал так:
public void InitializePlugins()
{
Libs=new ArrayList();
Directory.SetCurrentDirectory(Dir+"Plugins\\");//Получаем все файлы в директории с определенным расширением
string[]Files=Directory.GetFiles(Dir+"Plugins\\","*.dll");
ObjectHandle obj=null;
foreach (string Name in Files)
{
try
{
obj=Activator.CreateInstanceFrom(Name,"Razbor.Parser");//Тут создаем инстанс нужный
}
catch(System.Exception e)
{
string t=e.Message;
obj=null;
}
finally
{
}
if(obj is IPlugin) //тут проверяем наличие у инстанца нужного интерфейса
{
IPlugin Plugin=(IPlugin) obj.Unwrap();//Тут развертываем инстанс в нужный тип объекта
Libs.Add(Plugin);//Кладем в ArrayList для дальнейшего использования
}
Вариантов 2
1. Грузи в отдельный домен для инспекции, потом прибивай домен, и загружай по нормальному
2. Для 2.0: можно указать при загрузке что нужно только для инспекции ( только потом все равно лучше прибить домен ИМХО)
Здравствуйте, erigami, Вы писали:
E>А зачем такие мучения? E>Положите их в отдельную директорию E>или назовите по особому, например, добавив расширение .plugin E>или заведите конфиг файл, в котором будут имена плагинов...
положить отдельно идея классная но сборки используют еще допольнительные dll которые использует и основное приложение которое грузит сборки аобзывать их особенно конечно можно, но как то это не красиво, хотя насчет последнего может я и не прав.
Re: Reflection (наверно)
От:
Аноним
Дата:
19.10.05 15:08
Оценка:
положить отдельно идея классная но сборки используют еще допольнительные dll которые использует и основное приложение
Только вот еще замечание по поводу того, что все dll в одной куче.
Если это плагины, то они поставляются авторами в бинарном виде.
Далее — предположим, некто создал плагин, скомпилил и отдал его.
Потом разработчик приложения изменил одну из общих сборок —
в результате плагин работать перестал.
Если вы ответите, что все плагины ваши и поставляются в исходниках и компилятся вместе, то непонятно, зачем вообще возня с этими dll...
Здравствуйте, erigami, Вы писали:
E>Только вот еще замечание по поводу того, что все dll в одной куче. E>Если это плагины, то они поставляются авторами в бинарном виде. E>Далее — предположим, некто создал плагин, скомпилил и отдал его. E>Потом разработчик приложения изменил одну из общих сборок — E>в результате плагин работать перестал. E>Если вы ответите, что все плагины ваши и поставляются в исходниках и компилятся вместе, то непонятно, зачем вообще возня с этими dll...
ну предположим что не плашиновые dll поставляются разработчикам в бинарном виде и они их менять соответственно не могут, только писать на их основе свои плагины
