Пространство имен не распознано (хотя оно и есть)

145

Я получаю эту ошибку:

Не удалось найти тип или имя пространства имен 'AutoMapper' (отсутствует директива using или ссылка на сборку?)

Самое смешное, что у меня уже есть эта ссылка в моем проекте:

ProjectThatFails

И это мой код:

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

Другая странная вещь заключается в том, что в моем решении есть два других проекта, которые используют AutoMapper и ссылаются на один и тот же файл AutoMapper.dll. Они оба работают отлично.

Вот снимок экрана одного:

ProjectThatWorks

и вот этот код (который прекрасно компилируется):

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

Обе ссылки, кажется, имеют одинаковые данные на странице свойств.

Чего мне не хватает?

Я попытался:

  1. Перезапуск Visual Studio
  2. Ссылка без использования оператора (то есть AutoMapper.Mapper.CreateMap)
  3. Очистить и восстановить

Есть другие идеи?

Vaccano
источник
1
Неверный путь ссылки? Возможно, он был добавлен с абсолютным путем, но с тех пор DLL была перемещена?
kevingessner

Ответы:

259

Убедитесь, что ваш проект не настроен на использование клиентского профиля .NET Framework 4.

Вы можете проверить / изменить это, щелкнув правой кнопкой мыши ваш проект (не решение), выберите Свойства -> Приложение -> Целевая структура . Целевая структура - это выпадающий список на этой странице.

Это проблема в Visual Studio (я бы даже сказал, что это ошибка). Для AutoMapper требуются сборки, которые исключены из клиентского профиля .NET Framework 4. Поскольку ваш проект использует эту версию фреймворка, он ломается.

Аналогичная ошибка будет распространяться на процесс сборки, когда версия .NET Framework для проекта, на который вы ссылаетесь, выше, чем проект, на который делается ссылка. проект с таргетингом на 4.5, который ссылается на проект с таргетингом на 4.5.1, выдаст вам ту же ошибку.

Когда это происходит, должно быть лучшее сообщение об ошибке, потому что нет рационального объяснения, почему оно не будет собираться, поскольку в сообщении об ошибке указывается ссылка на сборку, на которую вы явно ссылались.

Эндрю Хэйр
источник
7
Это было именно то, что проблема была! Спасибо вам! Я согласен, что эта ошибка очень вводит в заблуждение. Я также не понимаю, почему «Профиль клиента» используется по умолчанию для нового проекта. У большинства компьютеров будет полный каркас .net, верно? (Или MS просто помещает клиентскую среду в Центр обновления Windows?) В любом случае, все компьютеры, для которых я разрабатываю, будут иметь полную структуру. Хотелось бы, чтобы был способ изменить настройки по умолчанию для нового проекта, чтобы он меня укусил, как это сделал. Тем не мение. Еще раз спасибо! Я застрял и не думал смотреть туда.
Vaccano
У меня была точно такая же проблема! Типы не были распознаны в моем проекте службы Windows, даже если я правильно добавил ссылки. Я изменил целевой фреймворк с .NET Framework 4 Client Profile на .NET Framework 4. Обратите внимание, что мне также пришлось повторно добавить свои ссылки, чтобы он компилировался. Кажется, проблема в Visual Studio 2010. Спасибо и привет из Будапешта.
Варга Тамас
Хорошо, это также случилось со мной. Мой тестовый проект не распознал ссылочные пространства имен, даже если они были там. Это произошло потому, что я изменил свою библиотеку на платформу .NET 4.5, но тестовый проект остался как 4.0. В любом случае, ваш ответ выведет меня на правильный путь. Спасибо, что выяснил это.
Юкка Пуранен
Я столкнулся с той же проблемой, когда пытался использовать сборку .Net 2.0 в проекте профиля клиента .Net 3.5. и переход на 3.5 полный профиль решить проблему.
Палани
Моя проблема была похожа. В проектах использовались разные версии Framework. Основной проект использовал 4.5, а недавно созданный проект использовал 4.5.1. Было бы хорошо, если бы сообщение об ошибке было лучше.
L_7337
27

Позвольте мне задать глупый вопрос: может ли быть два файла automapper.dll ? Один с AutoMapperпространством имен и один без? Подтвердите пути в обоих проектах.

Я также заметил, что порядок usingкоманд отличается. Это не должно иметь значения, но вы пытались перетасовать их?

n8wrl
источник
18

Если ваш класс не компилируется, даже если он находится в проекте, проверьте следующее:

  1. является ли имя класса точно таким же
  2. является ли пространство имен точно таким же
  3. показывают ли свойства класса build build = compile
анонимное
источник
6
Я скопировал файл .cs с помощью Explorer, а затем включил его в проект. VS.Net установил действие сборки как «Content» вместо «Compile» и поэтому не распознавал пространство имен. Хороший улов!
AUSteve
1
Я добавил класс с помощью функции Add -> Class, и он установил действие сборки для содержимого. Просто интересно, почему? Это все равно помогло мне, что-то такое простое, но никогда прежде не встречалось. Вот почему я даже не удосужился посмотреть туда, а вместо этого погуглил.
Аномалия
14

Это должно быть самое простое решение, если все остальные ответы не помогут вам

Я искал, что не так с моей настройкой среди ответов, перепробовал их все - ни один не работал, потом я понял, что Visual Studio 2018 была разработана Microsoft . Я сделал то, что делает большинство людей,

Перезапустил Visual Studio и все заработало

страдающий бессонницей
источник
Работал у меня, но удалил папку bin и obj перед перезапуском.
Чандан Я.С.
За все мои годы работы над stackoverflow это лучший соленый ответ на ошибку (которая фактически обеспечивает решение), и она работала при первом перезапуске. бессонница
Коллин Уайт
12

Я решил эту проблему, щелкнув правой кнопкой мыши по папке с файлами и выбрав « Исключить из проекта», а затем снова щелкнув правой кнопкой мыши и выбрав « Включить в проект» (сначала необходимо включить « Показать все файлы», чтобы сделать исключенную папку видимой).

user3251328
источник
Я имел эту ошибку для тонны файлов, просто удалив один и повторно включив его, решил проблему для всего решения.
Дэрил
Щелчок правой кнопкой мыши на чем? «Исключить из проекта» удаляет папку из обозревателя решений. Там нет "Включить в проект"
Флориан Зима
2
@FlorianWinter Чтобы щелкнуть правой кнопкой мыши по исключенной папке, вам нужно включить Показать все файлы . Это можно включить через обозреватель решений, он находится рядом с кнопкой « Свернуть все» .
user3251328
Не знаю почему, но это работало в VS2019, когда я добавил новый файл, содержащий новый класс, в проект, но не смог создать новый экземпляр этого класса в другом проекте, который уже имел ссылку на проект, содержащий новый класс. ..¯\_(ツ)_/¯
matt.fc
7

У меня похожая проблема с ссылками, которые не были распознаны в VS2010, и ответы здесь не смогли исправить это.

Проблема в моем решении была связана с расширением пути, по которому находился упомянутый проект. Работая с SVN, я сделал ветку репозитория, чтобы провести некоторое тестирование, и эта ветвь увеличила два уровня в структуре пути, поэтому путь стал слишком длинным, чтобы его можно было использовать в окнах. Это не выдало никакой ошибки, но не распознало пространство имен ссылки проекта. Когда я исправляю местоположение проекта, чтобы иметь меньший путь, все прошло нормально.

onurb84
источник
2
Это было проблемой и для нас, и именно длина пути вызывала проблему. VS должен сделать лучшую работу по предоставлению лучшей ошибки в этом случае, поскольку ошибка, которую мы получили, была довольно обманчивой.
VoodooChild
Благодаря вашему ответу идея пришла мне в голову. Я посмотрел путь моего проекта и понял, что в корневой папке, созданной в дереве исходных текстов, вместо имени _ указано «% 20». Я изменил его на _ и теперь все работает нормально.
Фернандо Вольф
5

В моем случае упомянутая dll была собрана в более высокой версии .Net Framework. После того, как я добавил ссылку, я мог ее использовать. Но как только я выполнил сборку, появится ошибка «отсутствует ссылка». Я обновляю dll, ошибка будет идти, но это никогда не будет строить. Этот пост заставил меня проверить версию фреймворка, и, таким образом, я смог решить ее, построив ссылочный проект в той же версии.

Анкур-м
источник
3

Возможно, таблица типов проекта находится в неверном состоянии. Я попытался бы удалить / добавить ссылку, и если это не сработало, создайте другой проект, импортируйте мой код и посмотрите, работает ли это.

Я столкнулся с этим во время использования VS 2005, можно было бы ожидать, что MS уже исправит эту конкретную проблему, хотя ..

Дейв
источник
не могли бы вы решить эту проблему?
Fran_gg7
3

Вопрос уже был задан, но есть еще не описанные дополнительные детали, которые необходимо проверить.

У меня тоже было такое поведение, когда проект B упоминался в проекте A, но пространство имен проекта B не было распознано в проекте A. После некоторого поиска я обнаружил, что мой путь слишком длинный. Благодаря сокращению пути проектов (как A, так и B) ссылки стали видимыми и доступными.

Я проверил эту теорию, создав проект C на гораздо меньшей глубине пути. Я ссылался на проект C в проекте A. Ссылки работали правильно, как и ожидалось. Затем я удалил проект C из решения, просто переместил проект C в глубокий путь, такой же, как проект B, и добавил проект C обратно в решение, и попытался скомпилировать. У меня тогда не было никакой видимости, чтобы проектировать объекты C больше.

barrypicker
источник
2

В моем случае я скопировал библиотеку классов и не изменил «Имя сборки» в свойствах проекта, поэтому одна DLL перезаписывала другую ...

Фернандо Менезес Гомес
источник
2

Это случилось со мной в Visual Studio 2019. Я пытался сослаться на другой проект в своем решении. Вот шаги, которые я предпринял в случае, если это поможет кому-то еще:

  1. Гарантировал, что проект, на который я хотел сослаться, был перечислен под Ссылками
  2. Убедитесь, что оба проекта используют правильную версию .NET Framework
  3. Построил проект (нажал зеленую стрелку «Пуск»)

Я был смущен, потому что я все еще получал ошибку после шагов 1 и 2, но создание проекта, казалось, решало ее.

mtfalcon31
источник
1

Я столкнулся с аналогичной проблемой, связанной с тем, что пространство имен / метод не был найден во время выполнения, хотя это было нормально во время компиляции, и причина этого, по-видимому, заключается в том, что сборка, на которую я ссылался, была развернута в GAC и с тех пор была изменена, поэтому, когда я ссылался на сборку в Visual Studion он использовал самый последний, но во время выполнения использовалась версия для GAC.

Павел Цыбуливский
источник
1

В моем случае я получил ошибку только в VS 2015. При открытии проекта в VS 2017 ошибка пропала.

Даниил
источник
1

Псих. Я знаю.

Перепробовал все варианты здесь. Перезапуск, очистка, ручная проверка в сгенерированных библиотеках DLL (это неоценимо для понимания, если это действительно вы испортили).

Я заставил его работать, установив многословие MSBuild на «Подробно» в настройках.

Program.X
источник
для меня это была конфигурация сборки, установленная на AnyCpu в PlatformTarget, когда Имя конфигурации было x86. Этот параметр помог мне выяснить это.
двухместное
1

На этот вопрос уже был дан ответ для оригинального постера, но в случае, если кто-то сталкивается с этим в проекте MS-Test:

в Visual Studio выберите меню «Тест» -> «Параметры теста» -> «Архитектура процессора по умолчанию» и убедитесь, что архитектура соответствует архитектуре другой сборки, на которую вы ссылаетесь. Если другая сборка - x64, а ваши настройки теста - x86, у вас могут возникнуть симптомы, характерные для оригинального плаката.

С. Хули
источник
0

Я работал над проектом Xamarin и, как всегда, удаление папки obj и перестройка решили мою проблему, пространство имен, которое не распознавал мой VS, было кодом в моем собственном проекте.

mohas
источник
0

В моем случае удаление / добавление этой сборки сработало.

шейх сабир
источник
0

У меня была похожая проблема, для устранения которой потребовалось немного времени, поэтому я решил поделиться ей:

Пространство имен, которое не могло быть разрешено в моем случае, было Company.Project.Common.Models.EF . Я добавил файл в новое пространство имен Company.Project.BusinessLogic.Common .

Большинство файлов имели

using Company.Project;

А затем ссылки на модели как Common.Models.EF . Все файлы, которые также имели

using Company.Project.BusinessLogic;

Сбой, поскольку VS не может определить, какое пространство имен использовать.

Решение состояло в том, чтобы изменить второе пространство имен на Company.Project.BusinessLogic.CommonServices

Mapi
источник
-1

Перезапуск Visual Studio 2019 - это сделал.

Джефф Вёлер
источник
Vaccano писал: Я пытался: Перезапуск Visual Studio
Woworks