Nie znaleziono pliku WebResource.axd

Question

Nie mogę pobrać plików skryptów do załadowania na moją witrynę. Wszystko inne działa dobrze. Jednak nie próbowałem ScriptResource.axd.

Zweryfikowałem, że ten problem istnieje zarówno w cassini, jak i IIS7.

Sprawdziłem mój 64bit 4.0 web.config zawiera mapowanie dla WebResource.axd.

Mój czas systemowy jest poprawny (słyszałem, że mogą z tym wystąpić problemy).

Sprawdziłem, czy działa w innych projektach, więc winowajcą musi być moja aplikacja internetowa.

Moja aplikacja internetowa to aplikacja internetowa 4.0 MVC3.

Mój web.config można znaleźć here.

Ten błąd mnie zabija! Każda pomoc będzie doceniona!

Answer 1

Plik web.config jest niesamowite (nie jest to komplement): w .NET Framework 4.0, powinien być znacznie krótszy/lżejsze.
myślę, że teleskopowa jest zadeklarowana w złym dziale:

<system.webServer> 
    <handlers> 
     <add name="WebResource" path="WebResource.axd" verb="GET" type="System.Web.Handlers.AssemblyResourceLoader" /> 
    </handlers> 
</system.webServer> 

Normalnie obsługi WebResource.axd jest zadeklarowana w sekcji „system.Web”:

<system.web> 
    <httpHandlers> 
     <add path="WebResource.axd" verb="GET" type="System.Web.Handlers.AssemblyResourceLoader" validate="True" /> 
    </httpHandlers> 
</system.web> 

Answer 2

mam podobny problem rozwiązany przez dodanie uprawnień odczytu dla wszystkich do folderu, w którym znajdował się zespół zawierający osadzony zasób. Najwyraźniej Każdy jest przesadny, ale to może pomóc innym badać podobne problemy.

W naszym przypadku niektóre zasoby zostały załadowane (więc wiem, że AssemblyResourceLoader działał) i działało na jednym komputerze, ale nie na innym.

This answer na inne pytanie pomogło mi ustalić, które zespoły nie działały.

Answer 3

I rozwiązać ten problem na maszynie produkcyjnej uruchomiony ponownie aspnet_regiis:

%WINDIR%\Microsoft .NET\Framework\4.xxxx\aspnet_regiis -i 

Prawdopodobnie standardowy montaż ram 4 poszło źle.

Answer 4

trochę późno, ale może komuś pomóc w przyszłości ...

Okazało się, że to może się zdarzyć, jeśli DLL aplikacji internetowej są dostarczającej są nowsze niż chwili obecnej daty. Na przykład umieszczasz swoją aplikację internetową na serwerze produkcyjnym, gdzie czas serwera jest starszy niż na komputerze programisty.

Pierwsze czas serwera zsynchronizowane z urządzeniem dev wystarczyły dla mnie ...

Answer 5

miałem ten problem z Umbraco .axd na serwerze produkcyjnym, to doprowadzało mnie do szału, dopóki nie okazało się, że serwer miał różne zabezpieczenia i w ramach filtrowania żądań rozszerzenia .axd i.asmx nie były domyślnie wymienione w nazwach plików Dozwolone, a firma hostująca miała ustawienie Zezwalaj na wyłączanie rozszerzeń nazw plików niepublicznych, co było inne niż w mojej maszynie programistycznej.

Answer 6

Absolutnie rozwiązaniem jest: http://www.4guysfromrolla.com/articles/080906-1.aspx podczas sprawdzania kodu .NET Framework: https://github.com/Microsoft/referencesource/blob/master/System.Web/Handlers/AssemblyResourceLoader.cs można zobaczyć trick: na linii 606

WebResourceAttribute wra = FindWebResourceAttribute(assembly, resourceName); 

jeśli zespół nie ma WebResourceAttribute zgłasza błąd 404. Można zobaczyć na tej linii

if (resourceStream == null) { 
      if (resourceIdentifierPresent) { 
       LogWebResourceFailure(decryptedData, exception); 
      } 
      throw new HttpException(404, SR.GetString(SR.AssemblyResourceLoader_InvalidRequest)); 
     } 

więc dodać WebResourceAttribute do AssemblyInfo.cs złożyć tak:

[assembly: WebResource("FullNameSpace.SampleResourceFile.js", "text/javascript")]