Исключение «Не удалось загрузить App_Web _ *. Dll» после компиляции и перезапуска ASP.NET

Question

Недавно я наткнулся на код следующей структуры:

• FooService.cs
• FooService.svc
• Default.aspx

Содержимое файлов:

[FooService.cs]

using System.ServiceModel;

namespace FooService
{
    [ServiceContract]
    public class FooService
    {
        static FooEngine engine = new FooEngine();

        [OperationContract]
        public string Foo()
        {
            return "bar";
        }
    }

    public class FooEngine
    {

    }
}

[FooService.svc]

<%@ ServiceHost Language="C#" Service="FooService.FooService" %>

[Default.aspx]

<%@ Page Language="C#" %>
<% var foo = "bar"; %>

Мы используем .Net 4.0 (отладка) и IIS6 в Windows Server 2003 с веб-сайтом fooservice и записью в файле хоста для вызова веб-службы через http://fooservice/FooService.svc и default.aspx через http://fooservice/. В этот момент все работает отлично.

Однако, после следующих шагов,

1. Изменить код в default.aspx, сохранить файл
2. Загрузка http://fooservice/ (запускает компиляцию ASP.NET)
3. Переработка пула приложений

вызов http://fooservice/FooService.svc завершается неудачно и выдает следующее исключение

[FileNotFoundException: Could not load file or assembly 'App_Web_ynlv0b1k, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.]
   System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) +0
   System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) +39
   System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection, Boolean suppressSecurityChecks) +132
   System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) +144
   System.Reflection.Assembly.Load(String assemblyString) +28
   System.ServiceModel.Activation.ServiceHostFactory.CreateServiceHost(String constructorString, Uri[] baseAddresses) +208
   System.ServiceModel.HostingManager.CreateService(String normalizedVirtualPath) +1440
   System.ServiceModel.HostingManager.ActivateService(String normalizedVirtualPath) +44
   System.ServiceModel.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath) +615

[ServiceActivationException: The service '/FooService.svc' cannot be activated due to an exception during compilation.  The exception message is: Could not load file or assembly 'App_Web_ynlv0b1k, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified..]
   System.Runtime.AsyncResult.End(IAsyncResult result) +679246
   System.ServiceModel.Activation.HostedHttpRequestAsyncResult.End(IAsyncResult result) +190
   System.ServiceModel.Activation.HostedHttpRequestAsyncResult.ExecuteSynchronous(HttpApplication context, String routeServiceVirtualPath, Boolean flowContext, Boolean ensureWFService) +234
   System.ServiceModel.Activation.HttpModule.ProcessRequest(Object sender, EventArgs e) +355
   System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +148
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +75

Что именно здесь происходит?

Примечания

• Я понимаю, что ASP.NET компилирует и загружает новый App_Web_*.dll (на шаге 2), но почему он пытается загрузить старый (удаленный) App_Web_*.dll после перезапуска (3.)?
• при использовании точно такого же кода, встроенного в FooService.svc вместо отдельного FooService.cs, эта проблема не возникает (?)
• удаление статической ссылки на FooEngine также устраняет эту проблему (?)

Answer 1

У меня просто была та же проблема, приложение было веб-приложением, поэтому полностью скомпилировано.Это исправило это для меня, но я не уверен почему:

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

Я получил это решение отсюда: http://web.archive.org/web/20140116171941/http://www.creative-jar.com/insights/labs/programming/could-not-load-file-or-assembly-app_web_/

Answer 2

Это должна быть проблема компилятора, как было упомянуто ранее.Если у вас нет доступа к iis, вы можете изменить свой собственный файл web.config, чтобы использовать другой временный каталог.Эта модификация заставит iis перекомпилировать ваш код и использовать эту новую компиляцию.

<compilation tempDirectory="C:\...">

Пользователь iis_iusrs должен иметь права на запись в этот новый каталог.

Answer 3

Код не должен иметь следующую структуру:

• FooService.cs
• FooService.svc
• Default.aspx

Но следующее:

• App_Code / FooService.cs
• FooService.svc
• Default.aspx

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

Итак, резюмируем:

~/App_Code/FooService.cs:

using System.ServiceModel;

namespace FooService
{
    [ServiceContract]
    public class FooService
    {
        static FooEngine engine = new FooEngine();

        [OperationContract]
        public string Foo()
        {
            return "bar";
        }
    }

    public class FooEngine
    {

    }
}

~/FooService.svc:

<%@ ServiceHost Language="C#" Debug="true" Service="FooService.FooService" CodeBehind="~/App_Code/FooService.cs" %>

~/Web.config:

<configuration>
  <system.web>
    <compilation debug="false" targetFramework="4.0" />
  </system.web>

  <system.webServer>
     <modules runAllManagedModulesForAllRequests="true"/>
  </system.webServer>

  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="">
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="false" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
  </system.serviceModel>
</configuration>

~/Default.aspx:

<%@ Page Language="C#" %>
<% var foo = "bar"; %>

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

Если вы используете скомпилированное веб-приложение, ваша структура будет следующей:

• bin / MyWebService.dll
• FooService.svc
• Default.aspx

Это то, что я бы порекомендовал вам.

Answer 4

У меня была похожая проблема с моим проектом, веб-сайт работал нормально, но все веб-службы svc сталкивались с такой же ошибкой.

Я попытался изменить строку ниже в web.config, но это не помогло

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

Решение, которое я нашел, было связано с тем, как было построено приложение.

Поскольку я использовал проект развертывания, я обнаружил, что сняв флажок с опции:

Рассматривать как компонент библиотеки (удалить файл App_Code.compiled)

на странице «Выходные сборки», а затем перестройка и развертывание проекта, похоже, мне помогли.

Надеюсь, это поможет кому-то еще.

Answer 5

Это похоже на проблему с компилятором Asp.Net.Кажется, что он не обновляет временные файлы ASP.NET для WCF с новой сборкой DLL после перекомпиляции.Не могли бы вы протестировать приложение с помощью batch = false, т.е.

Answer 6

Вы можете настроить пул приложений IIS на перезапуск через определенный период времени или определенный сбой приложения.Пожалуйста, проверьте следующие URL, которые могут вам помочь:

http://forums.asp.net/p/1551597/3934757.aspx http://weblogs.asp.net/albertpascual/archive/2010/07/01/installing-asp-net-4-in-iis-6.aspx

Гаурав Маниар MCP |MCSE |MCST |MCITP |Сертифицировано ITILv3

Answer 7

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

Если вы видите это, попробуйте выполнить IISRESET /noforce.Это должно сказать серверу, что нужно действительно перерабатывать все.