Komunikat o błędzie parsera: nie można załadować typu „TestMvcApplication.MvcApplication”

Na jednym z naszych serwerów produkcyjnych pojawia się następujący błąd. Nie wiesz, dlaczego to działa na serwerze DEV?

Opis błędu parsera : Wystąpił błąd podczas analizowania zasobu wymaganego do obsługi tego żądania. Zapoznaj się z poniższymi szczegółowymi szczegółami błędu analizy i odpowiednio zmodyfikuj plik źródłowy.

Komunikat błędu parsera : nie można załadować typu „TestMvcApplication.MvcApplication”.

Błąd źródła :

Wiersz 1: <% @ Application Codebehind = "Global.asax.cs" Inherits = "TestMvcApplication.MvcApplication" Language = "C #"%>

Plik źródłowy: /global.asax Linia: 1

Nie jestem pewien, czy ktoś wcześniej natknął się na ten błąd i jak go rozwiązano, ale dotarłem do końca. Każda pomoc będzie mile widziana.

Muszę również wspomnieć, że jest to opublikowany kod, więc wszystko jest kompilowane. Czy może być coś nie tak z ustawieniami mojego kompilatora?

Żadna z pozostałych odpowiedzi nie pomogła. Naprawiłem mój błąd, zmieniając ścieżkę wyjściową projektu internetowego. Ustawiłem go na bin \ debug, ale projekt sieciowy nie działa, chyba że ścieżka wyjściowa jest ustawiona na po prostu „bin”

Miałem to kilka razy. Jest to szczególnie frustrujące, ponieważ działa od razu, a komunikat o błędzie nie ma pojęcia, co może być przyczyną problemu.

Aby to naprawić, kliknij prawym przyciskiem myszy tytuł projektu, w tym przypadku „TestMvcApplication”, i kliknij buduj .

Wymusza to kompilację kodu przed jego uruchomieniem. Nie pytaj mnie dlaczego, ale to było dla mnie rozwiązanie w 100% przypadków.

Zauważyłem, że kiedy jesteś zmuszony używać Menedżera konfiguracji do uruchomienia na platformie x86 lub jakiejkolwiek innej niż standardowe ustawienia projektu „po wyjęciu z pudełka”, IDE tworzy kilka podkatalogów w folderze bin dla projektu internetowego.

Gdy to się zacznie, jeśli serwer Cassini jest uruchomiony, projekt nie będzie działał poprawnie.

Naprawiłem to, przechodząc do właściwości projektu internetowego -> Ustawienia kompilacji i zmieniając ścieżkę wyjściową na bin \

Następnie odbuduj i wszystko działa tak, jak powinno.

Po długim ciężkim spojrzeniu doszedłem tutaj do prawdziwego problemu.

Zestawy zostały uszkodzone przez klienta FTP, którego użyłem do przesłania plików do hostowanego środowiska.

Zmieniłem klienta FTP i wszystko działa zgodnie z przeznaczeniem.

Miałem ten sam problem: mój był taki, że projekt sieciowy miał platformę docelową x86. Pracowałem na komputerze 64-bitowym; inne projekty w rozwiązaniu zostały ustawione na 64-bitowe.

Aby sprawdzić ustawienia, kliknij projekt prawym przyciskiem myszy i wybierz opcję Właściwości. Na karcie Kompilacja sprawdź wartość „Platforma docelowa”.

Sprawdź również konfigurację kompilacji rozwiązania (menu kompilacji> Configuration Manager), aby sprawdzić, czy wszystkie projekty są tworzone na tej samej platformie.

W obu przypadkach upewnij się, że sprawdziłeś ustawienia zarówno dla trybu debugowania, jak i trybu wydania - w przeciwnym razie będziesz działać na swoim komputerze, ale nie podczas wdrażania!

Wypróbowałem wszystkie powyższe rozwiązania, ale bez powodzenia. Dodanie linii <add assembly="*" />do web.config naprawiło to za mnie. (Możesz także dodać do pliku machine.config lub root web.config odpowiednią wersję frameworka .NET, nie próbowałem tego). Dzięki wsparciu MS za rozwiązanie.

Miałem coś, co wyglądało na ten sam błąd. Wypróbowałem wiele sugestii z wielu stron, ale problem polegał na tym, że ustawiłem na stronie niewłaściwą wersję .Net

Bez względu na to, ile ponownych kompilacji lub osób mówiących „problem z konfiguracją”, nikt nie zauważył, że wersja .net wymaga sprawdzenia.

To się dzieje ze mną, kiedy zmieniam nazwę projektu / rozwiązania. Przejdź do folderu projektu w eksploratorze Windows (wyjdź z VS). Znajdź i otwórz plik Global (może znajdziesz 2 pliki, otwórz, które nie mają rozszerzenia ".asax.cs") i edytuj wiersz błędu, podając poprawną ścieżkę. Powodzenia!

Doświadczyłem dokładnie tego samego problemu kilka dni temu - o ile wiem, był to problem z 64-bitowymi usługami IIS z 32-bitową aplikacją internetową. Zmieniliśmy nasz serwer produkcyjny na 32-bitowy i ten problem zniknął.

Upewnij się, że domyślna przestrzeń nazw we właściwościach projektu sieci Web jest taka sama jak przestrzeń nazw w pliku Global.asax.cs. Zmodyfikowałem domyślną przestrzeń nazw, aby uczynić ją przestrzenią podrzędną, zmieniając ją z powrotem, rozwiązując ten problem.

Ze względu na kompletność podałem, jaki był mój problem i jak go rozwiązałem:

Jeśli lubisz mnie i masz httphandlers przez web.config i masz przekierowania ze swojego global.asax.cs (może w Session_Start ()), tak jak w moim przypadku, pojawia się ten błąd, jeśli twój projekt startowy nie ma zdefiniowanego odniesienia, które wskazuje na cel, na który wskazuje twój httphandler !! (ale nie otrzymasz błędów kompilacji, tylko błędy uruchomieniowe)

Więc:

1. Dokładnie sprawdź, czy w pliku web.config znajdują się elementy zewnętrzne
2. Dokładnie sprawdź, czy projekt startowy zawiera wszystkie potrzebne odniesienia.

Twoje zdrowie.

Jedyny raz, kiedy tego doświadczyłem, miał miejsce, gdy framework MVC nie był zainstalowany na serwerze. Czy to możliwe?

Uszkodzona może być również brakująca sekcja Pages w Views \ Web.config.

Miałem ten sam błąd i żadne z twoich rozwiązań nie pomogło. Myślę, że moim problemem była po prostu nazwa, którą wybrałem dla projektu. Nazwałam swój projekt „interfejsem”, który po otrzymaniu błędu analizy informował, że nie można go załadować:

Wiersz 1: <% @ Application Codebehind = "Global.asax.cs" Inherits = " @interface .MvcApplication" Language = "C #"%>

Gdzie z jakiegoś powodu był znak „@”. Domyślam się, że słowo „interfejs” jest zarezerwowane dla czegoś innego i dodało symbol @, ale to oczywiście coś zepsuło. Usunąłem projekt i bez problemu stworzyłem nowy z inną nazwą.

Oto kolejny:

1. Pracowałem nad projektem interfejsu API sieci Web, który korzystał z localhost: 12345.
2. Wyrejestrowałem inną gałąź z kontroli źródła zawierającą ten sam projekt.
3. Uruchomiłem projekt na gałęzi i otrzymałem błąd.
4. Poszedłem do „Właściwości> Sieć> Adres URL projektu” i kliknąłem „Utwórz katalog wirtualny”
5. Pojawiło się okno dialogowe z informacją, że adres URL został zmapowany do innego katalogu (katalogu oryginalnego projektu).
6. Kliknąłem OK i katalog wirtualny został ponownie zmapowany.
7. Błąd zniknął.

Mam nadzieję, że to gdzieś komuś pomoże :)

Miałem wiele problemów i błędów do rozwiązania, niektóre z powyższych odpowiedzi pomogły, ale ostatnia sztuczka, która sprawiła, że ​​to zadziałało, to: Idź do swojego projektu, kliknij właściwości.

Przejdź do zakładki Package / Publish Web i upewnij się, że konfiguracja jest ustawiona na Release, a Platform to All Platforms.

Na koniec upewnij się, że „Elementy do wdrożenia (dotyczy wszystkich metod wdrażania)” jest ustawione na „Wszystkie pliki w tym folderze projektu”

Wtedy zadziałało dobrze dla mnie.

Ten problem jest skomplikowany, ponieważ łatwo jest pomylić pierwotną przyczynę z bezpośrednią przyczyną.

W moim przypadku bezpośrednią przyczyną było to, że rozwiązanie jest skonfigurowane do korzystania z przywracania pakietu NuGet, ale serwer nie był połączony z Internetem, więc NuGet nie mógł pobrać zależności podczas tworzenia po raz pierwszy.

Uważam, że główną przyczyną jest po prostu to, że rozwiązanie nie jest w stanie poprawnie rozwiązać zależności. Może to być niepoprawna konfiguracja ścieżki, niewłaściwa wersja zestawu, sprzeczne zestawy lub częściowe wdrożenie. Ale we wszystkich przypadkach błąd polega po prostu na tym, że nie może znaleźć typu określonego w global.asax, ponieważ nie może go zbudować.

Upewnij się, że przestrzeń nazw w Global.asaxpliku jest zgodna z tym w Global.cspliku, tj

Global.asax: Some.Website.Webapplication

Global.cs: Some.Website(bez „WebApplication”)

Wypróbowałem większość powyższych odpowiedzi i nie zadziałały. Z jakiegoś powodu samo zamknięcie i ponowne otwarcie VS rozwiązało problem.

Mój problem został rozwiązany po przekonwertowaniu w usługach IIS fizycznego folderu zawierającego pliki na aplikację. Kliknij prawym przyciskiem myszy> przekonwertuj do aplikacji.

U mnie było to spowodowane tym, że tymczasowo wykluczyłem plik z projektu. Po prostu włączyłem to z powrotem do projektu, a potem zadziałało.

W moim przypadku brakowało odniesienia do System.Web.MVC w moim projekcie. Ale po dodaniu referencji problem był taki sam, więc sprawdziłem właściwości mojego folderu Bin, był to ReadOnly. Zaraz po umożliwieniu zapisu wszystko działa poprawnie.

Wystąpił błąd, ponieważ wdrożyłem aplikację jako katalog wirtualny i otrzymywałem błąd parsera „nie można załadować typu”, po czym wdrożyłem aplikację jako witrynę internetową i nie otrzymałem tego błędu ponownie.

Żadna z pozostałych odpowiedzi nie rozwiązała za mnie tego błędu.
Znalazłem rozwiązanie, które zadziałało, które proponuję osobom w podobnej sytuacji:

1. Zamknij program Visual Studio
2. Przejdź do Projects \ yourProject \ yourProject
3. Zmień nazwę Web.Debug.config i Web.Release.config
4. Przebuduj i uruchom aplikację

Nigdy tak naprawdę nie dotarłem do sedna tego, co było dla mnie przyczyną. Myślę, że gdzieś musiałem brakować niektórych plików. Otrzymałem błąd po opublikowaniu na nowym serwerze. Ostatecznie skopiowałem witrynę z działającej witryny. Następnie strona działała, podobnie jak dalsze publikacje na nowym serwerze.

Wykonaj następujące kroki:

1. Budować
2. Manager konfiguracji
3. Umieść projekt AnyCPU
4. Wróć do generowania
5. Gotowe, po tym po prostu wykonaj te same kroki, aby przekazać go do x86 lub x64

W moim przypadku miałem dołączoną bibliotekę DLL do mojego projektu, która musiała być uruchomiona w środowisku 32-bitowym.

Serwer został skonfigurowany do uruchamiania witryny w trybie 32-bitowym, ale nie mogłem uruchomić aplikacji na komputerze 64-bitowym, ponieważ localhostfolder nie został określony do działania w trybie 32-bitowym.

Właśnie miałem podobny problem.

Powodem było to, że zmieniałem plik file.aspx.c i musiałem wykonać czystą odbudowę. Potem wszystko działało.

Mój problem polegał na tym, że próbowałem utworzyć aplikację internetową ASPX w podfolderze folderu, w którym był już plik web.config i

Więc otworzyłem folder nadrzędny w programie Visual Studio jako witrynę sieci Web (Otwórz> Witryna sieci Web). Mogłem dodać nową stronę ASPX elementu, która nie miała problemu z analizowaniem / ładowaniem.

U mnie problem dotyczył tylko niektórych (długich) linków w witrynie i został wyśledzony do narzędzia URLScan z domyślną konfiguracją limitu długości adresu URL wynoszącego 260.

Miałem ten sam problem. Spróbuj:

Kliknij projekt prawym przyciskiem myszy i wybierz opcję Wyczyść, a następnie kliknij ponownie prawym przyciskiem myszy i wybierz opcję Przebuduj i uruchom projekt, aby sprawdzić, czy zadziałał.