Utilisation de VS2012 travaillant sur une application VB.NET WPF. J'ai une application de didacticiel 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.
Il a 2 classes dans l'application qui sont toutes les deux sous le même espace de noms. Je suis capable de référencer l'espace de noms dans le XAML, mais lorsque j'essaie de référencer l'objet de classe en XAML, j'obtiens une erreur et je ne peux pas compiler.
La chose étrange est que l'IntelliSense fonctionne très bien avec à la fois le référencement de l'espace de noms via la balise xmlns: c = et également lors de la saisie de l'objet de classe en utilisant <c:
Mais l'objet est souligné et des erreurs sont générées en essayant de construire ou de travailler dans le concepteur.
Les fichiers de classe .vb se trouvent dans un dossier appelé \ Controls. L'espace de noms racine du projet principal est laissé vide intentionnellement. La classe est codée comme ceci ...
Namespace MusicPlayer.Controls
Public Class UpdatingMediaElement
.... code here
End Public
End NamespaceLe xaml ressemble à ceci
(espace de noms défini dans la <Window >balise
xmlns:c="clr-namespace:MusicPlayer.Controls"(objet défini en a <Grid>)
<c:UpdatingMediaElement Name="MyMediaElement" />(erreur affichée) Le nom "UpdatingMediaElement" n'existe pas dans l'espace de noms "clr-namespace: MusicPlayer.Controls".
Vous ne savez pas ce qui ne va pas ou comment y remédier?
la source
Réponses:
Lorsque vous écrivez votre code wpf et VS indiquent que "Le nom ABCDE n'existe pas dans l'espace de noms clr-namespace: ABC". Mais vous pouvez totalement construire votre projet avec succès, il n'y a qu'un petit inconvénient car vous ne pouvez pas voir la conception de l'interface utilisateur (ou voulez simplement 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 changer les configurations du projet de Debug à Release ou vice versa.
Après cela, reconstruisez votre solution. Cela peut résoudre votre problème.
la source
Si l'assembly est différent de l'espace de noms dans lequel votre classe est contenue, vous devez le spécifier explicitement.
ex:-
la source
J'ai vu ce problème disparaître en effaçant le cache Xaml Design Shadow. J'ai eu le problème avec Visual Studio 2015 Update 1.
Dans Visual Studio 2015, le cache se trouve ici:
Processus:
Et voila plus d'erreurs d'espace de noms.
la source
Dans mon cas, c'était à cause d' autres erreurs de compilation . Lorsque d'autres erreurs ont été résolues, cette erreur apparemment liée a également été supprimée de la liste. En particulier les erreurs en bas de la liste des erreurs et sur les pages que vous avez récemment modifiées.
la source
Essayez de changer la plate-forme cible de construction en x86 et de créer le projet.
J'ai remarqué via Subversion que j'avais apparemment changé la cible de la plate-forme de construction du projet en x64. C'était le seul changement que j'avais fait. Après avoir apporté cette modification, le code a fonctionné pendant un court moment avant de commencer à afficher la même erreur que vous avez rencontrée. J'ai changé la cible de la plate-forme en x86 pour tester et soudain mon concepteur a recommencé à travailler. Par la suite, je l'ai changé en x64 et le problème a complètement disparu. Je soupçonne que le concepteur crée une sorte de code mis en cache dans x32 et que la modification de la plate-forme de construction x64 le casse lorsque vous modifiez le code.
la source
Je ne sais pas si cela aidera quelqu'un d'autre
Je suis nouveau sur WPF et toujours novice avec VB.net - donc je supposais que cette erreur était causée par le fait que je faisais un sommet stupide ........ supposons que je l'é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. L'erreur a disparu, le projet ne compile parfaitement aucun autre problème - pour le moment. Il semble que VS2015 rencontre toujours des problèmes avec les projets détenus sur un Drive partagé.
la source
Peut-être une autre solution lorsque le projet se compile mais que l'erreur XAML s'affiche:
Pas besoin de reconstruire ou de fermer Visual Studio.
la source
Jésus ... C'est toujours un problème cinq ans plus tard dans Visual Studio 2017. Depuis que je suis nouveau dans WPF, j'étais sûr que le problème venait de moi, mais non, tout était compilé et fonctionnait correctement.
J'ai essayé de reconstruire, nettoyer et reconstruire, basculer entre la sortie x86 / x64, redémarrer Windows, nettoyer le dossier ShadowCache, ajouter "; assembly = {mon nom d'assembly principal}" à la déclaration d'espace de noms XML, rien n'a fonctionné! La seule chose qui a fait:
Mettez ma classe statique de commandes (dans mon cas, l'accord consistait à faire découvrir mes commandes WPF à la conception) dans son assembly séparé et à remplacer le nom de l'assembly par celui-ci.
la source
J'ai eu le même problème, et dans mon cas, la vue de conception de balisage m'a demandé de reconstruire la solution et ne m'a pas montré la mise en page du formulaire avec ce message:,
Design view is unavailable for x64 and ARM target platformsouBuild the Project to update Design view.Il n'est pas résolu en reconstruisant la solution (ni la vue de conception ni l'erreur "Le nom n'existe pas dans l'espace de noms")
Je pense que c'était parce que j'avais 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 travaux:
Je pense que c'est un bogue dans Visual Studio2012 Update 2.
la source
Le même problème afflige Visual Studios 2013, Service Pack 4. Je l'ai également essayé avec Visual Studios 2015 Preview avec les mêmes résultats.
C'est juste une limitation du visualiseur WPF que l'équipe de Visual Studios n'a pas corrigée. Pour preuve, la construction en mode x86 active le visualiseur et la construction en mode x64 le désactive.
Curieusement, intellisense fonctionne pour Visual Studios 2013, Service Pack 4.
la source
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 était dans un dossier réseau , je l'ai déplacée localement et cela a résolu le problème.
Cela peut résoudre d'autres types de problèmes, car il semble que VS 2015 n'aime pas les chemins réseau. Un autre problème qui est un gros problème pour eux est la synchronisation des référentiels git si mon projet est dans un chemin réseau, également résolu en le déplaçant localement.
la source
On dirait que ce problème peut être résolu grâce à diverses «astuces».
Dans mon cas, j'avais construit / reconstruit / nettoyé la solution entière, au lieu du seul projet sur lequel je travaillais dans la solution. Une fois que j'ai cliqué sur "Construire [mon projet]", le message d'erreur a disparu.
la source
Essayez de vérifier vos références d'assemblage. Si vous avez un point d'exclamation jaune sur les références du 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, avoir un projet utilisant le framework 4.5 référence un projet avec le framework 4.5.2 n'est pas une bonne combinaison.
la source
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 "sandbox". Vous pouvez le voir dans la fenêtre de sortie lorsque vous créez. Les DLL sont bloquées si elles sont téléchargées sur Internet. Pour débloquer vos DLL d'assemblage tierces:
Remarque: ne débloquez les DLL que si vous êtes sûr qu'elles sont sûres.
la source
Dans mon cas, le contrôle utilisateur a été ajouté au projet principal. J'ai essayé différentes solutions ci-dessus en vain. Soit j'obtiendrais un balisage invalide mais la solution compilerait et fonctionnerait, soit j'ajouterais le xmlns: c = "clr-namespace: MyProject; assembly = MyProject" et ensuite le balisage montrerait, mais j'obtiendrais une erreur de compilation que le La balise n'existe pas dans l'espace de noms XML.
Enfin, j'ai ajouté un nouveau projet de bibliothèque de contrôle utilisateur WPF à 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'assemblage pour pointer vers la nouvelle bibliothèque et enfin le balisage a fonctionné et le projet compilé sans erreur.
la source
J'ai parcouru toutes les réponses et aucune ne m'a aidé. Finalement, j'ai pu le résoudre par moi-même, présentant ainsi la réponse car elle pourrait aider les autres.
Dans mon cas, la solution avait deux projets, l'un contenant les modèles (disons que le nom du projet et de l'assemblage était Modèles ) et un autre contenant les vues et les modèles de vue (selon notre convention: le projet, le nom de l'assemblage et l'espace de noms par défaut étaient des modèles. ) . Le projet Models.Monitor fait référence.
Dans le projet Models.Monitor, dans l'un des xaml, j'ai inclus l'espace de noms suivant: xmlns: monitor = "clr-namespace: Models.Monitor"
Je soupçonne que MsBuild et Visual Studio se sont alors trompés alors qu'ils essayaient de trouver un type «Moniteur» dans l'assemblage «Modèles» . Pour résoudre, j'ai essayé ce qui suit:
Aucun des éléments ci-dessus n'a fonctionné.
Finalement, j'ai abandonné, et comme un travail autour a déplacé le UserControl que j'essayais d'utiliser vers un autre espace de noms: 'ModelsMonitor' . J'ai pu bien compiler après cela.
la source
Dans mon cas, j'avais un espace de noms et une classe orthographiés exactement de la même manière, donc par exemple, l'un de mes espaces de noms était
qui contient ses propres classes (par exemple firstDepth.secondDepth.Fubar.someclass)
mais j'avais aussi une classe ' Fubar ' dans l'espace de noms
qui résout textuellement le même que l'espace de noms Fubar ci-dessus.
Ne fais pas ça
la source
Dans mon cas, le problème était dû à certains fichiers fantômes dans le répertoire obj du projet. Ce qui suit a résolu le problème pour moi:
la source
J'ai aussi beaucoup de problèmes avec celui-ci! Intellisense m'aide à compléter l'espace de noms et tout, mais le compilateur pleure. J'ai essayé tout ce que j'ai trouvé dans ce fil et dans d'autres. Cependant, dans mon cas, ce qui a aidé à la fin a été d'écrire quelque chose comme ceci:
Laisser le nom d'assemblage vide. Je ne sais pas pourquoi. Mais cela a été mentionné ici. Je dois ajouter que je développe un assembly, donc l'attribut assembly pourrait avoir un sens. Mais entrer le nom de l'assemblage ne fonctionnait pas. Si étrange.
la source
VB.NET n'ajoute pas automatiquement les informations d'espace de noms en fonction de la structure de dossiers comme il le fait dans C #. Je pense que je suis en train de suivre le même tutoriel que vous (Teach Yourself WPF en 24 heures), et de faire la même conversion en VB.
J'ai trouvé que vous devez ajouter manuellement les informations d'espace de noms à la fois à la classe XAML et au code XAML.VB pour pouvoir utiliser les espaces de noms comme décrit dans le livre. Même dans ce cas, VB n'attribue pas automatiquement l'espace de noms à l'assembly comme il le fait dans VB.
Il existe un autre article ici qui montre comment l'inclure dans vos modèles de projet afin de créer automatiquement les informations d'espace de noms - Ajouter automatiquement un espace de noms lors de l'ajout d'un nouvel élément
la source
Dans la page de propriétés de la solution, vérifiez la plate-forme de l'assembly qui contient «UpdatingMediaElement» et les assemblages qui contiennent l'une des 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".
la source
Autre cause possible: un événement post-build supprime la DLL du projet 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 lorsque le nom existe dans l'espace de noms et que le projet se construit et s'exécute très bien si un événement de post-génération supprime la DLL du projet de le dossier de construction (bin \ Debug, bin \ Release, etc.). J'ai une expérience personnelle avec cela dans Visual Studio 2015.
la source
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 correctement 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 recompilé. Plus d'erreurs.
la source
Ajout à la pile.
Le mien était le nom d'assembly de l'application WPF était le même nom d'assembly qu'une DLL référencée. Assurez-vous donc que vous n'avez pas de noms d'assembly en double dans l'un de vos projets.
la source
J'avais la solution stockée sur un partage réseau et chaque fois que je l'ouvrais, j'obtenais un avertissement concernant des sources non fiables. Je l'ai déplacé vers un lecteur local et l'erreur «l'espace de noms n'existe pas» a également disparu.
la source
Essayez également de faire un clic droit sur votre projet-> propriétés et de changer la cible de la plate-forme sur N'importe quel processeur et de reconstruire, cela fonctionnera ensuite. Cela a fonctionné pour moi
la source
Ce problème peut également être causé si l'assembly que vous référencez n'est pas réellement généré. Par exemple, si votre xaml est dans Assembly1 et que vous référencez une classe également dans Assembly1, mais que cet assembly a des erreurs et ne se construit pas, cette erreur sera affichée.
Je me sens ridicule, mais dans mon cas, je déchirais un contrôle utilisateur et j'ai eu toutes sortes d'erreurs dans les classes associées. Alors que j'essayais de tous les corriger, j'ai commencé par les erreurs en question, sans me rendre compte que xaml s'appuie sur des assemblys construits pour trouver ces références (contrairement au code c # / vb qui peut le résoudre avant même de construire).
la source
J'ai fait ajouter l'assemblage en tant que projet - d'abord supprimé le ddl qui a été ajouté spécifiquement aux références à la dll - qui l'a fait.
la source
J'ai ce problème tout le temps. Mes vues sont dans un projet de bibliothèque de contrôles personnalisés WPF (une variante de la bibliothèque de classes). Je peux référencer des assemblys prédéfinis, mais je ne peux référencer aucun code dans un autre projet de la même solution. Dès que je déplace le code vers le même projet que le xaml, il est reconnu.
la source
Dans mon cas, ce problème se produira lorsque l'architecture du programme wpf n'est pas exactement la même avec 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'existe pas", sinon le type dans la dll x64 "n'existe pas". Vous ne pouvez pas les émiler tous les deux.
la source