it-swarm.com.de

der Name <...> ist nicht im Namensraum clr-namespace <...> vorhanden

Ich habe eine kleine WPF-Anwendung, die früher kompiliert wurde, aber nicht mehr funktioniert. Ich kann nicht wirklich sagen, an welchem ​​Punkt es aufgehört hat zu bauen. Es hat einfach an einem Tag gut funktioniert und am nächsten nicht.

Hier ist die Projektstruktur:
enter image description here
Es gibt keine anderen Projekte oder externen Verweise außer Standard-.net-DLLs.

Hier ist die Benutzersteuerung, wo das Problem entstanden ist:

<UserControl x:Class="TimeRecorder.HistoryUserControl"
         xmlns="http://schemas.Microsoft.com/winfx/2006/xaml/presentation"
         xmlns:x="http://schemas.Microsoft.com/winfx/2006/xaml"
         xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
         xmlns:d="http://schemas.Microsoft.com/expression/blend/2008" 
         xmlns:local="clr-namespace:TimeRecorder.ViewModel"
         xmlns:framework="clr-namespace:TimeRecorder.Framework"
         mc:Ignorable="d" Height="Auto" Width="Auto" Padding="5">
<UserControl.Resources>
    <local:HistoryViewModel x:Key="ViewModel"/>
    <framework:BoolToColorConverter x:Key="ColorConverter"/>
</UserControl.Resources>
<StackPanel DataContext="{StaticResource ViewModel}">

Und hier ist der Fehler, den ich bekomme: http://i48.tinypic.com/5u1u8w.png

Bitte beachten Sie, dass dies nicht nur die eine Datei im Screenshot ist, sondern alle Referenzen, die ich auf ähnliche Weise in xaml in allen BenutzersteuerungsFensterdateien dieses Projekts hinzufüge. - /

Die Datei ist also vorhanden, der Namespace in der Datei ist korrekt, der Name des Namespaces/der Klasse in der XAML-Datei ist (meines Wissens nach) korrekt. Ich bekomme Intellisense, wenn ich das xaml eingebe, damit es die Dateien ok findet, aber nicht, wenn es kompiliert wird.

Die häufigste Lösung dafür war die .net-Framework-Version. Für mein Haupt- und Testprojekt ist es derzeit auf .Net Framework 4 eingestellt. Die Vollversion nicht das Client-Profil.

Ich denke, ich habe es vermasselt: Im Konfigurationsmanager ist die Plattform für beide Projekte auf Any CPU gesetzt. Beim Versuch, dieses Problem zu lösen, bemerkte ich jedoch, dass das Hauptprojekt auf x86 und Das Testprojekt wurde auf Any CPU gesetzt. Also habe ich im Konfigurationsmanager jede CPU manuell für das Hauptprojekt hinzugefügt. Ich weiß jedoch nicht, ob ich das richtig gemacht habe oder sogar, ob ich es tun sollte. Gibt es eine zusätzliche Frage: Gibt es eine Möglichkeit, den Konfigurationsmanager auf seinen Standardstatus zurückzusetzen? Wird dies für das Hauptproblem etwas zu sagen haben? Ich weiß nicht, ob das Hauptprojekt immer auf x86 eingestellt war oder nicht oder ob ich es irgendwie in x86 geändert habe und dann kaputt ging. Wie bereits erwähnt, war dieses Projekt eine Zeit lang gut. 

Irgendwelche Vorschläge? Ich beantworte detailliertere Fragen zu Code oder was auch immer Sie fragen, anstatt hier herumzurummeln :)

60
ardal

Jedes Mal, wenn mir das passiert ist, habe ich Visual Studio gerade neu gestartet, die Lösung neu aufgebaut und es hat gut funktioniert. Ich kann nicht sagen, warum

97
gil kr

Neben der Meldung "Im Namespace nicht vorhanden" wurde vom Designer auch die Meldung angezeigt, dass das Fenster für x64- und ARM -Ziele nicht angezeigt werden konnte.

Ich habe gerade herausgefunden, dass das Umstellen des Builds auf den x86-Modus, das Durchführen einer Neuerstellungslösung, das Zurückschalten in den x64-Modus und das erneute Erstellen des Problems dann behebt [beide] Probleme.

Durch das erneute Erstellen der x64-Lösung wurde nichts unternommen.

29
Jerry

Dies hat bei mir in Visual Studio 2012 (Update 3) funktioniert.

  • Starten Sie Visual Studio neu
  • Aktuelle Assembly zur Namespace-Deklaration hinzufügen xmlns:framework="clr-namespace:TimeRecorder.Framework;Assembly=MyAssembly
  • Build -> Build Solution
11
Leon Storey

Was mir dabei geholfen hat (besonders wenn dieser Fehler in App.xaml auftritt), ist Kommentieren Sie die Referenz (en) aus, die Ihnen Probleme bereitet, bauen Sie sie auf, und nehmen Sie dann einen Kommentar auf. I denke was dies erlaubt das gesamte Projekt tatsächlich erstellen, anstatt den Build beim Fehler zu stoppen. 

Die App versucht, die Dateien in einer bestimmten Reihenfolge zu erstellen. Wenn also App.xaml oder vermutlich andere Klassendateifehler in einer Referenz vorhanden sind, wurde die Datei, die den Fehler verursacht, nicht korrekt kompiliert, weshalb dies der Fall ist findet die Datei nicht in diesem Namespace.

9
jaysoncopes

Bauen Sie Ihre Lösung neu auf (manchmal klappt das Bauen besser). Sehen Sie sich dann Ihre Fehlerliste an und blättern Sie ganz nach unten. Dies weist höchstwahrscheinlich auf einen Fehler hin, der die Kompilierung Ihrer Assembly nicht zulässt. Der XAML-Compiler verwendet höchstwahrscheinlich eine zwischengespeicherte Version der Assembly und nicht die neue bedeuten zu bauen.

8
John C

Ich hatte das ähnliche Problem. In meinem Fall musste ich Folgendes tun

  • entfernen Sie das referenzierende Markup von xaml (in diesem Beispiel <local:HistoryViewModel x:Key="ViewModel"/>).
  • die Klasse erstellen (in dieser Beispieldatei, die die Klasse HistoryViewModel enthält)
  • Sobald es erstellt ist, fügen Sie das referenzierende Markup in xaml hinzu
  • wieder bauen

Die obige Methode hat für mich funktioniert. 

7
Chandru

Was für mich funktioniert hat: - Lösungskonfiguration von Debug zu Release wechseln - Konfiguration von Release zu Debug wechseln

5
Hugues

Keine der Lösungen funktionierte für mich. Ich habe es so repariert:

  • Entfernen Sie die DLL der Bibliothek aus den Verweisen
  • Laden Sie den Quellcode der Bibliothek herunter (anstelle der DLL-Datei).
  • Erstellen Sie das Projekt der Bibliothek, um eine neue DLL-Datei zu erhalten
  • Fügen Sie die neue DLL-Datei den Verweisen des Hauptprojekts hinzu
3
Noxxys

Ich habe das Ziel-Framework Meine Anwendung von ".Net Framework 4.5" in ".Net Framework 4.6" geändert und es hat funktioniert!

2
amir stack

Hier ist ein seltsames Beispiel einer ähnlichen Sache:

<UserControl x:Class="Gtl.Ui.Controls.WaitControl"
         xmlns="http://schemas.Microsoft.com/winfx/2006/xaml/presentation"
         xmlns:x="http://schemas.Microsoft.com/winfx/2006/xaml"
         xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
         xmlns:d="http://schemas.Microsoft.com/expression/blend/2008" 
         xmlns:controls="clr-namespace:Gtl.Ui.Controls"
         mc:Ignorable="d" 
         d:DesignHeight="120" d:DesignWidth="120"             
         Background="Transparent">
...
</UserControl>

wird kompilieren (VS2013).

<UserControl x:Class="Gtl.Ui.Controls.WaitControl"
         xmlns="http://schemas.Microsoft.com/winfx/2006/xaml/presentation"
         xmlns:x="http://schemas.Microsoft.com/winfx/2006/xaml"
         xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
         xmlns:d="http://schemas.Microsoft.com/expression/blend/2008" 
         xmlns:controls="clr-namespace:Gtl.Ui.Controls"
         mc:Ignorable="d" 
         d:DesignHeight="120" d:DesignWidth="120"             
         Background="Transparent"
         IsVisibleChanged=onIsVisibleChanged>
...
</UserControl>

erzeugt den Fehler "Typ Ui nicht in Gtl.Ui.Gtl gefunden" (und ich versichere Ihnen, dass die Handler-Methode im Code-Behind vorhanden ist). Um dieses Problem zu umgehen, fügen Sie den Handler im Klassenkonstruktor hinzu. Aber kommen Sie Microsoft, wtf ist im Gange?

2
Julian Gold

Ich hatte das gleiche Problem, als ich den Namespace in xaml aufrufen wollte. zeigte, dass die Klasse nicht im Namespace verfügbar ist. Ich habe viel gesucht. Schließlich fand ich, dass dieses Problem bei VS war. Ich verwende VS 2013 . Ich habe folgende Schritte ausprobiert:

  1. Build -> Configuration Manager -> Active Solution Platform -> Zu x64 und x86 und zu einer beliebigen CPU geändert.
  2. VS geschlossen und wieder geöffnet.
  3. Veränderung

    xmlns:VM="clr-namespace:MyFirstAppViewModel"
    

    zu

    xmlns:VM="clr-namespace:MyFirstAppViewModel;Assembly=ViewModel"
    
2

Hatte sich dieses Problem im Kreis herumgetrieben und ein paar Stunden verschwendet? Ich habe eine separate Benutzersteuerungs-DLL in das Projekt verschoben, sodass sie im Projekt kompiliert wurde und keine DLL, auf die verwiesen wird. Dies hat das gesamte Projekt zerstört, also habe ich alle Namensräume, Pfade und Dateinamen sorgfältig überprüft. Versucht, obj-Dateien zu löschen, zwischen Release und Debug zwischen x86 und AnyCPU zu wechseln. Öffnen, Speichern, alles neu kompilieren, keine Freude.

Denken Sie daran, dass Sie zuvor ein ähnliches Problem hatten. Der in VS2013 markierte Fehler hatte keinen direkten Bezug zu der Stelle, an der ich die XAML-Datei ändern musste

x:Name="myControl"

auf allen Bedienelementen anstelle von

Name="myControl"

behoben.

2
Moon Waxing
  • ich würde empfehlen, x:Key="ViewModel" umzubenennen, vielleicht gibt es eine Störung
  • und wenn Sie local: eingeben, zeigt VS Ihnen HistoryViewModel
  • prüfen Sie auch, ob Ihr Classpublic ist.
1
WiiMaxx

Mit Visual Studio 2017 Community Edition bin ich heute in diese Ausgabe gekommen. Habe alle Vorschläge hier ausprobiert (Reset VS 2017, von x64 auf x32 und wieder zurück usw.) und von anderen Quellen vergeblich. Intellisense weiß, dass alles vorhanden ist, aber ich habe jedes Mal den gleichen Fehler erhalten.

Wie auch immer, mein Fix erwies sich als sehr einfach ... nicht immer, wenn Sie ein paar Stunden mit dem Problem verbracht haben!

Grundsätzlich habe ich Folgendes getan ...

  1. Entfernen Sie den fehlerhaften Code aus der XAML-Datei (in meinem Fall nur 3 Zeilen).
  2. Erstelle ein Projekt, um einen erfolgreichen Build zu erhalten
  3. Zu diesem Zeitpunkt erschien das Layout magisch im Designerfenster, was ein gutes Zeichen war!
  4. Der in Punkt 1 entfernte Code wurde wieder eingefügt, einschließlich des Eintrags xmlns:
  5. An diesem Punkt sollten Sie keine blauen Schnörkel bekommen ... hoffentlich
  6. Bauen Sie das Projekt erneut auf

Es hat den Anschein, dass der Erfolg eines Builds etwas von VS und/oder der Assembly zurücksetzen muss. Wenn Sie einen erfolgreichen Build erstellt haben, fügen Sie den Code erneut ein.

Hoffe das hilft jemandem raus :)

1
DynamicL

Führen Sie einfach die Code-Analyse im Menü Build aus 

1
Ana El Bembo

Ich habe festgestellt, dass das Ausführen des Befehls "Run Code Analysis" alles neu erstellt und behebt das Problem fast immer (Rechtsklick-Projekt> Analysieren> Code-Analyse ausführen). Dies erstellt im Allgemeinen auch die Ressourcendateien neu, sodass Zeichenfolgen usw. gefunden werden können.

0
Jeff

Versuchte alle Lösungen in diesem Thread, aber keine funktionierte. Es stellte sich heraus, dass dies auf die Konfiguration der Lösung zurückzuführen ist. Meine WPF-App wurde für X64 erstellt, da einige systemeigene Abhängigkeiten es erfordern, die Lösungskonfiguration jedoch für das Projekt auf AnyCPU festgelegt wurde .. Das Erstellen einer neuen X64-Konfiguration für das Projekt im Lösungskonfigurationsmanager erlaubte dem XAML-Designer um endlich meinen Typ und meinen Namensraum zu erkennen.

0
Xeaz

Das Problem ist, dass beim Erstellen des x86-Ziels der Ausgabepfad für das bestimmte Projekt auf bin\x86\Debug festgelegt ist. Es sieht so aus, als ob Expression Blend das überhaupt nicht mag. Es scheint nur an was in bin\Debug interessiert zu sein.

Wenn Sie beispielsweise den Ausgabepfad/die Ausgabepfade für das x86-Projekt in bin\debug geändert haben, sind Sie sicher, dass es funktionieren wird. Naja, funktioniert bei mir trotzdem :)

0
RobM

Dies ist ein wiederkehrendes Problem für mich. Einmal habe ich die Lösung gefunden, die auf der Registerkarte Warnung war. Es handelte sich um eine .NET Framework-Version und es wurde Folgendes angegeben:

Warnung 9 Der primäre Verweis "myDll" konnte wegen .__ nicht aufgelöst werden. Es wurde für das Framework ".NETFramework, Version = v4.5.2" entwickelt. Dies ist eine höhere Version als das aktuell anvisierte Framework ".NETFramework, Version = v4.0".

0
André Santaló

Dieser Fehler tritt normalerweise auf, wenn das Projekt beim letzten Build nicht erfolgreich erstellt wurde. 

Schritt-1) Entfernen Sie zunächst den gesamten Fehler verursachenden Code aus der XAML- oder CS-Datei, und erstellen Sie das Projekt, indem Sie die Taste F5 drücken.

Schritt-2) Fügen Sie nach und nach Ihren Fehler verursachenden Code in XAML hinzu.

0

Das Ziel-Framework der hinzugefügten DLL-Datei sollte mit dem Ziel-Framework Ihrer App identisch sein.

0
Shuangpeng Pang

Ich benutzte xmlns: local = "using: MyRootNamespace.ChildNamespace" an der Kopfzeile von .xaml, und ich wandelte es in xmlns: local = "clr-namespace: MyRootNamespace.ChildNamespace" ... nun, ich lasse es einfach verstehen der Job, und es hat funktioniert.

0

Es gibt eine Panne mit der Pufferung der Objektlayouts. Wenn etwas umbenannt oder verschoben wird, geht es verloren. Was für mich am besten funktioniert, ist, eine komplett neue Klasse zu erstellen und den gesamten alten Code zu kopieren, die neue Klasse zum Laufen zu bringen und dann die ursprüngliche Klasse zu entfernen. Manchmal, nachdem Sie den neuen Klassennamen eingerichtet haben, können Sie versuchen, ihn wieder in den ursprünglichen Namen umzubenennen (normalerweise jedoch nicht).

0
DanW