it-swarm.com.de

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 auszukommentieren und das Projekt neu zu erstellen. Dann entkommentiere ich die Benutzersteuerelemente und alles ist in Ordnung.

Ich habe Build-Bestellungen und Abhängigkeiten überprüft.

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

Es ist sehr ärgerlich und muss kommentiert, gebaut und unkommentiert werden. Der Build wird extrem ermüdend.

543
Oliver

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

  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 es nicht finden kann, aktiviert ist. Wenn es bereits markiert ist, deaktivieren Sie das Kontrollkästchen, klicken Sie auf Anwenden und aktivieren Sie die Kontrollkästchen erneut.
690
Matt_Bro

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

Versuchen Sie außerdem, Visual Studio zu schließen und die .suo-Datei zu löschen, die sich neben der .sln-Datei befindet. (Es wird das nächste Mal generiert, wenn Sie Save all (oder Visual Studio beenden)).

Ich hatte dieses Problem, als ich der Lösung auf einem anderen Rechner neue Projekte hinzufügte und dann die Überarbeitungen zog. Die .suo-Datei kann jedoch auch in anderen Fällen beschädigt werden und zu sehr merkwürdigem Verhalten in Visual Studio führen die Dinge, die ich immer versuche. 

Beachten Sie, dass das Löschen der .suo-Datei das Startprojekt der Lösung zurücksetzt.

Mehr über die .suo-Datei finden Sie hier .

189
corvuscorax

Die vorgeschlagene Antwort hat bei mir nicht funktioniert. Der Fehler ist ein Lockvogel 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 markiert, aber das Gebäude schlug fehl ... .. Dies hätte als Fehler und nicht als Warnung angezeigt werden sollen.

122
jordan koskei

Nun, meine Antwort ist nicht nur die Zusammenfassung aller Lösungen, sondern bietet noch mehr.

Abschnitt (1):

In allgemeinen Lösungen:

Ich hatte vier Fehler dieser Art ("Metadatendatei konnte nicht gefunden werden") und einen Fehler mit der Aufschrift "Quelldatei konnte nicht geöffnet werden (" Nicht angegebener Fehler ").

Ich habe versucht, den Fehler zu beseitigen, dass die Metadatendatei nicht gefunden wurde. Dafür habe ich viele Posts, 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 'Solution Explorer' . Klicken Sie mit der rechten Maustaste auf Lösung. Gehen Sie zu Eigenschaften . Wechseln Sie zu 'Configuration Manager' . Überprüfen Sie, ob die Kontrollkästchen unter 'Build' aktiviert sind oder nicht. Wenn einige oder alle deaktiviert sind, überprüfen Sie sie und versuchen Sie es erneut.

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

  4. Auftragserstellung und Projektabhängigkeiten:

    Gehen Sie zu 'Solution Explorer' . Klicken Sie mit der rechten Maustaste auf Lösung. Gehen Sie zu 'Projektabhängigkeiten ...' . Sie sehen zwei Registerkarten: 'Abhängigkeiten' und 'Erstellungsreihenfolge' . 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. 'project1'), das von einem anderen abhängig ist (z. B. 'project2'), versucht, vor diesem Projekt (project2) zu erstellen. 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 ein 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.


Abschnitt (2):

Mein besonderer Fall:

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

Daher habe ich mich entschlossen, andere Fehler zu beseitigen, auf die ich gestoßen bin ('Quelldatei konnte nicht geöffnet werden (‘Nicht angegebener Fehler’)').

Ich bin auf einen Blogeintrag gestoßen: TFS-Fehler - Quelldatei konnte nicht geöffnet werden (‘Nicht angegebener Fehler’)

Ich habe die in diesem Blogbeitrag genannten Schritte ausprobiert und den Fehler 'Quelldatei konnte nicht geöffnet werden (' Nicht spezifizierter Fehler ')' und behoben überraschenderweise habe ich auch andere Fehler beseitigt ('Metadatendatei konnte nicht gefunden werden') .


Abschnitt (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 nichts funktioniert, löschen Sie gemäß dem in Abschnitt (2) oben erwähnten Blog die Einträge aller Quelldateien, die nicht mehr in der Quellcodeverwaltung und im Dateisystem vorhanden sind aus Ihrer .csproj-Datei.

94
Vikram

In meinem Fall wurde dies durch einen Konflikt der .NET Framework-Version verursacht.

Ein Projekt war 3.5 und das andere Referenzprojekt 4.6.1.

33
Eric Schneider

Das Schließen und erneute Öffnen von Visual Studio 2013 hat für mich funktioniert!

23
Roffers

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

Es schien mir offensichtlich, dass diese falsche Metadatendatei-Referenz irgendwo aufbewahrt werden muss.

Eine schnelle Suche in der .csproj-Datei zeigte die Schuldzeilen. Ich hatte einen Abschnitt namens <itemGroup>, der an den 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. Finden Sie die falschen Pfade in der .csproj-Datei und benennen Sie sie entsprechend um.

Bitte stellen Sie sicher, dass Sie eine Sicherungskopie Ihrer alten .csproj erstellen, bevor Sie .

16
Alex Stephens

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

13
user1678541

Ich habe den gleichen Fehler "Metadatendatei '.dll' konnte nicht gefunden werden", und ich habe einige der oben beschriebenen Dinge ausprobiert, aber der Grund für den Fehler war, dass ich auf eine Drittanbieter-Datei DLL verwies, die auf ein Ziel gerichtet war .NET-Version höher als mein Projekt für .NET-Version. Die Lösung bestand also darin, das Zielgerüst meines Projekts zu ändern.

13
Mladen Nikolov

Ich fügte meiner Lösung ein neues Projekt hinzu und fing an, dies zu erhalten. 

Der Grund? Das Projekt, das ich mitbrachte, bezog sich auf ein anderes .NET-Framework (4.6 und meine anderen zwei waren 4.5.2). 

10
Todd Vance

In meinem Fall habe ich mein Installationsverzeichnis falsch angelegt.

Wenn Ihr Lösungspfad so etwas wie "Mein Projekt% 2c Sehr beliebt% 2c Unit Testing% 2c Software und Hardware.Zip" ist, kann die Metadatendatei nicht aufgelöst werden. Möglicherweise sollten einige ungültige Wörter wie% 2c verhindert werden.

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

10
masphei

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

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

Ich habe wie alle anderen Bibliotheken auf Version 4.5.2 umgestellt, und es hat funktioniert.

9
Andre Mesquita

Ich zog mir auch die Haare aus diesem Problem, aber nachdem ich die vorherigen Antworten ausprobiert hatte, funktionierte das einzige, was für mich funktionierte, darin, jedes Projekt in meiner Lösung 1 für 1 zu öffnen und es einzeln zu bauen.

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

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

8
prospector

Für mich funktionierten folgende Schritte: 

  • Suchen Sie das Projekt, das nicht erstellt wird
  • Entfernen/Hinzufügen von Referenzen zu Projekten in der Lösung.
8

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

Lösung: Benennen Sie jedes Problem in Project um - fügen Sie einfach einen Buchstaben oder etwas anderes hinzu - und benennen Sie ihn dann in seinen ursprünglichen Namen zurück.

Dies muss einen gewissen globalen Cache in Visual Studio zurücksetzen, da dadurch sowohl dieses Problem als auch einige ähnliche behoben werden, während mit Clean nicht verfahren werden kann.

8
Chris Moschini

Meine Instanz des Problems wurde durch ein gemeinsames Projekt verursacht, das einen doppelten Klassennamen (unter einem anderen Dateinamen) enthielt. Es ist merkwürdig, dass Visual Studio das nicht erkennen konnte und stattdessen den Build-Prozess explodierte.

7
Eric

Ich habe dieses Problem in Visual Studio 2012 in einer Lösung mit vielen Projekten erhalten. Wenn Sie jedes Projekt in der Projektmappe manuell in derselben Reihenfolge wie die Projekterstellungsreihenfolge neu erstellen (mit der rechten Maustaste klicken und im Projektmappen-Explorer neu erstellen), wurde das Problem behoben.

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

7
dan-gph

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

fehler CS0067: Das Ereignis 'XYZ' wird nie verwendet

dass aus irgendeinem Grund nicht im Fehlerfenster angezeigt wurde.

Aus diesem Grund schien das Build-System von Visual Studio den Fehler zu übersehen und versuchte, abhängige Projekte zu erstellen, die wiederum mit der lästigen Metadaten-Nachricht fehlschlugen.

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

Schauen Sie sich zuerst Ihr Ausgabefenster an !

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

6
Heinz Kessler

Ich hatte auch den gleichen Fehler. Der Pfad, auf den ich mich für die Datei DLL bezog, ist wie "D:\Assemblies Folder\Assembly1.dll".

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

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

Die Lösung befindet sich in Stack Overflow-Frage Wie ersetze ich alle Leerzeichen durch% 20 in C #?.

5
Arun Prasad

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

Ich habe einfach .Net-Version meines Klassenbibliotheksprojekts (dasjenige, das den Build defekt hatte) identisch mit der .Net-Version des referenzierten Projekts gesetzt und das Problem wurde gelöst.

5
Code_Worm

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

5
David Ford

Einige Jahre später ist dies ein Problem, das höchstwahrscheinlich auf die maximale Pfadbegrenzung von Windows zurückzuführen ist:

Benennen von Dateien, Pfaden und Namespaces, Beschränkung der maximalen Pfadlänge

5
Oliver

Es sieht so aus, als würden solche Fehler mit der Tatsache 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 sich um einen Syntaxfehler oder etwas anderes handeln. Um solche Probleme zu lösen, sollten Sie häufig die Ursache des Problems finden (schauen Sie sich beispielsweise das Build-Protokoll an).

In meinem Fall bestand das Problem tatsächlich darin, dass das Error List-Fenster keine Fehler zeigte. Aber wirklich gab es Syntaxfehler; Ich habe diese Fehler im Output-Fenster gefunden, und nachdem sie behoben wurden, wurde das Problem behoben.

5
burzhuy

Dieser Fehler kann angezeigt werden, wenn Sie gefälschte Baugruppen verwenden. Das Entfernen von Fälschungen führt zum erfolgreichen Erstellen des Projekts.

4
FLCL

Ich verwende Visual Studio 2013.

Es scheint, dass die Build-Abhängigkeiten falsch waren. Durch das Löschen der * .suo-Dateien wurden meine Probleme behoben.

4
DrBB

Für meinen Fall war es so, dass ich Klassen in einem bestimmten (leeren) Namespace auskommentiert hatte:

namespace X.Y.Z.W
{

    // Class code

}

Wenn ich den Namespace-Code und die Importbefehle (unter Verwendung von) entfernt habe, wurde das Problem behoben.

Im Build heißt es auch - zusammen mit der fehlenden DLL -Datei des Projekts:

fehler CS0234: Der Typ- oder Namensraumname 'W' ist im Namensraum 'X.Y.Z' nicht vorhanden (fehlt eine Assemblyreferenz?)

4

Dieser Fehler ist aufgetreten, als ich eine Webanwendung veröffentlichen wollte. Es stellte sich heraus, dass eine der Eigenschaften einer Klasse eingeschlossen war

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

aber die objektnutzung war nicht. Die Veröffentlichung erfolgte offensichtlich in Release-Konfiguration ohne das Symbol DEBUG.

4
Dmitri Trofimov

Wenn sich in Ihrem Lösungsnamen ein Leerzeichen befindet, wird das Problem ebenfalls verursacht. Wenn Sie das Leerzeichen aus dem Namen Ihrer Lösung entfernen, sodass Pfad% 20 nicht enthält, wird dies gelöst. 

4
Ajaco

Weisen Sie einfach auf das offensichtliche Offensichtliche hin: Wenn Sie "Ausgabefenster beim Start des Builds anzeigen" nicht aktiviert haben, stellen Sie sicher, dass Sie feststellen, ob Ihr Build fehlschlägt (kleiner Fehler "Build fehlgeschlagen" links unten) !!!!

4
tbone

Ich habe diese Fehlermeldung erhalten, nachdem ich ein Projekt geöffnet hatte, in dem auf Entity Framework verwiesen wurde. Deshalb habe ich diese Verweise gelöscht und Entity Framework Version 6.0.0.0 über den Acket-Manager folgendermaßen neu installiert:

install-package entityframework -version 6.0.0.0

Der Fehler wurde immer noch angezeigt, also dachte ich, dass diese Verweise vorhanden waren, weil eine ältere Version von Entity Framework angeblich "vorinstalliert" wurde, aber es funktionierte nicht wirklich.

Also ging ich zur Datei packages.config und bemerkte, dass es eine andere Referenz gab:

<packages>
  **<package id="EntityFramework" version="5.0.0" targetFramework="net45" />**
  <package id="EntityFramework" version="6.0.0" targetFramework="net45" />
</packages>

Dann löschte ich die Zeile, bereinigte und baute das Projekt und die Containerlösung neu auf, und es funktionierte schließlich.

3
CoderRoller

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

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

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

3
JaredPar

In meinem Fall wurden diese Fehler durch eine Beschädigung des Paketmanagers von NuGet verursacht. Unterprojekte der Lösung wurden nicht erstellt, aber aufgrund der Metadatenfehler wurden keine Fehler angezeigt.

Sobald alle NuGet-Pakete korrigiert wurden, konnte das Projekt wieder ordnungsgemäß erstellt werden.

3
Nick

Ich hatte das gleiche Problem. In meinem Fall wurde das Projekt immer noch im Freigabemodus erstellt, und gerade als ich versuchte, Debuggen einzubauen, schlug es fehl.

Um das Problem zu beheben, kopierte ich einfach alle DLLs (und andere Dateien aus meinem Freigabeordner) in meinen Debug-Ordner. Nachdem dies für jedes Projekt erledigt war, waren die Fehler verschwunden.

3
Jack Fairfield

Das Entfernen des packages-Ordners mit NuGet im Lösungsordner funktionierte für mich. Nach dem Umbau funktionierte alles wieder. Überprüfen Sie References in der Projektmappe und suchen Sie nach Verweisen mit einem gelben Dreieck.

Beispielbild:

 Enter image description here

3
Ogglas

In meinem Fall hatte ich diesen Fehler, weil eines meiner Projekte eine andere .NET Framework-Version als die anderen der Lösung verwendete. Ich habe den NuGet-Paketmanager verwendet, um NLog zu installieren. Ich denke, es wurde für die .NET-Version dieses Projekts installiert.

Ich habe alle Lösungen aus diesem Beitrag ausprobiert, aber keine hat funktioniert. Ich entfernte NLog, säuberte die Lösung und trid zum Kompilieren: Gleiche Sache, CS006-Fehler.

Als ich alle Dateien in obj\Debug aus diesem Projekt löschte, kompilierte die Lösung.

Ich hatte ein ähnliches Problem, als ich eine sehr alte Bibliothek dekompilierte, die in einer Produktionsumgebung bereitgestellt wurde, aber der Quellcode verloren ging.

Ich nahm .dll, dekompilierte und erstellte Projekte und Lösungen. Ich konnte die Lösung aufgrund mehrerer Fehler dieser Art nicht erstellen.

Tipps in vorherigen Antworten haben nicht geholfen, aber nach einiger Zeit bemerkte ich, dass in einigen Projekten Verweise auf mehrere Assemblys wie System.dll vorhanden waren.

Angenommen, Projekt A ist von Projekt B abhängig. In Projekt B gab es keinen Verweis auf System.dll, aber der Fehler nach dem Erstellen war wie "Metadatendatei 'B.dll' wurde nicht gefunden".

Es ist kein Fehler wegen fehlender System.dll in Projekt B aufgetreten.

Durch das Hinzufügen von Verweisen auf Bibliotheken wie System.dll in Projekt B wurde das Problem gelöst .. (System.Data, System.DirectoryServices usw.).

3
drfaka

Ich hatte eine Klasse in 4.6.1 referenziert, eine Schnittstelle, die in 4.6.2 war.

3
Antonin GAVREL

In meinem Fall waren einige Projekte in der Lösung auf Any CPU ausgerichtet, einige auf x86. Der Kompilierungsfehler verschwand nach der Vereinheitlichung des Plattformziels in der Lösung.

3
Tomas Kubes

In meinem persönlichen Fall war es mir nicht gelungen, einen Verweis auf eines der Projekte in der Lösung hinzuzufügen. Dies war der Grund, warum der Fehler für mich ausgelöst wurde.

2
Jon D

In meinem Fall war es ReSharper dumm zu sein, und obwohl mein Projekt auf C # 6 abzielte, wurden mir Refactorings angeboten, um nur C # 7-Funktionen zu verwenden.

Aus diesem Grund habe ich diesen Code geändert,

private DateTime? _joinedDate;
[Column(TypeName = "DateTime2")]
public DateTime JoinedDate
{
    get { return _joinedDate ?? DateTime.Now; }
    set { _joinedDate = value; }
}

in diesen Code:

private DateTime? _joinedDate;
[Column(TypeName = "DateTime2")]
public DateTime JoinedDate
{
    get => _joinedDate ?? DateTime.Now;
    set => _joinedDate = value;
}

Aus irgendeinem Grund veranlasste der Getter und Setter, der Ausdruckskörper verwendet, den Metadatenfehler anstelle eines Syntaxfehlers.

2
Mathieu VIALES

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

2
wtjones

aaaaaund sechs Jahre später während eines Upgrades auf Visual Studio 2015 das gleiche Problem. Da diese spezielle Lösung nicht in dieser Liste enthalten ist, füge ich sie hinzu.

Zwei referenzierte DLLs befanden sich im Ordner c:\windows\system32 ... ... Sie in einen Nicht-Systemordner zu verschieben und einen Verweis auf den neuen Ordner hinzuzufügen, wurde endgültig behoben. Der Rest der Fragen war in der Tat das, was andere hier schon gesagt haben

2

Die Ursache des Problems kann darin bestehen, dass Sie in der Lösung Verweise auf DLL - Dateien und -Projekte hinzugefügt haben.

Wenn Sie Projekte A, B und C haben:

  • A referenziert B und C als Projekte in der Lösung.
  • B verweist auf C als DLL -Datei (Verweis auf eine Datei).

Sie können jedes Projekt separat erstellen, aber Sie können keine Lösung mit der Endung neu erstellen: Die Metadatendatei 'C.dll' wurde nicht gefunden.

Das Ändern der Referenz von einer Datei in ein Projekt in der Lösung hilft.

2
Liero

Wie Benutzer @burzhuy darauf hinweist, kann es wichtig sein, das Fenster Output und nicht nur das Fenster Error List zu betrachten.

In meinem Fall arbeitete ich daran, Modifikationen am Roslyn Compiler vorzunehmen. In den Build-Projekten wird zusätzlich geprüft, ob die öffentlichen Felder mit der als öffentliche Schnittstelle des Compilers definierten Einheit übereinstimmen. Andernfalls wird ein Fehler RS0016 oder RS0017 erzeugt. Ich hatte ein paar öffentliche Felder hinzugefügt und den RS0016-Fehler behoben, indem der Mauszeiger über den Fehler gefahren wurde und "Zu öffentlicher API hinzufügen" ausgewählt wurde.

Später änderte ich meine Meinung und verlegte die öffentlichen Bereiche in eine andere Klasse. Aus irgendeinem Grund führte dies zu einer "Metadaten-Datei, die nicht gefunden werden konnte", und je mehr ich damit herumfummelte, desto mehr Fehler bekam ich.

Sie müssen die korrekte PublicAPI.Unshipped.txt-Datei (in meinem Fall in E:\Roslyn\32414\src\Compilers\Core\Portable) suchen und sie manuell bearbeiten, um die nicht mehr relevanten Zeilen zu entfernen.

1
RenniePet

In meinem Fall erhielt ich diese Fehlermeldung aus dem einfachen Grund, dass nach dem Abrufen der neuesten Version des Projekts von TFS das falsche Projekt in der Lösung als Startprojekt markiert wurde. Das richtige Projekt als Startup-Projekt zu wählen, hat dies für mich gelöst.

1
Joe Dyndale

Wow, es scheint, als könnte dieser Fehler von überall her kommen.

Jedenfalls habe ich meiner MVC-Anwendung einen neuen WebAPI-Controller hinzugefügt, der automatisch alle Referenzen von NuGet erhielt. Ein wenig später entfernte ich die Referenzen von der NuGet-Benutzeroberfläche, aber ich vergaß, die Dateien mit diesen zu löschen (d. H. System.Http).

Aus irgendeinem Grund bestand der Fehler, den ich erhielt, zusammen mit einer einfachen Warnung, dass eine Variable nicht verwendet wurde.

Ich habe die Variable auskommentiert, um zumindest die Warnung loszuwerden, und der Wiederaufbau zeigte mich aus allen Dateien, die die nicht vorhandene Referenz verwendeten. Nach dem Löschen dieser Dateien lief alles in Ordnung.

1
Alexander D

Ich stand vor diesem Problem. In meinem Fall wurden mehrere C # -Projekte als DLL -Dateien referenziert. Jeder Fehler bei der Kompilierung in einem Projekt, das als DLL -Datei (in anderen Projekten) verwendet wird, führt zu einer Fehlerflut. Der Grund ist, dass der Fehler beim Kompilieren die Erstellung der entsprechenden DLL -Datei verhindert. Dies führt zu einer Reihe von Fehlern in Projekten, die sich auf die fehlende DLL -Datei beziehen.

Wenn Sie daher im Projektmappen-Explorer eine Neuerstellung durchführen (wobei die geringfügigen Fehler bei der Kompilierzeit ignoriert werden), tritt eine Reihe von "Metadaten-Dateien .dll konnte nicht gefunden werden" (und Sie werden der Meinung, dass Sie einen anderen Fehler gemacht haben als eine einfache Neuerstellung).

Wenn Sie mit diesem Problem konfrontiert sind, besteht die beste Lösung darin, die Lösung zu bereinigen und dann jedes Projekt einzeln zu erstellen, um herauszufinden, welches Projekt den Fehler auslöst.

1
josepainumkal

Dieses Problem kann aufgrund eines Syntaxfehlers in Ihrem Code auftreten, der aufgrund des Metadatenfehlers möglicherweise nicht für Sie sichtbar ist. Überprüfen Sie Ihre Quelldatei, bevor Sie eine der Aktionen in den vorherigen Antworten ausführen.

1
Hassan Malik

Ich habe herausgefunden, dass Sie diesen Fehler erhalten, wenn Sie Microsoft.CSharp Assembly als Referenz im Projekt entfernen.

1
Mirek

Mein Problem kam, als ich c # 7-Code schrieb, das Projekt jedoch eine ältere Version für das .net-Framework verwendete 

1
Abdullah Tahan

Dieser Fehler ist in Visual Studio 2015 aufgetreten, als ich die Typanmerkung aus einem Aufruf an eine Erweiterungsmethode entfernte, die nur die leeren spitzen Klammern hinterließ.

Anstelle von obj.extensionMethod<Type>() hatte ich obj.extensionMethod<>().

Ich würde dies als einen Fehler in Visual Studio klassifizieren, da ich nicht sehe, wie dieser Fehler diesen Fehler erzeugen kann.

1
mschwaig

Für mich bestand das Problem darin, dass zwei Visual Studio-Fenster geöffnet waren, mein Projekt in einem Fenster mit Debugging ausgeführt wurde und ich versuchte, es in einem anderen Fenster zu erstellen.

Ich musste aufhören zu debuggen und ließ mich dann erfolgreich bauen.

Ich habe alle oben nur einen Unterschied zugestimmt. In meinem Fall: Ich verwende Visual Studio 2019. Ich habe VS-2019 geschlossen und mit VS-2017 geöffnet. und das Projekt neu aufbauen alles funktioniert super! Für wen ist in meiner Position Datum: 19.04.2013

1
dewelloper
  1. Klicken Sie mit der rechten Maustaste auf die Lösung und klicken Sie auf Bereinigen.
  2. Klicken Sie mit der rechten Maustaste auf die Lösung und klicken Sie auf "Neu erstellen".

In meinem Fall habe ich dieses Problem gelöst, nachdem ich festgestellt hatte, dass ich ein .Net Framework 4.7-Projekt als Abhängigkeit von einem .Net Framework 4.6.1-Projekt referenziert hatte. Nach der Migration von Projekt 4.7 auf 4.6.1 wurde meine Anwendung normal kompiliert

0
Alexandre Lima

Überprüfen Sie die .csproj-Datei des Hauptprojekts. Visual Studio bereinigt dies nicht, wenn Sie Projekte entfernen oder Verweise in der Projektmappe ändern.

Ich hatte alte Projekte dreimal in der .csproj-Datei referenziert, und beim Kompilieren wurde dieser Fehler den entfernten Projekten angezeigt.

0
Tarmo Elfving

Ich habe diesen Fehler gesehen, weil ich die folgende Zeile in meinem Code hatte (sieht so aus, als würde ich immer noch im SQL-Modus nachdenken):

if(myVar is null)
    DoSomething();

Visual Studio (2017) hat keine Fehler bei der Entwurfs- oder Kompilierzeit gemeldet, das Projekt wurde jedoch nicht erstellt und der Fehler "fehlende .dll" ausgegeben. Beim Ändern der fehlerhaften Zeile in:

if(myVar == null)

Das Problem wurde gelöst.

0
Gavimoss

In meinem Fall hatte ich auch einige andere Build-Fehler (einige einfache Typumwandlungen) und ich kratzte am Kopf, um das Problem zu lösen, und konzentrierte mich nicht auf die anderen Fehler.

Was schließlich mein Problem gelöst hat, war, dass ich alle anderen Build-Fehler behoben habe und dann erneut bauen und erfolgreich bauen konnte.

Falls Sie andere Build-Fehler zusammen mit fehlendem DLL -Dateifehler haben und nichts anderes für Sie funktioniert, versuchen Sie, zuerst die anderen Fehler zu beheben und dann die Lösung erneut zu erstellen.

0

Keine der Dutzenden Antworten funktionierte bisher für mich. In meinem Fall bekam ich auch den Fehler:

Der Tupel-Elementname 'Value' wird abgeleitet. Bitte verwenden Sie die Sprachversion 7.1 oder höher, um auf ein Element über seinen abgeleiteten Namen zuzugreifen

Neben dem Fehler "Metadaten-Datei '.dll' konnte nicht gefunden werden 'wurden beim Erstellen Fehler angezeigt, die jedoch kurz darauf verschwanden, da Fehler manchmal auftreten, wenn IDE" aufholt ".

Doppelklicken Sie auf den Fehler, um ihn zu finden, und entfernen Sie den fehlerhaften Code, um ihn zu beheben.

Andernfalls können Sie dies in Visual Studio versuchen:

Menü Projekt → <Projektname> Eigenschaften Build → Taste Erweitert Sprachversion C # <neueste untergeordnete Version> (zB " C # 5,0 ")

Und das behebt das auch.

Es sieht so aus, als ob "Metadaten-Datei '.dll' nicht gefunden werden konnte" oft ein Symptom für einige andere zugrunde liegende Probleme. Wenn keine der Top-Lösungen für Sie geeignet ist, überprüfen Sie andere Fehler und Warnungen und versuchen Sie, das eigentliche Problem zu finden.

0
MGOwen

Ich hatte das gleiche Problem und eine andere Lösung.

Das Problem: Eine Lösung, mehrere Projekte. Die Hauptanwendung, die einige der anderen Ergebnisse verwendet, schlug fehl:

CSC: Fehler CS0006: Die Metadatendatei 'C:\Repos\TheApplication\TheApplicationCommon\bin\Debug\TheApplication.dll' wurde nicht gefunden

Dieses Projekt generierte jedoch C:\Repos\TheApplication\TheApplicationCommon\bin\Debug\TheApplicationCommon.dll Ein anderes Projekt, das dieselbe DLL verwendet, die fehlerfrei kompiliert wurde.

Bevor ich ein internes NuGet-Paket aktualisiert habe, das PostSharp 3.x.x.x und jetzt PostSharp 4.x.x.x verwendet. Und meine Lösung bestand darin, dies meiner * .csproj-Datei hinzuzufügen:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="...">
  <Import Project="..." Condition="..." />
  <PropertyGroup>
    ...
    <AssemblyName>TheApplication</AssemblyName>
    ...
    <SkipPostSharp>True</SkipPostSharp> <!-- This line -->
  </PropertyGroup>
...

Eine andere Lösung-> Clean, eine andere Lösung-> Rebuild und es funktioniert lokal und auf dem Build-Server.

Hoffe es hilft jemandem. Der Thread ist alt und ziemlich lang, aber dieses Problem kehrt häufig zurück und ich habe diese Lösung noch nicht gesehen. Übrigens mit Visual Studio 2017 (15.8.x).

0
ecth

Das Löschen der Ordner bin/obj und das anschließende Neuerstellen des Projekts haben bei mir funktioniert.

In meinem Fall ist meiner Meinung nach beim ersten Erstellen des Projekts ein Laufzeitfehler aufgetreten, sodass meine DLL-Datei nicht generiert wurde.

Dies geschah, wenn auf ein Projekt von einem anderen verwiesen wurde. Das Projekt, auf das ich mich bezog, war das mit dem Problem.

0
npineda

Viele dieser Antworten klingen nach Versuch und Irrtum. In meinem Fall war es jedoch einfach: Die referenzierte DLL wurde an diesem bestimmten Ort nicht gefunden.

Wenn Sie die Build-Fehler sehen, in der Regel in diesem Fall, beschwert sich der Build über viele DLLs. Der Schlüssel ist, die richtige DLL zu finden, die fehlt. In meinem Fall hatte eines der Projekte in meiner Lösung eine direkte DLL-Referenz anstelle einer Projektreferenz. Daher musste ich das Projekt erstellen, das die DLL ausgibt, bevor ich die fehlerhafte Lösung erstellte, um sicherzustellen, dass die fehlerhafte Lösung die fehlende DLL an diesem bestimmten Speicherort findet.

Wow ... das war einfach, aber ziemlich schwer in Worte zu fassen.

0

In meinem Fall änderte meine Web.config-Datei dies 

<?xml version="1.0" encoding="utf-8"?>

zu diesem

<?xml version="1.0"?>

mein Problem behoben

0
Elnoor

In meinem Fall passierte es mir, als ich auf NuGet-Pakete lokal verwies und deren Verzeichnis an einen anderen Ort verschob, ich änderte den Pfad in NuGet.Config, aber leider stellte ich fest, dass ich die .csproject-Dateien manuell ändern sollte, um den Referenzpfad zu aktualisieren, aber die Fehlermeldung CS0006 war weit davon entfernt, dieses Problem zu beschreiben. Im Allgemeinen kommt es auch vor, dass ein Verweis auf DLL nicht gefunden wurde. Um das Problem zu identifizieren, das beim Durchsuchen Ihrer Verweise im Projekt auftritt, finden Sie einige Verweise mit einem entsprechenden Warnsymbol Versuchen Sie, diese zu beheben, und es sollte wie erwartet funktionieren.

0
Ali Ezzat Odeh

Ich habe dieses Problem nach dem Befehl getting latest (Team Foundation Server (TFS)) festgestellt.

Nach dem Lösen der Konflikte fand ich eine Anweisung für einen namespace that does not exist in the project.

Also entfernte ich die using-Anweisung und dann clean and rebuild, und alles war in Ordnung.

0

Wenn ich einen Build erstellt habe, werden in Visual Studio 2017 normalerweise Fehler wie diese angezeigt:

Error   CS0006  Metadata file 'C:\src\ProjectDir\MyApp\bin\x64\Debug\Inspection.exe' could not be found MyApp   C:\src\ProjectDir\MyApp\CSC 1   Active

Aber manchmal wird ein Fehler wie dieser für ein paar Sekunden angezeigt und dann verschwindet er und wechselt wieder zur obigen Meldung:

Error   CS1503  Argument 1: cannot convert from 'MyApp.Model.Entities.Asset' to 'MyApp.Model.Model.Entities.Inspection' MyApp   C:\src\ProjectDir\MyApp\ViewModels\AssetDetailsViewModel.cs 1453    Active

Ich habe also viel Zeit damit verbracht, den ersten Fehler zu beheben, aber das eigentliche Problem war auf den zweiten Fehler zurückzuführen. Zuerst musste ich alle Verzeichnisse/bin und/obj löschen, dann löschte ich auch die .suo-Dateien wie oben angegeben. Dadurch konnte ich das Problem auf ein Schnittstellenproblem eingrenzen.

In meiner Oberfläche hatte ich Folgendes:

    Task<IList<Defect>> LoadDefects(Asset asset);

Bei meiner tatsächlichen Implementierung hatte ich jedoch folgenden Code:

    public virtual async Task<IList<Defect>> LoadDefects(Inspection inspection)
    {
       var results ...
       // ....

        return results;
    }

Der Build wurde erfolgreich abgeschlossen, nachdem ich die Schnittstelle folgendermaßen aktualisiert hatte:

    Task<IList<Defect>> LoadDefects(Inspection inspection);

Es scheint also, als hätte das Zwischenspeichern in VS dazu geführt, dass der CS0006-Fehler weiterhin angezeigt wurde, wenn das eigentliche Problem der CS1503-Fehler war.

0
user8128167

Keine der vorherigen Lösungen funktionierte für mich, also werde ich mitteilen, was gemacht wurde.

Ich hatte dieses Problem, nachdem ich einige neue Klassenbibliotheken aus einem anderen Zweig zusammengefügt hatte, die sich auf einander bezogen hatten. Durch das Löschen der Verweise in den Projekten und das erneute Erstellen wurde das Problem endgültig behoben. Offenbar hatte Visual Studio die falschen Dateipfade zusammengeführt.

0
Nick Van Brunt

Für mich war das Problem ein Fehler, der nicht in der Build-Ausgabe auftrat. Ich hatte nämlich zwei Utility-Klassen, die sich anfangs in unterschiedlichen Namespaces befanden. Ich habe den Namensraum des zweiten so geändert, dass er mit dem ersten übereinstimmt (ohne zu wissen, dass es im ersten eine weitere Utility-Klasse gab), und dann begann dieser Fehler aufzutreten. 

Ich stelle mir den Build-Ausgabefehler vor, weil die Logic Layer-Bibliothek DLL nicht erstellt werden konnte und die Hauptanwendung sie nicht finden konnte.

Die Lösung bestand darin, die zweite Utility-Klasse in einen anderen Namespace zu ändern, und dann begannen die echten Build-Fehler einzudringen. Nach dem Aussortieren lief der Build gut.

Wenn eine der vorherigen Lösungen für Sie nicht funktioniert, haben Sie möglicherweise Fehler im Code unterdrückt, die von Visual Studio nicht angezeigt werden. Versuchen Sie daher, die Codierungsschritte erneut zu verfolgen und nach Unregelmäßigkeiten zu suchen.

PS: Dies war in der Visual Studio 2015 Community Edition

0
Remus.A

Ich hatte dieses Problem, nachdem ich die Lösung häufig geändert hatte, die Änderungen zurückgestellt und rückgängig gemacht hatte.

Der einzige Weg, das Problem zu lösen, bestand darin, die Zuordnung von TFS zu meinem lokalen Ordner zu entfernen und erneut hinzuzufügen.

0
NoHero

Dieses Problem kann auftreten, weil Sie Funktionen verwenden, die von der für das Projekt ausgewählten Version von . Net nicht unterstützt werden.

In meinem Fall war der Grund, warum ich den Operator ?? verwendet habe, um auf Null zu prüfen und eine Ausnahme auszulösen.

Seltsamerweise informiert VS nicht über den tatsächlichen Grund des Problems in der Liste der Erstellungsfehler.

Sie finden diese Informationen jedoch in den Ausgabe Protokollen des Builds.

0
Alex Valchuk

Sehr eigenartig! Ich habe alle vorherigen Antworten ausprobiert und leider hat in meinem Fall nichts funktioniert.

Ich bin auf zwei Fehler gestoßen:

  1. Fehlende DLL-Datei
  2. Methode bereits an anderer Stelle mit den gleichen Parametern definiert

Ich habe den zweiten Fehler zuerst behoben, indem ich die an anderer Stelle duplizierte Funktion entfernt habe.

Mein erster Fehler - das ist die .dll-Datei, die es alleine gelöst hat.

Ich möchte sagen, wenn Sie mehr als einen einzelnen Fehler zusammen mit dem fehlenden .dll-Dateifehler haben, versuchen Sie zunächst, die anderen Fehler zu beheben. Möglicherweise löst der .dll-Fehler es von alleine! 

0
A user

In meinem Fall löste das Festlegen des Zielframeworks das Problem:

  1. Klicken Sie mit der rechten Maustaste auf das Projekt und wählen Sie Eigenschaften aus.

  2. Ändern Sie in ApplicationTarget Framework wie das Hauptprojekt (z. B. ".NET Framework 4.5").

0
Hamid

Das Visual Studio IDE erstellt keine Gebäude hinter den Kulissen, die Anwendung Msbuild. Der VS IDE erstellt im Wesentlichen nur die Projektdatei, die von Msbuild verwendet wird, und macht häufig Fehler, wenn Sie es den IDE überlassen, die Dinge selbst herauszufinden. Wenn Sie den Metadata file '.dll' could not be found-Fehler erhalten, liegt dies wahrscheinlich daran, dass die richtigen/erwarteten Assemblys nicht gefunden werden. Vielleicht erstellt Visual Studio möglicherweise eine Projektdatei für eine 4.5-Framework-App und erwartet 4,5 Assemblys, während Sie auf 4.0-Assemblys verweisen. Schauen Sie sich die Einstellungen in Visual Studio auf Inkompatibilitäten an, oder gehen Sie selbst in die Projektdatei, und korrigieren Sie sie manuell, indem Sie den richtigen Pfad <Reference Include="C:\\correct path to Assembly\\yourAssembly.dll" /> angeben.

0
annoying_squid