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' using
instruction, 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 using
dé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?
Réponses:
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:
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:
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 source
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:
la source
Update-Package -reinstall
j'ai eu plusieurs erreurs dans toute la solution, qui comprenait une version différente de ce package. J'ai mis à jour en tout, puis il a finalement fonctionné. Il a également corrigé les références dans les fichiers package.json de 45 à 452, car j'ai également changé la version cible il y a longtemps.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.
la source
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:
Cela garantit que le projet de bibliothèque est construit en premier.
la source
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.
la source
J'ai rencontré une situation plus délicate: le premier projet cible le framework complet 4.0 avec le
Microsoft.Bcl.Async
package 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é.
la source
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.
la source
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!!!
la source
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.
la source
[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.
la source
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.
la source
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.
la source
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
compile
entrées en double comme: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.
la source
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:
la source
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.
la source
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.
la source
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.
la source
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
la source
Cet événement se produit dans Visual Studio 2017.
la source
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.Core
ré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
la source
Pour résoudre ce problème, il peut également aider à supprimer et recréer le
*.sln.DotSettings
fichier de la solution associée.la source
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é!
la source
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
la source
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.
la source
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
Un peu pénible, mais c'était le seul moyen pour que mon site Web soit publié sur Azure.
la source
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.DLL
et fait référence à cela dans le fichier csproj: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 assembly
alors 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.la source
Dans mon cas, l'ajout de la DLL comme référence a donné l'
type or namespace name could not be found
erreur. 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é.
la source
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 :)
la source
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é.
la source
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
References
section et de cliquer sur l'un des panneaux d'exclamation jaunes.Après quelques secondes, les erreurs de balisage ont disparu.
la source