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

Question

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

В моем случае это происходит на производственном сервере. Я получаю ту же ошибку, которая была описана в других вопросах, и я разрешаю ее, повторно скопировав сборки в каталог 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) 

Answer 1

У меня был удар с этим исправлением.

http://weblogs.asp.net/scottgu/archive/2007/04/11/public-hotfix-patch-available-for-asp-net-compilation-issues.aspx

Хотя это не происходит с новыми машин/установок больше.

Answer 2

Чтобы не связывать мой сайт, но я столкнулся с этой проблемой, и я написал a blog post on the topic. Проверьте это, у него есть ссылки на дополнительную информацию по этой теме. Но подводить итоги здесь подробности:

Проблема:

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

Возможная работа Around (ы) или временные исправления:

1) Установив пакетное свойство компиляции тега ложь в Интернете.конфигурационный файл

<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 месяцев, и все хорошо!

Answer 3

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