Как я реализую плагины .NET, не используя AppDomains?
Простой цикл решает проблему, используя функцию toString той же библиотеки:
ALT <-0
for (i in 1:nrow(vcf)){ ALT[i] <- toString(tempo[[i]]) }
Однако я понятия не имею, почему tempo @ unlistData извлекает слишком много строк. Это не заслуживает доверия.
3 ответа
- Проверьте, загружается ли блок уже (для предотвращения утечек памяти, вызванных путем загрузки того же блока много раз).
- Если не загруженный, считайте блок в массив байтов. Это предотвратит блокировку файла.
- Предоставьте массив байтов как arguement к блоку. Загрузка
Следующий код предполагает знание FullName блока.
Assembly assembly = null;
foreach(Assembly loadedAssembly in AppDomain.CurrentDomain.GetAssemblies())
if (loadedAssembly.FullName == "foobar, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null")
assembly = loadedAssembly;
if(assembly == null)
{
byte[] studybin = System.IO.File.ReadAllBytes(@"C:\pathToAssembly\foobar.dll");
assembly = Assembly.Load(studybin);
}
Обратите внимание, что, при попытке найти определенный блок в каталоге, можно выполнить 'Систему. Отражение. AssemblyName. GetAssemblyName (путь)'; видеть, соответствует ли FullName тому, что Вы ищете. 'GetAssemblyName (путь)' НЕ вводит блок в Ваш текущий AppDomain.
Также обратите внимание, что это решение не подходит для приложений, которые должны только редко перезапускать И изменение блоков с высокой частотой. Каждый раз, когда блок загружается, объем потребляемой памяти Вас, приложение вырастет. Нет никакого метода для разгрузки блока, таким образом единственная опция уменьшить использование памяти состоит в том, чтобы перезапустить приложение. Однако это ограничение часто предпочтительно для большой производительности, памяти и сложности кода наверху использования нескольких доменов приложения. Это ограничение также неизбежно, если Вы хотите работать с Types.
Если вас интересует серьезный метод построения системы с архитектурой плагинов, вы можете попробовать MAF (Managed Add-in Framework), которая теперь является частью .NET. Framework, а именно пространство имен System.AddIn.
Оно поможет вам управлять изоляцией надстроек и версией, даже с обратной совместимостью с контрактами.
Здесь есть некоторая кривая обучения, так что это может быть не совсем то, что вы ищете.
Если вы хотите изолировать свои надстройки, вы должны ...
- Создать тип, расширяющий MarshallByRefObject, который будет взаимодействовать с вашими надстройками (позвольте позвонить it FOOMASTER)
- Создайте новый домен приложения (давайте назовем его addinLand)
- Позвонить addinLand.CreateInstanceAndUnwrap в создать экземпляр FOOMASTER в addinLand и получите прокси в текущий домен приложения
- Скажите FOOMASTER, чтобы он загрузил ваши дополнения
Теперь ваши дополнения загружены в addinLand, и вы можете взаимодействовать с ними из вашего основного домена приложения через прокси-сервер FOOMASTER. Когда ваши надстройки дают сбой, они не останавливают ваше приложение.
Это интересный и немного запутанный процесс. Первоначально я думал, что идея заключалась в том, чтобы загрузить ваши надстройки, а затем перенести их в текущий домен приложения как прозрачные прокси, но лучший вариант - оставить надстройки как простые объекты, которые взаимодействуют с более сложными типами, которые вы создаете (FOOMASTER), которые расширяют MarshallByRefObject, которые загружаются в домен приложения addinLand и с прозрачными прокси-серверами которых вы взаимодействуете.
Главы 21 и 22 CLR через C # очень полезны для понимания процесса.