Я получаю эту ошибку:
Не удалось найти тип или имя пространства имен '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
) - Очистить и восстановить
Есть другие идеи?
Ответы:
Убедитесь, что ваш проект не настроен на использование клиентского профиля .NET Framework 4.
Вы можете проверить / изменить это, щелкнув правой кнопкой мыши ваш проект (не решение), выберите Свойства -> Приложение -> Целевая структура . Целевая структура - это выпадающий список на этой странице.
Это проблема в Visual Studio (я бы даже сказал, что это ошибка). Для AutoMapper требуются сборки, которые исключены из клиентского профиля .NET Framework 4. Поскольку ваш проект использует эту версию фреймворка, он ломается.
Аналогичная ошибка будет распространяться на процесс сборки, когда версия .NET Framework для проекта, на который вы ссылаетесь, выше, чем проект, на который делается ссылка. проект с таргетингом на 4.5, который ссылается на проект с таргетингом на 4.5.1, выдаст вам ту же ошибку.
Когда это происходит, должно быть лучшее сообщение об ошибке, потому что нет рационального объяснения, почему оно не будет собираться, поскольку в сообщении об ошибке указывается ссылка на сборку, на которую вы явно ссылались.
источник
Позвольте мне задать глупый вопрос: может ли быть два файла automapper.dll ? Один с
AutoMapper
пространством имен и один без? Подтвердите пути в обоих проектах.Я также заметил, что порядок
using
команд отличается. Это не должно иметь значения, но вы пытались перетасовать их?источник
Если ваш класс не компилируется, даже если он находится в проекте, проверьте следующее:
источник
Это должно быть самое простое решение, если все остальные ответы не помогут вам
Я искал, что не так с моей настройкой среди ответов, перепробовал их все - ни один не работал, потом я понял, что Visual Studio 2018 была разработана Microsoft . Я сделал то, что делает большинство людей,
Перезапустил Visual Studio и все заработало
источник
Я решил эту проблему, щелкнув правой кнопкой мыши по папке с файлами и выбрав « Исключить из проекта», а затем снова щелкнув правой кнопкой мыши и выбрав « Включить в проект» (сначала необходимо включить « Показать все файлы», чтобы сделать исключенную папку видимой).
источник
¯\_(ツ)_/¯
У меня похожая проблема с ссылками, которые не были распознаны в VS2010, и ответы здесь не смогли исправить это.
Проблема в моем решении была связана с расширением пути, по которому находился упомянутый проект. Работая с SVN, я сделал ветку репозитория, чтобы провести некоторое тестирование, и эта ветвь увеличила два уровня в структуре пути, поэтому путь стал слишком длинным, чтобы его можно было использовать в окнах. Это не выдало никакой ошибки, но не распознало пространство имен ссылки проекта. Когда я исправляю местоположение проекта, чтобы иметь меньший путь, все прошло нормально.
источник
В моем случае упомянутая dll была собрана в более высокой версии .Net Framework. После того, как я добавил ссылку, я мог ее использовать. Но как только я выполнил сборку, появится ошибка «отсутствует ссылка». Я обновляю dll, ошибка будет идти, но это никогда не будет строить. Этот пост заставил меня проверить версию фреймворка, и, таким образом, я смог решить ее, построив ссылочный проект в той же версии.
источник
Возможно, таблица типов проекта находится в неверном состоянии. Я попытался бы удалить / добавить ссылку, и если это не сработало, создайте другой проект, импортируйте мой код и посмотрите, работает ли это.
Я столкнулся с этим во время использования VS 2005, можно было бы ожидать, что MS уже исправит эту конкретную проблему, хотя ..
источник
Вопрос уже был задан, но есть еще не описанные дополнительные детали, которые необходимо проверить.
У меня тоже было такое поведение, когда проект B упоминался в проекте A, но пространство имен проекта B не было распознано в проекте A. После некоторого поиска я обнаружил, что мой путь слишком длинный. Благодаря сокращению пути проектов (как A, так и B) ссылки стали видимыми и доступными.
Я проверил эту теорию, создав проект C на гораздо меньшей глубине пути. Я ссылался на проект C в проекте A. Ссылки работали правильно, как и ожидалось. Затем я удалил проект C из решения, просто переместил проект C в глубокий путь, такой же, как проект B, и добавил проект C обратно в решение, и попытался скомпилировать. У меня тогда не было никакой видимости, чтобы проектировать объекты C больше.
источник
В моем случае я скопировал библиотеку классов и не изменил «Имя сборки» в свойствах проекта, поэтому одна DLL перезаписывала другую ...
источник
Это случилось со мной в Visual Studio 2019. Я пытался сослаться на другой проект в своем решении. Вот шаги, которые я предпринял в случае, если это поможет кому-то еще:
Я был смущен, потому что я все еще получал ошибку после шагов 1 и 2, но создание проекта, казалось, решало ее.
источник
Я столкнулся с аналогичной проблемой, связанной с тем, что пространство имен / метод не был найден во время выполнения, хотя это было нормально во время компиляции, и причина этого, по-видимому, заключается в том, что сборка, на которую я ссылался, была развернута в GAC и с тех пор была изменена, поэтому, когда я ссылался на сборку в Visual Studion он использовал самый последний, но во время выполнения использовалась версия для GAC.
источник
В моем случае я получил ошибку только в VS 2015. При открытии проекта в VS 2017 ошибка пропала.
источник
Псих. Я знаю.
Перепробовал все варианты здесь. Перезапуск, очистка, ручная проверка в сгенерированных библиотеках DLL (это неоценимо для понимания, если это действительно вы испортили).
Я заставил его работать, установив многословие MSBuild на «Подробно» в настройках.
источник
На этот вопрос уже был дан ответ для оригинального постера, но в случае, если кто-то сталкивается с этим в проекте MS-Test:
в Visual Studio выберите меню «Тест» -> «Параметры теста» -> «Архитектура процессора по умолчанию» и убедитесь, что архитектура соответствует архитектуре другой сборки, на которую вы ссылаетесь. Если другая сборка - x64, а ваши настройки теста - x86, у вас могут возникнуть симптомы, характерные для оригинального плаката.
источник
Я работал над проектом Xamarin и, как всегда, удаление папки obj и перестройка решили мою проблему, пространство имен, которое не распознавал мой VS, было кодом в моем собственном проекте.
источник
В моем случае удаление / добавление этой сборки сработало.
источник
У меня была похожая проблема, для устранения которой потребовалось немного времени, поэтому я решил поделиться ей:
Пространство имен, которое не могло быть разрешено в моем случае, было Company.Project.Common.Models.EF . Я добавил файл в новое пространство имен Company.Project.BusinessLogic.Common .
Большинство файлов имели
А затем ссылки на модели как Common.Models.EF . Все файлы, которые также имели
Сбой, поскольку VS не может определить, какое пространство имен использовать.
Решение состояло в том, чтобы изменить второе пространство имен на Company.Project.BusinessLogic.CommonServices
источник
Перезапуск Visual Studio 2019 - это сделал.
источник