Der Name "XYZ" ist nicht im Namensraum "clr-namespace: ABC" vorhanden

Für jeden, der auf dieses Problem stößt, bevor Sie etwas anderes tun ... wenn Sie sicher sind, dass Ihre Klassen/Namespaces korrekt sind und das Wiederherstellen das Problem nicht gelöst hat:

Starten Sie Visual Studio neu

Das ist es!

Dies scheint ein Fehler in Visual Studio 2012 zu sein (betrifft offenbar auch alle anderen Versionen, die XAML-Entwicklung unterstützen.)

Update: Wenn der Neustart von Visual Studio nicht funktioniert, starten Sie den gesamten PC neu.

Update: Wie in den Kommentaren von @Dunk erwähnt, versuchen Sie, die .suo-Datei zu löschen, wenn der Neustart von Visual Studio nicht funktioniert

Das gleiche Problem ist aufgetreten, aber meine Dateien werden lokal gespeichert. Mein IValueConverter befindet sich in einer anderen Assembly als der Ansicht, die es verwendet. Obwohl VS2013 IntelliSense Folgendes vorgeschlagen hat, funktionierte es nicht:

xmlns:conv="clr-namespace:MySharedAssembly.Converters"

Nachdem ich die Versammlung am Ende explizit hinzugefügt habe, hat es funktioniert:

xmlns:conv="clr-namespace:MySharedAssembly.Converters;Assembly=MySharedAssembly"

Ich blieb stundenlang an diesem Fehler fest. Assemblys und Namespaces waren korrekt, Klassen und Referenzen waren ebenfalls korrekt. Kompilieren und ausführen, nur der Designer hatte irgendwie Probleme mit mir. Das einzige, was funktioniert hat

1. für Designzwecke von x64 bis x86
2. für run und debug wechseln Sie wieder zu x64

Ich verwende die 3d party portable.library, die ich nur in der x64-Version hatte.

Heruntergeladene Lösung DLL

1. Entsperren Sie die DLL-Datei
   • Klicken Sie mit der rechten Maustaste darauf und wählen Sie Eigenschaften aus
   • Blockierung auf der Registerkarte "Allgemein" aufheben (siehe Abbildung)
2. Stellen Sie sicher, dass VS die XAML erneut validiert (z. B. durch Neustart).

Es passiert immer noch in VS 2015. Ich habe den SomeConverter in App.xaml herausgenommen:

<Application.Resources>
    <!--Value Converters-->
    <local:SomeConverter x:Key="mySomeConverter"/>

Strg-Shift-B
Setzen Sie es wieder ein - und es hat funktioniert.

Erstellen Sie einen symbolischen Link zur Netzwerkfreigabe auf Ihrem lokalen Laufwerk.

Gehen Sie zur Befehlszeile und geben Sie mklink/D C:\LOCALFOLDER\YOURNETWORKPATH ein

Dann öffnen Sie die Projekte aus Ihrem lokalen Ordner und alle Probleme gehen weg .. Jetzt sind alle Dateien noch auf Ihrer Netzwerkfreigabe. :)

Bevor Sie eine umfassende Lösung ausprobieren, versuchen Sie Folgendes:

Ich hatte genau das gleiche Problem. Ich habe das Fenster/Formular geschlossen, das den Fehler verursacht hat, und dann das Projekt ausgeführt.

Der Fehler schien zu klären, sobald das Projekt erfolgreich ausgeführt wurde und nicht wieder auftaucht.

Hoffentlich hilft dies jedem, der nach einer schnellen Lösung sucht.

Ich habe den gleichen Fehler in Visual Studio 2015 erhalten und konnte den Designer durch Deaktivieren der Schaltfläche "Projektcode deaktivieren" aktivieren.

Ich begann ein neues Projekt und hatte dieses Problem. Keine der hier aufgeführten Lösungen funktionierte für mich, einschließlich Entfernen der suo-Datei, Entladen/erneutes Laden des Projekts, Neustarten von VS usw.

Was für mich funktionierte, war, denn dies war ein neues Projekt, ich hatte es noch nicht gebaut. Ich entfernte das Window.DataContext-Element in die Zwischenablage, erstellte das Projekt einmal (shift-ctrl-b), fügte das Element dann wieder hinzu und es funktionierte sofort.

Nach dem Neustart von Visual Studio erhielt ich einen IntelliSense-Fehler, der mich in die richtige Richtung zeigte.

Weil 'Microsoft.VisualStudio.DesignTools.Xaml.LanguageService.Semantics.Metadata.ReflectionTypeNode' Ist in derselben Assembly implementiert, müssen Sie das x: Name-Attribut .__ festlegen. eher als das Microsoft.VisualStudio.DesignTools.Xaml.LanguageService.Semantics.Metadata.ReflectionPropertyNode Attribut.

Also habe ich das geändert:

<local:MyView Name="test"/>

Zu diesem:

<local:MyView x:Name="test"/>

Und dann hat es funktioniert. Also gibt uns das was? 42 mögliche Ursachen? Unwirklich...

Ich habe auch ein Projekt auf einer Netzwerkfreigabe, und dieser Fehler wurde unerwartet angezeigt. Ich habe alle oben genannten Vorschläge ausprobiert, einschließlich des Kopierens des Projekts auf eine lokale Festplatte, Reinigen, Wiederherstellen und Öffnen und Schließen von VS. Nichts davon löste das Problem. 

Was für mich funktionierte, war einfach das Entfernen des Namespaces auf den Ordner "viewmodels" (xlmns: vm = "clr-namespace: Myproj.ViewModel").

Ich habe den Typ zu meinem Xaml hinzugefügt (DataTemplate DataType = "{x: Type vm: myviewmodel}"). Visual Studio stellte dann fest, dass der Namespace fehlte, und ich klickte auf die Aufforderung, um den Namespace hinzuzufügen. 

Für alle anderen stecken. 

Was für mich funktionierte, war das Ändern des Namensraum-Alias ​​von local zu irgendetwas anderem.

xmlns:local="clr-namespace:ExampleNameSpace.Folder" />

<Grid>
    <StackPanel>
        <local:ReferencedUserControl />
    </StackPanel>
</Grid>

zu 

xmlns:blah="clr-namespace:ExampleNameSpace.Folder" />

<Grid>
    <StackPanel>
        <blah:ReferencedUserControl />
    </StackPanel>
</Grid>

Hoffe das hilft!

Was für mich funktionierte, war das Ändern derMOVEinXCOPYinPost Buildimproject propertiesund dannre-builddes Projekts. Der Designer möchte möglicherweise die DLL im Projektausgabeordner. ich benutze vs 2015

Hatte das gleiche Problem. Das Problem wurde behoben, als mir klar wurde, dass die betreffende Klasse als internal markiert wurde:

internal class MyClass
{
}

Nach dem Ändern in public konnte der Designer die XAML ordnungsgemäß kompilieren.

Ich hatte 3 Fehler in dem Projekt und konzentrierte mich auf diesen Fehler in Bezug auf den ObjectDataProvider. Ich habe herausgefunden, dass dieser Fehler nicht behoben werden kann, wenn das Projekt aufgrund anderer Fehler nicht erstellt werden kann. Ich hatte ein paar andere Event-Handler, deren Code gelöscht wurde. Ich musste auch den Code löschen, mit dem versucht wurde, die Handler mit den Steuerelementen zu verknüpfen. Anschließend konnte das Projekt erstellen und feststellen, dass die Klasse, auf die ich mich von ObjectDataProvider aus bezog, verfügbar war.

Das nervt mich seit Jahren 2008, 10, 12, 13.

Immer wenn dies geschieht (und ja, ich arbeite an einer Netzwerkfreigabe - ich kann es nicht vermeiden), schließe ich VS, benenne den Ordner um und nenne das Projekt erneut. 9 mal von 10, das funktioniert. Für eine Weile.

Die Erklärung in einem Ressourcenwörterbuch funktionierte für mich.

<Window.Resources>
    <c:IsNullConverter x:Key="IsNullConverter" />
</Window.Resources>

Das Problem scheint zu sein, dass der Parser sich selbst scheißt, wenn er eine Markup-Erweiterung wie Converter={c:IsNullConverter}}" sieht, aber mit Converter={StaticResource IsNullConverter} in Ordnung ist. Ich glaube, vielleicht liegt das Problem darin. 

Windows 10, VS 2013

Der Name "XYZ" existiert nicht im Namensraum "clr-namespace: ABC"

Gelöst !!

prüfen Sie, ob die aufzurufende Funktion/die Klasse im Namensraum vorhanden ist 

Richtiges Beispiel:

.XAML-Datei

          <Window x:Class="objectbinding.MainWindow"
           <!--your xmlns:x .......
           namespace1 is the project name-->
           xmlns:m="clr-namespace:namespace1"
            Title="MainWindow" Height="350" Width="525">
    <Grid>
 <StackPanel Orientation="Vertical">
            <StackPanel.Resources>
                <ObjectDataProvider ObjectType="{x:Type m:StringData}"
                                    x:Key="anyname" MethodName="GetStrings"/>

            </StackPanel.Resources>

       ItemsSource="{Binding Source={StaticResource Runni}}" />
        </StackPanel>
    </Grid>

// StringData ist der Klassenname in xaml.cs und GetString ist die Funktion

.XAML.CS-Datei

 namespace namespace1
    {

        public partial class MainWindow : Window
        {
            public MainWindow()
            {
                InitializeComponent();
            }

        }
// the class StringData is defined in namespace namespace 1
        public class StringData
        {
            ObservableCollection<String> lst = new ObservableCollection<String>();

            public StringData()
            {
                lst.Add("Abhishek");
                lst.Add("Abhijit");
                lst.Add("Kunal");
                lst.Add("Sheo");
            }
            public ObservableCollection<String> GetStrings()
            {
                return lst;
            }
        }
    }

Falsches Beispiel:

.XAML-Datei

  <Window x:Class="objectbinding.MainWindow"
              <!--your xmlns:x .......
           namespace1 is the project name-->
           xmlns:m="clr-namespace:namespace1"
            Title="MainWindow" Height="350" Width="525">
    <Grid>
 <StackPanel Orientation="Vertical">
            <StackPanel.Resources>
                <ObjectDataProvider ObjectType="{x:Type m:StringData}"
                                    x:Key="anyname" MethodName="GetStrings"/>

            </StackPanel.Resources>

       ItemsSource="{Binding Source={StaticResource Runni}}" />
        </StackPanel>
    </Grid>

.XAML.CS 

namespace namespace1
{

    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
        }
//The StringData is defined in the class mainWindow not in namespace namespace1
        public class StringData
        {
            ObservableCollection<String> lst = new ObservableCollection<String>();

            public StringData()
            {
                lst.Add("Abhishek");
                lst.Add("Abhijit");
                lst.Add("Kunal");
                lst.Add("Sheo");
            }
            public ObservableCollection<String> GetStrings()
            {
                return lst;
            }
        }
    }

}

In meinem Fall wurde dieser Fehler dadurch verursacht, dass signierte Baugruppen mit aktiviertem 'delay sign only' aktiviert wurden. Die Lösung bestand darin, den Befehl sn -Vr * von der Entwicklerkonsole (als Administrator) auszuführen. Dadurch wird die Assembly für das Überspringen der Überprüfung registriert. Starten Sie anschließend Visual Studio neu.