Obtenir "le type ou le nom de l'espace de noms est introuvable" mais tout semble correct?

Je reçois un:

le nom du type ou de l'espace de noms est introuvable

erreur pour une application C # WPF dans VS2010. Cette zone de code se compilait bien, mais tout à coup, je reçois cette erreur. J'ai essayé de supprimer la référence du projet et l' usinginstruction, en fermant VS2010 et en redémarrant, mais j'ai toujours ce problème.

Des idées pourquoi cela pourrait se produire, où il semble que je fais la bonne chose concernant la référence et la usingdéclaration?

J'ai également noté dans VS2010 que l'intellisense pour cet espace de noms fonctionne correctement, il semble donc que VS2010 ait la référence du projet et voit l'espace de noms d'une part, mais pendant la compilation, ne le voit-il pas?

Cela peut être le résultat d'une incompatibilité de version du framework .Net entre deux projets.

Cela peut se produire de deux manières:

1. un projet de profil client référençant un projet cadre complet; ou
2. une version de framework plus ancienne ciblant une version de framework plus récente

Par exemple, cela se produit lorsqu'une application est définie pour cibler le framework de profil client .Net 4 et que le projet auquel elle fait référence cible le framework .Net 4 complet.

Donc, pour que ce soit plus clair:

• Le projet A cible le cadre du profil client
• Le projet A fait référence au projet B
• Le projet B cible le cadre complet

La solution dans ce cas consiste soit à mettre à niveau la cible de framework de l'application (projet A), soit à rétrograder la cible de l'assembly référencé (projet B). Il est correct pour une application de framework complet de référencer / consommer un assembly de framework de profil client, mais pas l'inverse (le profil client ne peut pas faire référence à un assembly ciblé de framework complet).

Notez que vous pouvez également obtenir cette erreur lorsque vous créez un nouveau projet dans VS2012 ou VS2013 (qui utilise .Net 4.5 comme infrastructure par défaut) et:

• le ou les projets de référence utilisent .Net 4.0 (cela est courant lorsque vous avez migré de VS2010 vers VS2012 ou VS2013 et que vous ajoutez ensuite un nouveau projet)

• les projets référencés utilisent une version supérieure, c'est-à-dire 4.5.1 ou 4.5.3 (vous avez redirigé vos projets existants vers la dernière version, mais VS crée toujours de nouveaux projets ciblant la v4.5, et vous référencez ensuite ces anciens projets à partir du nouveau projet)

La réinstallation des paquets nuget a fait l'affaire pour moi. Après avoir modifié les versions de .NET Framework pour qu'elles soient synchronisées pour tous les projets, certains packages de nuget (en particulier Entity Framework) étaient toujours installés pour les versions précédentes. Cette commande dans la console du Gestionnaire de packages réinstalle les packages pour l'ensemble de la solution:

Update-Package –reinstall

Je ne sais pas pourquoi cela a fonctionné, mais j'ai supprimé la référence de projet que VS2015 me disait qu'il ne pouvait pas trouver et l'ai ajoutée à nouveau. Résolu le problème. J'avais essayé de nettoyer, de construire et de redémarrer VS en vain.

Lors de la création de la solution, j'obtenais la même erreur (le type ou l'espace de noms '' est introuvable). En dessous, j'ai vu un avertissement indiquant que "la référence n'a pas pu être résolue" et pour m'assurer que "l'assemblage existe sur le disque".

J'étais très confus, car ma DLL était très clairement à l'emplacement vers lequel la référence pointait. VS n'a pas semblé mettre en évidence d'erreurs, jusqu'à ce que j'essaie de construire la solution.

J'ai finalement réalisé le problème (ou du moins ce que je soupçonne être le problème). Je construisais le fichier de bibliothèque dans la même solution. Donc, même s'il existait sur le disque, il était en cours de reconstruction à cet emplacement (d'une manière ou d'une autre dans le processus de reconstruction de la bibliothèque mon autre projet - dans la même solution - qui faisait référence à la bibliothèque doit avoir décidé que la bibliothèque n'existait pas)

Lorsque j'ai cliqué avec le bouton droit sur le projet et créé cela uniquement, au lieu de la solution entière, je n'ai pas eu l'erreur.

Pour résoudre ce problème, j'ai ajouté la bibliothèque en tant que dépendance au projet qui l'utilisait.

Pour faire ça:

1. J'ai fait un clic droit sur ma solution dans l'explorateur de solutions et j'ai sélectionné "Propriétés"
2. Ensuite, dans "Propriétés communes", j'ai sélectionné "Dépendances du projet".
3. Ensuite, dans le menu déroulant Projets, j'ai sélectionné le projet qui dépendait de la bibliothèque, et
4. Coché la case à côté de la bibliothèque trouvée sous "Dépend de"

Cela garantit que le projet de bibliothèque est construit en premier.

Je vérifierais d'abord que les informations générées par votre projet ne sont pas corrompues. Faites un nettoyage et reconstruisez votre solution.

Si cela n'aide pas, une chose que j'ai vue dans le passé pour les problèmes de concepteur est d'ouvrir un projet Windows Forms, puis de le refermer. C'est un peu de poulet-entrailles-ish, cependant, ne retenez pas votre souffle.

J'ai rencontré une situation plus délicate: le premier projet cible le framework complet 4.0 avec le Microsoft.Bcl.Asyncpackage installé. Project Two cible le framework complet 4.0 mais ne compilerait pas lors de la référence à une classe Project One.

Une fois que j'ai installé le package Async NuGet sur le deuxième projet, il s'est correctement compilé.

Dans mon cas, je trouve que la référence dans le VisualStudio a un triangle et un point d'exclamation comme cette image,

puis, je clique avec le bouton droit sur le supprimer et ajoute à nouveau la référence dll correctement, le problème a été résolu.

Celui-ci a fonctionné pour moi. Dans votre classe, où le nom de classe est défini, par exemple: Classe publique ABC, supprimez un caractère et attendez un peu. Votre liste d'erreurs augmentera car vous avez changé le nom. Remettez maintenant le caractère que vous avez tapé. Cela a fonctionné pour moi, j'espère que cela fonctionnera aussi pour vous. Bonne chance!!!

J'ai eu un problème similaire: le compilateur n'a pas pu détecter un dossier dans le même projet , donc une directive using reliant à ce dossier a généré une erreur. Dans mon cas, le problème provenait de renommer le dossier . Même si j'ai mis à jour l'espace de noms de toutes les classes à l'intérieur de ce dossier, les informations sur le projet n'ont pas réussi à se mettre à jour. J'ai tout essayé: supprimer le fichier .suo et les dossiers bin et obj, nettoyer la solution, recharger le projet - rien n'y fait. J'ai résolu le problème en supprimant le dossier et les classes à l'intérieur, en créant un nouveau dossier et en créant de nouvelles classes dans ce nouveau dossier (simplement déplacer les classes à l'intérieur du nouveau dossier n'a pas aidé).

PS: Dans mon cas, je travaillais sur une application Web, mais ce problème peut se produire dans différents types de projets.

[Facepalm] Mon problème était que j'avais ajouté la dépendance dans la façon de faire C ++.

Accédez au projet qui ne sera pas généré, ouvrez le dossier «Références» dans l'Explorateur de solutions et voyez si votre dépendance est répertoriée.

Sinon, vous pouvez 'Ajouter une référence' et choisir la dépendance dans l'onglet Projets.

Boom Shankar.

Nous avons eu un cas étrange de cela que je viens de corriger dans une solution. Il y avait un caractère caché / espace devant une instruction "using" dans le projet principal. Ce projet se développerait bien et le site Web fonctionnait bien, mais le projet de test unitaire qui y faisait référence ne pouvait pas être construit.

J'ai rencontré ce problème lors de la mise à niveau des projets existants de VS2008 vers VS2012. J'ai trouvé que deux projets (les deux seuls que j'ai créés) ciblaient différents cadres .Net (3.5 et 4.0). J'ai résolu ce problème dans l'onglet Application des projets en m'assurant que les deux projets avaient «.NET Framework 4» dans la zone Framework cible.

J'ai eu les mêmes erreurs, mon histoire était la suivante: après une mauvaise fusion (via git), l'un de mes fichiers .csproj avait des compileentrées en double comme:

<Compile Include="Clients\Tree.cs" />
<Compile Include="Clients\Car.cs" />
<Compile Include="Clients\Tree.cs" />        //it's a duplicate

Si vous avez une grande solution et plus de 300 messages dans la fenêtre des erreurs, il est difficile de détecter ce problème. J'ai donc ouvert le fichier .csproj endommagé via le bloc-notes et supprimé les entrées en double. A travaillé dans mon cas.

J'ai eu le même problème que celui discuté: VS 2017 souligne une classe dans le projet référencé comme une erreur mais la solution fonctionne correctement et même l'intellisense fonctionne.

Voici comment j'ai réussi à résoudre ce problème:

1. Déchargez le projet référencé
2. Ouvrez le fichier .proj dans VS (je cherchais des doublons comme quelqu'un l'a suggéré ici)
3. Recharger à nouveau le projet (je n'ai pas modifié ni même enregistré le fichier proj car je n'ai pas de doublons)

Vous pouvez également essayer d' éliminer le code que vous pensez que vous avez des problèmes avec et voir si elle compile sans références à ce code. Sinon, corrigez les choses jusqu'à ce qu'il se compile à nouveau, puis réintégrez votre code de problème suspect . Parfois, j'obtiens des erreurs étranges sur les classes ou les méthodes que je connais sont correctes lorsque le compilateur n'aime pas autre chose. Une fois que j'ai résolu le problème auquel il est vraiment accroché, ces erreurs «fantômes» disparaissent.

Je sais que c'est donner un coup de pied à un cheval mort mais j'ai eu cette erreur et les cadres étaient bien. Mon problème était essentiellement de dire qu'une interface ne pouvait pas être trouvée, mais elle se construisait et accédait très bien. Alors je me suis mis à penser: "Pourquoi cette interface quand les autres fonctionnent bien?"

Il s'est avéré que j'accédais à un service à l'aide de WCF avec une interface de point de terminaison qui utilisait Entity Version 6 et que le reste des projets utilisaient la version 5. Au lieu d'utiliser NuGet, j'ai simplement copié les packages de nuget dans un référentiel local pour les réutiliser et les a énumérés différemment.

par exemple EntityFramework6.dll contre EntityFramework.dll .

J'ai ensuite ajouté les références au projet client et pouf, mon erreur a disparu. Je me rends compte que c'est un cas limite car la plupart des gens ne mélangeront pas les versions d'Entity Framework.

Ajouter ma solution au mix car c'était un peu différent et ça m'a pris du temps à comprendre.

Dans mon cas, j'ai ajouté une nouvelle classe à un projet, mais comme mes liaisons de contrôle de version n'étaient pas définies, j'avais besoin de rendre le fichier accessible en écriture en dehors de Visual Studio (via le VC). J'avais annulé la sauvegarde dans Visual Studio, mais après avoir rendu le fichier accessible en écriture en dehors de VS, j'ai à nouveau appuyé sur Enregistrer tout dans VS. Par inadvertance, le nouveau fichier de classe n'a pas été enregistré dans le projet .. cependant..Intellisense l'a toujours affiché comme bleu et valide dans les projets de référence même si, lorsque j'essayais de recompiler, le fichier n'était pas trouvé et obtenait le erreur de type introuvable. La fermeture et l'ouverture de Visual Studio montraient toujours le problème (mais si j'avais pris note que le fichier de classe manquait à la réouverture).

Une fois que j'ai réalisé cela, la correction était simple: avec le fichier de projet défini en écriture, j'ai lu le fichier manquant dans le projet. Tout va bien maintenant.

J'ai eu le même problème. Une nuit, mon projet compilerait les ERREURS du lendemain matin!.

J'ai finalement découvert que Visual Studio avait décidé de "modifier" certaines de mes références et de les pointer ailleurs. par exemple:

System.ComponentModel.ISupportInitialize est devenu en quelque sorte "blahblah.System.ComponentModel.ISupportInitialize"

Une chose assez grossière pour vs à faire si vous comme moi

Cet événement se produit dans Visual Studio 2017.

1. Redémarrez Visual Studio
2. Projet propre qui ne parvient pas à construire.
3. Reconstruisez le projet.

Mon cas était le même que celui discuté ici, mais rien ne l'a résolu jusqu'à ce que j'aie supprimé la System.Coreréférence de la liste des références (Tout fonctionnait bien sans)

j'espère que cela aidera quelqu'un parce que ce problème est assez frustrant

Pour résoudre ce problème, il peut également aider à supprimer et recréer le *.sln.DotSettingsfichier de la solution associée.

Dans mon cas, j'avais une classe qui était répertoriée dans le dossier source approprié, mais ne s'inscrivait pas dans l'Explorateur de solutions. Je devais faire un clic droit sur le projet> Ajouter un élément existant et sélectionner manuellement cette classe, il a dit qu'il manquait. Ensuite, tout a bien fonctionné!

Dans mon cas, le problème était qu'après avoir changé l'espace de noms pour qu'il soit exactement le même que dans un autre projet (intentionnellement), le nom de l'assembly a également été modifié par VS, donc il y avait deux assemblys avec le même nom, l'un remplaçant l'autre

Dans mon cas, j'avais un fichier construit par une dépendance externe (xsd2code) et en quelque sorte ses fichiers designer.cs n'étaient pas traités correctement par VS. Créer un nouveau fichier dans Visual Studio et y coller le code a fait l'affaire pour moi.

Pour tous ceux qui obtiennent cette erreur lorsqu'ils essaient de publier leur site Web sur Azure, aucune des solutions prometteuses ci-dessus ne m'a aidé. J'étais dans le même bateau - ma solution a bien fonctionné d'elle-même. J'ai fini par devoir

1. Supprimez tous les packages nuget dans ma solution.
2. Fermez et rouvrez ma solution.
3. Ajoutez à nouveau tous les packages nuget.

Un peu pénible, mais c'était le seul moyen pour que mon site Web soit publié sur Azure.

J'ai eu cette erreur en essayant de créer une build avec une build Visual Studio Team Services exécutée sur ma machine locale en tant qu'agent.

Cela a très bien fonctionné dans mon espace de travail normal et j'ai pu ouvrir le fichier SLN dans le dossier de l'agent localement et tout s'est bien compilé.

La DLL en question a été stockée dans le projet en tant que Lib/MyDLL.DLLet fait référence à cela dans le fichier csproj:

<Reference Include="MYDLL, Version=2009.0.0.0, Culture=neutral, PublicKeyToken=b734e31dca085caa">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>Lib\MYDLL.dll</HintPath>
</Reference>

Il s'est avéré qu'il ne trouvait littéralement pas le fichier malgré le chemin d'accès. Je pense que msbuild cherchait peut-être par rapport au fichier SLN au lieu du fichier de projet.

Dans tous les cas, si le message que vous obtenez est Could not resolve this reference. Could not locate the assemblyalors assurez-vous que la DLL se trouve dans un emplacement accessible à msbuild.

J'ai en quelque sorte triché et j'ai trouvé un message qui disait Considered "Reference\bin\xxx.dll"et j'ai juste copié les DLL à la place.

Dans mon cas, l'ajout de la DLL comme référence a donné l' type or namespace name could not be founderreur. Cependant, copier et coller le fichier dll directement dans le dossier bin a résolu l'erreur.

Je ne sais pas pourquoi cela a fonctionné.

Je sais que ce thread est ancien mais de toute façon je partage, je dois installer toutes les dépendances de tiers de l'assembly importé - car l'assembly importé n'était pas inclus en tant que package Nuget, donc ses dépendances étaient manquantes.

Hop cette aide :)

Dans mon cas, j'avais deux projets dans une solution, j'ai ajouté un sous-espace de noms dans le projet référencé, mais lors de la construction, je n'ai pas remarqué que la construction du projet référencé a échoué et il a utilisé la dernière version construite avec succès qui n'a pas avoir ce nouvel espace de noms, donc l'erreur était correcte, qu'il ne peut pas être trouvé, car il n'existait pas La solution était évidemment de corriger les erreurs dans le projet référencé.

Je travaillais sur l'édition communautaire VS 2017 et j'ai eu le même problème avec les packages de pépites CefSharp.

Les packages ont été téléchargés et restaurés avec succès, le projet a pu être construit et exécuté avec succès - seul le balisage a indiqué que les espaces de noms n'étaient pas reconnus.

Tout ce que j'avais à faire était d'ouvrir la Referencessection et de cliquer sur l'un des panneaux d'exclamation jaunes.

Après quelques secondes, les erreurs de balisage ont disparu.