Namespace non reconnu (même s'il est là)
je reçois cette erreur:
le type ou le nom d'espace de noms "AutoMapper" n'a pas pu être trouvé (vous manque-t-il une directive d'utilisation ou une référence d'assemblage?)
la chose drôle 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 font référence au même AutoMapper.dll fichier. Ils fonctionnent tous les deux parfaitement bien.
Voici une capture d'écran d'un:
et voici ce code (qui compile fine):
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 des propriétés.
Qu'est-ce que je rate?
j'ai essayé:
- Redémarrer Visual Studio
- Référencement sans l'aide d'instruction (c'est à dire
AutoMapper.Mapper.CreateMap) - nettoyer et reconstruire
D'autres idées?
14 réponses
vérifiez que votre projet n'est pas configuré pour utiliser le profil client.Net Framework 4.
vous pouvez vérifier / modifier ceci en cliquant avec le bouton droit de la souris sur votre projet (pas la solution), sélectionnez propriétés -> Application -> cadre cible . Le framework cible est un menu déroulant sur la page.
C'est un problème dans Visual Studio (j'irais même jusqu'à appeler ça un bug). AutoMapper nécessite des assemblages qui sont exclus du profil client.NET Framework 4. Puisque votre projet utilise cette version du cadre, il casse.
une erreur similaire se propagera au processus de compilation lorsque la version .net Framework pour le projet auquel vous faites référence est plus élevée que le projet faisant la référence. c'est-à-dire un projet ciblant 4.5 qui fait référence à un le ciblage de projet 4.5.1 vous donnera cette même erreur.
il doit y avoir un meilleur message d'erreur lorsque cela se produit parce qu'il n'y a pas d'explication rationnelle quant à savoir pourquoi il ne serait pas construit comme le message d'erreur vous dit de faire référence à un assemblage que vous avez clairement référencé.
Permettez-moi de poser une question stupide: pourrait-il y avoir deux automapper.les fichiers dll ? Un avec un espace de nom AutoMapper et un sans? Confirmer les voies suivies dans les deux projets.
j'ai aussi remarqué que l'ordre des commandes using est différent. Il ne devrait pas, mais avez-vous essayé de les mélanger?
si votre classe ne compile pas, même si elle est dans le projet, cochez ces cases:
- si le nom de la classe est exactement le même
- si l'espace du nom est exactement le même
- si des propriétés de la classe montrent build action = compiler
j'ai un problème semblable avec les références qui n'ont pas été reconnues dans VS2010 et les réponses aux présentes n'ont pas été en mesure de le corriger.
le problème dans ma solution était lié à l'extension du chemin d'accès où le projet référencé était situé. Comme je travaille avec SVN, j'ai créé une branche d'un dépôt pour faire quelques tests et cette branche a augmenté deux niveaux dans la structure du chemin, de sorte que le chemin est devenu trop long pour être utilisable dans windows. Ce ne jetez pas d'erreur mais n' ne pas reconnaître 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é.
dans mon cas, la dll référencée a été construite dans la 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 construire, le "manque de référence' erreur apparaîtra. Je rafraîchis la dll l'erreur ira mais il ne construirait jamais. Ce post m'a fait vérifier la version de cadre et donc je pourrais le résoudre en construisant le projet référencé dans la même version.
peut-être que la table type du projet est dans un état incorrect. J'essaierais de supprimer/ajouter la référence et si cela ne fonctionne pas, créer un autre projet, importer mon code, et voir si cela fonctionne.
j'ai rencontré ceci en utilisant VS 2005, on s'attendrait MS pour avoir corrigé ce problème particulier à ce jour si..
j'ai résolu ce problème en cliquant droit sur le dossier contenant les fichiers et en choisissant exclure du projet puis en cliquant droit de nouveau et en sélectionnant inclure dans le projet (vous devez d'abord activer afficher tous les fichiers pour rendre le dossier exclu visible)
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.
moi aussi j'avais ce comportement, où le projet B était référencé dans le projet A, mais l'Espace-nom 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 de projets (A et B) les références sont devenues visibles et disponibles.
j'ai testé cette théorie par créer le projet C à une profondeur de chemin beaucoup moindre. J'ai fait référence au 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, j'ai simplement déplacé le projet C sur un chemin profond, comme le projet B, et j'ai ajouté le projet C à la solution, et j'ai essayé de compiler. Je n'avais alors plus aucune visibilité pour projeter des objets C plus longtemps.
dans mon cas, j'avais copié une bibliothèque de classe, et je n'avais pas changé le" nom de L'Assemblée " dans les propriétés du projet, donc une DLL écrasait l'autre...
cela doit être la solution la plus simple si toutes les autres réponses ne vous aident pas
j'étais à la recherche de ce qui ne va pas avec ma configuration parmi les réponses, essayé tous les - Aucun n'a fonctionné, puis j'ai réalisé Visual Studio 2018 a été développé par Microsoft . Donc j'ai fait ce que la plupart des gens font", 151930920"
Redémarré Visual Studio Et ça a marché
cette question a déjà été répondue pour l'affiche originale, mais au cas où quelqu'un rencontrerait cela dans un projet de MS-Test:
à partir de 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 vos paramètres de test sont x86, Vous pouvez éprouver les symptômes que l'affiche originale avait.
j'ai affronté le même problème d'espace de noms/méthode qui n'a pas été trouvé pendant l'exécution, bien que ce soit très bien lors de la compilation, et la raison semble être que l'assemblage auquel je faisais référence a été déployé à GAC et depuis lors a été modifié, donc quand j'ai référencé L'assemblage dans Visual Studion il utilisait le plus récent, mais pendant l'exécution la version de gac avait été utilisée.
dans mon cas j'ai eu l'erreur seulement dans VS 2015. Lors de l'ouverture du projet dans VS 2017 l'erreur avait disparu.
fou. Je sais.
a essayé toutes les options ici. Redémarrage, nettoyage, vérification manuelle des DLLs générés (c'est très utile pour comprendre si c'est vous qui a fait tout foirer).
j'ai obtenu de travailler en mettant la verbosité de MSBuild à" détaillé " dans les Options.