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

Я получаю:

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

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

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

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

Это может быть результатом несовместимости версии .Net Framework между двумя проектами.

Это может произойти двумя способами:

1. проект профиля клиента, ссылающийся на полный каркасный проект; или
2. более старая версия фреймворка, ориентированная на более новую версию фреймворка

Например, это произойдет, когда приложение настроено на целевую платформу .Net 4 Client Profile, а проект, на который оно ссылается, нацелено на полную платформу .Net 4.

Итак, чтобы прояснить это:

• Проект А ориентирован на структуру профиля клиента
• Проект A ссылки Проект B
• Проект B ориентирован на полную

Решение в этом случае состоит в том, чтобы либо обновить целевой объект приложения (проект A), либо понизить целевой объект сборки (проект B). Это нормально для приложения полного фреймворка ссылаться / использовать сборку фреймворка профиля клиента, но не наоборот (профиль клиента не может ссылаться на целевую сборку целевого фреймворка).

Обратите внимание, что вы также можете получить эту ошибку при создании нового проекта в VS2012 или VS2013 (который использует .Net 4.5 в качестве платформы по умолчанию) и:

• ссылочный проект (ы) используют .Net 4.0 (это часто происходит, когда вы мигрировали с VS2010 на VS2012 или VS2013 и затем добавили новый проект)

• в ссылочных проектах используется более поздняя версия, т.е. 4.5.1 или 4.5.3 (вы перенаправили существующие проекты на последнюю версию, но VS по-прежнему создает новые проекты, ориентированные на v4.5, и затем вы ссылаетесь на эти старые проекты из новый проект)

Переустановка пакетов nuget помогла мне. После того, как я изменил версии .NET Framework для синхронизации всех проектов, некоторые пакеты nuget (особенно Entity Framework) все еще были установлены для предыдущих версий. Эта команда в консоли диспетчера пакетов переустанавливает пакеты для всего решения:

Update-Package –reinstall

Я понятия не имею, почему это сработало, но я удалил ссылку на проект, который VS2015 сообщал мне, что не может найти, и добавил его снова. Решил проблему. Я пытался очистить, построить и перезапустить VS безрезультатно.

При создании решения я получал ту же ошибку (не удалось найти тип или пространство имен ''). Ниже я увидел предупреждение о том, что «ссылка не может быть разрешена» и что «сборка существует на диске».

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

Я наконец понял проблему (или по крайней мере то, что я подозреваю, была проблема). Я строил файл библиотеки в том же решении. Таким образом, несмотря на то, что он существовал на диске, он перестраивался в этом месте (каким-то образом в процессе перестройки библиотеки мой другой проект - в том же решении - который ссылался на библиотеку, должен был решить, что библиотека не существует)

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

Чтобы решить эту проблему, я добавил библиотеку в качестве зависимости к проекту, который ее использовал.

Сделать это:

1. Я щелкнул правой кнопкой мыши свое решение в обозревателе решений и выбрал «Свойства»
2. Затем в «Общие свойства» я выбрал «Зависимости проекта».
3. Затем в раскрывающемся меню «Проекты» я выбрал проект, основанный на библиотеке, и
4. Установлен флажок рядом с библиотекой в ​​разделе «Зависит от»

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

Сначала я хотел бы убедиться, что информация, сгенерированная вашим проектом, не повреждена. Сделайте чистку и восстановите свое решение.

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

Ситуация, с которой я столкнулся, была более сложной: первый проект нацелен на полный фреймворк 4.0 с Microsoft.Bcl.Asyncустановленным пакетом. Второй проект предназначен для полной версии 4.0, но не будет компилироваться при ссылке на один класс проекта.

После того, как я установил пакет Async NuGet на второй проект, он скомпилировался нормально.

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

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

Этот работал для меня. В вашем классе, где определено имя класса, например: Открытый класс ABC, удалите один символ и немного подождите. Ваш список ошибок увеличится, потому что вы изменили имя. Теперь верните символ, который вы ввели. Это сработало для меня, надеюсь, это сработает и для вас. Удачи!!!

У меня была похожая проблема: компилятору не удалось обнаружить папку внутри того же проекта , поэтому директива using, ссылающаяся на эту папку, вызвала ошибку. В моем случае проблема возникла из-за переименования папки . Несмотря на то, что я обновил пространство имен всех классов в этой папке, информация о проекте почему-то не удалось обновить. Я перепробовал все: удаление файла .suo и папок bin и obj, очистка решения, перезагрузка проекта - ничего не помогло. Я решил проблему, удалив папку и классы внутри нее, создав новую папку и создав новые классы в этой новой папке (простое перемещение классов внутри новой папки не помогло).

PS: в моем случае я работал над веб-приложением, но эта проблема может возникать в разных типах проектов.

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

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

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

Бум Шанкар.

У нас был странный случай, который я только что исправил в решении. Перед оператором «использование» в основном проекте был скрытый / пробельный символ. Этот проект будет хорошо работать, и веб-сайт будет работать нормально, но проект модульного тестирования, который ссылается на него, не может быть построен.

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

Если были те же ошибки, моя история была следующей: после неудачного слияния (через git) один из моих файлов .csproj имел дублированные compileзаписи, такие как:

<Compile Include="Clients\Tree.cs" />
<Compile Include="Clients\Car.cs" />
<Compile Include="Clients\Tree.cs" />        //it's a duplicate

Если у вас есть большое решение и более 300 сообщений в окне ошибок, трудно обнаружить эту проблему. Итак, я открыл поврежденный файл .csproj через блокнот и удалил дублированные записи. Работал в моем случае.

У меня была та же проблема, что и обсуждалась: VS 2017 подчеркивает класс в ссылочном проекте как ошибку, но решение работает нормально, и даже intellisense работает.

Вот как мне удалось решить эту проблему:

1. Выгрузить указанный проект
2. Откройте файл .proj в VS (я искал дубликаты, как кто-то предложил здесь)
3. Перезагрузите проект еще раз (я не изменил и даже не сохранил файл proj, так как у меня не было дубликатов)

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

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

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

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

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

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

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

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

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

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

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

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

Это событие произошло в Visual Studio 2017.

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

Мой случай был таким же, как обсуждалось здесь, но ничего не решил, пока я не удалил System.Core ссылку из списка ссылок (без него все работало нормально)

надеюсь, что это поможет кому-то, потому что эта проблема довольно расстраивает

Для решения этой проблемы также может помочь удалить и заново создать *.sln.DotSettingsфайл соответствующего решения.

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

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

В моем случае у меня был файл, созданный с помощью внешней зависимости (xsd2code), и почему-то его файлы designer.cs не были правильно обработаны VS. Создание нового файла в Visual Studio и вставка в него кода помогли мне.

Всем, кто получает эту ошибку при попытке опубликовать свой сайт в Azure, ни одно из представленных выше перспективных решений не помогло мне. Я был в одной лодке - моё решение строилось само собой. В итоге мне пришлось

1. Удалите все пакеты nuget в моем решении.
2. Закройте и снова откройте мое решение.
3. Повторно добавьте все пакеты nuget.

Немного больно, но это был единственный способ опубликовать свой сайт в Azure.

Я получил эту ошибку, пытаясь сделать сборку с помощью сборки Visual Studio Team Services, работающей на моем локальном компьютере в качестве агента.

Это нормально работало в моей обычной рабочей области, и я смог открыть файл SLN в папке агента локально, и все скомпилировано нормально.

Рассматриваемая DLL была сохранена в проекте как Lib/MyDLL.DLLи ссылки на это в файле csproj:

<Reference Include="MYDLL, Version=2009.0.0.0, Culture=neutral, PublicKeyToken=b734e31dca085caa">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>Lib\MYDLL.dll</HintPath>
</Reference>

Оказалось, что буквально просто не нашел файл, несмотря на путь подсказки. Я думаю, что, возможно, msbuild выглядел относительно файла SLN вместо файла проекта.

В любом случае, если полученное сообщение Could not resolve this reference. Could not locate the assembly убедитесь, что DLL находится в доступном месте для msbuild.

Я вроде как обманул и нашел сообщение, в котором говорилось, Considered "Reference\bin\xxx.dll"и вместо этого просто скопировал туда dll.

В моем случае добавление DLL в качестве ссылки дало type or namespace name could not be found ошибку. Тем не менее, копирование и вставка файла DLL непосредственно в папку bin устраняет ошибку.

Понятия не имею, почему это сработало.

Я знаю, что этот поток старый, но в любом случае, я делюсь, мне нужно установить все зависимости третьей части импортированной сборки - поскольку импортированная сборка не была включена в пакет Nuget, следовательно, ее зависимости отсутствовали.

Хоп это поможет :)

В моем случае у меня было два проекта в решении, я добавил под-пространство имен в ссылочный проект, но при сборке я не заметил, что сборка ссылочного проекта завершилась неудачно, и он использовал последнюю успешно собранную версию, которая не У меня есть это новое пространство имен, поэтому ошибка была правильной, и ее нельзя найти, потому что ее не было. Очевидно, решение было исправить ошибки в ссылочном проекте.

Я работал над версией сообщества VS 2017 и у меня была та же проблема с пакетами Nuget CefSharp.

Пакеты были успешно загружены и восстановлены, проект мог быть собран и успешно запущен - только разметка указывала, что пространства имен не были распознаны.

Все, что мне нужно было сделать, это открыть Referencesраздел и нажать на один из желтых восклицательных знаков.

Через несколько секунд ошибки разметки исчезли.