Пространство имен не распознано (хотя оно и есть)
Я получаю эту ошибку:
Не удалось найти тип или имя пространства имен 'AutoMapper' (отсутствует директива using или ссылка на сборку?)
Самое смешное, что у меня уже есть эта ссылка в моем проекте:
И это мой код:
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. Они оба работают отлично.
Вот снимок экрана одного:
и вот этот код (который прекрасно компилируется):
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>();
}
Кажется, что обе ссылки имеют одинаковые данные на странице свойств.
Что мне не хватает?
Я старался:
- Перезапуск Visual Studio
- Ссылка без использования оператора (т.е.
AutoMapper.Mapper.CreateMap
) - Очистить и восстановить
Есть другие идеи?
21 ответ
Убедитесь, что ваш проект не настроен на использование клиентского профиля.NET Framework 4.
Вы можете проверить / изменить это, щелкнув правой кнопкой мыши ваш проект (не решение), выберите Свойства -> Приложение -> Целевая структура. Целевая структура - это выпадающий список на этой странице.
Это проблема в Visual Studio (я бы даже сказал, что это ошибка). Для AutoMapper требуются сборки, которые исключены из клиентского профиля.NET Framework 4. Поскольку ваш проект использует эту версию фреймворка, он ломается.
Аналогичная ошибка будет распространяться на процесс сборки, когда версия.NET Framework для проекта, на который вы ссылаетесь, выше, чем проект, на который делается ссылка. проект с 4.5, который ссылается на проект с 4.5.1, выдаст вам ту же ошибку.
Когда это происходит, должно быть лучшее сообщение об ошибке, потому что нет рационального объяснения, почему оно не будет собираться, поскольку в сообщении об ошибке указывается ссылка на сборку, на которую вы явно ссылались.
Это должно быть самое простое решение, если все остальные ответы не помогут вам
Я искал, что не так с моей настройкой среди ответов, перепробовал их все - ни один не работал, затем я понял, что Visual Studio 2018 была разработана Microsoft. Я сделал то, что делает большинство людей,
Перезапустил Visual Studio и все заработало
Позвольте мне задать глупый вопрос: может ли быть два файла automapper.dll? Один с AutoMapper
Пространство имен и один без? Подтвердите пути в обоих проектах.
Я также заметил, что порядок using
Команды разные. Это не должно иметь значения, но вы пытались перетасовать их?
Если ваш класс не компилируется, даже если он находится в проекте, проверьте следующее:
- является ли имя класса точно таким же
- является ли пространство имен точно таким же
- показывают ли свойства класса build build = compile
Я решил эту проблему, щелкнув правой кнопкой мыши папку с файлами и выбрав " Исключить из проекта", а затем снова щелкнув правой кнопкой мыши и выбрав " Включить в проект" (сначала необходимо включить " Показать все файлы", чтобы сделать исключенную папку видимой).
У меня похожая проблема с ссылками, которые не были распознаны в VS2010, и ответы здесь не смогли исправить это.
Проблема в моем решении была связана с расширением пути, по которому находился упомянутый проект. Поскольку я работаю с SVN, я сделал ветвь репозитория, чтобы провести некоторое тестирование, и эта ветвь увеличила два уровня в структуре пути, поэтому путь стал слишком длинным, чтобы его можно было использовать в окнах. Это не выдало никакой ошибки, но не распознало пространство имен ссылки проекта. Когда я исправляю местоположение проекта, чтобы иметь меньший путь, все прошло нормально.
В моем случае упомянутая dll была собрана в более позднюю версию.Net Framework. После того, как я добавил ссылку, я мог ее использовать. Но как только я выполнил сборку, появится ошибка "отсутствует ссылка". Я обновляю dll, ошибка будет идти, но это никогда не будет строить. Этот пост заставил меня проверить версию фреймворка, и, таким образом, я смог решить ее, построив ссылочный проект в той же версии.
Вопрос уже был задан, но есть еще не описанные дополнительные детали, которые необходимо проверить.
У меня тоже было такое поведение, когда проект B упоминался в проекте A, но пространство имен проекта B не было распознано в проекте A. После некоторого копания я обнаружил, что мой путь слишком длинный. Благодаря сокращению пути проектов (как A, так и B) ссылки стали видимыми и доступными.
Я проверил эту теорию, создав проект C на гораздо меньшей глубине пути. Я ссылался на проект C в проекте A. Ссылки работали правильно, как и ожидалось. Затем я удалил проект C из решения, просто переместил проект C в глубокий путь, такой же, как проект B, и добавил проект C обратно в решение, и попытался скомпилировать. У меня тогда не было никакой видимости, чтобы проектировать объекты C больше.
Возможно, таблица типов проекта находится в неверном состоянии. Я попытался бы удалить / добавить ссылку, и если это не сработало, создайте другой проект, импортируйте мой код и посмотрите, работает ли это.
Я столкнулся с этим при использовании VS 2005, можно было бы ожидать, что MS уже исправит эту конкретную проблему, хотя..
Это случилось со мной в Visual Studio 2019. Я пытался сослаться на другой проект в своем решении. Вот шаги, которые я предпринял на случай, если это поможет кому-то еще:
- Убедитесь, что проект, на который я хочу сослаться, указан в разделе "Ссылки".
- Убедитесь, что оба проекта используют правильную версию.NET Framework.
- Создал проект (нажал зеленую стрелку "Пуск")
Я был сбит с толку, потому что после шагов 1 и 2 я все еще получал ошибку, но создание проекта, похоже, разрешило ее.
В моем случае я скопировал библиотеку классов и не изменил "Имя сборки" в свойствах проекта, поэтому одна DLL перезаписывала другую...
На этот вопрос уже был дан ответ для оригинального постера, но в случае, если кто-то сталкивается с этим в проекте MS-Test:
в Visual Studio выберите меню "Тест" -> "Параметры теста" -> "Архитектура процессора по умолчанию" и убедитесь, что архитектура соответствует архитектуре другой сборки, на которую вы ссылаетесь. Если другая сборка - x64, а ваши настройки теста - x86, у вас могут возникнуть симптомы, характерные для оригинального плаката.
Псих. Я знаю.
Перепробовал все варианты здесь. Перезапуск, очистка, ручная проверка в сгенерированных библиотеках DLL (это неоценимо для понимания, если это действительно вы испортили).
Я заставил его работать, установив многословие MSBuild на "Подробно" в настройках.
Я столкнулся с аналогичной проблемой, связанной с тем, что пространство имен / метод не был найден во время выполнения, хотя это было нормально во время компиляции, и причина этого заключается в том, что сборка, на которую я ссылался, была развернута в GAC и с тех пор была изменена, поэтому, когда я ссылался на сборку в Visual Studion он использовал самый последний, но во время выполнения использовалась версия для GAC.
В моем случае я получил ошибку только в VS 2015. При открытии проекта в VS 2017 ошибка пропала.
Мое решение состояло в том, чтобы удалить папку .vs из папки моего решения. Это сбрасывает intellisense, устраняя проблему. Вам нужно будет включить «Скрытые элементы» (если работаете с Windows), так как это скрытая папка.
Решение найдено здесь - https://weblog.west-wind.com/posts/2018/Aug/07/Fixing-Visual-Studio-Intellisense-Errors
Я работал над проектом Xamarin и, как всегда, удаление папки obj и перестройка решили мою проблему, пространство имен, которое не распознал мой VS, было кодом в моем собственном проекте.
У меня была аналогичная проблема, для устранения которой потребовалось немного времени, поэтому я решил поделиться ею:
В моем случае не удалось разрешить пространство имен Company.Project.Common.Models.EF. Я добавил файл в новое пространство имен Company.Project.BusinessLogic.Common.
Большинство файлов имели
using Company.Project;
И затем ссылка на модели как Common.Models.EF. Все файлы с
using Company.Project.BusinessLogic;
Сбой, поскольку VS не может определить, какое пространство имен использовать.
Решением было изменить второе пространство имен на Company.Project.BusinessLogic.CommonServices.
Признавая это как более старый пост, но все же решил, что добавлю это предложение в список ответов, так как я не видел, чтобы оно упоминалось.
Если неразрешенная ссылка существует в контексте другого проекта в решении:
Щелкните правой кнопкой мыши проект, в котором возникла проблема, выберите Build Dependencies -> Project Dependencies и убедитесь, что нужный проект выбран для справки.
У меня была та же проблема, что и описанная в сообщении, однако ни один из предложенных способов решения не помог. Я никогда раньше не видел такой причуды в VS (сейчас работает VS 2019)
Я проверил возможные проблемы с пространством имен и множество более очевидных причин, но ничего не имело смысла. Intellisense даже признал существование другого проекта и предложил использовать оператор using, но даже после добавления ссылки using; VS 2019 по-прежнему не признает другой проект.
Форсирование зависимости описанным способом решило проблему.