it-swarm.com.de

Der Name ist im Namespace-Fehler in XAML nicht vorhanden

Verwenden von VS2012 beim Arbeiten an einer VB.NET WPF-Anwendung. Ich habe eine einfache MusicPlayer-Lernprogramm-App, die ich zum Lernen von WPF verwende. Ich konvertiere eine C # -Version des Tutorials schrittweise in VB.NET.

Es gibt zwei Klassen in der App, die sich beide unter demselben Namespace befinden. Ich kann auf den Namespace in der XAML verweisen, aber wenn ich versuche, auf das Klassenobjekt in XAML zu verweisen, erhalte ich einen Fehler und kann nicht kompilieren.

Merkwürdig ist, dass IntelliSense gut funktioniert, wenn sowohl der Namespace über den Tag xmlns: c = referenziert wird, als auch das Klassenobjekt mit <c: .__ eingegeben wird. Das Objekt ist jedoch unterstrichen und es werden Fehler beim Erstellen oder Arbeiten im Designer generiert.

Die .vb-Klassendateien befinden sich in einem Ordner mit dem Namen\Controls. Das Hauptprojekt Root Namespace 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

(Namensraum, der im <Window >-Tag definiert ist

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

(Objekt definiert in einem <Grid>)

  <c:UpdatingMediaElement Name="MyMediaElement" />

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

Sie wissen nicht, was falsch ist oder wie Sie das Problem beheben können?

94
Jeff Davis

Wenn Sie Ihren WFP-Code schreiben und VS sagen, dass "Der Name ABCDE ist nicht im Namespace Clr-Namespace: ABC vorhanden". Sie können Ihr Projekt jedoch vollständig erstellen, es gibt nur eine kleine Unannehmlichkeit, da Sie das Design der Benutzeroberfläche nicht sehen können (oder einfach nur den Code bereinigen möchten). 

Versuchen Sie Folgendes:

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

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

Danach erstellen Sie Ihre Lösung neu. Es kann Ihr Problem lösen.

178
Toan Darkprince

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"
47
Vasanth Sriram

Ändern Sie die Build-Zielplattform in x86 und erstellen Sie das Projekt.

Über Subversion ist mir aufgefallen, dass ich anscheinend das Ziel für die Projekterstellungsplattform in x64 geändert habe. Dies war die einzige Änderung, die ich vorgenommen hatte. Nachdem diese Änderung vorgenommen wurde, funktionierte der Code eine kurze Zeit, bevor derselbe Fehler angezeigt wurde. Ich habe das Plattformziel auf x86 geändert, um zu testen, und plötzlich arbeitet mein Designer wieder. Anschließend habe ich es wieder in x64 geändert und das Problem ist vollständig verschwunden. Ich vermute, dass der Designer in x32 eine Art zwischengespeicherten Code erstellt. Durch das Ändern der x64-Buildplattform wird der Code zerstört, wenn Sie Codeänderungen vornehmen.

23
teynon

Ich habe gesehen, dass dieses Problem durch das Löschen des Xaml Design Shadow Cache behoben 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

Verarbeiten:

  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. 

22
Jasper H Bojsen

In meinem Fall lag es an anderen Kompilierfehlern . Wenn andere Fehler behoben wurden, wurde dieser scheinbar verwandte Fehler ebenfalls aus der Liste entfernt. Insbesondere die Fehler unten in 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 .

19
Iman Abidi

Keine Ahnung, ob dies anderen helfen wird

Ich bin neu bei WPF und noch ein Neuling bei VB.net - also ging ich davon aus, dass ich diesen Fehler bekommen habe, weil ich albern Summit gemacht habe. Es ist mir gelungen, das Projekt zu entfernen, indem ich mein Projekt von einem freigegebenen Laufwerk auf eines meiner lokalen Laufwerke verlagerte. Fehler verschwunden, Projekt kompiliert keine weiteren Probleme mehr - noch nicht. VS2015 hat nach wie vor Probleme mit Projekten, die auf einem gemeinsam genutzten Laufwerk gespeichert sind.

7
Supa Stix

Vielleicht eine andere Lösung, wenn das Projekt kompiliert wird, der XAML-Fehler jedoch angezeigt wird: 

  1. In der Lösungssuche 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 noch 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.

5
Simon

Jesus ... Dies ist immer noch ein Problem fünf Jahre später in Visual Studio 2017. Da ich neu bei WPF bin, war ich mir sicher, dass das Problem irgendwie auf mich zurückzuführen war, aber nein, alles wurde kompiliert und lief korrekt.

Ich habe versucht, rebuilding, clean und rebuilding zu machen, zwischen der x86/x64-Ausgabe umzuschalten, Windows neu zu starten, den Ordner ShadowCache zu säubern und der XML-Namespace-Deklaration "; Assembly = {my main Assembly name}" hinzuzufügen. Die einzige Sache, die tat:

Setzen Sie meine statische Klasse von Befehlen (in meinem Fall ging es darum, das Design meine WPF-Befehle entdecken zu lassen) in ihre separate Assembly ein und ändern Sie statt dessen den Namen der Assembly.

3
Jonas

Ich hatte dieses Problem vor kurzem mit 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 es lokal verschoben und damit das Problem gelöst.

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

2
gbdavid

Das gleiche Problem plagt 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-Visualizers, den das Visual Studios-Team nicht repariert hat . Wenn Sie im x86-Modus bauen, werden der Visualizer und der x64-Modus deaktiviert.

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

2
Trevy Burgess

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

Sie wird nicht gelöst, indem die Lösung neu erstellt wird (weder die Entwurfsansicht noch der Fehler "Der Name ist nicht im Namespace vorhanden").

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

Ich habe das Problem schließlich mit 2 Jobs gelöst:

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

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

2
Ehsan Abidi

Anscheinend kann dieses Problem durch verschiedene "Tricks" gelöst werden.

In meinem Fall hatte ich die gesamte Lösung aufgebaut/umgebaut/gereinigt und nicht nur das Projekt, an dem ich innerhalb der Lösung arbeitete. Sobald ich auf "Build [mein Projekt]" geklickt habe, ging die Fehlermeldung weg.

1
gusmally

Die Lösung für mich bestand darin, die Assembly-DLLs zu entsperren. Die Fehlermeldungen, die Sie erhalten, zeigen dies nicht an, aber der XAML-Designer weigert sich, die als "Sandkasten" bezeichneten Assemblys zu laden. Sie können dies beim Erstellen im Ausgabefenster sehen. DLLs werden gesperrt, wenn sie aus dem Internet heruntergeladen werden. So entsperren Sie Ihre Assembly-DLLs von Drittanbietern:

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

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

1
Jordan

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

  • Projekt bereinigen
  • Beenden Sie VS
  • rm -rf/obj/*
  • VS aufrufen und neu erstellen
1
eric gilbertson

In meinem Fall wurde das Benutzersteuerelement dem Hauptprojekt hinzugefügt. Ich habe verschiedene Lösungen oben ohne Erfolg ausprobiert. Entweder würde ich Invalid Markup bekommen, aber die Lösung würde kompilieren und funktionieren, oder ich würde das Xmlns hinzufügen: c = "clr-namespace: MyProject; Assembly = MyProject" und dann würde das Markup angezeigt, aber ich würde ein Compile erhalten Fehler, dass das Tag nicht im XML-Namespace vorhanden ist.

Schließlich habe ich der Lösung ein neues WPF User Control Library-Projekt hinzugefügt und mein Benutzersteuerelement aus dem Hauptprojekt in dieses verschoben. Fügte die Referenz hinzu und änderte die Assembly so, dass sie auf die neue Bibliothek verweist, und schließlich funktionierte das Markup und das Projekt wurde ohne Fehler kompiliert.

1
Kevin Cook

Ich habe alle Antworten durchgesehen und keine hat mir geholfen. Endlich konnte ich es selbst lösen und die Antwort so präsentieren, wie es anderen helfen könnte.

In meinem Fall bestand die Lösung aus zwei Projekten, von denen eines die Modelle enthielt (der Projekt- und Assemblyname lautete Modelle ) und das andere die Ansichten und Ansichtsmodelle (Gemäß unserer Konvention lauteten Projekt, Assemblyname und Standardnamespace Models.Monitor ). Das Models.Monitor-bezogene Models-Projekt.

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

Ich vermute, dass MsBuild und Visual Studio dann einen Fehler machten, als sie versuchten, einen 'Monitor'-Typ in der Assembly' Models 'zu finden . Um das Problem zu lösen, habe ich Folgendes versucht:

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

Keines der oben genannten hat funktioniert.

Schließlich habe ich aufgegeben und als eine Umgehungsmöglichkeit das UserControl verschoben habe, habe ich versucht, es in einen anderen Namespace zu verschieben: 'ModelsMonitor' . Danach konnte ich gut kompilieren.

1
Sandip

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 nicht auf Code in einem anderen Projekt derselben Lösung. Sobald ich den Code in dasselbe Projekt wie die XAML verschiebe, wird er erkannt.

0
user1040323

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

firstDepth.secondDepth.Fubar

die eigene Klassen enthält (z. B. firstDepth.secondDepth.Fubar.someclass)

aber ich hatte auch eine ' Fubar ' Klasse im Namespace

firstDepth.secondDepth

was sich in Textform wie der oben angegebene Fubar-Namespace auflöst.

Tu das nicht

0
Sean

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

0
jgong

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

Ich habe festgestellt, dass Sie die Namespace-Informationen manuell zu Both, der XAML-Klasse und dem dahinter liegenden XAML.VB-Code hinzufügen müssen, um die Namespaces wie in diesem Buch beschrieben verwenden zu können. Selbst dann weist VB der Assembly nicht automatisch den Namespace zu wie in VB.

Es gibt noch einen weiteren Artikel, der beschreibt, wie Sie dies in Ihre Projektvorlagen aufnehmen, damit die Namespace-Informationen automatisch erstellt werden. - Namespace beim Hinzufügen eines neuen Elements automatisch hinzufügen

0
Jeremy

Eine weitere mögliche Ursache: Ein Postbuild-Ereignis entfernt das Projekt DLL aus dem Build-Ordner.

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 if a post- Das Build-Ereignis entfernt das Projekt DLL aus dem Build-Ordner (bin\Debug, bin\Release usw.). Ich habe persönliche Erfahrungen mit diesem in Visual Studio 2015.

0
R.T.

Versuchen Sie, Ihre Assembly-Referenzen zu überprüfen. Wenn Sie ein gelbes Ausrufezeichen auf den Projektverweisen haben, liegt dort ein Problem vor und Sie erhalten alle möglichen Fehler.

Wenn Sie wissen, dass die Projektreferenz korrekt ist, überprüfen Sie das Target-Framework. Wenn Sie beispielsweise ein Projekt mit der Referenz für 4.5-Framework verwenden, ist ein Projekt mit 4.5.2-Framework keine gute Kombination.

0
Tommy Andersen

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. Dann funktioniert es. Das hat bei mir funktioniert

0
Corne

Dieses Problem kann auch auftreten, wenn die Assembly, auf die Sie verweisen, nicht wirklich erstellt wird. Wenn sich beispielsweise Ihr xaml 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, aber in meinem Fall habe ich ein Benutzersteuerelement auseinandergerissen und hatte alle möglichen Fehler in den verwandten Klassen. Als ich versuchte, alles zu korrigieren, fing ich mit den fraglichen Fehlern an, ohne zu wissen, dass xaml auf eingebaute Assemblys zurückgreift, um diese Referenzen zu finden (im Gegensatz zu c #/vb-Code, der das Problem bereits vor dem Erstellen beheben kann).

0
kad81

Ich habe auch viel Ärger mit diesem hier! Intellisense hilft mir dabei, den Namespace und alles zu vervollständigen, aber der Compiler schreit. Ich habe alles versucht, was ich in diesem und anderen Threads gefunden habe. In meinem Fall half es jedoch am Ende so etwas zu schreiben: xmlns: util = "clr-namespace: LiveSpielTool.Utils; Assembly ="

Den Namen der Assembly leer lassen. Keine Ahnung warum. Aber es wurde hier erwähnt. Ich muss hinzufügen, dass ich eine Assembly entwickle, sodass das Assembly-Attribut sinnvoll sein kann. Die Eingabe des Assemblynamens funktionierte jedoch nicht. So seltsam.

0
le_fritz

In meinem Fall tritt dieses Problem auf, wenn die Architektur des Programms wpf mit der Abhängigkeit nicht genau übereinstimmt. Angenommen, Sie haben eine Abhängigkeit mit x64 und eine andere mit AnyCPU. Wenn Sie sich für x64 entscheiden, ist der Typ in der AnyCPU-DLL "nicht vorhanden", andernfalls ist der Typ in der x64-DLL "nicht vorhanden". Sie können einfach nicht beide emilieren.

0
Cauly

Ich hatte die Assembly als Projekt hinzugefügt - zuerst die Ddl gelöscht, die speziell zu den Verweisen auf die DLL hinzugefügt wurde -, die dies tat.

0
PI Mike

Eine Kombination von zwei Ideen in diesem Thread hat für mich funktioniert, daher werde ich meine Arbeit in der Hoffnung veröffentlichen, dass es in den nächsten 5 Jahren jemand anderem hilft, dass dieses Problem weiterhin besteht. Ich benutze die VS2017 Community

  1. Löschen Sie den Verweis auf die DLL
  2. Bereinigen, neu erstellen, erstellen
  3. VS schließen, DLL entsperren (siehe Hinweis unten), Schatten-Cache löschen
  4. Öffnen Sie VS, Clean, Rebuild, Build
  5. Stellen Sie den Verweis auf die DLL wieder her
  6. Bereinigen, neu erstellen, erstellen

Möglicherweise stimmt die Bestellung in den Schritten 2, 4 und 6 nicht genau, aber ich habe nach fast 2 Stunden mit diesem Problem nach Strohhalmen gegriffen. Ich denke, der Schlüssel für mich war die Kombination aus Entfernen des Verweises, Entsperren der DLL und Löschen des Schattencaches.

(Hinweis zu Schritt 3 - Die von mir verwendete DLL wurde von einem meiner Kollegen/Mentoren geschrieben, daher weiß ich, dass sie sicher ist. Gehen Sie bei diesem Schritt vorsichtig vor, wenn Sie die Quelle Ihrer DLL nicht kennen. =

Ich werde diesen Thread für die Nachwelt bookmarken, da es den Anschein hat, dass MS keine Lust hat, dieses Zeug aufzuräumen. WPF ist schwer genug, um es selbst zu lernen, und es ist ärgerlich, solche Dinge durchzuhacken, wenn man alles richtig gemacht hat. ????????????

0
SpaceballOne

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

0
Kevin S. Miller

Hinzufügen zum Haufen.

Mein war der Assemblyname der WPF-Anwendung war der gleiche Assemblyname wie eine referenzierte DLL. Stellen Sie daher sicher, dass in keinem Ihrer Projekte doppelte Assemblynamen vorhanden sind. 

0
Ceres

Ok, so hat leider keiner dieser Tipps für mich funktioniert. Ich konnte das Problem schließlich lösen. Es scheint, dass Visual Studio nicht gut mit Netzlaufwerken funktioniert. Ich habe dieses Problem gelöst, indem ich das Projekt von dem freigegebenen Laufwerk auf mein lokales Laufwerk verschoben und erneut kompiliert habe. Keine Fehler mehr.

0
Noahm888