Przestrzeń nazw nie została rozpoznana (mimo że istnieje)

Otrzymuję ten błąd:

Nie można znaleźć nazwy typu lub przestrzeni nazw „AutoMapper” (czy brakuje dyrektywy using lub odwołania do zestawu?)

Zabawne jest to, że mam już to odniesienie w swoim projekcie:

A to mój kod:

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>();
        }

Inną dziwną rzeczą jest to, że mam dwa inne projekty w moim rozwiązaniu, które używają AutoMapper i odwołują się do tego samego pliku AutoMapper.dll. Oba działają doskonale.

Oto zrzut ekranu przedstawiający:

a oto ten kod (który dobrze się kompiluje):

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>();
        }

Wydaje się, że oba odwołania mają te same dane na stronie właściwości.

czego mi brakuje?

Próbowałem:

1. Ponowne uruchamianie programu Visual Studio
2. Odwołanie bez instrukcji using (tj. AutoMapper.Mapper.CreateMap)
3. Oczyść i odbuduj

Jakieś inne pomysły?

Upewnij się, że projekt nie jest skonfigurowany do korzystania z profilu klienta .NET Framework 4.

Możesz to sprawdzić / zmienić, klikając prawym przyciskiem myszy projekt (nie rozwiązanie), wybierz Właściwości -> Aplikacja -> Platforma docelowa . Struktura docelowa to lista rozwijana na tej stronie.

To jest problem w Visual Studio (posunąłbym się nawet do tego, że nazwałbym to błędem). AutoMapper wymaga zestawów, które są wykluczone z profilu klienta .NET Framework 4. Ponieważ twój projekt używa tej wersji frameworka, to się psuje.

Podobny błąd zostanie propagowany w procesie kompilacji, gdy wersja .NET Framework projektu, do którego się odwołujesz, jest wyższa niż wersja projektu, do którego się odwołujesz. tj. projekt ukierunkowany na 4.5, który odwołuje się do projektu ukierunkowanego na 4.5.1, spowoduje ten sam błąd.

W takim przypadku musi istnieć lepszy komunikat o błędzie, ponieważ nie ma racjonalnego wyjaśnienia, dlaczego nie miałby się skompilować, ponieważ komunikat o błędzie mówi, aby odwołać się do zestawu, do którego wyraźnie się odwołałeś.

Pozwól, że zadam głupie pytanie: czy mogą istnieć dwa pliki automapper.dll ? Jeden z AutoMapperprzestrzenią nazw, a drugi bez? Potwierdź ścieżki w obu projektach.

Zauważyłem też, że kolejność usingpoleceń jest inna. To nie powinno mieć znaczenia, ale czy próbowałeś je przetasować?

Jeśli twoja klasa się nie kompiluje, nawet jeśli jest w projekcie, sprawdź te:

1. czy nazwa klasy jest dokładnie taka sama
2. czy przestrzeń nazw jest dokładnie taka sama
3. czy właściwości klasy pokazują akcję kompilacji = kompilacja

To musi być najprostsze rozwiązanie, jeśli wszystkie inne odpowiedzi Ci nie pomogą

Szukałem, co jest nie tak z moją konfiguracją wśród odpowiedzi, wypróbowałem je wszystkie - żadna nie działała, a potem zdałem sobie sprawę, że Visual Studio 2018 zostało opracowane przez Microsoft . Zrobiłem więc to, co większość ludzi,

Uruchomiono ponownie program Visual Studio i zadziałało

Rozwiązałem ten problem, klikając prawym przyciskiem myszy folder zawierający pliki i wybierając opcję Wyklucz z projektu, a następnie ponownie klikając prawym przyciskiem myszy i wybierając opcję Uwzględnij w projekcie (najpierw musisz włączyć opcję Pokaż wszystkie pliki, aby wyświetlić wykluczony folder)

Mam podobny problem z nie rozpoznawaniem referencji w VS2010 i odpowiedzi tutaj nie były w stanie go naprawić.

Problem w moim rozwiązaniu był związany z przedłużeniem ścieżki, na której znajdował się projekt, do którego się odwołujemy. Kiedy pracuję z SVN, stworzyłem gałąź repozytorium, aby przeprowadzić testy i ta gałąź zwiększyła o dwa poziomy w strukturze ścieżki, więc ścieżka stała się zbyt długa, aby można ją było używać w oknach. Nie spowodowało to żadnego błędu, ale nie rozpoznało przestrzeni nazw odwołania do projektu. Kiedy poprawiam lokalizację projektu, aby mieć mniejszą ścieżkę, wszystko poszło dobrze.

W moim przypadku wspomniana biblioteka dll została zbudowana w wyższej wersji .Net Framework. Po dodaniu odniesienia mogłem go użyć. Ale gdy tylko utworzę kompilację, pojawi się błąd „brakującego odniesienia”. Odświeżam dll, błąd pójdzie, ale nigdy się nie skompiluje. Ten post sprawił, że sprawdziłem wersję frameworka i mogłem go rozwiązać, budując przywoływany projekt w tej samej wersji.

Być może tabela typów projektu ma nieprawidłowy stan. Spróbowałbym usunąć / dodać odniesienie, a jeśli to nie zadziałało, utworzyć inny projekt, zaimportować mój kod i sprawdzić, czy to działa.

Natknąłem się na to podczas korzystania z VS 2005, można by się jednak spodziewać , że MS już naprawiło ten konkretny problem.

Pytanie zostało już przyznane, ale są dodatkowe szczegóły, które nie zostały jeszcze opisane, które należy sprawdzić.

Ja również miałem takie zachowanie, w którym projekt B był przywoływany w projekcie A, ale przestrzeń nazw projektu B nie została rozpoznana w projekcie A. Po pewnym czasie odkryłem, że moja ścieżka jest za długa. Zmniejszając ścieżkę projektów (zarówno A, jak i B), odniesienia stały się widoczne i dostępne.

Przetestowałem tę teorię, tworząc projekt C na znacznie mniejszej głębokości ścieżki. Odwołałem się do projektu C w projekcie A. Odniesienia działały poprawnie, zgodnie z oczekiwaniami. Następnie usunąłem projekt C z rozwiązania, po prostu przeniosłem projekt C na głęboką ścieżkę, taką samą jak projekt B, i dodałem projekt C z powrotem do rozwiązania i próbowałem skompilować. Wtedy nie mogłem już wyświetlać obiektów C.

W moim przypadku skopiowałem bibliotekę klas i nie zmieniłem nazwy zestawu we właściwościach projektu, więc jedna biblioteka DLL nadpisywała drugą ...

Zdarzyło mi się to w Visual Studio 2019. Próbowałem odwołać się do innego projektu w moim rozwiązaniu. Oto kroki, które podjąłem na wypadek, gdyby pomogło to komukolwiek innemu:

1. Upewniłem się, że projekt, do którego chciałem się odwołać, znajduje się na liście Referencje
2. Zapewniono, że oba projekty używają poprawnej wersji .NET Framework
3. Zbudowano projekt (kliknięto zieloną strzałkę „Start”)

Byłem zdezorientowany, ponieważ nadal otrzymywałem błąd po krokach 1 i 2, ale kompilowanie projektu wydawało się go rozwiązać.

Napotkałem podobny problem z nie znalezieniem przestrzeni nazw / metody podczas wykonywania, chociaż było to w porządku podczas kompilacji, a przyczyną tego wydaje się być to, że zestaw, do którego się odwoływałem, został wdrożony do GAC i od tego czasu został zmieniony, więc kiedy odwoływałem się do zestawu w Visual Studion korzystał z najnowszej wersji, ale w czasie wykonywania była używana wersja z GAC.

W moim przypadku błąd wystąpił tylko w VS 2015. Podczas otwierania projektu w VS 2017 błąd zniknął.

Zwariowany. Wiem.

Wypróbowałem wszystkie opcje tutaj. Ponowne uruchamianie, czyszczenie, ręczne sprawdzanie wygenerowanych bibliotek DLL (jest to nieocenione, aby zrozumieć, czy to naprawdę pomieszałeś).

Uruchomiłem go, ustawiając Szczegółowość programu MSBuild na „Szczegółowy” w Opcjach.

Na to pytanie udzielono już odpowiedzi w przypadku oryginalnego plakatu, ale na wypadek, gdyby ktoś napotkał to w projekcie MS-Test:

z poziomu programu Visual Studio kliknij menu Test -> Ustawienia testowe -> Domyślna architektura procesora i upewnij się, że architektura jest zgodna z architekturą innego zestawu, do którego się odwołujesz. Jeśli drugi zestaw to x64, a ustawienia testowe to x86, mogą wystąpić symptomy oryginalnego plakatu.

Pracowałem nad projektem Xamarin i jak zawsze usunięcie folderu obj i odbudowanie rozwiązało mój problem, przestrzeń nazw, której mój VS nie rozpoznawał, była kodem w moim własnym projekcie BTW

W moim przypadku usunięcie / dodanie tego zestawu zadziałało.

Miałem podobny problem, który zajął trochę czasu, aby go rozwiązać, więc pomyślałem, aby go udostępnić:

Przestrzeń nazw, której nie można rozwiązać w moim przypadku, to Company.Project.Common.Models.EF . Dodałem plik w nowej przestrzeni nazw Company.Project.BusinessLogic.Common .

Większość plików miała rozszerzenie

using Company.Project;

A następnie określając modele jako Common.Models.EF . Wszystkie pliki, które również miały rozszerzenie

using Company.Project.BusinessLogic;

Niepowodzenie, ponieważ program VS nie mógł określić, której przestrzeni nazw użyć.

Rozwiązaniem była zmiana drugiej przestrzeni nazw na Company.Project.BusinessLogic.CommonServices

Ponowne uruchomienie programu Visual Studio 2019 - to wystarczyło.