Подтвердить что ты не робот

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

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

Не удалось найти имя типа или пространства имен "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>();
        }

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

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

Я пробовал:

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

Любые другие идеи?

4b9b3361

Ответ 1

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

  • ли имя класса точно такое же
  • будет ли пространство имен точно таким же.
  • свойства класса show build action = compile

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

Вопрос уже отмечен, но еще нет подробных сведений о том, что необходимо проверить.

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

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

Ответ 13

Псих. Я знаю.

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

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

Ответ 14

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

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

Ответ 15

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

Ответ 16

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

Ответ 17

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

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

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