Comments 4
После пары обновлений в голове откладывается эта особенность и дальше проблемы пропадают.
Те пересобирать/портировать N старых плагинов — это нормально, чтобы установить новый? Почему нельзя выделить каждому плагину свою папку с зависимостями и грузить их отуда?(Assembly.LoadFrom)
И что за проблема с перезаписью плагинов? У меня при замене плагина в папке, IIS просто перезапустит сайт, ничего нигде не блокируется (папки с плагинами можно переименовывать) и никакого кэша не используется.
Те пересобирать/портировать N старых плагинов — это нормально, чтобы установить новый? Почему нельзя выделить каждому плагину свою папку с зависимостями и грузить их отуда?(Assembly.LoadFrom)
Конечно вы можете это сделать. Просто я предпочитаю иногда обновлять сторонние библиотеки.
И что за проблема с перезаписью плагинов? У меня при замене плагина в папке, IIS просто перезапустит сайт, ничего нигде не блокируется (папки с плагинами можно переименовывать) и никакого кэша не используется.
Может быть я что-то упустил, поправьте меня. Если мы делаем загрузку плагина в домен приложения (в статье это описано), он будет заблокирован, пока не будет выгружено приложение. А замена файла в папке плагинов не вызовет автоматическую перезагрузку, как бы это случилось при замене файлов в папке bin. А каждый раз переименовывать папки — не слишком красивое решение.
Может быть я что-то упустил, поправьте меня. Если мы делаем загрузку плагина в домен приложения (в статье это описано), он будет заблокирован, пока не будет выгружено приложение. А замена файла в папке плагинов не вызовет автоматическую перезагрузку, как бы это случилось при замене файлов в папке bin. А каждый раз переименовывать папки — не слишком красивое решение.
У меня ничего не блокируется. Кстати у меня папка с папками плагинов находится в папке bin.
Sign up to leave a comment.
Плагинная система на ASP.NET. Развитие идеи