le nom <...> n'existe pas dans l'espace de noms clr-namespace <...>
J'ai une petite application WPF qui, auparavant, compilait parfaitement mais ne l'est plus. Je ne peux pas vraiment dire à quel point il a cessé de construire. Cela a bien fonctionné un jour et le lendemain, ce n'est pas le cas.
Voici la structure du projet:
Il n’existe pas d’autres projets ou références externes autres que les dll standard .net.
Voici le contrôle de l'utilisateur d'où provient le problème:
<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}">
Et voici l'erreur que j'obtiens: 
Veuillez noter qu'il ne s'agit pas du seul fichier de la capture d'écran, mais de toutes les références que j'ajoute de la même manière en xaml dans tous les fichiers de contrôle/fenêtre de l'utilisateur de ce projet.
Donc, le fichier est là, l'espace de nom dans le fichier est correct, le nom d'espace de nom/classe dans le fichier xaml est (à ma connaissance) correct. J'obtiens intellisense quand je tape le xaml pour qu'il trouve les fichiers ok alors mais pas quand il compile.
La solution la plus courante pour cela dans d’autres publications est la version du framework .net. Il est actuellement défini sur .Net Framework 4 pour mon projet principal et mon projet de test. La version complète n'est pas le profil du client.
Voici ce que je crois que je me suis trompé: Dans le gestionnaire de configuration, la plate-forme des deux projets est définie sur N'importe quel processeur, mais lorsque j'ai essayé de résoudre ce problème, j'ai remarqué que le projet principal était défini sur x86 et le projet de test a été défini sur N'importe quel processeur. J'ai donc ajouté manuellement n'importe quel processeur pour le projet principal dans le gestionnaire de configuration. Cependant, honnêtement, je ne sais pas si je l'ai fait correctement ou même si je devrais le faire. En guise de question supplémentaire, y a-t-il un moyen de réinitialiser le gestionnaire de configuration à son état par défaut? Cela aura-t-il quelque chose à dire pour le problème principal? Je ne sais pas si le projet principal a toujours été défini sur x86 ou non, ou si je l'ai changé d'une manière ou d'une autre en x86, puis il est tombé en panne. Comme mentionné, ce projet compilait parfaitement pendant un moment.
Aucune suggestion? Je vais répondre à des questions plus détaillées sur le code ou sur ce que vous demandez au lieu de vous perdre ici :)
Chaque fois que cela m'est arrivé, je viens de redémarrer Visual Studio, de reconstruire la solution et tout a bien fonctionné. Je ne peux pas dire pourquoi.
En plus du message "n'existe pas dans l'espace de noms", le concepteur m'avait également indiqué qu'il ne pouvait pas afficher la fenêtre pour les cibles x64 et ARM.
Je viens de constater que passer de la génération au mode x86, effectuer une solution de reconstruction, puis revenir en mode x64 puis reconstruire à nouveau corrige [les deux] problèmes.
Reconstruire simplement la solution x64 n'a rien fait.
C'est ce qui a fonctionné pour moi sur Visual Studio 2012 (mise à jour 3).
- Redémarrer Visual Studio
- Ajouter l'assembly actuel à la déclaration d'espace de nom
xmlns:framework="clr-namespace:TimeRecorder.Framework;Assembly=MyAssembly Build->Build Solution
Ce que j’ai trouvé qui a aidé (surtout si cette erreur se produit dans App.xaml) est de commenter la ou les références qui vous posent problème, reconstruire, puis supprimer le commentaire.} I pense à quoi cela permet, l’ensemble du projet à construire au lieu d’arrêter la construction à l’erreur.
D'après ce que je peux comprendre, l'application tente de construire les fichiers dans un certain ordre. Ainsi, lorsque App.xaml ou probablement toute autre erreur de fichier de classe dans une référence, le fichier à l'origine de l'erreur n'a pas été compilé correctement. ne trouve pas le fichier dans cet espace de noms.
Reconstruisez votre solution (parfois propre, alors que la construction fonctionne mieux). Regardez ensuite votre liste d’erreurs, faites défiler vers le bas et cela indiquera probablement une erreur qui ne permet pas à votre Assembly de compiler, et le compilateur XAML utilise probablement une version en cache de Assembly, signifie construire.
J'ai eu le même problème. Dans mon cas, je devais faire ce qui suit
- supprimer le balisage de référence de xaml (dans cet exemple,
<local:HistoryViewModel x:Key="ViewModel"/>) - construire la classe (dans cet exemple, le fichier qui contient la classe
HistoryViewModel) - Une fois construit, ajoutez le balisage de référence dans xaml
- reconstruire
La méthode ci-dessus a fonctionné pour moi.
Ce qui a fonctionné pour moi: - Basculer la configuration de la solution de Debug à Release - Basculer à nouveau de la configuration de Release à Debug
Aucune des solutions n'a fonctionné pour moi. Je l'ai corrigé de cette façon:
- Supprimer la DLL de la bibliothèque des références
- Téléchargez le code source de la bibliothèque (au lieu du fichier dll)
- Construisez le projet de la bibliothèque pour obtenir un nouveau fichier dll
- Ajouter le nouveau fichier DLL aux références du projet principal
J'ai changé le cadre cible Mon application de ".Net Framework 4.5" à ".Net Framework 4.6" et tout a fonctionné
Voici un exemple étrange d'une chose similaire:
<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>
va compiler (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>
produit l'erreur "type Ui introuvable dans Gtl.Ui.Gtl" (et je vous assure que la méthode de gestion existe dans code-behind). La solution consiste à ajouter le gestionnaire dans le constructeur de la classe, mais est-ce que Microsoft, wtf se passe?
J'ai rencontré le même problème lorsque j'essayais d'appeler l'espace de noms dans xaml. montrait que la classe n'est pas disponible dans l'espace de noms. J'ai beaucoup cherché. Finalement, j'ai trouvé que ce problème était avec VS. J'utilise VS 2013 . J'ai essayé les étapes suivantes:
- Construire -> Gestionnaire de configuration -> Plate-forme de solution active -> Modifié en x64 et x86 et en tout processeur.
- Fermé le VS et rouvert.
Changement
xmlns:VM="clr-namespace:MyFirstAppViewModel"à
xmlns:VM="clr-namespace:MyFirstAppViewModel;Assembly=ViewModel"
Avait ce problème tourner en rond perdre quelques heures. J'ai déplacé une dll de contrôle utilisateur distinct dans le projet afin qu'il soit compilé dans le projet et non une dll référencée. Cela a cassé le projet dans son ensemble et j'ai ensuite vérifié méticuleusement tous les espaces de noms, chemins et noms de fichiers. J'ai essayé de supprimer des fichiers obj, en changeant entre release et debug, entre x86 et AnyCPU. Ouverture en sauvant tout, recompiler toujours pas de joie.
N'oubliez pas que vous aviez un problème similaire auparavant, l'erreur signalée dans VS2013 n'était pas directement liée à l'endroit où je devais modifier le XAML, mais en utilisant
x:Name="myControl"
sur tous les contrôles, au lieu de
Name="myControl"
corrigé.
- je recommanderais de renommer
x:Key="ViewModel"peut-être qu'il y a un petit problème - et si vous tapez
local:, VS vous montrera-t-ilHistoryViewModel? - vérifiez également si votre
Classestpublic
Nous avons abordé ce problème aujourd'hui avec Visual Studio 2017 Community Edition. Essayé toutes les suggestions ici (réinitialiser VS 2017, changé de x64 à x32 et retour à nouveau etc etc) et d'autres sources en vain. Intellisense sait que tout est là, mais la même erreur se reproduisait à chaque fois.
Quoi qu'il en soit, ma solution s'est révélée très simple ... n'est-ce pas toujours lorsque vous avez passé quelques heures à résoudre le problème!
En gros, j'ai fait ce qui suit ...
- Supprimer le code fautif du fichier xaml (seulement 3 lignes dans mon cas)
- Construire le projet pour que votre construction soit réussie
- À ce stade, la mise en page est apparue comme par magie dans la fenêtre du concepteur, ce qui était bon signe!
- Réinsertion du code que j'ai supprimé au point 1., y compris l'entrée xmlns:
- À ce stade, vous ne devriez pas avoir de gribouillis bleus ... espérons-le
- Construire le projet à nouveau
Il semble que pour réussir, il faut réinitialiser "quelque chose" dans VS et/ou dans l’Assemblée. Une fois que vous avez réussi à construire, essayez d’insérer votre code à nouveau.
J'espère que ça aide quelqu'un :)
Il suffit d’exécuter l’analyse de code à partir de Build menu
J'ai constaté que l'exécution de la commande "Exécuter l'analyse de code" reconstruit tout et corrige presque toujours le problème (projet avec le clic droit> Analyser> Exécuter l'analyse de code). Cela reconstruit aussi généralement les fichiers de ressources afin que des chaînes, etc. puissent être trouvées.
J'ai essayé toutes les solutions sur ce fil, mais aucune n'a fonctionné. Cela a été causé par la configuration de la solution. Mon application WPF a été configurée pour générer pour X64 en raison de certaines dépendances natives qui l'exigent mais la configuration de la solution était toujours définie sur AnyCPU pour le projet . pour enfin reconnaître mon type et mon espace de noms.
Le problème est que lorsque vous créez la cible x86, le chemin de sortie du projet particulier est défini sur bin\x86\Debug. On dirait que le mélange d'expression n'aime pas ça du tout. Il semble ne s'intéresser qu'à ce qui se trouve dans bin\Debug.
Si vous avez modifié votre chemin de sortie pour le projet x86 en bin\debug par exemple, je suis sûr que vous constaterez que cela fonctionnera. Eh bien, ça marche pour moi quand même :)
C'est un problème récurrent pour moi. Une fois, j'ai trouvé la solution en regardant dans l'onglet Warning. Il s'agissait d'un problème de version du framework .NET et indiquait ce qui suit:
Avertissement 9 La référence principale "myDll" n'a pas pu être résolue car il a été construit sur le framework ".NETFramework, Version = v4.5.2" . Ceci est une version supérieure au framework actuellement ciblé ".NETFramework, Version = v4.0".
Cette erreur se produit généralement lorsque le projet n'a pas été généré avec succès lors de la dernière génération.
Étape 1: Commencez par supprimer tout le code causant l’erreur du fichier XAML ou .cs, puis générez et démarrez le projet en appuyant sur F5.
Étape 2) Ajoutez votre code d'erreur XAML un par un.
La structure cible du fichier .dll que vous ajoutez doit être identique à la structure cible de votre application.
J'utilisais xmlns: local = "using: MyRootNamespace.ChildNamespace" dans l'en-tête du fichier .xaml et je l'ai transformé en xmlns: local = "clr-namespace: MyRootNamespace.ChildNamespace" le travail, et cela a fonctionné.
Il y a un petit problème avec leur mise en mémoire tampon de la disposition des objets. Si quelque chose est renommé ou déplacé, il est perdu ... Ce qui fonctionne généralement pour moi est de créer une toute nouvelle classe et de la copier dans tout l'ancien code, de le faire fonctionner sur la nouvelle classe, puis de supprimer la classe d'origine. Parfois, une fois que vous l'utilisez avec le nouveau nom de classe, vous pouvez essayer de le renommer en lui donnant le nom d'origine (mais généralement pas).