Dlaczego mój IIS 7 odmawia obsłużenia css lub js, kiedy zmienię "Włącz aplikacje 32-bitowe" na False

Question

Mam bardzo prostą aplikację internetową (asp.net MVC3, .net 4, używając IIS nie osadzonego w Visual Studio serwer, 64-bitowy system Windows 7). Po zmianie ustawień w puli aplikacji dla mojej aplikacji i ustawieniu opcji "Włącz aplikacje 32-bitowe" na False, wyświetla się widok mojej aplikacji, ale nie wyświetla się żadna zawartość statyczna (Content/Site.css lub Scripts/myScript.js) w górę. Zamiast tego otrzymuję kod statusu 500 na tych żądaniach.

Błąd HTTP 500.0 - Błąd wewnętrznego serwera Strona nie może zostać wyświetlona, ​​ponieważ wystąpił wewnętrzny błąd serwera.

Powodem zmiany tej wartości jest to, że próbuję użyć 64-bitowego pliku Oracle.DataAccess.dll i jeśli mam tę wartość ustawioną na wartość True, powoduje to, że pula aplikacji działa w trybie WOW64, a ona próbuje załadować bibliotekę DLL w niewłaściwym formacie.

Wyszukiwanie przez pewien czas w Internecie i nie mogę znaleźć zbyt wielu informacji na ten temat. Próbowałem grać z uprawnieniami do plików, próbowałem już uruchomić aspnet_regiis z wszelkiego rodzaju flagami. Nie mam pomysłów. Dlaczego usługi IIS nie obsłużą tej statycznej zawartości podczas działania w trybie 64-bitowym?

Answer 1

Jest bardzo prawdopodobne, że w konfiguracji IIS przez przypadek zostanie zainstalowany moduł tylko 32-bitowy, który uniemożliwia działanie całej aplikacji internetowej w 64-bitowym module. To częsta przyczyna takich 500 błędów.

Failed żądanie śledzenia powinien być w stanie pokazać więcej informacji na temat, który moduł jest,

http://www.iis.net/learn/troubleshoot/using-failed-request-tracing/troubleshooting-failed-requests-using-tracing-in-iis

Answer 2

Muszę tu umieścić komentarz, ponieważ nie mam wystarczającej liczby punktów do skomentowania.

Czy próbowałeś sprawdzić mapowanie przewodnika na swojej stronie internetowej.

Pod Handler Mappings: Sprawdź, czy StaticFile Handler jest jeszcze zarejestrowany i że ścieżka jest przypisany do *

także sprawdzić, czy jest włączona.

Answer 3

Gdy miałem ten błąd wystąpił problem w system.webServer \ staticContent w web.config.

Z powodu różnicy między serwerami, na określony komputer wymagany był określony typ MIME, ale spowodował ten błąd na innym komputerze.

Zabezpieczenie przed zamrożeniem polega na dołączeniu każdego z nich do pliku web.config, aby uniknąć otrzymania 500, jeśli nie jest to wymagane.

Answer 4

Podwójne typy mime są poprawnie przypisane, może to wynikać z podwójnego wpisania typów MIME dla lokalnej witryny web.config i samego serwera.

Answer 5

Właśnie miałem ten problem osobiście z włączonymi zabezpieczeniami Windowsa i ananamicznym dostępem wyłączonym.

Rozwiązaniem w moim przypadku było dodanie strony localhost do moich lokalnych witryn intranetowych. Uruchomienie programu Visual Studio w trybie administratora może również rozwiązać problem.