Коррупционная сборка ASP.NET "Не удалось загрузить файл или сборку App_Web_ *"

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

В моем случае это происходит на производственном сервере. Я получаю ту же ошибку, которая была описана в других вопросах, и я разрешаю ее, повторно скопировав сборки в каталог bin. Они даже не перекомпилировали файлы, они те же, что были там раньше - копируются снова, а затем он начинает работать без проблем.

Странная часть этого заключается в том, что я использую проекты веб-развертывания, чтобы переименовать все мои файлы сборки в папку dll. Поэтому folder.dll и folder.subfolder.dll вместо App_Web_jt8nxllz.dll. Тем не менее ошибка все еще указывает исходный файл App_Web_jt8nxllz.dll.

Удаление содержимого папки C:\WINDOWS\Microsoft.NET\Framework[64]\v...\Temporary ASP.NET Files работает и все в порядке, но кто-нибудь знает, как предотвратить эту ошибку? Кроме того, закрытие IIS или перезапуск на самом деле не так реально, когда это происходит на рабочем сервере. Возможно, вы автоматически очистите папку Temp на планировщике?

Какая реальная проблема здесь? Есть ли что-то особенное, что заставляет это случиться? Сайт будет гудеть вообще без проблем, а затем внезапно одна целая папка перестает работать и создает эту ошибку.

Could not load file or assembly 'App_Web_jt8nxllz, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
Exception type 'System.IO.FileNotFoundException' was caught.
Source: App_Web_whv5zsvd
Target Site: Void __BuildControlTree(ASP.artists_controls_artistheader_ascx)
Stack Trace:
   at ASP.artists_controls_artistheader_ascx.__BuildControlTree(artists_controls_artistheader_ascx __ctrl)
   at ASP.artists_controls_artistheader_ascx.FrameworkInitialize()
   at System.Web.UI.UserControl.InitializeAsUserControlInternal()
   at System.Web.UI.UserControl.InitializeAsUserControl(Page page)
   at ASP._artists_artist_master.__BuildControlctlArtistHeader()
   at ASP._artists_artist_master.__BuildControlctlContent(Control __ctrl)
   at System.Web.UI.CompiledTemplateBuilder.InstantiateIn(Control container)
   at ASP.master_mysite_master.__BuildControlMainContent()
   at ASP.master_mysite_master.__BuildControlform1()
   at ASP.master_mysite_master.__BuildControlBody()
   at ASP.master_mysite_master.__BuildControlTree(master_mysite_master __ctrl)
   at ASP.master_mysite_master.FrameworkInitialize()
   at System.Web.UI.UserControl.InitializeAsUserControlInternal()
   at System.Web.UI.MasterPage.CreateMaster(TemplateControl owner, HttpContext context, VirtualPath masterPageFile, IDictionary contentTemplateCollection)
   at System.Web.UI.MasterPage.get_Master()
   at System.Web.UI.MasterPage.ApplyMasterRecursive(MasterPage master, IList appliedMasterFilePaths)
   at System.Web.UI.Page.ApplyMasterPage()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Ответ 1

Не просто связать мой сайт, но я столкнулся с этой проблемой, и я написал сообщение в блоге по теме. Проверьте это, у него есть ссылки на дополнительную информацию по этой теме. Но, чтобы подвести итог, вот подробности:

Проблема:

На веб-сайте появляется ошибка при попытке загрузить пользовательский веб-элемент управления. В последнем выпуске мы добавили новый настраиваемый элемент управления к другому настраиваемому веб-элементу управления, который отображается по мере необходимости. Поскольку внешний элемент/родительский элемент управления и новый дочерний элемент управления являются отдельными элементами управления в источнике, когда .Net Framework переходит на компиляцию одного из этих двух элементов управления и не перекомпилирует другой, в то же время у вас будет устаревший файл, пытающийся ссылаться на старую версию сборки. Тот факт, что инфраструктура .Net добавляет случайную строку к имени сборки во время компиляции, имя вновь скомпилированного файла и предыдущей версии файла вызывают несоответствие имени файла, и поэтому внешний/родительский элемент управления ищет который больше не существует.

Возможная работа вокруг (ов) или временных исправлений:

1) Задав для свойства партии тега компиляции значение false в файле web.config

<compilation debug="false" batch="false" />

2) Вы также можете уменьшить, как часто это происходит, устанавливая свойством numRecompileBeforeAppRestart:

<compilation debug="false" numRecompilesBeforeAppRestart="50" />

Подробнее см. KB Article 934839

Исправления для проблемы после того, как она уже состоялась:

1) Удалите временные файлы ASP.Net(это приведет к удалению сайта)

2) Заставьте элемент управления родительским/внешним элементом перекомпилировать, отредактировать и сохранить файл кода. Это лучший вариант для исправления, чем # 1, потому что это не сбивает веб-сайт.

Мое предложение:

1) Сначала я думаю, что мы должны установить временное исправление № 1 сверху, это может предотвратить все проблемы в будущем и может быть единственным ответом, который нам нужен.

2) Во-вторых, я бы загрузил и установил исправление 934839 от Microsoft в среде QA, чтобы убедиться, что он не вызывает никаких проблем. После некоторого времени тестирования исправления в QA я установил бы исправление, чтобы иметь постоянное исправление для этой проблемы. В это время мы могли удалить временную работу вокруг # 1.

Примечание: После установки исправления Temp №1 у меня не было проблемы снова. У меня было это исправление на месте более 12 месяцев, и все хорошо!

Ответ 3

Удаление временных файлов или изменение web.config не помогло мне. Для меня было исправлено перезагрузка моего компьютера.