Le nom n'existe pas dans l'erreur d'espace de nom en XAML
Utilisation de VS2012 sur une application WPF VB.NET. J'ai une application tutorielle MusicPlayer simple que j'utilise pour apprendre WPF. Je suis en train de convertir une version C # du didacticiel en VB.NET, étape par étape.
Elle comporte 2 classes dans l'application qui se trouvent toutes deux sous le même espace de nom. Je suis capable de référencer l'espace de noms dans le code XAML, mais lorsque j'essaie de référencer l'objet de classe dans le code XAML, une erreur survient et je ne parviens pas à compiler.
Ce qui est étrange, c’est que l’IntelliSense fonctionne correctement, à la fois en référençant l’espace de nom via la balise xmlns: c = et en tapant l’objet de classe à l’aide de <c: Mais l’objet est souligné et des erreurs sont générées lors de la création ou de l’utilisation du concepteur.
Les fichiers de classe .vb se trouvent dans un dossier appelé\Controls. L'espace de noms racine du projet principal est intentionnellement laissé vide. La classe est codée comme ça ...
Namespace MusicPlayer.Controls
Public Class UpdatingMediaElement
.... code here
End Public
End Namespace
Le xaml ressemble à ceci
(espace de noms défini dans la balise <Window >
xmlns:c="clr-namespace:MusicPlayer.Controls"
(objet défini dans un <Grid>)
<c:UpdatingMediaElement Name="MyMediaElement" />
(erreur affichée) Le nom "UpdatingMediaElement" n’existe pas dans l’espace de nommage "clr-namespace: MusicPlayer.Controls".
Vous ne savez pas ce qui ne va pas ou comment le réparer?
Lorsque vous écrivez votre code wpf et VS, vous indiquez que "Le nom ABCDE n’existe pas dans l’espace de nommage clr-namespace: ABC". Mais vous pouvez totalement construire votre projet avec succès, il n’ya qu’un petit inconvénient car vous ne pouvez pas voir la conception de l’interface utilisateur (ou vous voulez juste nettoyer le code).
Essayez de faire ceci:
Dans VS, faites un clic droit sur votre solution -> Propriétés -> Propriétés de configuration
Une nouvelle boîte de dialogue s'ouvre. Essayez de modifier les configurations du projet de Debug à Release ou vice versa.
Après cela, reconstruisez votre solution. Cela peut résoudre votre problème.
Si Assembly est différent de l'espace de noms dans lequel votre classe est contenue, vous devez le spécifier explicitement.
ex:-
xmlns:Local="clr-namespace:MusicPlayer.Controls;Assembly=MusicPlayer"
Essayez de changer la plate-forme cible de génération en x86 et de générer le projet.
J'ai remarqué via Subversion que j'ai apparemment changé la cible de la plate-forme de génération de projet en x64. C'était le seul changement que j'avais fait. Après avoir effectué cette modification, le code fonctionnait pendant un court instant avant de commencer à afficher la même erreur que vous. J'ai changé la cible de la plate-forme en x86 pour tester et tout à coup, mon concepteur a de nouveau travaillé. Par la suite, je l'ai rétabli en x64 et le problème a complètement disparu. Je soupçonne que le concepteur crée une sorte de code en cache dans x32 et que le fait de modifier la plate-forme de construction x64 l'enlève lorsque vous apportez des modifications au code.
J'ai vu ce problème disparaître en nettoyant le cache d'observation Xaml Design. J'ai eu le problème avec Visual Studio 2015 Update 1.
Dans Visual Studio 2015, le cache se trouve ici:
%localappdata%\Microsoft\VisualStudio\14.0\Designer\ShadowCache
Processus:
- Cliquez avec le bouton droit sur la solution dans l'explorateur de solutions et choisissez "Nettoyer la solution".
- Arrêter Visual Studio
- Supprimer le dossier ShadowCache
- Rouvert le projet Visual Studio
- Reconstruire la solution
Et voila plus d'erreurs d'espace de noms.
Dans mon cas, c'était à cause de autres erreurs de compilation . Lorsque d’autres erreurs ont été résolues, cette erreur apparemment apparentée a également été supprimée de la liste. Spécialement les erreurs au bas de la liste des erreurs et sur les pages que vous avez récemment modifiées.
Donc, ne faites pas directement attention à cette erreur et concentrez-vous sur autres erreurs au début.
Ne sais pas si cela aidera quelqu'un d'autre
Je suis nouveau sur WPF et je suis toujours un novice avec VB.net - alors j’imaginais que cette erreur était due au fait que je fusse au sommet ridicule ........ supposons que j’étais vraiment! J'ai réussi à m'en débarrasser en déplaçant mon projet d'un lecteur partagé vers l'un de mes lecteurs locaux. Error a disparu, le projet ne compile à la perfection aucun autre problème - pour le moment. On dirait que VS2015 a toujours des problèmes avec les projets conservés sur un lecteur partagé.
Peut-être une autre solution pour quand le projet se compile mais que l'erreur XAML est affichée:
- En solution explorer, sur le nœud de projet contenant le xaml
- Faites un clic droit sur le projet et choisissez 'Décharger le projet'
- Cliquez avec le bouton droit sur le projet et choisissez "Recharger le projet" Assurez-vous que votre projet est toujours choisi comme "projet de démarrage". Si non :
- Cliquez avec le bouton droit sur le projet et choisissez "Définir comme projet de démarrage".
Pas besoin de reconstruire, ou de fermer studio visuel.
Jésus ... C’est toujours un problème cinq ans plus tard dans Visual Studio 2017. Depuis que je suis nouveau à WPF, j’étais persuadé que c’était mon problème, mais non, tout a été compilé et exécuté correctement.
J'ai essayé de reconstruire, de nettoyer et de reconstruire, de basculer entre les sorties x86/x64, de redémarrer Windows, de nettoyer le dossier ShadowCache, d'ajouter "; Assembly = {mon nom principal d'Assembly}" à la déclaration d'espace de noms XML, rien n'a fonctionné! La seule chose qui a fait:
Mettez ma classe de commandes statique (dans mon cas, l’accord visait à faire découvrir la conception à mes commandes WPF) dans son assemblée distincte et en changeant le nom de l’assemblée en celui-ci.
J'ai eu ce problème récemment en utilisant VS 2015 Update 3 pour mon projet WPF dans .NET 4.6.2. La copie de mon projet se trouvait dans un dossier network , je l’ai déplacée localement et le problème a été résolu.
Cela peut résoudre d'autres problèmes, car il semblerait que VS 2015 n'aime pas les chemins d'accès réseau. Un autre problème majeur pour eux est la synchronisation des référentiels git si mon projet se trouve sur un chemin réseau, également résolu en le déplaçant localement.
Le même problème sévit dans Visual Studios 2013, Service Pack 4 . Je l'ai également essayé avec Visual Studios 2015 Preview avec les mêmes résultats.
Il s’agit simplement d’une limitation du visualiseur WPF que l’équipe de Visual Studios n’a pas corrigée ..__ Pour preuve, la création en mode x86 active le visualiseur et celle en mode x64 le désactive.
Curieusement, intellisense fonctionne pour Visual Studios 2013, Service Pack 4.
J'ai eu le même problème et dans mon cas, le Markup Design View m'a demandé de reconstruire la solution et ne m'a pas montré la disposition du formulaire avec le message suivant: Design view is unavailable for x64 and ARM target platforms ou Build the Project to update Design view.
Il ne sera pas résolu en reconstruisant la solution (ni l'erreur "Le nom n'existe pas dans l'espace de nom")
Je pense que c’est parce que j’ai joué avec les paramètres de Solution -> Propriétés> Propriétés de configuration
J'ai finalement résolu le problème avec 2 emplois:
- Cochez toutes les cases de la colonne de construction de la page: Solution -> Propriétés -> Propriétés de configuration
- Changer les configurations de la solution de Debug à Release ou vice versa.
Je pense que c'est un bogue dans Visual Studio2012 Update 2.
On dirait que ce problème peut être résolu par une variété de "trucs".
Dans mon cas, je construisais/reconstruisais/nettoyais toute la solution, au lieu du projet sur lequel je travaillais. Une fois que j'ai cliqué sur "Construire [mon projet]", le message d'erreur a disparu.
La solution pour moi était de débloquer les DLL d'assemblage. Les messages d'erreur que vous obtenez ne l'indiquent pas, mais le concepteur XAML refuse de charger ce qu'il appelle des assemblys "en sandbox". Vous pouvez le voir dans la fenêtre de sortie lorsque vous construisez. Les DLL sont bloquées si elles sont téléchargées à partir d'Internet. Pour débloquer vos DLL d'assemblage tierces:
- Cliquez avec le bouton droit sur le fichier DLL dans l'Explorateur Windows et sélectionnez Propriétés.
- Au bas de l'onglet Général, cliquez sur le bouton ou la case à cocher "Débloquer".
Remarque: Ne débloquez les DLL que si vous êtes sûr qu'elles sont en sécurité.
Dans mon cas, le problème était dû à certains fichiers fantômes situés dans le répertoire obj du projet. Ce qui suit a résolu le problème pour moi:
- Projet propre
- Sortie VS
- rm -rf/obj/*
- Invoquer VS et reconstruire
Dans mon cas, le contrôle utilisateur a été ajouté au projet principal. J'ai essayé diverses solutions ci-dessus en vain. Soit j'obtiendrais Invalid Markup mais la solution compilerait et fonctionnerait, ou j'ajouterais le Xmlns: c = "espace de nom clr: MyProject; Assembly = MyProject", puis l'indication montrerait, mais j'obtiendrais une compilation erreur que la balise n'existe pas dans l'espace de noms XML.
Enfin, j'ai ajouté un nouveau projet WPF User Control Library à la solution et déplacé mon contrôle utilisateur du projet principal vers celui-ci. Ajout de la référence et modification de l'Assemblée pour qu'elle pointe vers la nouvelle bibliothèque. Enfin, le balisage a fonctionné et le projet a été compilé sans erreur.
J'ai parcouru toutes les réponses et personne ne m'a aidé. Enfin, j'ai pu résoudre le problème moi-même, donc présenter la réponse qui pourrait aider les autres.
Dans mon cas, la solution comportait deux projets, l’un contenant les modèles (par exemple, le projet et le nom de l’Assemblée était Modèles) et l’autre contenant les vues et les modèles d’affichage (selon notre convention: projet, Nom de l’Assemblée et valeur par défaut Les espaces de noms étaient Models.Monitor _). Le projet Modèles référé Models.Monitor.
Dans le projet Models.Monitor, dans l'un des fichiers xaml, j'ai inclus l'espace de noms suivant: Xmlns: monitor = "espace de noms clr: Models.Monitor"
Je soupçonne que MsBuild et Visual Studio se sont trompés alors qu'ils essayaient de trouver un type 'Monitor' dans les modèles d'assemblage. Pour résoudre j'ai essayé ce qui suit:
- xmlns: monitor = "espace de noms clr: Models.Monitor; Assembly =" - valide si l'espace de noms se trouve dans le même assemblage, conformément à https://msdn.Microsoft.com/en-us/library/ms747086(v = vs.110) .aspx
- a également essayé la déclaration d'espace de noms explicite: xmlns: monitor = "espace de noms clr: Models.Monitor; Assembly = Models.Monitor"
Aucune de ce qui précède n'a fonctionné.
Enfin, j’ai abandonné, et comme travail autour de a déplacé le UserControl que j’essayais d’utiliser dans un autre espace de noms: 'ModelsMonitor'. J'ai pu compiler bien après ça.
Je reçois ce problème tout le temps. Mes vues sont dans un projet de bibliothèque de contrôles personnalisée WPF (une variante de la bibliothèque de classes). Je peux faire référence à des assemblages prédéfinis, mais je ne peux faire référence à aucun code dans un autre projet de la même solution. Dès que je déplace le code sur le même projet que le xaml, il est reconnu.
Dans mon cas, un espace de noms et une classe étaient épelés exactement de la même manière. Par exemple, un de mes espaces de noms était
firstDepth.secondDepth.Fubar
qui contient ses propres classes (par exemple, firstDepth.secondDepth.Fubar.someclass)
mais j'ai aussi eu une classe ' Fubar ' dans le namespace
firstDepth.secondDepth
qui résout textuellement la même chose que l'espace de noms Fubar ci-dessus.
Ne fais pas ça
Dans la page de propriétés de la solution, vérifiez la plate-forme de l'assembly contenant "UpdatingMediaElement" et les assmeblies contenant les superclasses et interfaces à partir desquelles "UpdatingMediaElement" sous-classe ou implémente. Il apparaît que la plate-forme de tous ces assemblages doit être "AnyCPU".
VB.NET n'ajoute pas automatiquement les informations d'espace de noms basées sur la structure de dossiers, contrairement à C #. Je pense que je suis en train de suivre le même tutoriel que vous (Teach Yourself in 24 Hours) et de faire la même conversion en VB.
J'ai trouvé que vous deviez ajouter manuellement les informations d'espace de noms à Both, la classe XAML et le code XAML.VB pour pouvoir utiliser les espaces de noms comme décrit dans le manuel. Même dans ce cas, VB n'affecte pas automatiquement l'espace de noms à l'assembly comme dans VB.
Il y a un autre article ici qui montre comment inclure cela dans vos modèles de projet pour qu'il génère automatiquement les informations d'espace de noms - Ajouter automatiquement un espace de noms lors de l'ajout d'un nouvel élément
Une autre cause possible: un événement post-génération est la suppression du projet DLL du dossier de génération.
Pour clarifier: le concepteur WPF peut signaler "Le nom XXX n'existe pas dans l'espace de noms ...", même si le nom existe déjà dans l'espace de noms et que le projet se construit et s'exécute parfaitement si un événement post-génération supprime le projet DLL du dossier de construction (bin\Debug, bin\Release, etc.). J'ai une expérience personnelle avec cela dans Visual Studio 2015.
Essayez de vérifier vos références d'assemblage. Si vous avez un point d'exclamation jaune sur les références de projet, il y a un problème et vous obtiendrez toutes sortes d'erreurs.
Si vous savez que la référence du projet est correcte, vérifiez le cadre cible. Par exemple, un projet utilisant le cadre 4.5 fait référence à un projet doté du cadre 4.5.2 n’est pas une bonne combinaison.
Essayez également de cliquer avec le bouton droit de la souris sur votre projet -> Propriétés et de changer la cible de la plate-forme en Tout processeur et de la reconstruire, cela fonctionnera ensuite. Cela a fonctionné pour moi
Ce problème peut également être causé si l’Assemblée à laquelle vous faites référence n’est pas construite. Par exemple, si votre xaml est dans Assembly1 et que vous référencez une classe également dans Assembly1, mais que Assembly a des erreurs et qu'il n'est pas en train de construire, cette erreur sera affichée.
Je me sens bête à ce sujet, mais dans mon cas, j’étais sous le contrôle de l’utilisateur et j’ai eu toutes sortes d’erreurs dans les classes associées. Alors que j'essayais de les corriger tous, j'ai commencé avec les erreurs en question, ne réalisant pas que xaml s'appuyait sur des assemblys construits pour trouver ces références (contrairement au code c #/vb qui peut résoudre ce problème avant même de générer).
J'ai aussi beaucoup de problèmes avec celui-ci! Intellisense m'aide à compléter l'espace de noms et tout le reste, mais le compilateur pleure. J'ai essayé tout ce que j'ai trouvé dans ceci et d'autres discussions. Cependant, dans mon cas, ce qui a aidé à la fin a été d’écrire quelque chose comme ceci: xmlns: util = "espace de noms clr: LiveSpielTool.Utils; Assembly ="
Laissant le nom de l'Assemblée vide. Aucune idée pourquoi. Mais cela a été mentionné ici. Je dois ajouter que je suis en train de développer une assemblée, de sorte que l'attribut Assembly peut avoir un sens. Mais entrer dans le nom de l'Assemblée n'a pas fonctionné. Si étrange.
Dans mon cas, ce problème se posera lorsque l’architechure du programme wpf n’est pas exactement la même chose que la dépendance. Supposons que vous ayez une dépendance x64 et une autre AnyCPU. Ensuite, si vous choisissez x64, le type dans la DLL AnyCPU "n'existera pas", sinon le type dans la DLL x64 "n'existera pas". Vous ne pouvez tout simplement pas les émuler tous les deux.
J'avais ajouté l'Assemblée en tant que projet - d'abord supprimé le ddl ajouté spécifiquement aux références à la dll - qui l'a fait.
Une combinaison de deux idées dans ce fil a fonctionné pour moi, alors je vais poster ce que j'ai fait dans l'espoir que cela aide quelqu'un d'autre au cours des 5 prochaines années à ce que ce problème persiste. J'utilise VS2017 Community)
- Supprimer la référence à la DLL
- Nettoyer, reconstruire, construire
- Fermez VS, débloquez la dll (voir remarque ci-dessous), Supprimez le cache shadow
- Ouvrir le VS, nettoyer, reconstruire, construire
- Restaurer la référence à la DLL
- Nettoyer, reconstruire, construire
Les commandes 2, 4 et 6 ne sont peut-être pas tout à fait exactes, mais je m'attaquais à la paille après avoir passé près de 2 heures à résoudre ce problème. Je pense que la clé pour moi était la combinaison de la suppression de la référence, du déblocage de la dll et de la suppression du cache shadow.
(Note pour l'étape 3 - La dll que j'utilise a été écrite par un de mes collègues/mon mentor, je sais donc qu'elle est sans danger. Faites attention à cette étape si vous ne connaissez pas la source de votre dll) =
Je vais mettre ce sujet dans mes favoris pour la postérité, car il apparaît que MS ne souhaite pas tout nettoyer. WPF est assez difficile à apprendre seul, et avoir à bidouiller des choses comme celles-là quand tout est bien fait est exaspérant. ????????????
La solution était stockée sur un partage réseau et chaque fois que je l’ouvrais, je recevais un avertissement concernant les sources non fiables. Je l'ai déplacé sur un lecteur local et l'erreur "L'espace de noms n'existe pas" a également disparu.
Ajout à la pile.
Mine était le nom d'assembly de l'application WPF était le même nom d'assembly qu'une dll référencée. Veillez donc à ne pas dupliquer les noms d'assemblés dans aucun de vos projets.
Ok, donc aucun de ces conseils n'a fonctionné pour moi, malheureusement. J'ai finalement réussi à résoudre le problème. Il semble que Visual Studio ne fonctionne pas bien avec les lecteurs réseau. J'ai résolu ce problème en déplaçant le projet du lecteur partagé vers mon local et en le recompilant. Pas plus d'erreurs.