Блок, недоступный после Web.config, изменяется

У меня аналогичная проблема, когда я обновляю 2–5 файлов, ether web.config, ether, другие файлы, а asp.net нужно воссоздать работающий files, то несколько раз не находил некоторые классы / функции, существующие в файлах dll, и моя система не работает - выкидывайте ошибки, подобные вашей.

Мое решение состоит в том, что я помещаю app_offline.htm в корневой каталог, делаю обновления, затем переименовываю / удаляю app_offline.htm, и моя система работает нормально.

Я уверен, что это имеет какое-то отношение к кэшированным скомпилированным файлам, но я не тщательно исследовал, что именно является причиной этого.

[самый элегантный обходной путь для перезагрузки всех сборок в корзине]

Самый элегантный обходной путь - это вызвать HttpRuntime.UnloadAppDomain и фактически заставить ваше приложение останавливаться и запускаться снова.

http://msdn.microsoft.com/en-us/library/system.web.httpruntime.unloadappdomain (VS.80) .aspx

Я не знаю, решит ли это вашу проблему, вам нужно сделать тесты.

возможно на Global.asax сделать что-нибудь подобное

void Application_Error(object sender, EventArgs e) 
{
   Exception ex = Server.GetLastError().GetBaseException();
   ...if ex is your error, and you get more than 2 ...
   {
     HttpRuntime.UnloadAppDomain();
   }
}

Я никогда раньше не слышал об этой проблеме.

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

см .: http://msdn.microsoft.com/en-us/library/823z9h8w (VS.80) .aspx

пример:

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <probing privatePath="bin;bin2\subbin;bin3"/>
      </assemblyBinding>
   </runtime>
</configuration>

Как вы, очевидно, знаете, существует множество ситуаций, когда текущий домен приложения выгружается и перезагружается . После каждой перезагрузки все сборки выгружаются и все приложение запускается «с нуля».

Сборки по умолчанию загружаются по запросу. Обычно это происходит, когда JIT натыкается на какую-нибудь ссылку.Как следствие, перезагрузка домена приложения приведет к удалению сборок в домене приложения, и они появятся снова только позже, когда JIT загрузит их.

В качестве решения я бы вернулся к использованию статического метода Type.GetType () и предоставил полное имя сборки (например, имя типа с включенным именем сборки). То же самое фреймворк использует при загрузке типов, указанных в файле конфигурации, и гарантирует, что требуемая сборка будет найдена и загружена по запросу без каких-либо уловок. См. Раздел примечаний к описанному выше методу (имя метода над именем является ссылкой).

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

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

var temp = new BaseModuleBuilder();

Это не выглядит умным, но это очень прямолинейно, и asp.net должен сделать все за вас. В случае, если ваш список слишком динамический, это может быть что-то вроде

var temp = Activator.CreateInstance(Type.GetType("BaseModuleBuilder, Modules.dll"));

. Убедитесь, что вы всегда указываете DLL при работе с динамически загруженными классами.