Visual Studio - Fehler "Metadatendatei 'XYZ' konnte nicht gefunden werden" nach der Bearbeitung wird fortgesetzt

Ich bin auf ein Problem gestoßen, das wirklich nervt.
Wenn ich meine Software debugge, läuft alles in Ordnung. Wenn ich jedoch einen Haltepunkt erreiche und den Code bearbeite, wird beim Versuch, die Ausführung fortzusetzen, folgende Fehlermeldung angezeigt:
Metadata file 'XYZ' could not be found

Nachdem ich mich eine Weile umgesehen hatte, stellte ich einige ähnliche Probleme fest , die sich jedoch alle auf einen Build-Fehler bezogen, was nicht mein Fall ist (dies geschieht erst nach dem Bearbeiten und Fortfahren).

Was ich bisher versucht habe:

• Mein Code wird kompiliert und ausgeführt.
• Ich habe die Lösung gereinigt und VS neu gestartet.
• Ich habe sichergestellt, dass das Projekt der fehlenden Datei für die von mir ausgeführte Konfiguration erstellt wird (im Konfigurationsmanager).
• Ich habe das Projekt der fehlenden Datei manuell erstellt.

Einige zusätzliche Informationen :

• Es spielt keine Rolle, was ich ändere, es wird immer noch der gleiche Fehler angezeigt (die Änderung bezieht sich nicht auf die fehlende Datei).
• Dies passiert auch, wenn ich pausiere und fortfahre (nicht nur Haltepunkte)
• Ich führe das Projekt mit einer benutzerdefinierten Konfiguration aus (Konfigurationsmanager ...). Wenn ich es mit der Standardkonfiguration ausführe, tritt Debugder Fehler nicht auf.

Irgendwelche Ideen?

Schließlich löste das Problem Folgendes:

1. Bereinigen Sie jedes Projekt einzeln ( Rechtsklick > Bereinigen ).
2. Erstellen Sie jedes Projekt einzeln neu ( Rechtsklick > Neu erstellen ).
3. Erstellen Sie das Startprojekt neu.

Ich denke aus irgendeinem Grund hatte nur das Reinigen der Lösung einen anderen Effekt als das spezifische Reinigen jedes Projekts einzeln.

Bearbeiten:
Gemäß @ maplemale-Kommentar scheint es manchmal auch erforderlich zu sein, jede Referenz zu entfernen und erneut hinzuzufügen.

Update 2019:
Diese Frage hatte in der Vergangenheit viel Verkehr, aber es scheint, dass sie seit der Veröffentlichung von VS 2017 viel weniger Beachtung gefunden hat.
Ein weiterer Vorschlag wäre: Update auf eine neuere Version von VS (> = 2017) und neben anderen neuen Funktionen wird auch dieses Problem behoben

Soweit ich das beurteilen kann, geschieht dies, wenn die Projektabhängigkeiten aus irgendeinem Grund durcheinander geraten (während alle projektübergreifenden Referenzen noch intakt sind). In vielen Fällen handelt es sich NICHT um ein Codeproblem. Und für diejenigen, die mehr als ein paar Projekte haben, ist es NICHT akzeptabel, sie einzeln durchzugehen.

Es ist einfach, Projektabhängigkeiten zurückzusetzen -

1. Wählen Sie alle Projekte aus und klicken Sie mit der rechten Maustaste auf Entladen
2. Wählen Sie alle Projekte aus und klicken Sie mit der rechten Maustaste auf Neu laden
3. Lösung neu erstellen

Für diejenigen, die ein Problem in ihrem Code oder ein anderes Problem haben, das dieses Problem verursacht, müssen Sie dieses Problem natürlich zuerst lösen.

Ein möglicher Grund könnte sein, dass Sie einige Ihrer Projekte (in der Lösung) auf eine höhere Version aktualisiert haben, z. B. von .NET 4.0 auf 4.5. Dies geschah in meinem Fall, als ich die Lösung in VS 2013 öffnete (ursprünglich mit VS 2010 und .NET erstellt) 4.0). Als ich in VS 2013 öffnete, wurde mein C ++ - Projekt auf .NET 4.5 aktualisiert und ich sah das Problem.

Im Allgemeinen ist diese Art von Fehler mit menschlichen Fehlern verbunden, z. B. wenn wir den Namespace auf unangemessene Weise ändern oder Ordnernamen aus dem Explorer für das aktuelle Projekt usw. ändern, die der Compiler manchmal nicht erkennen kann.

Ich bin auf den gleichen Fehler gestoßen, um ihn zu beheben, und habe einige Schritte versucht. Bitte befolgen Sie alle Schritte:

1. Ganze Lösung reinigen
2. Klicken Sie mit der rechten Maustaste auf jedes Projekt in Ihrer Lösung. Gehen Sie zu Eigenschaften und stellen Sie Ihren Standard-Namespace sowie den Standard-Assemblynamen auf den gleichen Namen wie in Ihrem Code (dh Namespace vor Klassenname).
3. Überprüfen Sie die Ordnernamen für jedes Projekt, indem Sie den Explorer durchgehen (wo sich Ihre Projektlösung befindet). Wenn es nicht mit Ihren Projektnamen übereinstimmt, machen Sie es ihnen ähnlich (wie in Schritt 2 ).
4. Entfernen Sie alle Ihre Referenzen aus jedem Projekt, das für ein anderes Projekt derselben Lösung relevant ist, und fügen Sie es erneut hinzu.
5. In Ihrem Projektlösungsordner finden Sie die Visual c # -Projektdatei. Klicken Sie mit der rechten Maustaste und öffnen Sie mit Notepad. In Ihren ersten Zeilen finden Sie Zeilen für jedes Projekt wie folgt:

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "**Client**", "**Client** \ **Client**.csproj", "{4503E259-0E3B-414A-9074-F251684322A5}" EndProject

Überprüfen Sie die Ordnernamen erneut (ich habe sie in Fettdruck hervorgehoben) und machen Sie sie ähnlich wie in Schritt 2 .

6. Reinigen Sie die gesamte Lösung erneut

7. Erstellen Sie die Lösung (Wenn dies nicht funktioniert, versuchen Sie, sie nach der Reinigung erneut zu erstellen.)

Stellen Sie sicher, dass alle abhängigen Projekte dieselbe .NET Framework-Version verwenden. Ich hatte das gleiche Problem, das durch ein abhängiges Projekt mit 4.5.1 verursacht wurde, während alle anderen 4.5 verwendeten. Das Ändern des Projekts von 4.5.1 auf 4.5 und das Neuerstellen meiner Lösung haben dieses Problem für mich behoben.

XYZ konnte nicht gefunden werden, da es noch nicht gebaut wurde ....

Klicken Sie mit der rechten Maustaste auf die Lösung und aktivieren Sie Projektabhängigkeiten. Die Projekterstellungsreihenfolge sollte sich auch entsprechend den festgelegten Abhängigkeiten ändern.

Das einzige, was für mich funktioniert hat, war das Löschen der .suoDatei Solution User Options ( ) . Beachten Sie, dass dies eine versteckte Datei ist.

Um diese Datei zu finden, schließen Sie Ihr Virsual Studio und suchen Sie im Datei-Explorer Ihres Projekts nach .suo.

PS: Eine neue .suo-Datei wird erneut erstellt, wenn Sie Ihr Projekt neu erstellen, und hoffentlich gibt Ihnen diese neu erstellte keine Probleme.

Ich hoffe, das hilft jemandem, diesen nervigen Fehler loszuwerden :).

Meine Antwort ist nicht nur die Zusammenfassung aller Lösungen, sondern bietet auch mehr.

Abschnitt 1):

Allgemeine Lösungen:

Ich hatte 4 Fehler dieser Art ('Metadatendatei konnte nicht gefunden werden') zusammen mit 1 Fehler mit der Aufschrift 'Quelldatei konnte nicht geöffnet werden (' Nicht spezifizierter Fehler ')'.

Ich habe versucht, den Fehler "Metadatendatei konnte nicht gefunden werden" zu entfernen. Dafür habe ich viele Beiträge, Blogs usw. gelesen und festgestellt, dass diese Lösungen möglicherweise effektiv sind (hier zusammengefasst):

Starten Sie VS neu und versuchen Sie es erneut.

Gehen Sie zu 'Projektmappen-Explorer'. Klicken Sie mit der rechten Maustaste auf Lösung. Gehen Sie zu Eigenschaften. Gehen Sie zu 'Configuration Manager'. Überprüfen Sie, ob die Kontrollkästchen unter "Erstellen" aktiviert sind oder nicht. Wenn einige oder alle deaktiviert sind, überprüfen Sie sie und versuchen Sie erneut, sie zu erstellen.

Wenn die oben genannten Lösungen nicht funktionieren, befolgen Sie die in Schritt 2 oben beschriebene Reihenfolge. Deaktivieren Sie sie, aktivieren Sie sie erneut und versuchen Sie erneut, sie zu erstellen, auch wenn alle Kontrollkästchen aktiviert sind.

Build Order- und Projektabhängigkeiten:

Gehen Sie zu 'Projektmappen-Explorer'. Klicken Sie mit der rechten Maustaste auf Lösung. Gehen Sie zu 'Projektabhängigkeiten ...'. Sie sehen 2 Registerkarten: "Abhängigkeiten" und "Build-Reihenfolge". Diese Erstellungsreihenfolge ist diejenige, in der die Lösung erstellt wird. Überprüfen Sie die Projektabhängigkeiten und die Erstellungsreihenfolge, um festzustellen, ob ein Projekt (z. B. 'Projekt1'), das von einem anderen abhängig ist (z. B. 'Projekt2'), versucht, vor diesem zu erstellen (Projekt2). Dies könnte die Ursache für den Fehler sein.

Überprüfen Sie den Pfad der fehlenden DLL:

Überprüfen Sie den Pfad der fehlenden DLL. Wenn der Pfad Leerzeichen oder ein anderes ungültiges Pfadzeichen enthält, entfernen Sie es und versuchen Sie es erneut.

Wenn dies die Ursache ist, passen Sie die Erstellungsreihenfolge an.

Ich hatte dieses Problem seit Tagen! Ich habe alle oben genannten Dinge ausprobiert, aber das Problem trat immer wieder auf. Wenn diese Nachricht angezeigt wird, kann sie die Bedeutung haben, dass ein oder mehrere Projekte in Ihrer Lösung nicht sauber kompiliert wurden. Daher wurden die Metadaten für die Datei nie geschrieben. Aber in meinem Fall habe ich keinen der anderen Compilerfehler gesehen !!! Ich habe weiter daran gearbeitet, jede Lösung manuell zu kompilieren, und erst nachdem VS2012 einige Compilerfehler aufgedeckt hatte, die ich zuvor noch nicht gesehen hatte, verschwand dieses Problem.

Ich habe mit Build-Aufträgen herumgespielt, keine Build-Aufträge, auf Debug-DLLs verwiesen (die manuell kompiliert wurden) ... NICHTS schien zu funktionieren, bis ich diese Fehler fand, die beim Kompilieren der gesamten Lösung nicht auftauchten !!!!

Manchmal scheint es, dass der Compiler beim Kompilieren bei einigen Fehlern beendet wird ... Ich habe dies in der Vergangenheit gesehen, wo nach dem Beheben von Problemen nachfolgende Kompilierungen NEUE Fehler anzeigen. Ich weiß nicht, warum es passiert und es kommt eher selten vor, dass ich diese Probleme habe. Wenn Sie sie jedoch so haben, ist es ein echtes Problem, herauszufinden, was los ist. Viel Glück!

Verwenden Sie in Ihrem Projekt ein Tool zur Generierung von Datenbankcode wie SQLMETAL?

In diesem Fall stehen Sie möglicherweise vor einem Problem mit pluralisierten bis nicht pluralisierten Übergängen.

In meinem Fall habe ich festgestellt, dass einige alte pluralisierte (*) Tabellennamen (auf denen SQLMETAL standardmäßig am Ende einen " s " -Buchstaben hinzufügt ) auf Klassen verweisen, die von SQLMETAL generiert wurden.

Seitdem ich kürzlich die Pluralisierung von Namen deaktiviert habe, haben einige von ihnen nach dem erneuten Ausführen einiger datenbankbezogener Klassen ihr Präfix " s " verloren. Daher wurden alle Verweise auf betroffene Tabellenklassen ungültig. Aus diesem Grund habe ich mehrere Kompilierungsfehler wie die folgenden:

'xxxx' enthält keine Definition für 'TableNames' und es konnte keine Erweiterungsmethode 'TableNames' gefunden werden, die ein erstes Argument vom Typ 'yyyy' akzeptiert (fehlt Ihnen eine using-Direktive oder eine Assemblyreferenz?)

Wie Sie wissen, übernehme ich nur Fehler, um das Kompilieren einer Assembly zu verhindern. Und das heißt, die fehlende Assembly kann mit abhängigen Assemblys verknüpft werden, was dazu führt, dass die ursprüngliche "Metadatendatei 'XYZ' nicht gefunden wurde".

Nachdem ich betroffene Klassentabellenreferenzen manuell auf ihre aktuellen Namen korrigiert hatte (nicht pluralisiert), konnte ich mein Projekt endlich wieder zum Leben erwecken!

(*) Wenn die Option Visual Studio> Menü Extras > Optionen > Datenbanktools > O / R Designer > Pluralisierung von Namen aktiviert ist, fügt ein SQLMETALl-Codegenerator am Ende einiger generierter Tabellenklassen einen " s " -Buchstaben hinzu , obwohl die Tabelle dies hat Kein "s" -Suffix in der Zieldatenbank. Weitere Informationen finden Sie unter http://msdn.microsoft.com/en-us/library/bb386987(v=vs.110).aspx

Ich hoffe es hilft!

Ich hatte diesen Fehler. Ich habe alle Lösungen hier verfolgt, aber nichts hat funktioniert. Ich habe Visual Studio 2013 Professional verwendet. Ich konnte die einzelnen Projektumbauten nicht zum Laufen bringen und fand schließlich heraus, dass es eine gabmeine Referenzen zirkuläre Abhängigkeit aufwiesen. Visual Studio warnt Sie normalerweise ziemlich gut, wenn Sie einen Verweis auf etwas hinzufügen, das auf zurück verweist, aber aus irgendeinem Grund war dies in diesem Fall nicht der Fall. Ich habe einen Verweis auf ein Projekt hinzugefügt, der auf das Projekt verweist, an dem ich gearbeitet habe - und es hat es akzeptiert. VS Bug vielleicht?

Meine 5 Cent.

Dieses Problem begann nach einer lösungsweiten Reinigung.

Ich habe es geschafft, das Problem zu beheben, indem ich die Active Solution-Konfiguration unter: Build -> Configuration Manager zum Freigeben festgelegt habe. Erstellen Sie es dann und setzen Sie es zurück, um es erneut zu debuggen. Der Build war danach erfolgreich.

Schließen Sie VS, suchen Sie den Ordner "Pakete" und entfernen Sie ihn von außerhalb von Visual Studio. Starten Sie VS neu und erstellen Sie -> alle Abhängigkeiten werden neu installiert

Visual Studio 2019 Community 16.3.10
Ich hatte ein ähnliches Problem mit dem Release-Build. Der Debug-Build wurde ohne Probleme kompiliert. Es stellt sich heraus, dass das Problem durch OneDrive verursacht wurde. Höchstwahrscheinlich können bei einem gesicherten Laufwerk oder Cloud-Dienst ähnliche Probleme auftreten.

Ich habe alles gemäß der großartigen Antwort von Avi Turner gereinigt.

Außerdem habe ich den Ordner \ obj \ Release manuell aus meinem OneDrive-Ordner gelöscht und mich mit einem Browser bei OneDrive angemeldet und den Ordner dort auch gelöscht, um zu verhindern, dass OneDrive die Cloud-Version beim Kompilieren wieder lädt.
Danach wieder aufgebaut und alles funktionierte wie sollte.

Dies geschieht aufgrund der unterschiedlichen Namen im Ordnernamen und im Namespace-Namen. Wenn Sie einen Namespace unter einem bestimmten Namen erstellen und ihn später umbenennen, hat der Namespace den alten Namen. Und die Kompilierung nimmt den alten Pfad, um die .dllund .exe-Datei zu finden . Um dies zu vermeiden, öffnen Sie die.csproj Datei jedes Namespace mit einer Textdatei und suchen Sie den alten Pfad in der Datei.

Entfernen Sie diese, reinigen Sie die Lösung und erstellen Sie sie neu. Das hat bei mir funktioniert. Ich habe einen ganzen Tag an diesem Problem gearbeitet.

Ich hatte dies und konnte es mit dieser SO-Antwort beheben: Die Metadatendatei '.dll' konnte nicht gefunden werden

Ich musste alle Kontrollkästchen deaktivieren, auf Übernehmen klicken, alle Kontrollkästchen wieder aktivieren und dann erneut auf Übernehmen klicken, aber das Problem wurde behoben.

Ich bin gerade auf dieses Problem gestoßen und nach einer Stunde des Herumschraubens wurde mir klar, dass ich meinem Produkt eine Aspx- Datei hinzugefügt hatte, die den gleichen Namen wie eine meiner Linq-To-Sql- Klassen hatte.
Klasse und Seite wo "Warteschlange".
Die Seite wurde in QueueMgr.aspx geändert und alles wurde einwandfrei erstellt .

Bei einem neuen Build kann es sein, dass einige Abhängigkeiten nicht installiert sind. Für mich war es Crystal Reports.

Es passiert, wenn eine Projekt-DLL ausfällt und dies durch die Anzahl der Projekte referenziert wird. Korrigieren Sie es also zuerst und bauen Sie dann Einzelpersonen.

Ich hatte dieses Problem und es hat begonnen, nachdem wir unsere Lösung als neues Projekt in TFS importiert haben. Ich bin auf dieses Thema gestoßen und habe eine schnelle Lösung gefunden, die sich von Ihren Antworten inspirieren lässt.

Alles, was ich tun musste, war, das Projekt neu zu erstellen, das angeblich seine Metadatendatei und Voila verloren hat. Das Problem wurde gelöst.

Es gibt noch einen anderen dummen Grund, den Sie mit Geduld prüfen sollten ... wie mir einfiel, nachdem ich 4 Stunden lang nach Antworten gesucht hatte:

Die Geschichte für mich war, dass ich versehentlich eine kleine Codezeile unter Tausenden von Dateien der Klasse C # geändert und dann versucht habe, die Lösung neu zu erstellen. Wie Sie sich vorstellen können, fehlten mir mehr als 40 Metadatendateien und 1 Kompilierungsfehler - was ich nicht sorgfältig überprüft habe, nur weil ich dachte, dass alle Fehler gleich sind!

Nachdem ich 4 Stunden lang gesucht und dann versehentlich meine Fehlerliste überprüft hatte, fand ich diesen dummen Codefehler, behebte ihn, kompilierte ihn und dann verschwand der Fehler.

Keine gute Antwort auf Ihr Problem, aber ich hoffe, mein Fall war nicht der gleiche wie Ihr.

Ich hatte das gleiche Problem. In meinem Fall hatte ich versehentlich alle Projekte mit der Hauptmethode als Konsolenanwendung vom Projekt getrennt.

Zur Lösung ging ich zu jedem anderen Projekt als dem mit der Hauptfunktion und klickte mit der rechten Maustaste auf> Eigenschaften> Ausgabetyp> Klassenbibliothek

Es ist mir passiert, weil ich einen seltsamen Konflikt in den Namespaces habe: Ich hatte AssemblyA mit dem Namespace AssemblyA.ParentNamespace, der ClassA definiert, und in derselben Assembly einen anderen Namespace mit dem Namen AssemblyA.ParentNamespace.ChildNamespace, der eine andere ClassA definiert (aber mit dem gleicher Name)

Ich hatte dann in AssemblyA.ParentNamespace IInterfaceB eine Methode, die am Anfang IEnumerable zurückgibt, und eine ClassB-Hexe implementiert IInterfaceB

Ich hatte später die Methode in ClassB geändert, um IEnumerable zurückzugeben, aber ich habe vergessen, die IInterfaceB-Definition zu aktualisieren, sodass die dortige Methode immer noch IEnumerable zurückgab. Die lustige Tatsache war, dass die Lösung immer noch kompatibel war, wenn ich alle neu erstellte, aber die Tests mit verweist auf AssemblyA hat nicht funktioniert und gibt den Fehler "Metadatendatei konnte nicht gefunden werden" zurück.

Das Aktualisieren von InterfaceB auf die korrekte Rückgabe von IEnumerable, da der Implementierer ClassB das Problem gelöst hat. Leider war die Fehlermeldung vage und die Tatsache, dass die Kompilierung funktioniert hat, lässt vermuten, dass im Compiler möglicherweise etwas zu beheben ist

Ein Mitarbeiter stieß auf dieses Problem und die Ursache entging uns. Schließlich stellten wir fest, dass das Projektverzeichnis (und damit der Pfad zu den NuGet-Paketen) %20(danke, ein Git-GUI-Tool, das nicht benannt werden soll ) enthielt , und die Fehlermeldungen zeigten, dass der Compiler nach einem sehr ähnlich aussehenden Pfad suchte, aber nach einem das musste%20 eher ein raum. Anscheinend führt irgendwo im Build-System irgendwo eine HTML-Dekodierung für lokale Dateisystempfade durch.

Das Arbeitskopienverzeichnis wurde umbenannt und alles begann zu funktionieren.

Ich hatte auch dieses Problem.

Es begann, nachdem ich in meinem Projekt einen kleinen Ordner aufgeräumt hatte. Ich habe dann versucht zu kompilieren und habe viele doppelte Klassenfehler erhalten. (obwohl sie nicht dupliziert wurden. Ich denke, die Verknüpfung war einfach verrückt)

Wenn Sie diese überprüfen, verschwinden alle Fehler und es bleibt nur der Fehler "Metadatendatei ... debug \ application.exe konnte nicht gefunden werden".

Ich habe dieses Problem gelöst, indem ich im Build-Ausgabefenster nach den duplizierten Klassen gesucht habe.

Ich würde dann mit der rechten Maustaste auf den Klassennamen klicken und "zur Definition gehen".

Es stehen zwei Definitionen zur Auswahl, beide werden geöffnet, die zweite Definition scheint dieselbe Datei erneut zu öffnen, die zweite wird jedoch als Fehlerquelle identifiziert (rote Unterstreichung).

Löschen Sie den gesamten Code aus der Datei und speichern Sie ihn (dies hat keine Auswirkungen auf Ihre eigentliche Datei).
Dies sollte nun korrekt kompiliert werden.

Stellen Sie sicher, dass der Pfad zu Ihrem Projekt keine Leerzeichen enthält ...

Ich verwende Windows 10 mit Visual Studio Community 2019 und habe eine Multiprojektlösung wie aus einem GIT-Repo geklont. Ich hatte diesen Fehler mit allen anderen Abhängigkeiten in der Lösung zusammen mit einem E_POINTER- Fehler. Sein von GIT geerbter Pfad hatte Leerzeichen wie C: / repos / MY PROJECT NAME / ...

Ich habe es gelöscht, erneut geklont und sichergestellt, dass sein Pfad keine Leerzeichen wie C: / repos / MY_PROJECT_NAME enthält / ... enthält.

Das hat mein Problem behoben.

Ich hatte auch das gleiche Problem.

In meinem Fall habe ich kürzlich irgendwo im Projekt eine interne Klasse hinzugefügt. Eine der Abhängigkeiten in der Lösung hat denselben Klassennamen und beide werden korrekt zu Referenzen hinzugefügt.

Ich habe meine letzte Aktivität geändert und neu aufgebaut, es funktioniert.

Stellen Sie sicher, dass Ihre Compilermeldungen gültig sind. In meinem Fall erhalte ich von dort einen Referenzfehler, der nicht als Fehler in der Fehlerliste aufgeführt ist.