Fehler "Metadatendatei '… \ Release \ project.dll' wurde in Visual Studio nicht gefunden"

Vor kurzem habe ich zufällig diese Nachricht erhalten:

Die Metadatendatei '... \ Release \ project.dll' wurde in Visual Studio nicht gefunden

Ich habe eine Lösung mit mehreren Projekten. Der aktuelle Erstellungsmodus ist Debug und alle Projektkonfigurationen sind auf Debug eingestellt. Aber wenn ich versuche, das Hauptprojekt auszuführen - manchmal gibt es ein paar Fehler, die alle lauten: "Metadatendatei '... \ Release \ projectX.dll' konnte nicht gefunden werden" - und es heißt, es heißt über RELEASE Ordner, obwohl der aktuelle Modus Debug ist. Warum? Ich habe versucht, in allen Lösungsdateien nach einem Verweis auf "Release \ projectX.dll" zu suchen, und in der Datei "ResolveAssemblyReference.cache" einen gefunden.

Ich habe über das Internet gut gesucht und ein paar Leute mit einem ähnlichen Problem gefunden, aber es gab keine oder zumindest keine funktionierende Lösung.

Ich habe versucht, Verweise auf diese Projekte zu löschen und sie zu lesen, aber nach einiger Zeit werden diese Fehler erneut angezeigt.

Es scheint wie ein Fehler. Warum wird in Release-Ordnern nach referenzierten Projekten gesucht, wenn ich immer den Debug-Modus verwende?

PS. Für diejenigen, die auf dieses Problem gestoßen sind: Ich konnte es nicht einfach lösen. Es verschwand erst, nachdem ich Windows neu installiert hatte :(

Jeder hat Recht ... versuche alles ... (in der Reihenfolge, in der ein wenig bis viel Zeit verschwendet wird)

1. Hast du schlechten Code? Beheben Sie das zuerst.
2. Bereinigen Sie die Lösung und starten Sie Visual Studio neu
3. Referenzen entfernen / hinzufügen
4. Überprüfen Sie Ihren Build-Auftrag mit größeren Projekten und überprüfen Sie
5. Unterprojekte manuell neu erstellen
6. Kopieren Sie DLLs zwischen Projekten manuell in zugehörige Bin-Ordner
7. Holen Sie sich einen Kaffee, spielen Sie Flipper und kommen Sie morgen wieder ... vielleicht denken Sie in der Zwischenzeit an etwas anderes.

Ich hatte genau das gleiche Problem. Große visuelle Studiolösung mit über 50 Projekten.

Alle Referenzen wurden als Projekte hinzugefügt. Die Projekterstellungsreihenfolge war korrekt (klicken Sie mit der rechten Maustaste auf das Projekt und wählen Sie die Erstellungsreihenfolge aus).

Beim Erstellen einiger Projekte auf höherer Ebene wurde jedoch nicht das "Root" -Projekt erstellt, von dem sie abhängig waren.

Das Problem war, dass diese Projekte nicht ausgewählt wurden, um unter der aktuellen Konfiguration erstellt zu werden (ich weiß nicht, wie dies passiert ist).

Um dies zu überprüfen, wählen Sie "Configuration Manager" (Menü "Erstellen") und prüfen Sie, ob die problematischen Projekte erstellt werden sollen.

Wenn Sie sagen, Sie haben Verweise auf diese Projekte gelöscht und erneut hinzugefügt, wie haben Sie sie genau erneut hinzugefügt? Haben Sie die Registerkarte "Durchsuchen" im Dialogfeld "Referenz hinzufügen" in Visual Studio verwendet? Oder haben Sie die Registerkarte "Projekte" verwendet (auf der benachbarte Projekte in Ihrer Lösung aufgelistet sind)?

Bearbeiten : Wenn Sie die Registerkarte "Durchsuchen" verwenden und den Verweis auf Ihre DLL, die sich im Ordner / Release befindet, manuell hinzufügen, sucht Visual Studio immer nach der DLL an diesem Speicherort, unabhängig davon, in welchem ​​Modus Sie sich befinden derzeit in (Debug oder Release).

Wenn Sie die eigentliche DLL-Datei aus dem Release-Ordner entfernt haben (entweder manuell oder mit "Clean Solution"), wird Ihre Referenz unterbrochen, da die DLL nicht vorhanden ist.

Ich würde vorschlagen, den Verweis auf ProjectX.dll zu entfernen und erneut hinzuzufügen. Verwenden Sie diesmal jedoch die Registerkarte "Projekte" im Dialogfeld "Verweis hinzufügen". Wenn Sie auf diese Weise eine Referenz hinzufügen, weiß Visual Studio, wo Sie die entsprechende DLL erhalten. Wenn Sie sich im Debug-Modus befinden, wird es aus dem Ordner / Debug abgerufen. Im Release-Modus den Ordner / Release. Ihr Build-Fehler sollte behoben sein und Sie werden im Debug-Modus nicht mehr (nicht ordnungsgemäß) auf eine Release-DLL verweisen.

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') sowie 1 Fehler mit der Aufschrift 'Quelldatei konnte nicht geöffnet werden (' Nicht angegebener 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):

1. Starten Sie VS neu und versuchen Sie es erneut.

2. 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.

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

4. 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.

5. Ü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.

   ---

Sektion 2):

Mein besonderer Fall:

Ich habe alle oben genannten Schritte mit verschiedenen Permutationen und Kombinationen versucht, wobei VS einige Male neu gestartet wurde. Aber es hat mir nicht geholfen.

Also habe ich beschlossen, andere Fehler zu beseitigen, auf die ich gestoßen bin ('Quelldatei konnte nicht geöffnet werden (' Nicht spezifizierter Fehler ')').

Ich bin auf einen Blog gestoßen: http://www.anujvarma.com/tfs-errorsource-file-could-not-be-opened-unspecified-error/#comment-1539

Ich habe die in diesem Blog erwähnten Schritte ausprobiert und den Fehler 'Quelldatei konnte nicht geöffnet werden (' Nicht angegebener Fehler ')' entfernt. Überraschenderweise habe ich auch andere Fehler behoben ('Metadatendatei konnte nicht gefunden werden') .

Sektion 3):

Moral der Geschichte:

Probieren Sie alle in Abschnitt (1) oben genannten Lösungen (und alle anderen Lösungen) aus, um den Fehler zu beheben. Wenn gemäß dem in Abschnitt (2) oben genannten Blog nichts funktioniert, löschen Sie die Einträge aller Quelldateien, die nicht mehr in der Quellcodeverwaltung und im Dateisystem vorhanden sind, aus Ihrer .csproj-Datei .

Ich hatte dieses Problem schon einmal und die einzige Möglichkeit, es zu lösen, besteht darin, Clean Solution auszuführen und Visual Studio neu zu starten.

Für mich ist das Ziel-Framework normalerweise deaktiviert (4.5.2 statt 4.6). Wenn Sie das Ziel-Framework des Projekts so festlegen, dass es mit dem Ziel-Framework der Lösung übereinstimmt und erstellt wird, wird eine neue DLL erstellt.

Öffnen Sie Visual Studio erneut als Administrator.

Die meisten Antworten sagen, dass Sie die Bibliotheken Ihrer Lösung entfernen müssen. Dies ist wahr, aber wenn Sie die Bibliotheken erneut hinzufügen, wird der Fehler erneut angezeigt. Sie müssen überprüfen, ob alle Bibliotheken, auf die verwiesen wird, über ein kompatibles .net-Framework mit dem .net-Framework Ihrer Lösung verfügen. Beheben Sie dann alle Fehler in Ihrem Code und erstellen Sie die Lösung neu.

Haben Sie die Einstellungen des Konfigurationsmanagers überprüft? Im Dialogfeld Projekteinstellungen oben rechts.

Manchmal kommt es vor, dass zwischen allen Release-Einträgen ein Debug-Eintrag eingeht. In diesem Fall wird die automatische Abhängigkeit, die durch das Abhängigkeitsdiagramm der Lösung erstellt wird, verwirrt.

Ich habe diesen Fehler auch bei Lösungen gesehen, bei denen ich mehrere Projekte habe (normalerweise bei netTiers-Projekten, bei denen ich eines oder mehrere der Unterprojekte aktualisiert habe, um auf das 4.0-Framework abzuzielen). Das Entfernen kann problematisch sein. Oft kann es jedoch behoben werden, indem zuerst alle anderen Fehler in Unterprojekten (z. B. fehlende Referenzen) behoben, diese Unterprojekte einzeln neu erstellt und dann alle Verweise auf diese Unterprojekte in Visual Studio entfernt / wieder hinzugefügt werden. Persönlich hatte ich wenig Glück, diesen Fehler zu beheben, indem ich die Lösung alleine reinigte.

Dieses Problem ist kürzlich nach dem Upgrade von Office 2007 auf Office 2010 aufgetreten. Wir mussten die Verweise in unserem Projekt manuell auf Version 14 der Office Interops ändern, die wir in einigen Projekten verwenden.

Hoffe das hilft - wir haben ein paar Tage gebraucht, um es herauszufinden.

In meinem Fall wurde es durch zwei Dinge verursacht (VS.2012):

1) Eines der Projekte wurde für AnyCPU anstelle von x86 konfiguriert

2) Bei einem Projekt, auf das verwiesen wurde, wurde das Kontrollkästchen "Erstellen" deaktiviert.

Überprüfen Sie Ihren Build | Configuration Manager, um einen Überblick darüber zu erhalten, was für welche Plattform erstellt wird. Stellen Sie außerdem sicher, dass Sie sowohl Debug als auch Release überprüfen, da diese möglicherweise unterschiedliche Einstellungen haben.

In meinem Fall hatte ich einige Fehler in meinem Code. Visual Studio zeigte den Fehler an, den Sie anstelle der tatsächlichen Fehler hatten, z. B. Syntaxfehler oder unbekannte Klassennamen. Versuchen Sie, die Lösung zu reinigen und Projekt für Projekt zu erstellen. Auf diese Weise entdecken Sie die tatsächlichen Fehler.

Auch dies ist genau das, was den Fehler für mich verursacht .

Ich hatte dieses Problem und brauchte lange, um es herauszufinden. Das Problem trat auf, als ich Projekte aus der Lösung entfernte und diese durch Nuget-Pakete ersetzte.

Die Lösung schien in Ordnung zu sein, aber die .csproj-Datei enthielt diese Projekte immer noch mehrmals als Referenz.

Scheint, dass VS diese Datei nicht richtig bereinigt. Es bezog sich immer noch auf die entfernten Projekte unter der Haube. Wenn die Referenzen manuell aus der csproj-Datei entfernt werden, funktioniert alles wieder! wohoo

Dieses Problem ist auf PDF-Dateien oder CodeContracts zurückzuführen.

So lösen Sie es:

1. Bereinigen Sie Ihren Ausgabeordner und erstellen Sie die Lösung neu.

2. Konfigurieren Sie die CodeContracts neu oder deaktivieren Sie sie für die temporäre Erstellung.

Wir haben dieses Problem ziemlich oft, aber nur mit Verweisen auf C ++ / CLI-Projekte aus C # -Projekten. Es ist offensichtlich ein Fehler tief in Visual Studio, den Microsoft nicht behoben hat, weil er "zu komplex" ist und eine Überarbeitung des C ++ - Build-Systems versprochen hat, das jetzt für Visual Studio 2010 vorgesehen ist.

Das war vor einiger Zeit, und vielleicht ging das Update sogar in Visual Studio 2008 ein. Ich habe es nicht mehr weiterverfolgt. Unsere typische Problemumgehung war jedoch

• Konfiguration wechseln
• Starten Sie Visual Studio neu
• Erstellen Sie die Lösung

Ich hatte selbst das gleiche Problem.

Visual Studio 2013 hat mir nur mitgeteilt, dass es nicht darauf verweisen und die Metadaten nicht finden kann. Als ich meine Lösung öffnete (die mehrere Projekte enthält), wurde angegeben, dass ich Projekte verwendet habe, die niedriger sind als die Framework-Version eines meiner Projekte.

Also habe ich alles auf Version 4.5 umgestellt und es hat wieder funktioniert.

Ich erinnere mich an ein ähnliches Problem vor einigen Monaten. Ich habe es vorübergehend gelöst, indem ich die referenzierte DLL in den Release-Ordner kopiert habe, um die Erwartungen von Visual Studio zu erfüllen. Später entdeckte ich den Verweis auf die Release-DLL in meinem eigentlichen Code. Sie sollten versuchen, das gesamte Projekt nach \ release \ project.dll zu durchsuchen.

Außerdem ist mir aufgefallen, dass Visual Studio-Komponententestprojekte manchmal ein "DeploymentItem" -Attribut für jede der Testmethoden festlegen, die auf Ihre Ziel-DLL verweisen. Wenn Sie zwischen Debug und Release wechseln, kann Visual Studio verwirrt werden, wenn die DLL nicht mehr vorhanden ist am erwarteten Ort. Nach meiner Erfahrung können diese Attribute sicher gelöscht werden, wenn Sie sie nicht selbst als Teil eines "Einzelbereitstellungs" -Szenarios dort abgelegt haben.

Ich hatte dieses Problem und es lag an einer ungültigen Methode in der fehlerhaften Bibliothek (DLL), die keinen Wert zurückgab, z

public bool DoSomething()
{
   //I never bothered putting code here....

}

Als ich das herauskommentierte, wurde alles zusammengestellt :)

Manchmal wechselt VS2010 meine Konfiguration von einer beliebigen CPU zu einer gemischten Plattform. In diesem Fall wird diese Fehlermeldung angezeigt.

Um es zu beheben, wechsle ich zurück zu Beliebige CPU:
1. Klicken Sie mit der rechten Maustaste auf die Lösung und wählen Sie Eigenschaften aus.
2. Klicken Sie auf Konfigurationseigenschaften und dann auf die Schaltfläche Konfigurationsmanager.
3. Wählen Sie unter Active Solution Platform die Option Beliebige CPU aus

Ich finde, dass mir dies normalerweise einfällt, wenn ich noch eine Methodendeklaration in einer Schnittstelle habe, die eine Klasse implementiert, die ich aber später entfernt und vergessen hatte, sie auch von der Schnittstelle zu entfernen. Normalerweise speichere ich die gesamte Lösung alle 30 Minuten und kehre dann einfach zu einer früheren Version zurück, wenn ich den Fehler nicht finden kann.

Am Ende löschte ich meine Referenzen (ich hatte sie ordnungsgemäß über die Registerkarte "Projekte" hinzugefügt und sie wurden einwandfrei erstellt), bearbeitete meine .csproj-Dateien von Hand und entfernte bizarre Einträge, die nicht dazu gehörten - und stellte meine Ausgaben für Debug und ein release, x86 und x64 und jede CPU, die alle "\ bin" sein soll - ich habe sie einmal erstellt, dann die Referenz erneut hinzugefügt (erneut über die Registerkarte "Projekte") und alles begann wieder für mich zu funktionieren. Visual Studio musste überhaupt nicht neu gestartet werden.

Für mich wurde dies dadurch verursacht, dass das Build-Ziel neu geschrieben wurde, um die DLL nicht auszugeben. Das Problem wurde behoben, indem dies entfernt wurde, um auf das Standard-Build-Ziel zurückzugreifen.

In meinem Fall arbeitete ich an einem Zweig-Off-Master. Also habe ich den Hauptzweig ausgecheckt, einen Build ausgeführt und dann meinen Zweig ausgecheckt. Das Problem wurde behoben. Wenn Sie bereits auf Master sind, empfehle ich Ihnen, das vorherige Commit zu überprüfen und es dann zu erstellen.

Dies scheint zu passieren, wenn Sie eine Lösung mit mehreren Projekten auschecken, zwischen denen Referenzen vorhanden sind, und die Sie zuvor noch nicht erstellt haben. Wenn Sie Verweise direkt auf die DLLs haben, anstatt auf das Projekt zu verweisen, wird diese Meldung angezeigt. Sie sollten immer die Registerkarte Projekte im Dialogfeld Referenz hinzufügen verwenden, um einen Verweis auf ein Projekt in derselben Lösung hinzuzufügen. Auf diese Weise kann VS die richtige Reihenfolge für die Erstellung der Lösung ermitteln

das gleiche ist mir heute passiert, wie von Vidar beschrieben.

Ich habe einen Erstellungsfehler in einer Hilfsbibliothek (auf die von anderen Projekten verwiesen wird) und anstatt mir mitzuteilen, dass in der Hilfsbibliothek ein Fehler vorliegt, zeigt der Compiler eine Liste der vom Typ MetaFile nicht gefundenen Typfehler an. Nach der Korrektur des Build-Fehlers in der Hilfsbibliothek sind die MetaFile-Fehler verschwunden.

Gibt es in VS eine Einstellung, um dies zu verbessern?

Ich hatte das gleiche Problem. Ich habe festgestellt, dass mein Datenbankkontext (EF4), der sich in der Projekt-DLL befindet, aus irgendeinem Grund nicht erkannt wurde. Ich habe es gelöscht und stattdessen ein anderes erstellt. und das hat es für mich gelöst.

Hatte heute das gleiche Problem.

Meine Anwendung, eine Windows Forms-Anwendung, hatte versehentlich einen Verweis auf sich. Seltsam.

Nach dem Entfernen verschwand der Fehler.

Die Referenz wurde jedes Mal hinzugefügt, wenn ich ein Benutzersteuerelement im Windows Forms-Projekt selbst in ein Formular gezogen habe.

Ich hatte das gleiche Problem. Das manuelle Entfernen und Hinzufügen der DLLs hat nicht geholfen. ClassLibraries wurde nicht für alle Projekte kompiliert und fehlte im Ordner ... \ bin \ Debug für das Projekt [weil ich die Lösung versehentlich bereinigt habe]. Da die Klassenbibliothek nicht kompiliert wurde, kann es sein, dass irgendwo in einem dieser Unterprojekte Fehler auftreten .

Lösung: Da meine DLLs für den Ordner ... \ bin \ Release vorhanden waren , habe ich versucht, im Release-Modus neu zu erstellen, und in einem der Unterprojekte in einer Zeile einen Fehler gefunden. Durch Beheben des Fehlers und erneutes Erstellen der Lösung wurde der Erstellungsfehler behoben.

Für mich hatte Visual Studio einen Projektnamen.v11 vom Typ "Visual Studio Solution User Options" erstellt. Ich habe diese Datei gelöscht und neu gestartet und alles war in Ordnung.