Obtenir "le type ou le nom de l'espace de nom est introuvable" mais tout semble aller pour le mieux?
Je reçois un:
le type ou le nom de l'espace de nom est introuvable
erreur pour une application C # WPF dans VS2010. Cette zone de code compilait bien, mais tout à coup, je reçois cette erreur. J'ai essayé de supprimer la référence du projet et l'instruction using, de fermer VS2010 et de redémarrer, mais le problème persiste.
Avez-vous des idées sur la raison pour laquelle cela pourrait se produire, où il me semble que je fais la bonne chose concernant l'énoncé Reference & using?
J'ai également noté dans VS2010 qu'intelliSense pour cet espace de noms fonctionne correctement. Il semble donc que VS2010 possède la référence du projet et voit l'espace de noms d'une main, mais ne le voit pas pendant la compilation.
Cela peut être le résultat d'une incompatibilité de la version du framework .Net entre deux projets.
Cela peut se produire de deux manières:
- un projet de profil client référençant un projet cadre complet; ou
- 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 la structure de profil client .Net 4 et que le projet référencé cible l'ensemble de la structure .Net 4.
Donc, pour que cela soit plus clair:
- Le projet A cible la structure de profil client
- Le projet A fait référence au projet B
- Le projet B vise le cadre complet
Dans ce cas, la solution consiste à mettre à niveau la cible de structure de l'application (projet A) ou à rétrograder la cible de l'assembly référencé (projet B). Il est normal qu'une application de cadre complet référence/utilise un cadre de profil de client Assembly, mais pas l'inverse (le profil du client ne peut pas référencer une structure complète Assembly ciblée).
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 que:
le ou les projets référençants utilisent .Net 4.0 (cela est courant lorsque vous avez migré de VS2010 à VS2012 ou VS2013 et que vous ajoutez ensuite un nouveau projet)
les projets référencés utilisent une version plus récente, à savoir 4.5.1 ou 4.5.3 (vous avez ré-ciblé vos projets existants vers la version la plus récente, mais VS crée toujours de nouveaux projets ciblant la version 4.5 et vous référencez ensuite ces projets plus anciens à nouveau projet)
Réinstaller les paquets de nuget a fait l'affaire pour moi. Après avoir modifié la synchronisation des versions de .NET Framework pour tous les projets, certains packages de nuget (notamment Entity Framework) étaient toujours installés pour les versions précédentes. Cette commande de la console Packages Manager réinstalle les packages pour l'ensemble de la solution:
Update-Package –reinstall
Lors de la construction de la solution, la même erreur se produisait (le type ou l'espace de noms '' était introuvable). Au-dessous de lui j'ai vu un avertissement indiquant que "la référence ne pouvait pas être résolue" et que "l'assemblage existe sur le disque".
J'étais très confus, car ma DLL était très clairement à l'emplacement indiqué par la référence. VS n'a semblé mettre en évidence aucune erreur jusqu'à ce que j'essaie de construire la solution.
J'ai finalement compris 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. Ainsi, même s'il existait sur le disque, il était en train d'être reconstruit à cet emplacement (en même temps que la bibliothèque était en train de reconstruire mon autre projet - dans la même solution - qui référencait la bibliothèque devait avoir décidé que la bibliothèque n'existait pas)
Lorsque j'ai cliqué avec le bouton droit sur le projet et que je l'ai construit uniquement, au lieu de la solution complète, je n'ai pas obtenu l'erreur.
Pour résoudre ce problème, j'ai ajouté la bibliothèque en tant que dépendance du projet qui l'utilisait.
Pour faire ça:
- J'ai cliqué avec le bouton droit de la souris sur ma solution dans l'explorateur de solutions et sélectionné "Propriétés".
- Ensuite, dans "Propriétés communes", j'ai sélectionné "Dépendances du projet".
- Puis, dans le menu déroulant Projets, j’ai sélectionné le projet qui dépendait de la bibliothèque.
- A 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 n'ai aucune idée du pourquoi cela a fonctionné, mais j'ai supprimé la référence de projet que VS2015 m'avait dit qu'il ne pouvait pas trouver et je l'ai ajoutée à nouveau. Résolu le problème. J'avais essayé à la fois de nettoyer, de construire et de redémarrer VS sans succès.
Premièrement, je vérifierais que les informations générées par votre projet ne sont pas corrompues. Faites un nettoyage et reconstruisez votre solution.
Si cela ne vous aide pas, par exemple, j’ai déjà vu une solution au problème des concepteurs ouvrir un projet Windows Forms puis le refermer. C'est un peu les entrailles de poulet, cependant, alors ne retenez pas votre souffle.
Une situation plus délicate que j'ai rencontrée est la suivante: Le projet 1 cible le framework complet 4.0 avec le package Microsoft.Bcl.Async installé . Project 2 cible le framework complet 4.0 mais ne compile pas lorsqu'il fait référence à une classe du projet un.
Une fois que j'ai installé le paquet Async NuGet sur le deuxième projet, il a bien compilé.
Celui-ci a fonctionné pour moi. Dans votre classe, où le nom de la classe est défini, par exemple: Classe publique ABC, supprimez un caractère et attendez un peu. Votre liste d'erreurs augmentera parce que 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 pour vous aussi. Bonne chance!!!
J'ai eu un problème similaire: Le compilateur était incapable de détecter un dossier dans le même projet , donc une directive utilisant un lien vers ce dossier a généré une erreur. Dans mon cas, le problème venait 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 du 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, en créant un nouveau dossier et en créant de nouvelles classes dans ce nouveau dossier (le simple fait de 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.
J'ai rencontré ce problème lors de la mise à niveau de projets existants de VS2008 à VS2012. J'ai constaté 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 contenaient ".NET Framework 4" dans la zone Target Framework.
[Facepalm] Mon problème était que j'avais ajouté la dépendance à la manière de faire C++.
Accédez au projet qui ne se construit pas, ouvrez le dossier "Références" dans l'Explorateur de solutions et vérifiez 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 ce que je viens de résoudre dans une solution. Il y avait un caractère caché/espace blanc devant une instruction "using" dans le projet principal. Ce projet se déroulerait bien et le site Web fonctionnerait bien, mais le projet de test unitaire qui le référencait ne pouvait pas être construit.
Dans mon cas, je trouve la référence dans le VisualStudio avoir un triangle et un point d’exclamation comme cette image,
puis, je fais un clic droit le supprime, et ajoute la référence de dll correctement à nouveau, le problème a été résolu.
J'ai eu le même problème que discuté: VS 2017 souligne une classe dans le projet référencé comme une erreur, mais la solution se construit bien et même intellisense fonctionne.
Voici comment j'ai réussi à résoudre ce problème:
- Décharger le projet référencé
- Ouvrir le fichier .proj dans VS (je cherchais des doublons, comme quelqu'un l'a suggéré ici)
- Recharger le projet à nouveau (je n'ai pas changé ni même sauvegardé le fichier proj car je n'avais aucun doublon)
Je sais que cela tue un cheval mort, mais j’ai eu cette erreur et les cadres étaient bons. Mon problème était essentiellement de dire qu’une interface n’était pas trouvée, mais elle se construisait et était accessible correctement. Alors je me suis dit: "Pourquoi cette interface alors que d'autres fonctionnent bien?"
En fin de compte, j’accédais à un service utilisant WCF avec une interface de terminal utilisant Entity version 6 et le reste des projets utilisant la version 5. Plutôt que d’utiliser NuGet, j’ai simplement copié les packages de nuget dans un les énumérés différemment.
par exemple. EntityFramework6.dll versusEntityFramework.dll.
J'ai ensuite ajouté les références au projet client et à poof, mon erreur est partie. Je réalise qu'il s'agit d'un cas Edge car la plupart des gens ne mélangeront pas les versions d'Entity Framework.
Dans mon cas, un cours était répertorié dans le dossier source approprié, mais n'était pas enregistré dans l'Explorateur de solutions. Je devais faire un clic droit sur le projet> Ajouter un élément existant et sélectionner manuellement la classe pour laquelle il était dit qu'il était manquant. Ensuite, tout a bien fonctionné!
Cet événement se produit dans Visual Studio 2017.
- Redémarrer Visual Studio
- Projet propre qui ne parvient pas à construire.
- Reconstruisez le projet.
Ajout de ma solution au mélange parce que c'était un peu différent et m'a pris un certain 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'ai dû rendre le fichier accessible en écriture en dehors de Visual Studio (via le VC). J'avais annulé l'enregistrement dans Visual Studio, mais après avoir rendu le fichier accessible en écriture en dehors de VS, je cliquai de nouveau sur Enregistrer tout dans VS. Cela a provoqué par inadvertance que le nouveau fichier de classe ne soit pas enregistré dans le projet..Toutefois..Intellisense l'a toujours affiché en bleu et valide dans les projets de référencement, même si, lors de la tentative de recompilation, le fichier n'a pas été trouvé et a obtenu le erreur type non trouvée. La fermeture et l’ouverture de Visual Studio montraient toujours le problème (mais si j’avais pris note du fait que le fichier de classe manquait à la réouverture).
Une fois que j'ai réalisé cela, le correctif était simple: avec le fichier de projet défini sur écriture, lisez le fichier manquant dans le projet. Tout se passe bien maintenant.
Si j'avais les mêmes erreurs, mon histoire était la suivante: Après une mauvaise fusion (via git), un de mes fichiers .csproj avait dupliqué des entrées compile telles que
<Compile Include="Clients\Tree.cs" />
<Compile Include="Clients\Car.cs" />
<Compile Include="Clients\Tree.cs" /> //it's a duplicate
Si vous avez une grosse 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.
Vous pouvez également essayer d'éliminer le code avec lequel vous pensez que vous rencontrez des problèmes et voir s'il compile sans aucune référence à ce code. Si ce n'est pas le cas, corrigez le problème jusqu'à ce qu'il compile à nouveau, puis remettez votre code de problème soupçonné. Parfois, je reçois d'étranges erreurs au sujet de classes ou de méthodes que je sais être correctes lorsque le compilateur n'aime pas autre chose. Une fois que je corrige le problème qui a vraiment commencé, ces erreurs «fantômes» disparaissent.
J'ai eu le même problème. Un soir, mon projet compilerait le lendemain matin ERRORS !.
J'ai finalement découvert que Visual Studio avait décidé de "modifier" certaines de mes références et de les orienter ailleurs. par exemple:
System.ComponentModel.ISupportInitialize est devenu en quelque sorte "blahblah.System.ComponentModel.ISupportInitialize"
Assez grossier pour vs faire si vous comme moi
Dans mon cas, le problème était que, après avoir modifié exactement l'espace de noms comme dans un autre projet (intentionnellement), le nom de Assembly a également été modifié par VS.
Pour résoudre ce problème, vous pouvez également supprimer et recréer le fichier *.sln.DotSettings de la solution associée.
Mon cas était le même que celui discuté ici, mais rien ne l'a résolu jusqu'à ce que j'ai retiré la référence System.Core de la liste des références (tout a bien fonctionné sans elle)
j'espère que ça va aider quelqu'un parce que cette question est assez frustrante
J'ai eu cette erreur en essayant de créer une version avec une version de Visual Studio Team Services s'exécutant sur mon ordinateur local en tant qu'agent.
Cela a très bien fonctionné dans mon espace de travail habituel et j'ai pu ouvrir le fichier SLN dans le dossier de l'agent localement et tout a bien été compilé.
Le DLL en question était stocké dans le projet sous le nom Lib/MyDLL.DLL et faisait 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 n’a pas trouvé le fichier malgré le chemin d’affichage. Je pense que msbuild a peut-être été à la recherche du fichier SLN plutôt que du fichier de projet.
Dans tous les cas, si le message que vous recevez est Could not resolve this reference. Could not locate the Assembly, assurez-vous que DLL se trouve dans un emplacement accessible pour msbuild.
J'ai en quelque sorte triché et trouvé un message qui dit Considered "Reference\bin\xxx.dll" et que je viens de copier les dll à la place.
Ok, des années plus tard avec VS 2017 .NET Core 2.2 Razor Pages, je pense que cette réponse pourrait aider quelqu'un. Si c'était un serpent, il m'aurait mordu. J'étais en train de lancer des trucs, de changer de nom, de renommer Modèles, et tout à coup, j'ai eu l'erreur
Erreur CS0246 Le nom de type ou d'espace de nom 'UploadFileModel' est introuvable (vous manque une directive using ou une référence Assembly?)
Cela a été souligné en rouge dans ma page .chstml Razor. (non souligné après correction):
@page
@model UploadFileModel
Donc, finalement, et heureusement, j'ai trouvé le code de quelqu'un d'autre que j'avais utilisé à l'origine, et voilà, l'espace de noms n'incluait pas le nom du fichier .cshtml !!!
Voici ma mauvaise erreur factice me fesser avec le nom de la page dans le namespace:
namespace OESAC.Pages.UploadFile
{
public class UploadFileModel : PageModel
{
Ce que mon code original et tout ce que j'avais à faire était de supprimer le nom de la page de l'espace de noms, UploadFile:
namespace OESAC.Pages
{
public class UploadFileModel : PageModel
{
Et bas et voici, toutes les erreurs ont disparu !! Que je suis bête. Mais vous savez, MS a rendu ce travail .NET C # MVC vraiment déroutant pour nous, non-informaticiens. Je trébuche constamment sur mes lacets en essayant de comprendre les noms de modèle, les noms de page et la syntaxe pour les utiliser. Cela ne devrait pas être si difficile. Tant pis. J'espère que l'erreur et la solution aident quelqu'un. L'erreur était correcte, il n'y a pas d'espace de nommage nommé "UploadFileModel" haha.
Je travaillais sur l'édition communautaire VS 2017 et le même problème avec les paquets CefSharp nuget.
Les packages ont été téléchargés et restaurés avec succès, le projet peut être construit et exécuté avec succès - seule la balise indique que les espaces de noms ne sont pas reconnus.
Tout ce que je devais faire était d'ouvrir la section References et de cliquer sur l'un des signes d'exclamation jaunes.
Après quelques secondes, les erreurs de marquage ont disparu.
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é avait échoué et elle utilisait la dernière version construite avec succès qui ne fonctionnait pas. avoir ce nouvel espace de noms, donc l'erreur était correcte, impossible à trouver, car elle n'existait pas. La solution était évidemment de corriger les erreurs dans le projet référencé.
Dans mon cas, je suis allé dans les propriétés de la solution et je me suis assuré que "Construire" était coché dans la configuration pour les deux projets. Mon projet principal ne l'a pas vérifié.
Dans mon cas, l'ajout de la DLL en tant que référence a généré l'erreur type or namespace name could not be found. Cependant, copier et coller le fichier dll directement dans le dossier bin a résolu l'erreur.
Aucune idée pourquoi cela a fonctionné.
Je sais que ce fil est ancien, mais de toute façon, je partage, je dois installer toutes les dépendances en troisième partie de l'assembly importé - l'assembly importé n'étant pas inclus dans le package Nuget, ses dépendances étaient donc manquantes.
Hop cette aide :)
Dans mon cas, j'avais un fichier créé par dépendance externe (xsd2code) et 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 s’est révélé être une bonne solution.
Pour tous ceux qui rencontrent cette erreur lorsqu'ils tentent de publier leur site Web sur Azure, aucune des solutions prometteuses décrites ci-dessus ne m'a aidé. J'étais dans le même bateau - ma solution a bien fonctionné toute seule. J'ai fini par devoir
- Supprimez tous les paquets de nuget dans ma solution.
- Fermez et rouvrez ma solution.
- Ajoutez à nouveau tous les paquets de pépites.
Un peu pénible, mais c’est le seul moyen de publier mon site Web sur Azure.