Der Name ist im Namespace-Fehler in XAML nicht vorhanden

Verwenden von VS2012 in einer VB.NET WPF-Anwendung. Ich habe eine einfache MusicPlayer-Tutorial-App, mit der ich WPF lerne. Ich konvertiere Schritt für Schritt eine C # -Version des Tutorials in VB.NET.

Die App enthält zwei Klassen, die sich beide unter demselben Namespace befinden. Ich kann auf den Namespace in der XAML verweisen, aber wenn ich versuche, auf das Klassenobjekt in der XAML zu verweisen, wird eine Fehlermeldung angezeigt und ich kann nicht kompilieren.

Seltsam ist, dass IntelliSense sowohl mit dem Verweisen auf den Namespace über das xmlns: c = -Tag als auch beim Eingeben des Klassenobjekts mit <c: funktioniert. Das Objekt ist jedoch unterstrichen und es werden Fehler beim Erstellen oder Arbeiten im Designer generiert.

Die .vb-Klassendateien befinden sich in einem Ordner namens \ Controls. Der Root-Namespace des Hauptprojekts wurde absichtlich leer gelassen. Die Klasse ist so codiert ...

Namespace MusicPlayer.Controls
    Public Class UpdatingMediaElement
       .... code here
    End Public
End Namespace

Das xaml sieht so aus

(Namespace im <Window >Tag definiert

xmlns:c="clr-namespace:MusicPlayer.Controls"

(Objekt definiert in a <Grid>)

  <c:UpdatingMediaElement Name="MyMediaElement" />

(Fehler angezeigt) Der Name "UpdatingMediaElement" ist im Namespace "clr-namespace: MusicPlayer.Controls" nicht vorhanden.

Sie sind sich nicht sicher, was falsch ist oder wie Sie es beheben können?

Wenn Sie Ihren wpf-Code und VS schreiben, teilen Sie mit, dass "der Name ABCDE im Namespace clr-namespace: ABC nicht vorhanden ist". Sie können Ihr Projekt jedoch vollständig erfolgreich erstellen. Es gibt nur kleine Unannehmlichkeiten, da Sie das Entwerfen der Benutzeroberfläche nicht sehen können (oder nur den Code bereinigen möchten).

Versuchen Sie Folgendes:

• Klicken Sie in VS mit der rechten Maustaste auf Ihre Lösung -> Eigenschaften -> Konfigurationseigenschaften

• Ein neues Dialogfeld wird geöffnet. Versuchen Sie, die Projektkonfigurationen von Debug auf Release oder umgekehrt zu ändern.

Erstellen Sie danach Ihre Lösung neu. Es kann Ihr Problem lösen.

Wenn sich die Assembly von dem Namespace unterscheidet, in dem Ihre Klasse enthalten ist, müssen Sie sie explizit angeben.

Ex:-

xmlns:Local="clr-namespace:MusicPlayer.Controls;assembly=MusicPlayer"

Ich habe gesehen, wie dieses Problem behoben wurde, indem der Xaml Design Shadow Cache geleert wurde. Ich hatte das Problem mit Visual Studio 2015 Update 1.

In Visual Studio 2015 befindet sich der Cache hier:

%localappdata%\Microsoft\VisualStudio\14.0\Designer\ShadowCache

Prozess:

1. Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf die Lösung und wählen Sie "Lösung reinigen".
2. Fahren Sie Visual Studio herunter
3. Löschen Sie den ShadowCache-Ordner
4. Das Visual Studio-Projekt wurde erneut geöffnet
5. Erstellen Sie die Lösung neu

Und voila keine Namespace-Fehler mehr.

In meinem Fall lag es an anderen Kompilierungsfehlern . Wenn andere Fehler behoben wurden, wurde dieser scheinbar verwandte Fehler ebenfalls aus der Liste entfernt. Insbesondere die Fehler am Ende der Fehlerliste und auf Seiten, die Sie kürzlich geändert haben.

Achten Sie also nicht direkt auf diesen Fehler und konzentrieren Sie sich zunächst auf andere Fehler .

Versuchen Sie, die Build-Zielplattform auf x86 zu ändern und das Projekt zu erstellen.

Über Subversion habe ich festgestellt, dass ich anscheinend das Ziel der Project Build Platform in x64 geändert habe. Dies war die einzige Änderung, die ich vorgenommen hatte. Nach dieser Änderung funktionierte der Code eine kurze Zeit, bevor derselbe Fehler angezeigt wurde, den Sie hatten. Ich habe das Plattformziel zum Testen auf x86 geändert und plötzlich arbeitete mein Designer wieder. Anschließend habe ich es wieder auf x64 geändert und das Problem ist vollständig verschwunden. Ich vermute, dass der Designer eine Art zwischengespeicherten Code in x32 erstellt und das Ändern der x64-Buildplattform ihn bricht, wenn Sie Codeänderungen vornehmen.

Keine Ahnung, ob dies jemand anderem hilft

Ich bin neu bei WPF und noch ein Neuling bei VB.net - also nahm ich an, dass dieser Fehler dadurch verursacht wurde, dass ich einen dummen Gipfel gemacht habe ........ Angenommen, ich war es wirklich! Ich habe es geschafft, es loszuwerden, indem ich mein Projekt von einem freigegebenen Laufwerk auf eines meiner lokalen Laufwerke verschoben habe. Der Fehler ist verschwunden, das Projekt kompiliert perfekt keine weiteren Probleme - noch nicht. VS2015 hat anscheinend immer noch Probleme mit Projekten, die auf einem gemeinsam genutzten Laufwerk gespeichert sind.

Möglicherweise eine andere Lösung, wenn das Projekt kompiliert wird, aber der XAML-Fehler angezeigt wird:

1. In der Lösungserkundung auf dem Projektknoten, der die xaml enthält
2. Klicken Sie mit der rechten Maustaste auf das Projekt und wählen Sie "Projekt entladen".
3. Klicken Sie mit der rechten Maustaste auf das Projekt und wählen Sie "Projekt neu laden". Stellen Sie sicher, dass Ihr Projekt weiterhin als "Startprojekt" ausgewählt ist. Wenn nicht :
4. Klicken Sie mit der rechten Maustaste auf das Projekt und wählen Sie "Als Startprojekt festlegen".

Keine Notwendigkeit, das visuelle Studio neu zu erstellen oder zu schließen.

Jesus ... Dies ist auch fünf Jahre später in Visual Studio 2017 immer noch ein Problem. Da ich neu bei WPF bin, war ich mir sicher, dass das Problem irgendwie bei mir lag, aber nein, alles wurde korrekt kompiliert und ausgeführt.

Ich habe versucht, neu zu erstellen, zu bereinigen und neu zu erstellen, zwischen x86 / x64-Ausgabe zu wechseln, Windows neu zu starten, den ShadowCache-Ordner zu bereinigen und der XML-Namespace-Deklaration "; Assembly = {mein Hauptassembly-Name}" hinzuzufügen. Es hat nichts funktioniert! Die einzige Sache, die tat:

Fügen Sie meine statische Befehlsklasse (in meinem Fall ging es darum, das Design meine WPF-Befehle erkennen zu lassen) in eine separate Baugruppe und ändern Sie stattdessen den Namen der Baugruppe in diesen.

Ich hatte das gleiche Problem, und in meinem Fall wurde ich in der Markup-Entwurfsansicht aufgefordert, die Lösung neu zu erstellen, und das Formularlayout wurde nicht mit der folgenden Meldung angezeigt : Design view is unavailable for x64 and ARM target platforms, oder Build the Project to update Design view.

Es wird nicht durch Neuerstellen der Lösung gelöst (weder die Entwurfsansicht noch der Fehler "Der Name existiert nicht im Namespace").

Ich denke, das lag daran, dass ich mit den Einstellungen unter Lösung -> Eigenschaften> Konfigurationseigenschaften gespielt hatte

Ich habe das Problem endlich mit 2 Jobs gelöst:

1. Aktivieren Sie alle Kontrollkästchen in der Spalte "Erstellen" der Seite: Lösung -> Eigenschaften -> Konfigurationseigenschaften
2. Ändern der Lösungskonfigurationen von Debug auf Release oder umgekehrt.

Ich denke, es ist ein Fehler in Visual Studio2012 Update 2.

Das gleiche Problem betrifft Visual Studios 2013, Service Pack 4. Ich habe es auch mit Visual Studios 2015 Preview mit den gleichen Ergebnissen versucht.

Dies ist nur eine Einschränkung des WPF-Visualisierers, die das Visual Studios-Team nicht behoben hat. Als Beweis aktiviert das Erstellen im x86-Modus den Visualizer und das Erstellen im x64-Modus deaktiviert ihn.

Seltsamerweise funktioniert Intellisense für Visual Studios 2013, Service Pack 4.

Ich hatte dieses Problem kürzlich bei der Verwendung von VS 2015 Update 3 für mein WPF-Projekt in .NET 4.6.2. Die Kopie meines Projekts befand sich in einem Netzwerkordner . Ich habe sie lokal verschoben und das Problem wurde behoben.

Dies kann andere Probleme lösen, da VS 2015 anscheinend keine Netzwerkpfade mag. Ein weiteres Problem, das für sie ein großes Problem darstellt, ist die Synchronisierung von Git-Repositorys, wenn sich mein Projekt in einem Netzwerkpfad befindet. Dies wird auch durch lokales Verschieben gelöst.

Es sieht so aus, als ob dieses Problem durch eine Vielzahl von "Tricks" gelöst werden kann.

In meinem Fall habe ich die gesamte Lösung erstellt / neu erstellt / gereinigt, anstatt nur das Projekt, an dem ich innerhalb der Lösung gearbeitet habe. Nachdem ich auf "Build [my project]" geklickt hatte, verschwand die Fehlermeldung.

Überprüfen Sie Ihre Assemblyreferenzen. Wenn Sie ein gelbes Ausrufezeichen auf den Projektreferenzen haben, liegt dort ein Problem vor und Sie erhalten alle Arten von Fehlern.

Wenn Sie wissen, dass die Projektreferenz korrekt ist, überprüfen Sie das Ziel-Framework. Zum Beispiel ist es keine gute Kombination, wenn ein Projekt mit der 4.5-Framework-Referenz ein Projekt mit 4.5.2-Framework verwendet.

Die Lösung für mich bestand darin, die Assembly-DLLs zu entsperren. Die Fehlermeldungen, die Sie erhalten, geben dies nicht an, aber der XAML-Designer lehnt es ab, sogenannte "Sandbox" -Baugruppen zu laden. Sie können dies im Ausgabefenster sehen, wenn Sie erstellen. DLLs werden blockiert, wenn sie aus dem Internet heruntergeladen werden. So entsperren Sie Ihre Assembly-DLLs von Drittanbietern:

1. Klicken Sie im Windows Explorer mit der rechten Maustaste auf die DLL-Datei und wählen Sie Eigenschaften.
2. Klicken Sie unten auf der Registerkarte Allgemein auf die Schaltfläche oder das Kontrollkästchen "Entsperren".

Hinweis: Entsperren Sie DLLs nur, wenn Sie sicher sind, dass sie sicher sind.

In meinem Fall wurde das Benutzersteuerelement zum Hauptprojekt hinzugefügt. Ich habe oben verschiedene Lösungen ohne Erfolg ausprobiert. Entweder würde ich ein ungültiges Markup erhalten, aber die Lösung würde kompilieren und funktionieren, oder ich würde die xmlns hinzufügen: c = "clr-namespace: MyProject; assembly = MyProject" und dann würde das Markup angezeigt, aber ich würde einen Kompilierungsfehler erhalten, den das Tag ist im XML-Namespace nicht vorhanden.

Schließlich habe ich der Lösung ein neues WPF User Control Library-Projekt hinzugefügt und mein Benutzersteuerelement vom Hauptprojekt in dieses verschoben. Die Referenz wurde hinzugefügt und die Assembly so geändert, dass sie auf die neue Bibliothek verweist. Schließlich funktionierte das Markup und das Projekt wurde fehlerfrei kompiliert.

Ich ging alle Antworten durch und keiner half mir. Endlich konnte ich es selbst lösen und die Antwort so präsentieren, wie es anderen helfen könnte.

In meinem Fall hatte die Lösung zwei Projekte, eines mit den Modellen (sagen wir, der Projekt- und Baugruppenname war Models ) und eines mit den Ansichten und Ansichtsmodellen (gemäß unserer Konvention: Projekt, Baugruppenname und Standardnamespace waren Models.Monitor ). . Das auf Models.Monitor bezogene Modellprojekt.

Im Models.Monitor-Projekt habe ich in einem der xaml den folgenden Namespace eingefügt: xmlns: monitor = "clr-namespace: Models.Monitor"

Ich vermute, dass MsBuild und Visual Studio damals einen Fehler gemacht haben, als sie versucht haben, einen 'Monitor'-Typ in der Assembly' Models 'zu finden . Um das Problem zu beheben, habe ich Folgendes versucht:

1. xmlns: monitor = "clr-namespace: Models.Monitor; Assembly =" - Dies ist gültig, wenn sich der Namespace in derselben Assembly befindet wie unter https://msdn.microsoft.com/en-us/library/ms747086(v=vs .110) .aspx
2. versuchte auch die explizite Namespace-Deklaration: xmlns: monitor = "clr-Namespace: Models.Monitor; Assembly = Models.Monitor"

Keiner der oben genannten Punkte hat funktioniert.

Schließlich gab ich auf und als eine Umgehung das UserControl verschob, versuchte ich, es in einen anderen Namespace zu verwenden: 'ModelsMonitor' . Danach konnte ich gut kompilieren.

In meinem Fall hatte ich einen Namespace und eine Klasse, die genau gleich geschrieben waren, also war zum Beispiel einer meiner Namespaces

firstDepth.secondDepth.Fubar

welches seine eigenen Klassen enthält (zB firstDepth.secondDepth.Fubar.someclass)

Ich hatte aber auch eine ' Fubar' -Klasse im Namespace

firstDepth.secondDepth

Dies wird in Textform in den oben genannten Fubar-Namespace aufgelöst.

Tu das nicht

In meinem Fall lag das Problem an einigen Phantomdateien im obj-Verzeichnis des Projekts. Folgendes hat das Problem für mich behoben:

• Projekt reinigen
• Beenden Sie VS
• rm -rf / obj / *
• Rufen Sie VS auf und erstellen Sie es neu

Ich habe auch große Probleme mit diesem! Intellisense hilft mir, den Namespace und alles zu vervollständigen, aber der Compiler weint. Ich habe alles versucht, was ich in diesem und anderen Threads gefunden habe. In meinem Fall hat es jedoch am Ende geholfen, so etwas zu schreiben:

xmlns:util="clr-namespace:LiveSpielTool.Utils;assembly="

Lassen Sie den Baugruppennamen leer. Keine Ahnung warum. Aber es wurde hier erwähnt. Ich muss hinzufügen, dass ich eine Assembly entwickle, damit das Assembly-Attribut möglicherweise Sinn macht. Die Eingabe des Assemblynamens funktionierte jedoch nicht. So seltsam.

VB.NET fügt die Namespace-Informationen basierend auf der Ordnerstruktur nicht automatisch hinzu, wie dies in C # der Fall ist. Ich glaube, ich mache das gleiche Tutorial wie Sie durch (Teach Yourself WPF in 24 Stunden) und mache die gleiche Konvertierung zu VB.

Ich habe festgestellt, dass Sie die Namespace-Informationen sowohl zur XAML-Klasse als auch zum XAML.VB-Code manuell hinzufügen müssen, um die im Buch beschriebenen Namespaces verwenden zu können. Selbst dann weist VB der Assembly den Namespace nicht automatisch zu, wie dies in VB der Fall ist.

In einem weiteren Artikel wird gezeigt, wie Sie dies in Ihre Projektvorlagen aufnehmen können, damit die Namespace-Informationen automatisch erstellt werden. Fügen Sie beim Hinzufügen eines neuen Elements automatisch einen Namespace hinzu

Überprüfen Sie auf der Lösungseigenschaftsseite die Plattform der Assembly, die "UpdatingMediaElement" enthält, und die Assmeblies, die eine der Oberklassen und Schnittstellen enthalten, von denen "UpdatingMediaElement" Unterklassen oder Implementierungen enthält. Es scheint, dass die Plattform all dieser Baugruppen "AnyCPU" sein muss.

Eine weitere mögliche Ursache: Ein Ereignis nach dem Erstellen entfernt die Projekt-DLL aus dem Erstellungsordner.

Zur Verdeutlichung: Der WPF-Designer meldet möglicherweise "Der Name XXX ist im Namespace nicht vorhanden ...", auch wenn der Name im Namespace vorhanden ist und das Projekt ordnungsgemäß erstellt und ausgeführt wird, wenn ein Ereignis nach dem Erstellen die Projekt-DLL entfernt den Build-Ordner (bin \ Debug, bin \ Release usw.). Ich habe persönliche Erfahrungen damit in Visual Studio 2015.

Ok, leider hat keiner dieser Tipps bei mir funktioniert. Ich konnte das Problem schließlich lösen. Es scheint, dass Visual Studio mit Netzwerklaufwerken nicht gut funktioniert. Ich habe dieses Problem gelöst, indem ich das Projekt vom freigegebenen Laufwerk auf mein lokales Laufwerk verschoben und neu kompiliert habe. Keine Fehler mehr.

Hinzufügen zum Stapel.

Meins war der Assemblyname der WPF-Anwendung der gleiche Assemblyname wie eine referenzierte DLL. Stellen Sie daher sicher, dass Sie in keinem Ihrer Projekte doppelte Baugruppennamen haben.

Ich hatte die Lösung auf einer Netzwerkfreigabe gespeichert und jedes Mal, wenn ich sie öffnete, wurde ich vor nicht vertrauenswürdigen Quellen gewarnt. Ich habe es auf ein lokales Laufwerk verschoben und der Fehler "Namespace existiert nicht" ist ebenfalls verschwunden.

Versuchen Sie auch, mit der rechten Maustaste auf Ihr Projekt-> Eigenschaften zu klicken und das Plattformziel in Beliebige CPU zu ändern und neu zu erstellen. Dies funktioniert dann. Das hat bei mir funktioniert

Dieses Problem kann auch verursacht werden, wenn die Assembly, auf die Sie verweisen, nicht tatsächlich erstellt wurde. Wenn sich Ihre xaml beispielsweise in Assembly1 befindet und Sie auch in Assembly1 auf eine Klasse verweisen, diese Assembly jedoch Fehler aufweist und nicht erstellt wird, wird dieser Fehler angezeigt.

Ich fühle mich dumm dabei, aber in meinem Fall habe ich eine Benutzersteuerung auseinandergerissen und infolgedessen alle möglichen Fehler in den zugehörigen Klassen gehabt. Als ich versuchte, sie alle zu beheben, begann ich mit den fraglichen Fehlern, ohne zu bemerken, dass xaml sich auf erstellte Assemblys stützt, um diese Referenzen zu finden (im Gegensatz zu c # / vb-Code, der dies bereits vor dem Erstellen ausarbeiten kann).

Ich hatte die Assembly als Projekt hinzugefügt - zuerst löschte ich die ddl, die speziell zu den Verweisen auf die dll hinzugefügt wurde - das tat es.

Ich bekomme dieses Problem die ganze Zeit. Meine Ansichten befinden sich in einem WPF Custom Control Library-Projekt (eine Variante der Klassenbibliothek). Ich kann auf vorgefertigte Assemblys verweisen, aber keinen Code in einem anderen Projekt derselben Lösung referenzieren. Sobald ich den Code in dasselbe Projekt wie die XAML verschiebe, wird er erkannt.

In meinem Fall tritt dieses Problem auf, wenn die Architektur des wpf-Programms mit der Abhängigkeit nicht genau identisch ist. Angenommen, Sie haben eine Abhängigkeit, die x64 ist, und eine andere ist AnyCPU. Wenn Sie dann x64 auswählen, wird der Typ in der AnyCPU-DLL "nicht vorhanden", andernfalls wird der Typ in der x64-DLL "nicht vorhanden" sein. Sie können einfach nicht beide emilieren.