"Parser-Fehlermeldung: Typ konnte nicht geladen werden" in Global.asax

Ich arbeite an einem MVC3-Projekt und erhalte die folgende Fehlermeldung:

Parser-Fehlermeldung: Typ 'GodsCreationTaxidermy.MvcApplication' konnte nicht geladen werden.

Quellfehler:

Linie 1: <%@ Application Codebehind="Global.asax.cs" Inherits="GodsCreationTaxidermy.Core.MvcApplication" Language="C#" %>

Der Fehler, den ich erhalte, ist, dass GodsCreationTaxidermy.Core.MvcApplication nicht geladen werden kann, aber in diesem Screenshot wird der Kernteil im Fehler nicht angezeigt:

Hat jemand Ideen oder eine Lösung für diesen Fehler?

Auf Ihrem lokalen Webserver wird ein anderer Code ausgeführt als der, an dem Sie tatsächlich arbeiten. Stellen Sie sicher, dass Sie das Debuggen beendet haben, stoppen Sie Ihren lokalen Webserver, bereinigen und neu erstellen, wie von Peter vorgeschlagen, überprüfen Sie Ihre global.asax und global.asax.cs und versuchen Sie es erneut.

Wenn dies nicht funktioniert und Sie lokalen IIS verwenden, entfernen Sie die Site im IIS-Manager und erstellen Sie sie manuell neu.

Überprüfen Sie, ob der Projektausgabepfad (Projekteigenschaften / Build) auf binund nicht bin\Release oder eingestellt istbin\Debug

Aus irgendeinem Grund greift IIS (VS Development Server oder Local IIS) immer über das binVerzeichnis auf die Bibliotheken zu (und sucht nicht nach Unterverzeichnissen).

Versuchen Sie, Ihre global.asax-Datei zu ändern (fügen Sie einfach irgendwo ein Leerzeichen hinzu) und führen Sie sie erneut aus. Dadurch wird der integrierte Webserver gezwungen, die Datei global.asax zu aktualisieren und neu zu kompilieren.

Führen Sie auch eine Reinigung und einen Neuaufbau durch - sollte das Problem beheben

Dies passiert manchmal, wenn Sie die Namespace-Informationen (Projekt- oder Klassenebene) nach der global.asaxGenerierung ändern .

Klicken Sie mit der rechten Maustaste auf die Global.asaxDatei und wählen Sie "Öffnen mit" und dann "XML (Text) -Editor mit Codierung" (andere Editoren funktionieren möglicherweise ebenfalls, aber das verwende ich).

Bearbeiten Sie dann den Abschnitt "Inherits" in der XML-Direktive

<% @ Application Codebehind = "Global.asax.cs" Inherits = "GodsCreationTaxidermy.MvcApplication" Language = "C #"%>)

damit es mit dem tatsächlichen vollständigen Namen Ihrer Anwendungsklasse übereinstimmt. Und das ist es.

Eine andere Möglichkeit besteht darin, Ihren gesamten Code aus Global.asax.cs zu kopieren und dann eine weitere Global.asax-Datei zu löschen und zu erstellen (und den Code dann wieder in Global.asax.cs zu kopieren).

Ich habe das visuelle Studio geschlossen und wieder geöffnet und es hat funktioniert.

Ich musste zu BUILD -> CONFIGURATION MANAGER gehen und - ähm - das Kontrollkästchen neben meinem Projekt aktivieren, um sicherzustellen, dass es tatsächlich erstellt wird.

Ich hatte dieses Problem heute und es dauerte eine Weile, bis ich die Ursache gefunden hatte.

Grundsätzlich enthielt mein Hauptprojekt VS2015 ein Unterprojekt, das mit einer höheren Version von .Net Framework erstellt wurde.

Wenn Sie dieses Problem haben, meldet VS2015 seltsamerweise gerne, dass die Lösung in Ordnung ist. Wenn Sie jedoch versuchen, die Website auszuführen, erhalten Sie nur diesen irreführenden Fehler, der darauf hindeutet, dass Ihre Global.asax.cs Datei falsch ist.

Wenn Sie diesen Fehler sehen und das Bereinigen / Wiederherstellen nicht hilft, öffnen Sie den ReferencesBaum Ihres Projekts und suchen Sie nach Ausrufezeichen.

Überprüfen Sie auch Ihr OutputFenster auf Nachrichten wie diese:

The primary reference "C:\Projects\Business Objects 4\bin\Release\BusinessObjects.dll" 
could not be resolved because it was built against 
the ".NETFramework,Version=v4.5" framework. 
This is a higher version than the currently targeted framework
".NETFramework,Version=v4.0".

Die Lösung besteht natürlich darin, mit der rechten Maustaste auf Ihr Hauptprojekt zu klicken, die obere Registerkarte "Anwendung" auszuwählen und die Target Framework-Version in eine höhere Version zu ändern, die Ihrem Unterprojekt entspricht.

Es ist ärgerlich, dass Sie mit Visual Studio 2015 vollständig Lösungen erstellen und ausführen können, die dieses Problem stillschweigend enthalten. Es bittet um Ärger ..!

Sie können auch die Eigenschaften Ihrer Site in IIS überprüfen. (Klicken Sie in IIS mit der rechten Maustaste auf die Site und wählen Sie Eigenschaften.) Stellen Sie sicher, dass die Einstellung Physischer Pfad auf den richtigen Pfad für Ihre Anwendung zeigt, nicht auf eine andere Anwendung. (Das hat diesen Fehler für mich behoben.)

Ich bin gerade auf eine MVC5-Anwendung gestoßen, und bei mir hat nichts funktioniert. Dies geschah direkt nachdem ich versucht hatte, eine SVN-Wiederherstellung auf eine ältere Version des Projekts durchzuführen.

Ich musste löschen global.asax.cs und dann ein neues hinzufügen, indem mit der rechten Maustaste auf Projekt -> Neues Element hinzufügen -> Global.asax klickte, und DAS hat es schließlich behoben.

Ich dachte nur, es könnte jemandem helfen.

Ich muss berichten, dass ich mindestens 4 Vorschläge aus diesem Beitrag ausprobiert habe. Keiner von ihnen hat funktioniert. Ich freue mich jedoch, Ihnen mitteilen zu können, dass ich mich durch Abrufen von der Sicherung erholt habe. Musste nur meine letzten Codeänderungen aus der Protokolldatei aktualisieren. Dauerte weniger als 10 Minuten. Verbrachte 3 Mal damit, diesen Beitrag zu lesen und andere Vorschläge auszuprobieren. Es tut uns leid.

Es war ein sehr seltsamer Fehler. Viel Glück für alle anderen, die diesem Gremlin begegnen.

Ich habe das gleiche Problem, wenn zwei Instanzen von Visual Studio dasselbe Projekt ausführen. Also habe ich beide Visual Studio geschlossen und nur eine Instanz geöffnet und es funktioniert jetzt gut!

Ich habe an einem älteren "ordnerbasierten" ASP.NET-Webprojekt gearbeitet (das ich verabscheue) - und fand, dass dies mein Fix ist:

Erstellen Sie einen App_CodeOrdner (falls Sie noch keinen hatten)

Verschieben Sie die Global.asax.vbDatei in den App_CodeOrdner

Das Markup in Global.asax kann beliebige Namespaces weglassen (zumindest für diesen Projektstil afaik):

<%@ Application Codebehind="Global.asax.vb" Inherits="MyApp" Language="VB" %>

... wobei "MyApp" der Name der Klasse ist, die in Global.asax.vb definiert wird

"BUILD -> CONFIGURATION MANAGER und - ähm - aktivieren Sie das Kontrollkästchen neben meinem Projekt, um sicherzustellen, dass es tatsächlich erstellt wird." Dies und das Aufrufen des Projektordners im Windows Explorer, das Drücken von Optionen und das Deaktivieren des Kontrollkästchens "Schreibgeschützt" haben geholfen.

Leeren Sie den Ordner bin. Erstellen Sie alle abhängigen Klassenbibliotheken, verweisen Sie auf sie im Hauptprojekt und erstellen Sie die vollständige Lösung.

Quelle

Auch ich hatte das gleiche Problem. Obwohl ich jeder Antwort gefolgt bin, hat es nicht funktioniert. Dann habe ich die "Inherits = namespace.class " in "Inherits = vollständig qualifizierter Assemble-Name " geändert , dh "Inherits = namespace.class, assemblyname, Version =, Culture =, PublicKeyToken = " Hoffe, es hilft.

Dies kann auch passieren, wenn Sie versehentlich vergessen haben, Ihre VS-Lösung auf "Mehrere Startprojekte" zu setzen, wenn Sie ein Web und WebApi mit derselben Lösung ausführen.

Sie können dies überprüfen, indem Sie im Projektmappen-Explorer mit der rechten Maustaste auf "Lösung" klicken und "Eigenschaften" auswählen. Suchen Sie dann nach "Startprojekte".

Löschen Sie das .vsVerzeichnis aus dem Lösungsstamm. Reinigen. Wiederaufbauen.

Dieses Problem macht mich hin und wieder verrückt und ich lande unweigerlich hier, um Antworten zu finden. Ich vermute, dass es mehrere Ursachen gibt, die diese Ausnahme hervorrufen können. Dies funktioniert einmal für mich.

Ja, ich habe alle Antworten gelesen. Wenn Sie jedoch ich sind und alle Reste Ihrer Haare herausgezogen haben, überprüfen Sie den Ordner \ bin. Da die meisten proj-Dateien möglicherweise mehrere Konfigurationen unter dem XML-Element gruppiert haben PropertyGroup, habe ich den OutputPathWert von 'bin \ Debug' geändert , um den Teil '\ Debug' zu entfernen und neu zu erstellen. Dadurch wurden die Dateien im Ordner \ bin abgelegt, sodass Express IIS den Build finden und laden kann. Ich frage mich, wie diese verschiedenen Builds richtig verwaltet werden können, damit eine lokale Debug-Bereitstellung die Zielumgebung finden und laden kann.

Dieses Problem wurde gelöst, indem ich die richtige Berechtigung für den Ordner erteilte und von IIS aus überprüfte.

Ich habe allen die Erlaubnis gegeben, während ich in meiner lokalen Umgebung teste. Im Veröffentlichungsmodus erteilen wir dem ASP.Net-Benutzer jedoch nur die Berechtigung.

Ich habe auch den gleichen Fehler ... überprüfen Sie den Namen der Anwendung, die Sie richtig entwickelt haben, dh. Der zugewiesene Namespace und der Assemblyname sowie der physische Name des Ordners, der für die Anwendung erstellt wurde, sollten mit dem Namen im obigen Namespace in der Datei global.asax übereinstimmen

Ich habe auch den gleichen Fehler erhalten ... Überprüfen Sie die IIS-Konfiguration Ihres virtuellen Verzeichnisses und stellen Sie sicher, dass Eigenschaften - ASP.NET - ASP.NET-Version mit Projekteigenschaften - Anwendung - Zielframework identisch sind. (Das hat diesen Fehler für mich behoben.)

Meine App wurde in einer älteren Version von VS erstellt und hatte keinen bin-Ordner. Ich hatte es auf eine neuere Version aktualisiert und hatte einen Albtraum, es bereitzustellen. Ich habe diesen Fehler schließlich bis zu Projekt> Eigenschaften> Anwendung verfolgt. Das Ziel-Framework wurde auf 2.0 festgelegt. Das Problem wurde für mich behoben, indem es auf dem Server so geändert wurde, dass es mit dem IIS-Manager / App-Pool übereinstimmt.

Ich fand, dass das Ändern des Namespace im Projekt, ohne dies über die gesamte Lösung hinweg umzugestalten, mein Problem war. Überprüfen Sie die Eigenschaften Ihres Projekts und stellen Sie fest, wie Ihr Namespace lautet. Stellen Sie sicher, dass die Linien auf der ganzen Linie ausgerichtet sind.

Das Problem für mich ist, dass ich global.asax.cs nicht in mein Projekt aufgenommen habe. Und weil ich Dateien von .net 4.5 auf 4.0 kopiert habe, habe ich keine Zeilen auskommentiert, die in 4.0 nicht benötigt werden. Da es nicht enthalten war, kompilierte Visual Studio es trotzdem ohne Probleme. Aber als ich es einfügte, wurden die Zeilen hervorgehoben, die Probleme verursachen.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
//using System.Web.Http;
using System.Web.Mvc;
//using System.Web.Optimization;
using System.Web.Routing;

namespace YourNameSpace
{
    public class WebApiApplication : System.Web.HttpApplication
    {
        protected void Application_Start()
        {
            AreaRegistration.RegisterAllAreas();
            //GlobalConfiguration.Configure(WebApiConfig.Register);
            FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
            RouteConfig.RegisterRoutes(RouteTable.Routes);
            //BundleConfig.RegisterBundles(BundleTable.Bundles);
        }
    }
}

Ich habe buchstäblich einen Tag damit verbracht, dieses Problem zu lösen.

Das einzige, was funktionierte, war das Löschen der SLN-Datei, das Erstellen einer neuen und das Hinzufügen der Projekte nacheinander.

¯ \ _ (ツ) _ / ¯ - Programmierung - ¯ \ _ (ツ) _ / ¯

In meinem Fall war die Webassembly Teil von GAC. Nach dem Erstellen muss sie in GAC installiert werden und funktioniert.

Ich bin auf diese Fehlermeldung gestoßen und habe schließlich festgestellt, dass die Fehlermeldung irreführend ist. In meinem Fall scheint es ein Routing-Problem in IIS gegeben zu haben, das dazu führte, dass die Datei global.asax von einer anderen Site auf dem Webserver gelesen wurde, wodurch der Fehler generiert wurde.

In IIS war meine Site an http: * 80: webservices.local gebunden und enthielt eine Anwendung namens MyAPI. Ich habe die gefürchtete Nachricht erhalten, als ich die MyAPI-Anwendung unter Verwendung der IP-Adresse des Webservers aufgerufen habe.

Um meine Anwendung erfolgreich aufzurufen, musste ich auf allen Computern, auf denen die MyAPI-Anwendung aufgerufen wurde, einen Hostdateieintrag für webservices.local hinzufügen. Dann musste allen meinen Anfragen das Präfix http: //webservices.local/MyAPI/ vorangestellt werden, um korrekt weiterzuleiten .

Ich habe hier absolut alles versucht und nichts hat funktioniert. Mein Projekt war in VS 2013. Ich habe seitdem ein Upgrade auf VS 2015 durchgeführt und alle meine neuen Anwendungen im Jahr 2015 erstellt, aber alle meine alten Apps, die 2013 in dieser Version erstellt wurden, geladen, kompiliert, erstellt usw.

Ich habe die Lösung 2015 nur geladen und sie für mich gelöst.

Ich habe mehrere Tage mit diesem Thema verbracht. Ich habe es endlich mit der folgenden Kombination von Vorschlägen aus diesem Beitrag gelöst.

1. Ändern Sie das Plattformziel in Beliebige CPU. Ich hatte diese Konfiguration derzeit nicht, daher musste ich zum Konfigurationsmanager gehen und sie hinzufügen. Ich habe speziell für x64 kompiliert. Dies allein hat den Fehler nicht behoben.
2. Ändern Sie den Ausgabepfad in bin\anstelle von bin\x64\Debug. Ich hatte dies bereits mehrmals versucht, bevor ich das Plattformziel geändert hatte. Es hat nie einen Unterschied gemacht, außer dass der Fehler aufgetreten ist, dass die Assembly aufgrund eines ungültigen Formats nicht geladen werden konnte.

Um klar zu sein, musste ich beides tun, bevor es anfing zu funktionieren. Ich hatte sie mehrere Male einzeln ausprobiert, aber es wurde erst behoben, als ich beides tat.

Wenn ich eine dieser Einstellungen wieder auf das Original zurücksetze, wird der gleiche Fehler erneut angezeigt, obwohl ich Clean Solution ausgeführt und alles im binVerzeichnis manuell gelöscht habe .

Zwei Möglichkeiten, dies zu erreichen:

• Der Konfigurationsmanager zeigt die DLL-Builds als eine Mischung aus '64'- und' beliebiger CPU'-Builds an. Wenn Sie alle auf denselben Build setzen, wird das Problem behoben.

• Beim Wechseln zwischen Zweigen wird der IIS-Expresspfad manchmal nicht aktualisiert. Klicken Sie in der Taskleiste mit der rechten Maustaste auf "IIS Express"> Alle Anwendungen anzeigen und überprüfen Sie, ob der Pfad zum richtigen Zweig führt.