"Typ oder Namespace-Name konnte nicht gefunden werden", aber alles scheint in Ordnung zu sein?

Ich bekomme ein:

Typ- oder Namespace-Name konnte nicht gefunden werden

Fehler für eine C # WPF-App in VS2010. Dieser Codebereich wurde einwandfrei kompiliert, aber plötzlich wird dieser Fehler angezeigt. Ich habe versucht, die Projektreferenz und die usingAnweisung zu entfernen , VS2010 zu schließen und neu zu starten, aber ich habe immer noch dieses Problem.

Irgendwelche Ideen, warum dies passieren könnte, wo es so aussieht, als würde ich das Richtige in Bezug auf Referenz und usingAussage tun ?

Ich habe auch in VS2010 festgestellt, dass Intellisense für diesen Namespace in Ordnung ist. Es scheint also, dass VS2010 die Projektreferenz hat und den Namespace auf der einen Seite sieht, aber beim Kompilieren nicht?

Dies kann das Ergebnis einer Inkompatibilität der .NET Framework-Version zwischen zwei Projekten sein.

Es kann auf zwei Arten geschehen:

1. ein Kundenprofilprojekt, das auf ein vollständiges Framework-Projekt verweist; oder
2. Eine ältere Framework-Version, die auf eine neuere Framework-Version abzielt

Dies ist beispielsweise der Fall, wenn eine Anwendung auf das .Net 4-Clientprofil-Framework ausgerichtet ist und das Projekt, auf das sie verweist, auf das vollständige .Net 4-Framework abzielt.

Um das klarer zu machen:

• Projekt A zielt auf das Client-Profil-Framework ab
• Projekt A verweist auf Projekt B.
• Projekt B zielt auf den gesamten Rahmen ab

In diesem Fall besteht die Lösung darin, entweder das Framework-Ziel der Anwendung (Projekt A) zu aktualisieren oder das Ziel der referenzierten Assembly (Projekt B) herunterzustufen. Es ist in Ordnung, dass eine vollständige Framework-App auf eine Clientprofil-Framework-Assembly verweist / diese verwendet, jedoch nicht umgekehrt (das Client-Profil kann nicht auf eine vollständige Framework-zielgerichtete Assembly verweisen).

Beachten Sie, dass Sie diesen Fehler auch erhalten können, wenn Sie ein neues Projekt in VS2012 oder VS2013 erstellen (das .Net 4.5 als Standardframework verwendet) und:

• Die referenzierenden Projekte verwenden .Net 4.0 (dies ist häufig der Fall, wenn Sie von VS2010 auf VS2012 oder VS2013 migriert sind und dann ein neues Projekt hinzufügen.)

• Die Projekte, auf die verwiesen wird, verwenden eine größere Version, z. B. 4.5.1 oder 4.5.3 (Sie haben Ihre vorhandenen Projekte auf die neueste Version ausgerichtet, VS erstellt jedoch weiterhin neue Projekte für Version 4.5 und verweisen dann auf diese älteren Projekte aus dem neues Projekt)

Die Neuinstallation von Nuget-Paketen hat mir geholfen. Nachdem ich die .NET Framework-Versionen so geändert hatte, dass sie für alle Projekte synchron sind, wurden einige der Nuget-Pakete (insbesondere Entity Framework) noch für frühere Versionen installiert. Dieser Befehl in der Packages Manager Console installiert Pakete für die gesamte Lösung neu:

Update-Package –reinstall

Ich habe keine Ahnung, warum dies funktioniert hat, aber ich habe die Projektreferenz, die VS2015 mir mitteilte, dass sie nicht gefunden werden konnte, entfernt und erneut hinzugefügt. Problem gelöst. Ich hatte versucht, VS zu reinigen, zu erstellen und neu zu starten, ohne Erfolg.

Beim Erstellen der Lösung wurde der gleiche Fehler angezeigt (Typ oder Namespace '' konnte nicht gefunden werden). Darunter sah ich eine Warnung , die besagte , dass "die Referenz nicht aufgelöst werden konnte" und dass "die Assembly auf der Festplatte vorhanden ist".

Ich war sehr verwirrt, weil sich meine DLL sehr deutlich an der Stelle befand, auf die die Referenz zeigte. VS schien keine Fehler hervorzuheben, bis ich versuchte, die Lösung zu erstellen.

Endlich wurde mir das Problem klar (oder zumindest, was ich vermute, war das Problem). Ich habe die Bibliotheksdatei in derselben Lösung erstellt. Obwohl es auf der Festplatte vorhanden war, wurde es an diesem Speicherort neu erstellt (irgendwie wurde während der Neuerstellung der Bibliothek mein anderes Projekt - in derselben Lösung -, das auf die Bibliothek verwies, entschieden, dass die Bibliothek nicht vorhanden war).

Als ich mit der rechten Maustaste auf das Projekt geklickt und nur das anstelle der gesamten Lösung erstellt habe, wurde der Fehler nicht angezeigt.

Um dieses Problem zu beheben, habe ich die Bibliothek als Abhängigkeit zu dem Projekt hinzugefügt, das sie verwendet hat.

Um dies zu tun:

1. Ich habe im Projektmappen-Explorer mit der rechten Maustaste auf meine Lösung geklickt und "Eigenschaften" ausgewählt.
2. Dann habe ich in "Allgemeine Eigenschaften" "Projektabhängigkeiten" ausgewählt.
3. Dann habe ich im Dropdown-Menü Projekte das Projekt ausgewählt, das auf der Bibliothek basiert, und
4. Aktivierte das Kontrollkästchen neben der Bibliothek unter "Abhängig von".

Dadurch wird sichergestellt, dass das Bibliotheksprojekt zuerst erstellt wird.

Zuerst würde ich überprüfen, ob die generierten Informationen Ihres Projekts nicht beschädigt sind. Reinigen Sie Ihre Lösung und bauen Sie sie neu auf.

Wenn das nicht hilft, habe ich in der Vergangenheit bei Designerproblemen gesehen, dass ein Windows Forms-Projekt geöffnet und dann wieder geschlossen wird. Dies ist jedoch ein wenig Hühnchen-Eingeweide, also halten Sie nicht den Atem an.

Eine schwierigere Situation, in die ich geraten bin, war: Projekt 1 zielt auf das 4.0-Vollframework mit Microsoft.Bcl.Asyncinstalliertem Paket ab. Projekt zwei zielt auf das vollständige 4.0-Framework ab, wird jedoch nicht kompiliert, wenn auf eine Project one-Klasse verwiesen wird.

Nachdem ich das Async NuGet-Paket im zweiten Projekt installiert hatte, wurde es einwandfrei kompiliert.

In meinem Fall finde ich, dass die Referenz im VisualStudio ein Dreieck und ein Ausrufezeichen als dieses Bild hat.

Dann klicke ich mit der rechten Maustaste auf Entfernen und füge die DLL-Referenz wieder korrekt hinzu. Das Problem wurde behoben.

Dieser hat für mich gearbeitet. Entfernen Sie in Ihrer Klasse, in der der Klassenname definiert ist, z. B.: Öffentliche Klasse ABC, ein Zeichen und warten Sie ein wenig. Ihre Fehlerliste wird vergrößert, weil Sie den Namen geändert haben. Setzen Sie nun das eingegebene Zeichen zurück. Das hat bei mir funktioniert, hoffentlich auch bei Ihnen. Viel Glück!!!

Ich hatte ein ähnliches Problem: Der Compiler konnte keinen Ordner innerhalb desselben Projekts erkennen , sodass eine mit diesem Ordner verknüpfte using-Direktive einen Fehler verursachte. In meinem Fall ist das Problem auf das Umbenennen des Ordners zurückzuführen . Obwohl ich den Namespace aller Klassen in diesem Ordner aktualisiert habe, konnten die Projektinformationen irgendwie nicht aktualisiert werden. Ich habe alles versucht: Löschen der .suo-Datei und der Ordner bin und obj, Bereinigen der Lösung, erneutes Laden des Projekts - nichts hat geholfen. Ich habe das Problem behoben, indem ich den Ordner und die darin enthaltenen Klassen gelöscht, einen neuen Ordner erstellt und neue Klassen in diesem neuen Ordner erstellt habe (das einfache Verschieben der Klassen in den neuen Ordner hat nicht geholfen).

PS: In meinem Fall habe ich an einer Webanwendung gearbeitet, aber dieses Problem kann bei verschiedenen Arten von Projekten auftreten.

[Facepalm] Mein Problem war, dass ich die Abhängigkeit in der C ++ - Vorgehensweise hinzugefügt hatte.

Wechseln Sie zu dem Projekt, das nicht erstellt werden soll, öffnen Sie den Ordner "Referenzen" im Projektmappen-Explorer und prüfen Sie, ob Ihre Abhängigkeit aufgeführt ist.

Wenn nicht, können Sie 'Referenz hinzufügen' und die Abhängigkeit auf der Registerkarte Projekte auswählen.

Boom Shankar.

Wir hatten einen seltsamen Fall, den ich gerade in einer Lösung behoben habe. Vor einer "using" -Anweisung im Hauptprojekt stand ein verstecktes / Leerzeichen. Dieses Projekt würde gut funktionieren und die Website würde gut funktionieren, aber das Unit-Test-Projekt, auf das verwiesen wurde, konnte nicht erstellt werden.

Dieses Problem ist beim Upgrade vorhandener Projekte von VS2008 auf VS2012 aufgetreten. Ich stellte fest, dass zwei Projekte (die einzigen zwei, die ich erstellt habe) auf unterschiedliche .NET Frameworks (3.5 und 4.0) abzielten. Ich habe dies auf der Registerkarte "Anwendung" der Projekte behoben, indem ich sichergestellt habe, dass beide Projekte ".NET Framework 4" im Feld "Ziel-Framework" enthalten.

Hatte die gleichen Fehler, meine Geschichte war folgende: Nach dem schlechten Zusammenführen (über Git) hatte eine meiner .csproj-Dateien doppelte compileEinträge wie:

<Compile Include="Clients\Tree.cs" />
<Compile Include="Clients\Car.cs" />
<Compile Include="Clients\Tree.cs" />        //it's a duplicate

Wenn Sie eine große Lösung und mehr als 300 Meldungen im Fehlerfenster haben, ist es schwierig, dieses Problem zu erkennen. Also habe ich eine beschädigte .csproj-Datei über den Editor geöffnet und doppelte Einträge entfernt. Hat in meinem Fall funktioniert.

Ich hatte das gleiche Problem wie besprochen: VS 2017 unterstreicht eine Klasse in einem referenzierten Projekt als Fehler, aber die Lösung ist in Ordnung und sogar Intellisense funktioniert.

So habe ich es geschafft, dieses Problem zu lösen:

1. Entladen Sie das referenzierte Projekt
2. Öffnen Sie die .proj-Datei in VS (ich habe nach Duplikaten gesucht, wie hier vorgeschlagen).
3. Projekt erneut laden (Ich habe die Projektdatei nicht geändert oder gar gespeichert, da ich keine Duplikate hatte)

Sie können auch versuchen, den Code zu entfernen , mit dem Sie Probleme haben, und prüfen, ob er ohne Verweise auf diesen Code kompiliert wird. Wenn nicht, beheben Sie die Probleme , bis sie erneut kompiliert werden, und arbeiten Sie dann Ihren vermuteten Problemcode wieder ein. Manchmal erhalte ich seltsame Fehler bei Klassen oder Methoden, von denen ich weiß, dass sie korrekt sind, wenn der Compiler etwas anderes nicht mag. Sobald ich das Problem behoben habe, an dem es wirklich hängen bleibt, verschwinden diese "Phantom" -Fehler.

Ich weiß, dass dies ein totes Pferd tritt, aber ich hatte diesen Fehler und die Rahmenbedingungen waren in Ordnung. Mein Problem bestand im Grunde darin, dass eine Schnittstelle nicht gefunden werden konnte, aber dennoch gut erstellt und darauf zugegriffen werden konnte. Also musste ich mir denken: "Warum nur diese Schnittstelle, wenn andere gut funktionieren?"

Es endete damit, dass ich tatsächlich über WCF auf einen Dienst mit einer Endpunktschnittstelle zugegriffen habe, die Entity Version 6 verwendete, und die übrigen Projekte Version 5 verwendeten. Anstatt NuGet zu verwenden, habe ich die Nuget-Pakete einfach zur Wiederverwendung in ein lokales Repository kopiert listete sie anders auf.

zB EntityFramework6.dll versus EntityFramework.dll .

Ich habe dann die Verweise auf das Client-Projekt und den Poof hinzugefügt, mein Fehler ist verschwunden. Mir ist klar, dass dies ein Randfall ist, da die meisten Leute keine Versionen von Entity Framework mischen werden.

Hinzufügen meiner Lösung zum Mix, weil es etwas anders war und ich eine Weile gebraucht habe, um es herauszufinden.

In meinem Fall habe ich einem Projekt eine neue Klasse hinzugefügt, aber da meine Versionskontrollbindungen nicht festgelegt waren, musste ich die Datei außerhalb von Visual Studio (über die VC) beschreibbar machen. Ich hatte das Speichern in Visual Studio abgebrochen, aber nachdem ich die Datei außerhalb von VS beschreibbar gemacht hatte, drückte ich in VS erneut auf Alle speichern. Dies führte versehentlich dazu, dass die neue Klassendatei nicht im Projekt gespeichert wurde. Intelisense zeigte sie jedoch immer noch als blau und gültig in den referenzierenden Projekten an, obwohl beim Versuch, die Datei neu zu kompilieren, die Datei nicht gefunden wurde und die bekam Typ nicht gefunden Fehler. Das Schließen und Öffnen von Visual Studio zeigte immer noch das Problem (aber wenn ich zur Kenntnis genommen hatte, fehlte die Klassendatei beim erneuten Öffnen).

Als ich dies erkannte, war das Update einfach: Wenn die Projektdatei beschreibbar eingestellt war, las ich die fehlende Datei in das Projekt. Alles baut sich jetzt gut auf.

Ich hatte das gleiche Problem. Eines Nachts würde mein Projekt am nächsten Morgen ERRORS! Kompilieren.

Ich fand schließlich heraus, dass Visual Studio beschlossen hatte, einige meiner Referenzen zu "optimieren" und sie an anderer Stelle zu verweisen. beispielsweise:

System.ComponentModel.ISupportInitialize wurde irgendwie zu "blahblah.System.ComponentModel.ISupportInitialize"

Ziemlich unhöflich für vs zu tun, wenn Sie als ich

Das Ereignis findet in Visual Studio 2017 statt.

1. Starten Sie Visual Studio neu
2. Sauberes Projekt, das nicht erstellt werden kann.
3. Erstellen Sie das Projekt neu.

Mein Fall war der gleiche wie hier besprochen, aber nichts hat ihn gelöst, bis ich den entfernt habe System.Core Referenz aus der Referenzliste (ohne sie hat alles gut funktioniert).

Ich hoffe, es wird jemandem helfen, da dieses Problem ziemlich frustrierend ist

Um dieses Problem zu beheben, kann es auch hilfreich sein, die *.sln.DotSettingsDatei der zugehörigen Lösung zu löschen und neu zu erstellen .

In meinem Fall hatte ich eine Klasse, die im richtigen Quellordner aufgeführt war, sich aber nicht im Projektmappen-Explorer registrierte. Ich musste mit der rechten Maustaste auf das Projekt> Vorhandenes Element hinzufügen klicken und manuell die Klasse auswählen, die fehlte. Dann hat alles gut funktioniert!

In meinem Fall bestand das Problem darin, dass nach dem Ändern des Namespace in genau das gleiche wie in einem anderen Projekt (absichtlich) auch der Name der Assembly von VS geändert wurde, sodass zwei Assemblys mit demselben Namen übereinander standen

In meinem Fall hatte ich eine Datei, die durch externe Abhängigkeit (xsd2code) erstellt wurde, und irgendwie wurden die designer.cs-Dateien von VS nicht korrekt verarbeitet. Das Erstellen einer neuen Datei in Visual Studio und das Einfügen des Codes haben den Trick für mich getan.

Für jeden, der diesen Fehler erhält, wenn er versucht, seine Website in Azure zu veröffentlichen, hat mir keine der oben genannten vielversprechend aussehenden Lösungen geholfen. Ich saß im selben Boot - meine Lösung war von selbst gut gebaut. Am Ende musste ich

1. Entfernen Sie alle Nuget-Pakete in meiner Lösung.
2. Schließen Sie meine Lösung und öffnen Sie sie erneut.
3. Fügen Sie alle Nuget-Pakete erneut hinzu.

Ein wenig schmerzhaft, aber nur so konnte ich meine Website in Azure veröffentlichen.

Beim Versuch, einen Build mit einem Build von Visual Studio Team Services zu erstellen, der auf meinem lokalen Computer als Agent ausgeführt wird, ist dieser Fehler aufgetreten.

Es funktionierte in meinem regulären Arbeitsbereich einwandfrei und ich konnte die SLN-Datei im Agentenordner lokal öffnen und alles in Ordnung kompilieren.

Die betreffende DLL wurde im Projekt als gespeichert Lib/MyDLL.DLLund verweist darauf in der csproj-Datei:

<Reference Include="MYDLL, Version=2009.0.0.0, Culture=neutral, PublicKeyToken=b734e31dca085caa">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>Lib\MYDLL.dll</HintPath>
</Reference>

Es stellte sich heraus, dass die Datei trotz des Hinweispfads buchstäblich nicht gefunden wurde. Ich denke, vielleicht hat msbuild relativ zur SLN-Datei statt zur Projektdatei gesucht.

Could not resolve this reference. Could not locate the assemblyStellen Sie in jedem Fall sicher, dass sich die DLL an einem für msbuild zugänglichen Ort befindet, wenn die Nachricht, die Sie erhalten , lautet.

Ich habe irgendwie geschummelt und eine Nachricht gefunden, die besagt, Considered "Reference\bin\xxx.dll"und stattdessen einfach die DLLs dort kopiert.

In meinem Fall ergab das Hinzufügen der DLL als Referenz den type or namespace name could not be foundFehler. Das Kopieren und Einfügen der DLL-Datei direkt in den Ordner bin hat den Fehler jedoch behoben.

Keine Ahnung warum das funktioniert hat.

Ich weiß, dass dieser Thread alt ist, aber ich teile ihn trotzdem. Ich muss alle Abhängigkeiten des dritten Teils der importierten Assembly installieren - da die importierte Assembly nicht als Nuget-Paket enthalten war, fehlten ihre Abhängigkeiten.

Hop diese Hilfe :)

In meinem Fall hatte ich zwei Projekte in einer Lösung. Ich habe dem referenzierten Projekt einen Sub-Namespace hinzugefügt. Beim Erstellen habe ich jedoch nicht bemerkt, dass die Erstellung des referenzierten Projekts fehlgeschlagen ist, und es wurde die letzte erfolgreich erstellte Version verwendet, die dies nicht tat Haben Sie diesen neuen Namespace, so dass der Fehler korrekt war, dass er nicht gefunden werden kann, weil er nicht vorhanden war. Die Lösung bestand offensichtlich darin, Fehler im referenzierten Projekt zu beheben.

Ich habe an der VS 2017 Community Edition gearbeitet und hatte das gleiche Problem mit CefSharp Nuget-Paketen.

Pakete wurden erfolgreich heruntergeladen und wiederhergestellt, das Projekt konnte erfolgreich erstellt und ausgeführt werden - nur das Markup zeigte an, dass die Namespaces nicht erkannt wurden.

Ich musste nur den ReferencesAbschnitt öffnen und auf eines der gelben Ausrufezeichen klicken.

Nach einigen Sekunden verschwanden die Markup-Fehler.