Espace de noms non reconnu (même s'il y est)
Je reçois cette erreur:
Le type ou le nom de l'espace de noms 'AutoMapper' est introuvable (vous manque une directive using ou une référence Assembly?)
La chose amusante 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 deux AutoMapper et font référence au même fichier AutoMapper.dll. Ils fonctionnent tous les deux parfaitement bien.
Voici une capture d'écran d'un:
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é:
- Redémarrage de Visual Studio
- Référencement sans instruction using (ie
AutoMapper.Mapper.CreateMap) - 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/changer cela en cliquant avec le bouton droit de la souris sur votre projet (pas sur 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 requiert des assemblys exclus du profil client .NET Framework 4. Comme votre projet utilise cette version du framework, il se déchire.
Une erreur similaire se propage au processus de génération lorsque la version du .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 la même erreur.
Il doit y avoir un meilleur message d'erreur lorsque cela se produit car il n'existe aucune explication rationnelle de la raison pour laquelle il ne serait pas généré, car le message d'erreur vous indique de référencer un assemblage 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 espace de noms AutoMapper et un sans? Confirmez les chemins dans les deux projets.
J'ai également remarqué que l'ordre des commandes using 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 ce qui suit:
- si le nom de la classe est exactement le même
- si l'espace de noms est exactement le même
- si les propriétés de classe montrent build action = compile
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 de la souris 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 des références non reconnues dans VS2010 et les réponses fournies ici n'ont pas permis de le corriger.
Le problème de ma solution était lié à l’extension du chemin où se trouvait le projet référencé. Alors que je travaillais avec SVN, j'ai créé une branche d'un référentiel pour effectuer des tests et cette branche a augmenté la structure de chemin d'accès de deux niveaux, de sorte que 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. Quand je corrige l'emplacement du projet pour avoir un chemin plus petit, tout s'est bien passé.
Ce 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. J’ai essayé toutes les réponses - 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 la plupart des gens font,
Visual Studio redémarré Et cela a fonctionné
Dans mon cas, la DLL référencée était 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 construit, l'erreur de "référence manquante" apparaîtra. J'actualise la dll l'erreur disparaîtra mais elle ne se construirait jamais. Cet article m'a incité à vérifier la version du framework. Je pouvais donc le résoudre en construisant le projet référencé dans la même version.
La table de type du projet est peut-être dans un état incorrect. J'essayerais 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 fonctionnait.
Je me suis heurté à cela en utilisant VS 2005, on aurait attend MS pour avoir résolu ce problème particulier maintenant ..
La question a déjà été attribuée, mais des détails supplémentaires non encore décrits doivent être vérifiés.
J'avais moi 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 retiré le projet C de la solution, simplement déplacé le projet C vers un chemin profond, identique au projet B, et ajouté le projet C à la solution et essayé de compiler. Je n'avais alors plus aucune visibilité pour projeter des objets en C.
Dans mon cas, j'avais copié une classlibrary sans changer le "Nom de l'assembly" dans les propriétés du projet, donc un DLL remplaçait l'autre ...
Fou. Je connais.
J'ai essayé toutes les options ici. Redémarrer, nettoyer, archiver manuellement les DLL générées (c'est un atout précieux pour comprendre si c'est vous-même qui a été gâché).
Je l'ai fait fonctionner en réglant la verbosité de MSBuild sur "Détaillé" dans Options.
J'ai rencontré un problème similaire, celui de la non-découverte de la méthode/de l'espace de noms lors de l'exécution, bien que cela ait été correct lors de la compilation, et que la raison en soit que l'assembly auquel je faisais référence ait été déployé dans GAC et depuis lors, il a été modifié. dans Visual Studion, il utilisait la version la plus récente, mais lors de l'exécution, la version de GAC avait été utilisée.
Cette question a déjà été résolue pour l'affiche originale, mais au cas où quelqu'un le rencontrerait dans un projet MS-Test:
dans Visual Studio, cliquez sur le menu Test -> Paramètres de test -> Architecture de processeur par défaut et assurez-vous que l'architecture correspond à celle de l'autre assemblage 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 originale.
Dans mon cas, l'erreur n'est apparue que dans VS 2015. Lors de l'ouverture du projet dans VS 2017, l'erreur avait disparu.
Dans mon cas, supprimer/ajouter cette assemblée a fonctionné.
Je travaillais sur le projet Xamarin et, comme toujours, la suppression du dossier obj et la reconstruction ont résolu mon problème. L'espace de nom que mon VS ne reconnaissait pas était un code dans mon propre projet. BTW