Die Metadatendatei '.dll' wurde nicht gefunden

Ich arbeite an einem WPF, C # 3.0-Projekt und erhalte folgende Fehlermeldung:

Error 1 Metadata file
'WORK=- \Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug
\BusinessLogicLayer.dll' could not be found C:\-=WORK=- \Tools
\VersionManagementSystem\VersionManagementSystem\CSC VersionManagementSystem

So verweise ich auf meine Benutzersteuerungen:

xmlns:vms="clr-namespace:VersionManagementSystem"
<vms:SignOffProjectListing Margin="5"/>

Es passiert nach jedem fehlgeschlagenen Build. Die einzige Möglichkeit, die Lösung zum Kompilieren zu erhalten, besteht darin, alle meine Benutzersteuerelemente zu kommentieren und das Projekt neu zu erstellen. Dann kommentiere ich die Benutzersteuerelemente aus und alles ist in Ordnung.

Ich habe Konfigurationen für Build-Aufträge und Abhängigkeiten überprüft.

Wie Sie sehen können, scheint es den absoluten Pfad der DLL-Datei abgeschnitten zu haben ... Ich habe gelesen, dass es einen Fehler mit der Länge gibt. Ist das ein mögliches Problem?

Es ist sehr nervig und muss kommentieren, bauen und kommentieren, der Build wird extrem lästig.

Ich hatte gerade das gleiche Problem. Visual Studio erstellt nicht das Projekt, auf das verwiesen wird.

Schriftliche Anweisungen:

1. Klicken Sie mit der rechten Maustaste auf die Lösung und klicken Sie auf Eigenschaften.
2. Klicken Sie links auf Konfiguration.
3. Stellen Sie sicher, dass das Kontrollkästchen unter "Erstellen" für das Projekt, das nicht gefunden werden kann, aktiviert ist. Wenn es bereits aktiviert ist, deaktivieren Sie es, klicken Sie auf Übernehmen und aktivieren Sie die Kontrollkästchen erneut.
4. (Optional) Sie mussten dies sowohl für den Release- als auch für den Debug-Modus für die Lösungseigenschaften tun.

Anleitung zur Bildschirmaufnahme:

• Man sagt, ein Bild sagt mehr als tausend Worte. Klicken Sie auf das GIF, um es zu vergrößern. Hoffentlich ist es einfach zu folgen:

Dies kann in neueren Versionen von Visual Studio immer noch passieren (ich hatte es gerade in Visual Studio 2013):

Sie können auch versuchen, Visual Studio zu schließen und die .suoDatei neben der .slnDatei zu löschen . (Es wird beim nächsten Mal Save all(oder beim Beenden von Visual Studio) neu generiert .)

Ich hatte dieses Problem beim Hinzufügen neuer Projekte zur Lösung auf einem anderen Computer und beim anschließenden Abrufen der Revisionen, aber die .suoDatei kann auch in anderen Fällen beschädigt werden und zu einem sehr seltsamen Verhalten von Visual Studio führen. Daher ist das Löschen eine der folgenden Dinge, die ich immer versuche.

Beachten Sie, dass durch das Löschen der .suoDatei die Startprojekte der Lösung zurückgesetzt werden.

Mehr zur .suoDatei finden Sie hier .

Die vorgeschlagene Antwort hat bei mir nicht funktioniert. Der Fehler ist ein Köder für ein anderes Problem.

Ich fand heraus, dass ich auf eine etwas andere Version von .NET abzielte, und dies wurde vom Compiler als Warnung gekennzeichnet, aber es führte dazu, dass das Erstellen fehlschlug. Dies sollte als Fehler und nicht als Warnung gekennzeichnet sein.

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

Abschnitt 1):

Allgemeine Lösungen:

Ich hatte vier Fehler dieser Art ('Metadatendatei konnte nicht gefunden werden') sowie einen Fehler mit der Meldung '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 Visual Studio neu und versuchen Sie es erneut.

2. Gehen Sie zu 'Projektmappen-Explorer' . Klicken Sie mit der rechten Maustaste auf Lösung. Gehe 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 zwei 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 zu überprüfen, 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 und Visual Studio einige Male neu gestartet. 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-Beitrag gestoßen : TFS-Fehler - Quelldatei konnte nicht geöffnet werden ('Nicht angegebener Fehler')

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

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 .

In meinem Fall wurde dies durch eine Nichtübereinstimmung der .NET Framework-Version verursacht.

Ein Projekt war 3.5 und das andere Referenzprojekt 4.6.1.

Das Schließen und Wiedereröffnen von Visual Studio 2013 hat bei mir funktioniert!

Nun, nichts in den vorherigen Antworten hat für mich funktioniert, also habe ich darüber nachgedacht, warum ich klicke und hoffe, wann wir als Entwickler wirklich versuchen sollten, zu verstehen, was hier vor sich geht.

Mir schien klar, dass diese falsche Referenz für Metadatendateien irgendwo gespeichert werden muss.

Eine schnelle Suche in der .csproj-Datei zeigte die Schuldlinien. Ich hatte einen Abschnitt namens <itemGroup>, der an dem alten falschen Dateipfad zu hängen schien.

<ItemGroup>
    <ProjectReference Include="..\..\..\MySiteOld\MySite.Entities\MySite.Entities.csproj">
        <Project>{5b0a347e-cd9a-4746-a3b6-99d6d010a6c2}</Project>
        <Name>Beeyp.Entities</Name>
    </ProjectReference>
...

Also wirklich eine einfache Lösung:

1. Sichern Sie Ihre .csproj-Datei.
2. Suchen Sie die falschen Pfade in der .csproj-Datei und benennen Sie sie entsprechend um.

Bitte stellen Sie sicher, dass Sie Ihre alte .csproj sichern, bevor Sie fummeln .

Ich habe auch dieses Problem getroffen. Zunächst müssen Sie Ihr DLL-Projekt manuell erstellen, indem Sie mit der rechten Maustaste auf Erstellen klicken. Dann wird es funktionieren.

In meinem Fall habe ich mein Verzeichnis falsch installiert.

Wenn Ihr Lösungspfad etwa "Mein Projekt% 2c Sehr beliebt% 2c Unit Testing% 2c Software und Hardware.zip" lautet, kann die Metadatendatei nicht aufgelöst werden. Vielleicht sollten wir einige ungültige Wörter wie% 2c verhindern.

Das Umbenennen des Pfads in einen normalen Namen hat mein Problem behoben.

Ich habe den gleichen Fehler "Metadatendatei '.dll' konnte nicht gefunden werden" erhalten und verschiedene oben beschriebene Versuche unternommen. Der Grund für den Fehler war jedoch, dass ich auf DLL-Dateien von Drittanbietern verwies, die auf eine höhere .NET-Version abzielten dass mein Projekt Ziel .NET-Version. Die Lösung bestand also darin, das Ziel-Framework meines Projekts zu ändern.

Visual Studio 2019 das hat bei mir funktioniert:

1. Schließen Sie Visual Studio
2. Löschen Sie den versteckten .vsOrdner
3. Öffnen Sie Visual Studio erneut und erstellen Sie die Lösung neu.

Für mich wurde versucht, eine DLL in einem Pfad zu finden, der das Projekt enthielt, aber wir hatten sie in ein neues Verzeichnis verschoben. Die Lösung hatte den richtigen Pfad zum Projekt, aber Visual Studio suchte irgendwie weiter am alten Speicherort.

Lösung: Benennen Sie jedes Problemprojekt um - fügen Sie einfach ein Zeichen oder was auch immer hinzu - und benennen Sie es dann wieder in seinen ursprünglichen Namen um.

Dies muss einen globalen Cache in Visual Studio zurücksetzen, da dies sowohl dieses als auch einige ähnliche Probleme behebt, während Dinge wie "Clean" dies nicht tun.

Ich habe meiner Lösung ein neues Projekt hinzugefügt und damit begonnen.

Der Grund? Das Projekt, das ich einbrachte, zielte auf ein anderes .NET-Framework ab (4.6 und meine anderen beiden waren 4.5.2).

Für mich ist es passiert, als ich ein neues Projekt in eine Lösung aufgenommen habe.

Visual Studio wählt automatisch .NET Framework 4.5 aus.

Ich habe wie die anderen Bibliotheken auf Version .NET 4.5.2 umgestellt und es hat funktioniert.

Bei mir haben folgende Schritte funktioniert:

• Suchen Sie das Projekt, das nicht erstellt wird
• Entfernen / Hinzufügen von Verweisen auf Projekte in der Lösung.

Ich habe mir auch mit diesem Problem die Haare ausgezogen, aber nachdem ich die vorherigen Antworten ausprobiert hatte, war das einzige, was für mich funktioniert hat, jedes Projekt in meiner Lösung 1 nach 1 zu öffnen und sie einzeln zu erstellen.

Dann habe ich Visual Studio 2013 geschlossen, meine Lösung erneut geöffnet und sie wurde gut kompiliert.

Es ist seltsam, denn wenn ich in meinem Projektmappen-Explorer auf jedes Projekt geklickt und versucht habe, es auf diese Weise zu erstellen, sind alle fehlgeschlagen. Ich musste sie alleine in ihren eigenen Lösungen öffnen.

Es sieht nach solchen Fehlern aus, die damit zusammenhängen, dass Visual Studio keine korrekten Informationen zu einem Fehler liefert. Der Entwickler versteht nicht einmal den Grund für den fehlgeschlagenen Build. Es kann ein Syntaxfehler oder etwas anderes sein. Um solche Probleme zu lösen, sollten Sie häufig die Wurzel des Problems finden (siehe beispielsweise das Build-Protokoll).

In meinem Fall war das Problem tatsächlich, dass das Error ListFenster keine Fehler zeigte. Aber es gab wirklich Syntaxfehler; Ich habe diese Fehler im OutputFenster gefunden und nachdem ich sie behoben hatte, wurde das Problem behoben.

Meine Instanz des Problems wurde durch ein allgemeines Projekt verursacht, das einen doppelten Klassennamen enthielt (unter einem anderen Dateinamen). Es ist seltsam, dass Visual Studio dies nicht erkennen konnte und stattdessen nur den Erstellungsprozess in die Luft jagte.

Ich habe dieses Problem in Visual Studio 2012 in einer Lösung mit vielen Projekten erhalten. Das manuelle Neuerstellen jedes Projekts in der Lösung in derselben Reihenfolge wie die Projekterstellungsreihenfolge (Rechtsklick und Neuerstellung im Projektmappen-Explorer) hat es für mich behoben.

Schließlich kam ich zu einem, der mir einen Kompilierungsfehler gab. Ich habe den Fehler behoben und die Lösung wurde danach korrekt erstellt.

In meinem Fall bestand das Problem darin, dass ich eine Nicht-Kompilierungsdatei, die als "fehlend" markiert war, manuell gelöscht hatte. Nachdem ich den Verweis auf die jetzt fehlende Datei gelöscht und neu kompiliert hatte, war alles in Ordnung.

Wenn Ihr Lösungsname ein Leerzeichen enthält, verursacht dies ebenfalls das Problem. Wenn Sie den Speicherplatz aus Ihrem Lösungsnamen entfernen, damit der Pfad nicht% 20 enthält, wird dies behoben.

Wenn wir einige Jahre später darauf zurückkommen, hängt dieses Problem höchstwahrscheinlich mit der maximalen Pfadbeschränkung von Windows zusammen:

Benennen von Dateien, Pfaden und Namespaces , maximale Pfadlängenbeschränkung

In meinem Fall wurde das Problem durch einen einfachen Erstellungsfehler verursacht.

Fehler CS0067: Das Ereignis 'XYZ' wird niemals verwendet

das wurde aus irgendeinem Grund nicht im Fehlerfenster angezeigt.

Aus diesem Grund schien das Visual Studio-Buildsystem den Fehler zu übersehen und versuchte, abhängige Projekte zu erstellen, was wiederum mit der nervigen Metadatenmeldung fehlschlug.

Die Empfehlung ist - so dumm es auch klingen mag -:

Schauen Sie sich zuerst Ihr Ausgabefenster an !

Es dauerte eine halbe Stunde, bis mich diese Idee traf ...

Ich hatte auch den gleichen Fehler. Es versteckt sich wie im folgenden Pfad. Der Pfad, auf den ich für die DLL-Datei verwiesen habe, lautet "D: \ Assemblies Folder \ Assembly1.dll".

Der ursprüngliche Pfad, auf den sich die Assembly bezog, war "D: \ Assemblies% 20Folder \ Assembly1.dll".

Aufgrund dieser Variation des Pfadnamens konnte die Assembly nicht aus ihrem ursprünglichen Pfad abgerufen werden und löst daher den Fehler "Metadaten nicht gefunden" aus.

Die Lösung finden Sie in der Frage zum Stapelüberlauf. Wie ersetze ich alle Leerzeichen in C # durch% 20? .

Ich hatte das gleiche Problem. In meinem Fall habe ich auf ein Klassenbibliotheksprojekt mit einer höheren .NET-Version als mein Projekt verwiesen, und VS konnte das Projekt nicht erstellen und hat denselben Fehler ausgelöst, den Sie veröffentlicht haben.

Ich habe einfach die .Net-Version meines Klassenbibliotheksprojekts (die, die den Build beschädigt hat) identisch mit der .Net-Version des referenzierten Projekts festgelegt und das Problem gelöst.

Ich möchte nur auf das Offensichtliche hinweisen: Wenn Sie das Kontrollkästchen "Ausgabefenster beim Start des Builds anzeigen" nicht aktiviert haben, stellen Sie sicher, dass Sie feststellen, ob Ihr Build fehlschlägt (kleiner Fehler "Build fehlgeschlagen" unten links).

Ich hatte diesen Fehler, als ich versuchte, eine Webanwendung zu veröffentlichen. Es stellte sich heraus, dass eine der Eigenschaften einer Klasse eingeschlossen war

#if DEBUG
    public int SomeProperty { get; set; }
#endif

aber die Eigentumsnutzung war nicht. Die Veröffentlichung erfolgte DEBUGoffensichtlich in der Release-Konfiguration ohne das Symbol.

Aufgrund der Fehlermeldung glaube ich nicht, dass der Dateipfad abgeschnitten wird. Es scheint einfach falsch zu sein. Wenn ich die Nachricht richtig lese, scheint sie nach der DLL-Datei zu suchen unter ...

WORK = - \ Tools \ VersionManagementSystem \ BusinessLogicLayer \ bin \ Debug \ BusinessLogicLayer.dll

Dies ist kein gültiger Pfad. Ist es möglich, dass Sie im Erstellungsprozess eine Makrodefinition auf einen ungültigen Wert gesetzt haben?

Ich hatte dieses Problem, weil .nuget\NuGet.exees nicht in meinem Repository enthalten war. Obwohl ich DownloadNuGetExein NuGet.targets aktiviert habe, wurde beim Herunterladen ein Proxy-Fehler gemeldet. Dies führte dazu, dass der Rest der Projektbuilds fehlschlug.

Dieser Fehler wird möglicherweise angezeigt, wenn Sie gefälschte Baugruppen verwenden. Das Entfernen von Fälschungen führt zu einem erfolgreichen Aufbau des Projekts.