2013-03-13 15 views
19

Mam projekt, który działa z pakietowaniem, gdy uruchamiasz go z poziomu wizualnego studio. Jednak po wykonaniu deploymentu obsługa powiązania nigdy nie wydaje się odbierać trasy. Kończy się ono do statycznego programu obsługi plików, który zwraca odpowiedź 404.Pakiety MVC4 zwracają 404

Wszelkie pomysły? Widzę zestaw optymalizacyjny w koszu strony internetowej w IIS.

Korzysta z puli aplikacji 4.0 i trybu zintegrowanego.

Zastanawiam się, czy ktoś ma jakieś pomysły lub sugestie?

Dzięki

----- na podstawie pytań aktualizacja -----

VS2012

targetFramework = "4.5"

Dodałem też trochę kodu do celu pokaż, które moduły zostały załadowane i widzę tam wymieniony moduł pakietu.

BundleConfig jest ustawieniem domyślnym podczas korzystania z szablonu projektu aplikacji internetowej MVC4.

Witryna jest wdrażana w katalogu głównym. To dziwne, jak gdy ustawiam EnableOptimizations = true (z powodu uruchamiania w trybie debugowania za pośrednictwem visual studio F5), działa idealnie! Mogę nawigować do treści/css i wypluwa połączone css.

Wdrażam go i wszystko inne działa, ale łączę w pakiety!

+1

Może być Twoja ścieżka do plików w pakiecie różni się od tej, która powinna być ... –

+0

jest ustawieniem czasu wykonywania na 4.0 lub 4.5? Sprawdź web.config. Korzystasz z VS2012 lub 2010? – ApolloSoftware

+0

Nie widzę, jak ścieżka może być niewłaściwa, biorąc pod uwagę, że robię publikację do mojego folderu IIS i wszystko inne ładuje się dobrze (widoki, układy, obrazy). Jeśli ręcznie odwołam się do pliku css /content/site.css, ładuje się. Ale kiedy trafiam/content/css, bundlemoduł wydaje się nie przechwytywać połączenia i załadować dołączoną zawartość css! – Mike

Odpowiedz

23

Właśnie trafiłem (i rozwiązałem) ten problem.

Upewnij się, że ścieżka wirtualna pakietu nie może zostać zmylona dla istniejącego katalogu lub rzeczywistej nazwy pliku. W moim przypadku, ja oznaczonych jako:

bundles.Add(new ScriptBundle("~/bundles/main.js").Include(... 

Ale kiedy zmienił go do

bundles.Add(new ScriptBundle("~/bundles/main").Include(... 

wszystko zaczęło działać.

+0

Miałem ten sam problem, aby uzyskać dostęp do fontów, świetnych czcionek, dla ** innych rozwiązań ** wypróbuj te linki, które dotyczą 'StyleBundle' ** virtualpath **: [Link 1] (http://www.mvccentral.net/story/details/articles/kahanu/stylebundle-403-error-solved), [Link 2] (http://forums.asp.net/t/1774324.aspx?MVC4+css+bundling+and+image+references), [Link 3] (http://ericpanorel.net/2013/10/25/font-awesome-4-0-mvc-bundling-and-minification/), [Link 4] (http://jameschambers.com/ 2014/08/dodanie-trochę-font-awesome-to-mvc-and-bootstrap /), mam nadzieję, że to komuś pomaga. – stom

12

Zaktualizowana odpowiedź z dnia 17.11.2013 Jest to spowodowane tym, że domyślne routing MVC obsługuje tylko * zamiast *. * Tzn IIS lub applicationHost.config IIS Express serwuje ma następujący:

  <add name="ExtensionlessUrl-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" responseBufferLimit="0" /> 

Tak, aby go obejść, możemy dodać następujące do pliku web.config:

 <system.webServer> 
     <handlers>  
      <add name="UrlRoutingHandler" 
       type="System.Web.Routing.UrlRoutingHandler, 
        System.Web, Version=4.0.0.0, 
        Culture=neutral, 
        PublicKeyToken=b03f5f7f11d50a3a" 
       path="/bundles/*" 
       verb="GET"/>  
     </handlers> 
     </system.webServer> 

Aby uzyskać więcej informacji, można odwoływać się, co następuje: http://weblogs.asp.net/owscott/archive/2013/01/16/handing-mvc-paths-with-dots-in-the-path.aspx ASP.NET MVC Url Route supporting (dot)

Old źle odpowiedź: zasadniczo DOT jest generalnie niedozwolone w wirtualnej ścieżki gdy IIS przetwarza adresy URL. Ten a Link wspomniał o następującym parametrze URLScan AllowDotInPath: Domyślnie ta opcja jest ustawiona na 0. Jeśli ta opcja jest ustawiona na 0, narzędzie URLScan odrzuca każde żądanie zawierające wiele kropek (.).Zapobiega to próbom ukrycia żądań dotyczących niebezpiecznych rozszerzeń nazw plików poprzez umieszczenie bezpiecznego rozszerzenia nazwy pliku w informacji o ścieżce lub części łańcucha zapytania w adresie URL. Na przykład, jeśli ta opcja jest ustawiona na 1, narzędzie URLScan może zezwolić na żądanie dla http: // nazwaserwera/BadFile.exe/SafeFile.htm, ponieważ interpretuje to jako żądanie strony HTML, gdy faktycznie jest żądaniem plik wykonywalny (.exe) z nazwą strony HTML w obszarze PATH_INFO. Gdy ta opcja jest ustawiona na 0, narzędzie URLScan może również odmawiać żądań dla katalogów zawierających kropki.

+1

Dokumentacja mówi, że odrzuci żądanie zawierające ** kilka ** okresów; który sugeruje, że pojedynczy okres powinien być w porządku. – gerrod

+1

@gerrod, ostatnie zdanie oznaczone: Gdy ta opcja jest ustawiona na 0, narzędzie URLScan może także odmawiać żądań dla katalogów zawierających kropki. Wraz z tym, jak praca związana z pakowaniem zbiorczym, doda wygenerowany przyrostek mieszający do wygenerowanego adresu URL. Tak więc pojawi się kropka w katalogu wirtualnym. Tak więc to nie zadziała. – xinqiu

+0

Uhm, nie, to wciąż nie jest w porządku. Wartość skrótu zostaje dodana jako parametr ciągu zapytania, np. 'bundles/main.js? v = {hash}'. Dosłownie próbowałem tego, a Ty masz rację **, że posiadanie więcej niż jednego okresu w ścieżce spowoduje, że narzędzie URLScan odrzuci żądanie; ale posiadanie jednego okresu jest w porządku. – gerrod

3

Nawet ja dostałem ten sam błąd. Dodanie <modules runAllManagedModulesForAllRequests="true" /> pod <system.webServer> w pliku web.config rozwiązało problem.

0

Miałem ten sam problem nawet z przykładową aplikacją MVC. Widziałem domyślny szablon pakuje arkusz stylów z nazwami css, które, jak sądzę, IIS nie lubi powodując błąd 404.

Zmiana nazwy pakietu z css na APPCSS rozwiąże problem.