Espace de nom non reconnu (même s'il est là)


145

J'obtiens cette erreur:

Le type ou le nom d'espace de noms 'AutoMapper' est introuvable (vous manque une directive using ou une référence d'assembly?)

Le plus drôle, c'est que j'ai déjà cette référence dans mon projet:

ProjectThatFails

Et voici mon code:

using System.Collections.Generic;
using DataContract;
using SelectorDAL;
using AutoMapper;

namespace SpecimenSelect
{
    public class SpecimenSelect : ISpecimenSelect
    {
        public SpecimenSelect()
        {
            SetupMaps();
        }

        private static void SetupMaps()
        {
            Mapper.CreateMap<SpecimenDetail, SpecimenDetailContract>();
        }

L'autre chose étrange est que j'ai deux autres projets dans ma solution qui utilisent tous les deux AutoMapper et référencent exactement le même fichier AutoMapper.dll. Ils fonctionnent tous les deux parfaitement bien.

En voici une capture d'écran:

ProjetThatWorks

et voici ce code (qui compile bien):

using System.Collections.Generic;
using AutoMapper;
using DataContract;
using SelectorDAL;

namespace PatientSelect
{

    public class PatientSelect : IPatientSelect
    {
        public PatientSelect()
        {
            SetupMaps();
        }

        private void SetupMaps()
        {
            Mapper.CreateMap<Patient, PatientContract>();
            Mapper.CreateMap<OrderedTest, OrderedTestsContract>();
            Mapper.CreateMap<Gender, GenderContract>();
        }

Les deux références semblent avoir les mêmes données sur la page de propriétés.

Qu'est-ce que je rate?

J'ai essayé:

  1. Redémarrer Visual Studio
  2. Référencement sans instruction using (ie AutoMapper.Mapper.CreateMap)
  3. Nettoyer et reconstruire

D'autres idées?


1
Le chemin de référence est-il incorrect? Peut-être qu'il a été ajouté avec un chemin absolu, mais la DLL a depuis été déplacée?
kevingessner

Réponses:


259

Vérifiez que votre projet n'est pas configuré pour utiliser le profil client .NET Framework 4.

Vous pouvez vérifier / modifier cela en cliquant avec le bouton droit sur votre projet (pas la solution), sélectionnez Propriétés -> Application -> Cadre cible . Le cadre cible est une liste déroulante sur cette page.

C'est un problème dans Visual Studio (j'irais même jusqu'à l'appeler un bogue). AutoMapper nécessite des assemblys exclus du profil client .NET Framework 4. Puisque votre projet utilise cette version du framework, il se brise.

Une erreur similaire se propage au processus de génération lorsque la version .NET Framework du projet que vous référencez est supérieure à celle du projet faisant la référence. c'est-à-dire qu'un projet ciblant 4.5 qui fait référence à un projet ciblant 4.5.1 vous donnera cette même erreur.

Il doit y avoir un meilleur message d'erreur lorsque cela se produit car il n'y a aucune explication rationnelle quant à la raison pour laquelle il ne serait pas généré car le message d'erreur vous indique de référencer un assembly que vous avez clairement référencé.


7
C'était exactement ce qu'était le problème! Merci! Je reconnais que cette erreur est très trompeuse. Je ne comprends pas non plus pourquoi le profil client est la valeur par défaut pour un nouveau projet. La plupart des ordinateurs auront le framework .net complet, n'est-ce pas? (Ou est-ce que MS met simplement le framework client sur Windows Update?) Quoi qu'il en soit, tous les ordinateurs pour lesquels je développe auront le framework complet. J'aurais aimé qu'il y ait un moyen de changer la valeur par défaut pour un nouveau projet afin que cela me morde comme ça. En tous cas. Merci encore! J'étais coincé et je n'ai pas pensé à regarder là-bas.
Vaccano

J'ai eu exactement le même problème! Les types n'étaient pas reconnus dans mon projet de service Windows même si j'avais ajouté les références correctement. J'ai changé le framework cible de .NET Framework 4 Client Profile en .NET Framework 4. Notez que j'ai également dû rajouter mes références pour le faire compiler. Semble être un problème dans Visual Studio 2010. Merci et salutations de Budapest.
Varga Tamas le

Bon, ça m'est aussi arrivé. Mon projet de test n'a pas reconnu les espaces de noms référencés même s'ils étaient là. C'est parce que j'ai changé ma bibliothèque sur la plate-forme .NET 4.5, mais le projet de test est resté 4.0. En tout cas, votre réponse me conduit sur la bonne voie. Merci pour la solution.
Jukka Puranen le

J'ai rencontré le même problème lorsque j'ai essayé d'utiliser l'assemblage .Net 2.0 dans le projet de profil client .Net 3.5. et le passage au profil complet 3.5 résout le problème.
Palani

Mon problème était similaire. Les projets utilisaient différentes versions de Framework. Le projet principal utilisait 4.5 et le projet nouvellement créé utilisait 4.5.1. Ce serait bien si le message d'erreur était meilleur.
L_7337

27

Permettez-moi de poser une question stupide: pourrait-il y avoir deux fichiers automapper.dll ? Un avec un AutoMapperespace de noms et un sans? Confirmez les chemins dans les deux projets.

J'ai également remarqué que l'ordre des usingcommandes est différent. Cela ne devrait pas avoir d'importance, mais avez-vous essayé de les mélanger?


18

Si votre classe ne compile pas, même si elle est dans le projet, vérifiez ces éléments:

  1. si le nom de la classe est exactement le même
  2. si l'espace de nom est exactement le même
  3. si les propriétés de classe affichent l'action de construction = compiler

6
J'ai copié un fichier .cs avec Explorer, puis je l'ai inclus dans le projet. VS.Net a défini l'action de construction comme "Contenu" au lieu de "Compiler" et ne reconnaissait donc pas l'espace de noms. Bonne prise!
AUSteve

1
J'ai ajouté la classe via la fonctionnalité Ajouter -> Classe, et elle a défini l'action de construction sur le contenu. Curieux de savoir pourquoi? Cela m'a aidé de toute façon, quelque chose de si simple, mais jamais rencontré auparavant. C'est pourquoi je n'ai même pas pris la peine de regarder là-bas, et je l'ai recherché sur Google à la place.
Anomalie du

14

Cela doit être la solution la plus simple si toutes les autres réponses ne vous aident pas

Je cherchais ce qui ne va pas avec ma configuration parmi les réponses, je les ai toutes essayées - aucune n'a fonctionné, puis j'ai réalisé que Visual Studio 2018 avait été développé par Microsoft . Alors j'ai fait ce que font la plupart des gens,

Redémarré Visual Studio et cela a fonctionné


A travaillé pour moi mais supprimé le dossier bin et obj avant de redémarrer.
Chandan YS

Au cours de toutes mes années sur stackoverflow, c'est la meilleure réponse salée à un bogue (qui fournit en fait une solution) et cela a fonctionné au premier redémarrage. insomniaque ftw!
Collin White le

12

J'ai résolu ce problème en cliquant avec le bouton droit sur le dossier contenant les fichiers et en choisissant Exclure du projet , puis en cliquant à nouveau avec le bouton droit et en sélectionnant Inclure dans le projet (vous devez d'abord activer Afficher tous les fichiers pour rendre le dossier exclu visible)


J'ai eu cette erreur pour des tonnes de fichiers, il suffit d'en supprimer un et de le réintégrer à résoudre le problème pour toute la solution.
Daryl le

Faire un clic droit sur quoi? "Exclure du projet" supprime le dossier de l'explorateur de solutions. Il n'y a pas de "Inclure dans le projet"
Florian Winter

2
@FlorianWinter Pour faire un clic droit sur le dossier exclu, vous devez activer Afficher tous les fichiers . Cela peut être activé via l'Explorateur de solutions, il se trouve à côté du bouton Réduire tout .
user3251328

Je ne sais pas pourquoi, mais cela a fonctionné dans VS2019 lorsque j'ai ajouté un nouveau fichier contenant une nouvelle classe à un projet, mais que je n'ai pas pu créer une nouvelle instance de cette classe dans un autre projet qui avait déjà une référence au projet contenant la nouvelle classe. ..¯\_(ツ)_/¯
matt.fc

7

J'ai un problème similaire avec les références qui ne sont pas reconnues dans VS2010 et les réponses ici n'ont pas été en mesure de le corriger.

Le problème dans ma solution était lié à l'extension du chemin où se trouvait le projet référencé. Comme je travaille avec SVN, j'ai créé une branche d'un référentiel pour faire des tests et cette branche a augmenté de deux niveaux dans la structure du chemin, donc le chemin est devenu trop long pour être utilisable dans Windows. Cela n'a généré aucune erreur mais n'a pas reconnu l'espace de noms de la référence du projet. Lorsque j'ai corrigé l'emplacement du projet pour avoir un chemin plus petit, tout s'est bien passé.


2
C'était aussi un problème pour nous et c'était la longueur du chemin qui causait le problème. VS doit faire un meilleur travail pour donner une meilleure erreur dans ce cas, car l'erreur que nous avons obtenue était assez trompeuse.
VoodooChild

Grâce à votre réponse, une idée m'est venue à l'esprit. J'ai regardé le chemin de mon projet et réalisé que le dossier racine, celui créé par l'arborescence source, avait "% 20" au lieu de _ dans le nom. Je l'ai changé en _ et tout fonctionne bien maintenant.
Fernando Wolff

5

Dans mon cas, la dll référencée a été construite dans une version supérieure de .Net Framework. Après avoir ajouté la référence, je pourrais l'utiliser. Mais dès que j'ai fait une compilation, l'erreur «référence manquante» apparaîtra. J'actualise la dll, l'erreur disparaîtra mais elle ne sera jamais construite. Ce post m'a fait vérifier la version du framework et ainsi j'ai pu le résoudre en construisant le projet référencé dans la même version.


3

La table des types du projet est peut-être dans un état incorrect. J'essaierais de supprimer / ajouter la référence et si cela ne fonctionnait pas, créer un autre projet, importer mon code et voir si cela fonctionne.

J'ai rencontré ce problème en utilisant VS 2005, on s'attendrait à ce que MS ait résolu ce problème particulier maintenant.


pourriez-vous résoudre ce problème?
Fran_gg7

3

La question a déjà été attribuée, mais il y a des détails supplémentaires non encore décrits qui doivent être vérifiés.

J'avais aussi ce comportement, où le projet B était référencé dans le projet A, mais l'espace de noms du projet B n'était pas reconnu dans le projet A. Après quelques recherches, j'ai trouvé que mon chemin était trop long. En réduisant le chemin des projets (A et B), les références sont devenues visibles et disponibles.

J'ai testé cette théorie en créant le projet C à une profondeur de chemin bien moindre. J'ai référencé le projet C dans le projet A. Les références ont fonctionné correctement comme prévu. J'ai ensuite supprimé le projet C de la solution, déplacé simplement le projet C vers un chemin profond, le même que le projet B, et ajouté le projet C à la solution et essayé de compiler. Je n'avais alors plus de visibilité pour projeter des objets C.


2

Dans mon cas, j'avais copié une bibliothèque de classes, et je n'avais pas changé le "nom de l'assembly" dans les propriétés du projet, donc une DLL écrasait l'autre ...


2

Cela m'est arrivé dans Visual Studio 2019. Pour moi, j'essayais de référencer un autre projet dans ma solution. Voici les étapes que j'ai suivies au cas où cela aiderait quelqu'un d'autre:

  1. S'assurer que le projet que je voulais référencer était répertorié sous Références
  2. S'assurer que les deux projets utilisaient la version correcte de .NET Framework
  3. Construire le projet (cliquez sur la flèche verte "Démarrer")

J'étais confus parce que j'obtenais toujours l'erreur après les étapes 1 et 2, mais la construction du projet semblait le résoudre.


1

J'ai été confronté à un problème similaire d'espace de noms / méthode introuvable pendant l'exécution, bien que cela soit bien lors de la compilation, et la raison en est que l'assembly que je référençais a été déployé sur GAC et a depuis été modifié, donc quand j'ai référencé l'assembly dans Visual Studion, il utilisait la version la plus récente, mais pendant l'exécution, la version de GAC avait été utilisée.


1

Dans mon cas, j'ai eu l'erreur uniquement dans VS 2015. Lors de l'ouverture du projet dans VS 2017, l'erreur avait disparu.


1

Fou. Je connais.

J'ai essayé toutes les options ici. Redémarrer, nettoyer, vérifier manuellement les DLL générées (cela est inestimable pour comprendre si c'est vraiment vous-même qui a gâché).

Je l'ai fait fonctionner en définissant la verbosité de MSBuild sur "Détaillé" dans les Options.


pour moi, c'était une configuration de construction définie sur AnyCpu sur PlatformTarget lorsque le nom de configuration était x86. Ce paramètre m'a aidé à le découvrir.
Dbl

1

Cette question a déjà été répondue pour l'affiche originale, mais au cas où quelqu'un la rencontrerait dans un projet MS-Test:

à partir de Visual Studio, cliquez sur le menu Test -> Paramètres de test -> Architecture du processeur par défaut et assurez-vous que l'architecture correspond à celle de l'autre assembly que vous référencez. Si l'autre assemblage est x64 et que vos paramètres de test sont x86, vous pouvez rencontrer les symptômes de l'affiche d'origine.


0

Je travaillais sur un projet Xamarin et comme toujours, la suppression du dossier obj et la reconstruction ont résolu mon problème, l'espace de noms que mon VS ne reconnaissait pas était un code dans mon propre projet BTW



0

J'ai eu un problème similaire, qui a pris un peu de temps à dépanner, alors j'ai pensé à le partager:

L'espace de noms qui n'a pas pu être résolu dans mon cas était Company.Project.Common.Models.EF . J'avais ajouté un fichier dans un nouvel espace de noms Company.Project.BusinessLogic.Common .

La majorité des fichiers avaient un

using Company.Project;

Et puis référençant les modèles comme Common.Models.EF . Tous les fichiers qui avaient également un

using Company.Project.BusinessLogic;

Ont échoué car VS n'a pas pu déterminer quel espace de noms utiliser.

La solution a été de changer le deuxième espace de noms en Company.Project.BusinessLogic.CommonServices


-1

Redémarrer Visual Studio 2019 - c'est fait.


Vaccano a écrit: J'ai essayé: Redémarrage de Visual Studio
Woworks
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.