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

276

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?

Greg
quelle
Möglicherweise funktioniert es, Visual Studio zu schließen und neu zu starten. Es scheint manchmal "
Ris Adams
2
Anleitung: 1) Assembly geladen?, 2) Assembly geladen stimmt mit Origin-Assembly überein?, 3) "using" -Anweisungen, die auf alte oder keine gültigen Referenzen verweisen?, 4) .csproj-Manifest enthält ungültige Quelle?, 5) ein Suchwerkzeug, das Regex aussieht in der gesamten Lösung (jede Klassenbibliothek und jedes Projekt). 5) Überprüfen Sie die Projekteinstellungen für die Erstellungsoption für die Net Framework-Version (arbeiten Sie in Teams zusammen, um diese Art von Problem zu lösen. Sie müssen der Net Framew-Build-Version auf beiden Seiten zustimmen.) 6) Bereinigen und erstellen Sie anschließend jede einzelne und schließen Sie schließlich alle Referenzen ein zur Zielprojekt- / Klassenbibliothek. Ich sollte arbeiten!
Felix Aballi
Überprüfen Sie, ob Sie auf die DLL verwiesen haben. Die DLL befindet sich im Ordner bin Ihres Lösungsverzeichnisses.
Abhishek Poojary

Antworten:

470

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)

Slugster
quelle
2
Hervorragend - das hat funktioniert - Ich musste meinen WPF-App-Client aktualisieren, um das vollständige .NET Framework 4 nutzen zu können. Sie sind sich nicht sicher, welche Auswirkungen dies auf den Client-Footprint haben wird? Ich habe versucht, die Bibliothek, die ich habe, auf das .Net 4-Client-Profil herunterzustufen. Als ich dies tat, gab es jedoch ähnliche Probleme mit der kürzlich von Quartz.net verwendeten Drittanbieter-Bibliothek, die ich gerade verwendet hatte. Die Verwendung von Quartz.net in meinem Bibliotheksprojekt zwingt mich letztendlich dazu, das vollständige .Net 4-Framework in meiner UI-WPF-App verwenden zu müssen.
Greg
3
Danke - das hat gerade geholfen. Ich habe kürzlich die Lösung von VS2010 auf VS2012 verschoben und in VS2012 eine neue Klassenbibliothek erstellt. Plötzlich bekam ich diesen Fehler, und das lag natürlich daran, dass die neue Klassenbibliothek auf .NET 4.5 abzielte, während das Projekt, das darauf verweist, auf .NET 4.0 abzielte. Durch ein Downgrade der neuen Bibliothek auf Ziel 4.0 wurde das Problem behoben.
Richard
22
Wäre wirklich schön, wenn Visual Studio Ihnen einen Hinweis dazu geben würde!
Jason Coyne
3
Obwohl diese Antwort eine großartige Beschreibung dessen gibt, was getan werden muss ... hat sie keinen Vorschlag, wie es zu tun ist, was eine nette Ergänzung wäre
Jon Story
1
Selbst die Besten von uns hatten manchmal einfach nie die Notwendigkeit, einige Aufgaben zu erledigen. Ich bin mir nicht sicher, wie ich das Framework nie ändern musste, und obwohl ich es jetzt gefunden habe, war es mir noch nie in den Sinn gekommen. Es ist kein Deal Breaker für die Antwort, nur dass ich finde, dass die allerbesten Antworten als One-Stop-Shop für "Beschreiben Sie das Problem, geben Sie die Lösung an, zeigen Sie, wie es
Jon Story
50

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
Saxorut
quelle
Das Problem, mit dem ich konfrontiert war, war, dass ich eine neue Lösung erstellt und eine andere Version eines Nuget-Pakets hinzugefügt habe, als andere verwendet werden. Als ich dann lief, hatte Update-Package -reinstallich mehrere Fehler in der gesamten Lösung, einschließlich einer anderen Version dieses Pakets. Ich habe alles aktualisiert, dann läuft es endlich durch. Es wurden auch die Verweise in den package.json-Dateien von 45 auf 452 korrigiert, da ich vor einiger Zeit auch die Zielversion geändert habe.
Ádám Kovács
Arbeitete für mich und ich musste Sytems.Net.Http aus Referenzen während des Downgrades entfernen
Binil Anto
1
Das hat auch bei mir funktioniert. Ich habe den Befehl ausgeführt, dann die resultierenden ausstehenden Änderungen
aufgehoben
Es hat bei mir funktioniert, es hat mir eine Referenz gezeigt, die mit meinem aktuellen Framework nicht unterstützt wurde
Adleri
Dies funktionierte für mich und der Fehler, der behoben wurde, hatte nichts mit einem installierten Nuget-Paket zu tun.
CAD-Typ
31

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.

Alexander Høst
quelle
Empfehlen Sie diesen Trick nur, wenn Sie ein Referenzierungsproblem in einer VS-Lösung finden. Es löste mein Problem in VS2017, nachdem ich ein neues Projekt hinzugefügt hatte, das auf eine höhere Version von .NET Framework abzielte. Ich wette, es ist etwas Caching gelöscht.
Themenfeld
1
Gleiches hier: Dies hat geholfen (ich hatte auch keine anderen Versionsprobleme). Ich habe Fehlermeldungen für jede geöffnete Datei erhalten, bis zu 400+ ... obwohl das Erstellen / Ausführen kein Problem war. Außerdem: Die lösungsweite Analyse von ReSharper zeigte dieselben Fehler.
Mike
Hat mir auch bei diesem Trick geholfen. Hatte nicht einmal Unterschiede in der Zielversion. Bauen war möglich, Rider zeigte keine Probleme, aber VS bestand weiterhin darauf, dass alle Projektreferenzen fehlten ...
Daniel Lerps
Der Compiler wird gemäß der Projekterstellungsreihenfolge kompiliert. Wenn also in einem Projekt ein echter Fehler auftritt, kann dieser in einem Meer von Red Hering-Fehlern "Typ oder Namespace konnte nicht gefunden werden" verloren gehen - da er nur beendet wird, wenn er den Fehler findet Fehler und kann die Referenzen nicht aktualisieren. Wenn nicht zu viele Fehler aufgelistet sind, sollten Sie in der Lage sein, den echten Fehler zu finden. Leider gab es Hunderte von ihnen für mich, also hat mir dieser Trick wirklich geholfen. Ich denke, Intelisense kümmert sich nicht um die Erstellungsreihenfolge und kompiliert Projekte nur einzeln, und deshalb erhalten Sie keine Intelisense-Fehler.
Kev
29

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.

ksun
quelle
2
Vielen Dank für den Tipp, die Warnungen zu lesen. Mein Problem war, dass mein Testprojekt das NuGet-Paket für Bcl installieren musste, da mein Hauptprojekt darauf verwies.
Kim
Vielen Dank! Dies veranlasste mich, das Problem zu finden, das ich hatte. Es stellte sich heraus, dass ich zwei Verweise auf das Abhängigkeitsprojekt hatte, und derjenige, der Vorrang hatte, war eine zuvor erstellte DLL im Ordner bin. Ich habe die DLL und die Rogue-Referenz gelöscht und eine Neuerstellung durchgeführt, dann wurde alles korrekt kompiliert.
Chris Davis
7

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.

Greg D.
quelle
Ich hatte versucht, Ihre Lösung zu reinigen und neu aufzubauen, aber kein Glück. Versucht, nur das WPF-App-Projekt zu entfernen / hinzuzufügen / zu reinigen / neu zu erstellen und immer noch kein Glück. :(
Greg
Ein Clean gefolgt von einem Rebuild behebt das Problem. Dieses Problem tritt jedoch jeden Tag auf. Zumindest kann ich meine Sachen erledigen, bis ich sie komplett erledigt habe.
Valamas
5

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.

Kim
quelle
1
Ah danke dafür. Mein portables Projekt konnte in Xamarin Studio problemlos kompiliert werden, während es in Visual Studio aus diesem Grund fehlschlug. Ich denke, XS macht etwas 'Magie', um es kompilieren zu lassen, wenn implizite Referenzen fehlen.
Nicola Iarocci
5

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.

Yu Yang Jian
quelle
4

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!!!

Sandeep Goundar
quelle
4

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.

Ilia Anastassov
quelle
3

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


quelle
2

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.

Henry Fieger
quelle
2

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.

Rechnung
quelle
2

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.

Andrey Kotov
quelle
1
Ich hatte ein ähnliches Problem mit einer schlechten Zusammenführung in VS 2019. Das Projekt wurde erfolgreich kompiliert, aber nicht die Lösung. Es gab tatsächlich einen Fehler für dieses Projekt (sehr seltsam). Es schlug fehl, weil auf eine zusätzliche Datei verwiesen wurde, die zuvor entfernt, aber nach einer Zusammenführung erneut hinzugefügt wurde. Ich habe die Datei entfernt, die .csproj-Datei bereinigt, neu erstellt und alle Referenzen haben wieder funktioniert.
Cryptc
2

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)
Michael D.
quelle
1

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.


quelle
1

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.

Djangojazz
quelle
1

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.

Nick Gotch
quelle
1

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

user3784340
quelle
1

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.
Jalal
quelle
1

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

Yossico
quelle
Das war genau das Problem für mich. Ich habe System.Core entfernt und neu erstellt, Fehler haben sich sofort von selbst behoben. Vielen Dank, dass Sie mir viel Kopfschmerzen
erspart haben
1

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 .

Robin Güldenpfennig
quelle
1

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!

MPJ567
quelle
1

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

user1121956
quelle
Wo kann ich den Namen der Baugruppe bearbeiten, um ihn in den richtigen Namen zu ändern?
Matt123
1
in der Projektdatei (.csproj) manuell oder durch Klicken mit der rechten Maustaste auf das Projekt -> Eigenschaften
user1121956
0

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.

Tanuki
quelle
0

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.

Dan
quelle
0

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.

Simon_Weaver
quelle
0

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.

ZerosAndOnes
quelle
0

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 :)

Samih A.
quelle
0

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.

Albert221
quelle
0

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.

Geben Sie hier die Bildbeschreibung ein

Nach einigen Sekunden verschwanden die Markup-Fehler.

Geben Sie hier die Bildbeschreibung ein

Janis S.
quelle
Ich denke, Sie werden feststellen, dass dies nur funktioniert, wenn das Eigenschaftenfenster geöffnet ist (klicken Sie mit der rechten Maustaste auf eine problematische Referenz und wählen Sie Eigenschaften.) Kann nun jemand erklären, warum dies funktioniert?
Qwertie