ASP.NET забывает dll в каталоге bin

Question

У нас есть система плагинов в службе WCF, которая проверяет библиотеки, размещенные в папке bin, на наличие определенных атрибутов уровня сборки и загружает их. Это позволяет настраивать определенные вызовы службы в зависимости от того, какой клиент выполняет вызов. Это прекрасно работает большую часть времени. Однако иногда кажется, что он теряет dll, что заставляет службу возвращаться к реализации по умолчанию для каждого клиента. Решение до сих пор заключалось в том, чтобы просто переместить файл dll из папки bin и обратно. Это заставляет asp.net забрать файл, и настройки снова начинают работать.

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

Редактировать: проблема изложена более четко

Наши сервисы используют фабрику сервисов для раздачи пользовательских реализаций в зависимости от того, какой клиент вызывает код. Если пользовательской реализации нет, мы раздадим реализацию по умолчанию. Мы используем GetAssemblies для проверки сборок, которые украшены атрибутом, определяющим их как пользовательскую реализацию и связывающим их с клиентом. Проблема в том, что GetAssemblies перестает возвращать пользовательскую сборку клиента, даже если библиотека остается в папке bin. Перемещение dll из корзины и обратно в нее решит проблему примерно на неделю, пока это не произойдет снова

Answer 1

Проблема, с которой вы столкнулись, должна быть связана с автоматической переработкой домена приложения. Очевидно, перезапуск appdomain ведет себя не так, как реальный перезапуск. При перезапуске он будет загружать только те библиотеки DLL, которые явно ссылаются и загружаются по мере необходимости. Смотрите эту ссылку http://www.chrisvandesteeg.nl/2006/06/15/appdomain-recycle-different-from-real-restart/

Тот факт, что GetAssemblies вернет вам только сборку, которая в данный момент загружена в домен приложения, может объяснить аномалию, которую вы получаете с вашей программой. На всякий случай, если вы имеете дело с библиотекой типов плагинов, вы всегда должны сканировать файлы плагинов (dll) и загружать их явно, используя Assembly.LoadFrom. Другой альтернативой является размещение ваших служб WCF снаружи на вашем пользовательском хосте, таком как оконная служба, чтобы время жизни хоста не зависело от политики утилизации IIS.

Прочтите это для получения дополнительной информации по утилизации appdomain http://blogs.msdn.com/tess/archive/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles.aspx

Answer 2

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

Answer 3

GetAssemblies возвращает только список уже загруженных сборок.Если вы еще не использовали тип из этой сборки, он еще не был загружен.Вам нужно использовать Assembly.Load для загрузки нужной сборки с диска;сборки в папке / bin автоматически не загружаются в домен приложения.

Кроме того, вы можете использовать Managed Extensibility Framework (MEF) , он был разработан специально для обработкифункциональность, о которой вы говорите.

Answer 4

... замена сборки в каталоге \ bin приведет к новой пакетной компиляции этого каталога.

http://msdn.microsoft.com/en-us/library/5dws599a(VS.71).aspx

Есть ли у вас код инициализации в Application_Start внутри global.aspx?

Answer 5

Как вы загружаете сборки? Следующий вопрос ... почему? Сборки в каталоге bin должны автоматически загружаться и быть доступными для приложений ASP.NET, которые ссылаются на них. Возможно, вы получаете здесь какой-то конфликт ... то есть доступ запрещен, потому что какой-то другой поток / процесс имеет открытый дескриптор сборки. Извините, это так расплывчато, но это единственное, что сразу приходит на ум. Вы можете использовать FileMon или аналогичный инструмент для проверки этого.

Кроме того ... что именно вы подразумеваете под "потерять" DLL? Вы вызываете какой-то конкретный метод, чтобы найти его, и он терпит неудачу? В чем ошибка? Вы проверяли Event Viewer на необработанные исключения?