Visual Studio 2010 kann den Namespace plötzlich nicht mehr sehen?


83

Meine C # WinForms-Lösung hat zwei Projekte. Eine DLL, die das Hauptprojekt ist, an dem ich arbeite, und eine ausführbare WinForms, die ich "Sandbox" nenne, damit ich die DLL einfach auf einmal kompilieren / ausführen / debuggen kann.

Ich arbeite in .Net 4.0 für beide Projekte.

Alles funktionierte einwandfrei, bis ich einen scheinbar unschuldigen Code und einen Verweis auf System.Web in der DLL hinzufügte. Jetzt kann mein Sandbox-Projekt den Namespace des DLL-Projekts nicht sehen. Ich habe nichts geändert, von dem ich glaube, dass es dies hätte beeinflussen sollen.

Wenn ich den Projektverweis auf die DLL aus den Sandbox-Verweisen lösche und erneut hinzufüge, verschwinden alle roten Unterstreichungen und die Farbcodierung wird für alle meine Klassen usw. zurückgegeben. Aber sobald ich versuche, die Lösung zu entwickeln, fällt das Ganze wieder auseinander.

Wenn ich in den Sandbox-Referenzen mit der rechten Maustaste auf das DLL-Projekt klicke und es im Objektbrowser ansehe, kann ich den Namespace und alle darin enthaltenen Inhalte sehen.

Ich habe das Gefühl, dass dies eine Art Fehler sein könnte?

Ist das eine Art VS2010-Fehler? Ich hatte das gleiche Problem vor einigen Monaten und konnte es zu diesem Zeitpunkt nur beheben, indem ich ein ganz neues Projekt erstellte und meine Dateien erneut importierte. Dieses Mal habe ich jedoch eine Bajillion Dateien und werde dies nur als letzten Ausweg tun!

Bearbeiten: Nachdem ich panisch alle meine Änderungen durchlaufen und rückgängig gemacht habe und versucht habe herauszufinden, was die Probleme verursacht hat, scheint es diese Zeile zu sein:

string url = "http://maps.google.com?q=" + HttpUtility.UrlEncode(address);

Wenn ich diese Zeile auskommentiere, erhalte ich keine Namespace-Fehler und das Projekt wird einwandfrei erstellt. Ich kann mit dieser Zeile nichts falsches sehen.

Antworten:


149

Ich bin bereit, dies als Fehler in VS2010 zu deklarieren. Dies hat bereits viel zu viele Programmierer gebissen. Die Korrektur ist einfach: Projekt + Eigenschaften, Registerkarte Anwendung, ändern Sie Target Framework in ".NET Framework 4" anstelle des standardmäßig ausgewählten Client-Profils.

System.Web ist nicht im Client-Profil enthalten. Diese Option überhaupt zu haben ist ziemlich albern, das Client-Profil ist nur 15% kleiner als die Vollversion von .NET 4.0. Die Standardauswahl ist noch dümmer. Aber ich schweife ab.

UPDATE: Zum Glück wurde dies alles in VS2012 behoben. Dadurch wird das Client-Profil nicht mehr zum Standard für ein neues Projekt. Und das Client-Profil wurde in .NET 4.5 vollständig eingestellt.


1
Dank dafür. Meine DLL wurde auf .NET 4.0 festgelegt, aber die Sandbox wurde auf .NET 4.0-Clientprofil festgelegt. Nachdem ich 5 Monate an diesem Projekt gearbeitet hatte, bekam ich Panik, als das Ganze scheinbar ohne Grund auseinander fiel ... Zumindest werde ich es für das nächste Mal wissen!
Ozzah

27
Diese Art von Antworten sind das wahre Fleisch und die Kartoffeln dieser Seite. Mein Vertrauen in die Menschheit hat leicht zugenommen und mein Projekt wird endlich kompiliert. Vielen Dank.
CloudMeta

1
Ich habe das Ziel-Framework in allen meinen Projekten auf 4.0 geändert, jedoch können Namespaces der abhängigen Projekte immer noch nicht gefunden werden. Gibt es noch etwas, das ich unbedingt überprüfen sollte?
Steven Ryssaert

@UwConcept - hier geht es nicht um die Versionsnummer. Es geht um ein vollständiges vs Kundenprofil. Bitte starten Sie Ihre eigene Frage, wenn das nicht hilft.
Hans Passant

@ HansPassant Ja, es tut mir leid, wenn meine Frage verwirrend war. Ich habe die 4.0-Client-Version verwendet und diese in 4.0 geändert. Die Namespaces in anderen Projekten in meiner Lösung können jedoch nicht projektübergreifend gefunden werden.
Steven Ryssaert

8

Stellen Sie sicher, dass beide Projekte das Nicht-Client-Profil für ihr Zielframework verwenden (gehen Sie dazu zu den Eigenschaften jedes Projekts).


Danke Mark. Sie und Hans haben es auf den Kopf genagelt, das hat es repariert.
Ozzah

2

Eine Möglichkeit besteht darin, dass die .NET Framework-Zielversion der Klassenbibliothek höher ist als die des Projekts. Ich war mit diesem Problem konfrontiert und habe es gelöst, indem ich Visual Studio geschlossen, Visual Studio wieder geöffnet, die Lösung gereinigt und neu erstellt habe. Das hat bei mir funktioniert. In einigen anderen Beiträgen habe ich die Antworten gelesen und die meisten Benutzer haben das Problem auf diese Weise gelöst.


1
Diese Frage wurde bereits vor mehr als viereinhalb Jahren zufriedenstellend beantwortet.
Ozzah

+ für das Hinzufügen hilfreicher und nützlicher Informationen zu einem eng verwandten Fehler
Eric Brown - Cal

@Ozzah als jemand, der sich 2017 mit diesem Fehler befasst, bin ich auf jeden Fall froh, weitere Informationen zu haben. +1
Cowthulhu

1

Versuchen Sie zunächst, nur das Projekt mit der Sandbox-DLL unabhängig zu erstellen.

Zeigen Sie dann mit Ihrem ausführbaren Projekt auf die gewünschte DLL und stellen Sie sicher, dass copy locales auf eingestellt ist true. in Referenzeinstellungen.

Erstellen Sie dann das ausführbare Projekt.


Und aus Liebe zu allen heiligen Dingen stellen Sie sicher, dass der
Zieltyp

0

Das Ändern des Zielframeworks vom ".NET Framweork 4-Clientprofil" in ".NET Framework 4" hat bei mir mit einem ähnlichen Problem funktioniert. Ich bin damit einverstanden, dass das Kundenprofil keinen großen Vorteil bei der Verwendung zu haben scheint. Ich scheine mit seltsamen Fehlern konfrontiert zu sein, nach denen ich suche, bis ich mich daran erinnere, dass Visual Studio standardmäßig das Client-Profil verwendet. Ich denke, die Moral der Geschichte, wenn ein Fehler angezeigt wird, lautet: Wenn "Rebuild Solution" nicht funktioniert, überprüfen Sie das Target-Framework ...


0

Wenn Sie bereits versucht haben, die Framework-Änderung vorzunehmen, und dies immer noch nicht funktioniert hat, hoffe ich, dass dies für Sie funktioniert (wie für mich): Fügen Sie einfach die erforderlichen Referenzen aus Ihren Projekten hinzu. Sehr offensichtlich, aber ich habe es falsch gemacht, bis ich herausgefunden habe, worum es ging.


0

Ich hatte gerade dieses Problem und es stellte sich heraus, dass mehrere Namespaces verwendet wurden, die denselben Objektnamen hatten (dh Geschäftsobjekte hatten dieselben Namen wie MVC-Modelle).

Die vollständige Qualifizierung der Namen hat das Problem für mich behoben.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.