web-dev-qa-db-fra.com

WPF: le nom n'existe pas dans l'espace de noms

Je construis une application C #/WPF utilisant VS2013 et j'ai la définition de classe suivante (dans le même assembly de l'application en cours d'exécution):

namespace MyNamespace
{
    public class MyKey
    {
        public MyKey() { }
        public string name = "";
    }
}

Dans MainWindow.xaml, j'ai:

<Window x:Class="MyNamespace.MainWindow"
        xmlns="http://schemas.Microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.Microsoft.com/winfx/2006/xaml"
        xmlns:local="clr-namespace:MyNamespace"
        Title="MainWindow" Height="350" Width="525" WindowState="Maximized" WindowStyle="None">
    <Window.Resources>
        <local:MyKey x:Key="key" />
    </Window.Resources>
...

VS continue à signaler que 

Le nom "MyKey" n'existe pas dans l'espace de noms "espace de noms clr: MyNamespace"

Des idées?

P.S. J'ai essayé les solutions suivantes (à partir de questions déjà posées dans stackoverflow) mais aucune d'entre elles n'a fonctionné:

  1. Déplacement de la classe vers un autre espace de noms, puis utilisation du nouvel espace de noms dans la référence xaml
  2. Redémarrage de VS et nettoyage/reconstruction de la solution
  3. nettoyer la solution puis renommer son dossier puis reconstruire la solution
  4. changer la référence en:

xmlns: local = "clr-namespace: MyNamespace; Assembly ="

Édition: Informations complémentaires: Architecture cible: X64, infrastructure cible: .Net 4.5

c#.netwpfxaml
23
Ibraheem

Une solution commune à ce bogue VS connu que vous n'avez pas indiqué comme ayant essayé consiste à modifier la plate-forme cible de génération. 

  1. Si votre plate-forme cible de génération actuelle est x64, passez à x86. S'il s'agit actuellement de x86, passez à x64.

  2. Solution Clean and Build pour la nouvelle plate-forme cible.

  3. Revenez sur la plateforme cible souhaitée et reconstruisez-le. 

50
Gordon True

J'ai eu le même problème dans l'édition VS2012 Express. Résolu le problème en utilisant la commande

"WDExpress/ResetSettings" dans l'invite de commande vs2012.

https://stackoverflow.com/a/33706647/4855197

2
Adeeb Arangodan

Une solution possible consiste à supprimer tous les dossiers .dll de Debug et Release .

Parfois, lorsque vous faites référence au projet, il fait référence aux DLL prédéfinies, même si vous exécutez votre projet en mode débogage.

Supprimez tous les fichiers du dossier debug et release et générez à nouveau ce projet, ajoutez maintenant la référence de ce projet à l’endroit souhaité. A parfaitement fonctionné de mon côté. 

1
Khawaja Asim

Généralement, lorsque je rencontre ce problème, je constate que Visual Studio répertorie les erreurs «erronées» dans la liste des erreurs et me met sur une mauvaise piste. L'examen de la sortie de construction réelle dans la fenêtre de sortie de Visual Studio a révélé l'erreur correcte. 

En bref: Comparez votre résultat de construction avec votre liste d’erreurs.

0
Daniel

Exécution de VS Enterprise 2017 version 15.6.2 Ciblage .Net 4.6.1

J'ai eu le même problème avec une page UserControl xaml où, dans ses ressources, elle essayait de référencer un ValueConverter. L'espace de noms était correct, l'intellisense le déposerait même pour vous, mais le concepteur ne chargerait pas la page et le code ne compilerait pas. J'ai même essayé de déplacer l'un des convertisseurs de valeur hors du fichier et de l'espace de noms en question et de le déplacer vers le code-behind. VS commençait à paniquer au point d'affirmer que la méthode InitializeComponent () du constructeur code-behind était inexistante. 

Ce que je pense avoir finalement résolu pour moi, c’est quand j’ai réalisé que la classe ValueConverter manquait de l’attribut principal comme ceci:

[ValueConversion (typeof (chaîne), typeof (décimal))]

Une fois que j'ai ajouté cette ligne, j'ai fait une solution rapide propre et compilée, puis elle a été compilée et a fonctionné. Puis soudainement le xaml pourrait voir toutes les règles de validation et les convertisseurs de valeur de ce fichier. Et maintenant, je me suis rendu compte que les 3 autres convertisseurs de valeur de ce fichier n’avaient pas non plus d’attribut ValueConversion et pourtant le code est toujours compilé. Peut-être que quelque chose à propos des types entrants dans ce premier convertisseur était vague.

C'est encore un peu un mystère. Je sais que je devrais revenir en arrière et voir si l'erreur est reproductible, mais après avoir lutté contre ce code pendant presque toute la journée, j'en ai eu marre de l'examiner. C'était un ancien projet Prism qui ne fonctionnait pas et je l'ai mis à niveau vers les bibliothèques Prism 7.0. J'avais également essayé de réinitialiser tous les paramètres du processeur sur "Tout processeur". Il s’est plaint de l’amortissement du démarrage, mais je l’avais ignoré. J'avais tout redémarré et tout nettoyé. J'avais même supprimé le dossier .vs. J'aurais probablement dû essayer plus tôt de supprimer carrément les dossiers obj et bin - c'est la seule chose que je n'avais pas faite.

Ce n'était pas mon projet. Normalement, je construis toujours des convertisseurs de valeur, l'un en un fichier portant le même nom. Je ne penserais pas que cela aurait de l'importance, mais toute l'erreur était un peu folle au départ.

0
Kevin Sherrill

J'ai eu un problème similaire. Ce qui a réglé le problème pour moi, c’était de changer les propriétés de construction du projet, c’était ajouté comme référence. Il s'est avéré que la "cible de la plate-forme" avait été modifiée par le passé. Le réglage sur "Tout processeur" et sa reconstruction résolvent l'erreur.

0
karstenp