Получение "типа или имени пространства имен не может быть найдено", но все кажется нормальным?

Question

Я получаю:

имя типа или пространства имен не найдено

ошибка для приложения C # WPF в VS2010. Эта область кода компилировалась нормально, но внезапно я получаю эту ошибку. Я пытался удалить ссылку на проект и оператор using, закрыть VS2010 и перезапустить, но все же у меня есть эта проблема.

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

Я также отметил в VS2010, что intellisense для этого пространства имен работает нормально, поэтому кажется, что VS2010 имеет ссылку на проект и видит пространство имен с одной стороны, но во время компиляции его не видит?

Answer 1

Я столкнулся с этой проблемой при обновлении существующих проектов с VS2008 до VS2012. Я обнаружил, что два проекта (только два, которые я создал) были нацелены на разные .Net Frameworks (3.5 и 4.0). Я решил эту проблему на вкладке «Приложение» проектов, убедившись, что в обоих проектах был установлен «.NET Framework 4» в поле Target Framework.

Answer 2

В моем случае, я считаю, что ссылка в VisualStudio имеет треугольник и восклицательный знак, как это изображение,

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

Answer 3

[Facepalm] Моя проблема заключалась в том, что я добавил зависимость в способе выполнения C ++.

Перейдите в проект, который не будет создан, откройте папку «Ссылки» в обозревателе решений и посмотрите, есть ли ваша зависимость в списке.

Если нет, вы можете «Добавить ссылку» и выбрать зависимость на вкладке «Проекты».

Бум Шанкар.

Answer 4

Вы также можете попробовать удалить код, с которым вы думаете возникли проблемы, и посмотреть, компилируется ли он без ссылок на этот код.Если нет, исправляйте ошибки до тех пор, пока он снова не скомпилируется, а затем верните ваш подозрительный код проблемы обратно. Иногда я получаю странные ошибки о классах или методах, которые, как я знаю, являются правильными, когда компилятору не нравится что-то еще.Как только я исправляю то, от чего действительно зависает, эти «фантомные» ошибки исчезают.

Answer 5

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

В моем случае я добавил новый класс в один проект, но потому что мои привязки контроля версий не былиМне нужно было сделать файл доступным для записи вне Visual Studio (через VC).Я отменил сохранение в Visual Studio, но после того, как я сделал файл доступным для записи вне VS, я снова нажал Save All в VS.Это непреднамеренно привело к тому, что новый файл класса не был сохранен в проекте .. однако ... Intellisense по-прежнему показывал его синим и действительным в ссылочных проектах, даже когда я пытался перекомпилировать файл, он не был найден и получилошибка типа не найдена.Закрытие и открытие Visual Studio все еще показывали проблему (но, если бы я обратил внимание, что файл класса отсутствовал при повторном открытии).

Как только я понял это, исправление было простым: с файлом проекта, установленным для записи, readdотсутствующий файл в проекте.Теперь все хорошо.

Answer 6

Я знаю, что это пинает мертвую лошадь, но у меня была эта ошибка и рамки, где все в порядке.Моя проблема в основном заключалась в том, что интерфейс не может быть найден, но все же он хорошо собран.Поэтому я подумал: «Почему именно этот интерфейс, когда другие работают нормально?»

В итоге я фактически получал доступ к сервису, используя WCF с интерфейсом конечной точки, который использовал Entity Version 6, а остальные проекты использовали версию 5. Вместо NuGet я просто скопировал пакеты nuget влокальный репозиторий для повторного использования и перечислил их по-разному.

например EntityFramework6.dll против EntityFramework.dll .

Затем я добавил ссылки на клиентский проект и poof, моя ошибка ушла.Я понимаю, что это крайний случай, так как большинство людей не будут смешивать версии Entity Framework.

Answer 7

В моем случае проблема заключалась в том, что после изменения пространства имен на точно такое же, как в другом проекте (намеренно), имя сборки также было изменено VS, поэтому было две сборки с одинаковым именем, одна переопределяла другую

Answer 8

У меня была такая же проблема.Однажды ночью мой проект скомпилирует на следующее утро ОШИБКИ!.

В конце концов я обнаружил, что Visual Studio решила «подправить» некоторые из моих ссылок и указать их в другом месте.например:

System.ComponentModel.ISupportInitialize каким-то образом стал "blahblah.System.ComponentModel.ISupportInitialize"

Довольно грубо, если вы как я *

Answer 9

В моем случае у меня был класс, который был указан в соответствующей исходной папке, но не регистрировался в обозревателе решений. Мне нужно было щелкнуть правой кнопкой мыши по проекту> Добавить существующий элемент и вручную выбрать тот класс, который, как он сказал, отсутствует. Тогда все работало нормально!

Answer 10

Это событие происходит в Visual Studio 2017.

1. Перезапустите Visual Studio
2. Очистите проект, который не удается построить.
3. Перестройте проект.