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

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:

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:

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?

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é.

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?

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

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é

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 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é.

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.

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.

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.

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 ...

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.

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.

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.

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.

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.

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

Dans mon cas, supprimer / ajouter cet assemblage a fonctionné.

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

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