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


276

Я получаю:

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

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

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

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


Это может работать, чтобы закрыть и перезапустить Visual Studio. Иногда кажется, что «застрял»
Рис Адамс

2
Руководство: 1) сборка загружена ?, 2) сборка загружена совпадает с исходной сборкой ?, 3) директивы "using", указывающие на старые или нет действительных ссылок ?, 4) манифест .csproj содержит недопустимый источник ?, 5) инструмент поиска, выглядящий регулярным выражением во всем решении (каждая библиотека классов и проект). 5) проверьте настройки проекта для опции построения версии net Framework (совместная работа с командами приводит к возникновению такого рода проблем, вы должны согласиться с net framew. Версия сборки с обеих сторон) 6) После этого очистите и соберите каждый отдельно и, наконец, включите все ссылки в целевой проект / библиотеку классов. Я должен работать!
Феликс Абалли

Проверьте, ссылались ли вы на dll. Dll находится в папке bin вашего каталога решений.
Абхишек Пуджары

Ответы:


471

Это может быть результатом несовместимости версии .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, и затем вы ссылаетесь на эти старые проекты из новый проект)


2
отлично - это сработало - мне пришлось обновить мой клиент приложения WPF для использования полной версии .NET Framework 4. Не знаете, какое влияние это окажет на клиентскую зону? Я попытался понизить имеющуюся у меня библиотеку до .Net 4 Client Profile, однако, когда я сделал это, у нее возникли похожие проблемы с недавней сторонней библиотекой Quartz.net, которую я только начал использовать. Таким образом, кажется, что использование Quartz.net в моем библиотечном проекте в конечном итоге вынуждает меня использовать полную инфраструктуру .Net 4 в моем приложении WPF UI.
Грег

3
Спасибо - это помогло только сейчас. Недавно я переместил решение в VS2012 из VS2010 и создал одну новую библиотеку классов в VS2012. Внезапно я получил эту ошибку, и, конечно, это произошло потому, что новая библиотека классов нацелена на .NET 4.5, а проект, на который она ссылается, на .NET 4.0. Понижение новой библиотеки до цели 4.0 исправило это.
Ричард

22
Было бы здорово, если бы Visual Studio дала вам какой-то намек на это!
Джейсон Койн

3
Хотя этот ответ дает отличное описание того, что нужно делать ... в нем нет предложений о том, как это сделать, что было бы хорошим дополнением
Jon Story

1
Иногда даже лучшим из нас никогда не приходилось выполнять некоторые задачи. Я не уверен, что мне никогда не нужно было менять каркас, и хотя я нашел его, мне раньше этого не приходило в голову. Ответ не является решающим фактором, просто я нахожу, что самые лучшие ответы действуют как единое окно для «опишите проблему, изложите решение, покажите, как ее исправить»
Jon Story

50

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

Update-Package reinstall

Проблема, с которой я столкнулся, заключалась в том, что я создал новое решение, добавил другую версию пакета Nuget, отличную от используемой. Затем, когда я запустил, у Update-Package -reinstallменя было несколько ошибок во всем решении, включая другую версию этого пакета. Я обновил во всем, то это, наконец, запустить. Также исправлены ссылки в файлах package.json с 45 на 452, поскольку я также изменил целевую версию назад.
Адам Ковач

Работал для меня, и мне пришлось удалить Sytems.Net.Http из ссылок при понижении
Бинил Анто

1
Это было то, что работало для меня. Запустил команду, затем
снял

Это сработало для меня, оно показало мне ссылку, которая не поддерживалась моей нынешней платформой
Адлери

это сработало для меня, и ошибка, которая исчезла, была совершенно не связана с любым установленным пакетом nuget.
CAD-блок

31

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


Настоятельно рекомендуем этот прием при обнаружении проблем со ссылками в решении VS. Это решило мою проблему в VS2017 после того, как я добавил новый проект, ориентированный на более высокую версию .NET Framework. Могу поспорить, что очищено некоторое кэширование.
themefield

1
То же самое здесь: это то, что помогло (у меня также не было других проблем с версией). Я получал сообщения об ошибках для каждого открытого файла, до 400+ ... хотя сборка / запуск не был проблемой. Кроме того: анализ решения ReSharper также показал те же ошибки.
Майк

Помог мне тоже этот трюк. Даже не было различий в целевой версии. Строительство было возможно, Райдер не показывал никаких проблем, но VS продолжал настаивать на том, что все ссылки на проекты отсутствовали ...
Даниэль Лерпс

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

29

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

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

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

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

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

Сделать это:

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

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


2
Спасибо за подсказку, чтобы посмотреть на предупреждения. Моя проблема заключалась в том, что моему тестовому проекту требовалось установить пакет NuGet для Bcl, поскольку мой основной проект ссылался на него.
Ким

Спасибо! Это побудило меня найти проблему, с которой я столкнулся. Оказывается, у меня было две ссылки на проект зависимостей, и тот, который имел приоритет, был ранее созданной DLL в папке bin. Я удалил DLL и мошенническую ссылку и сделал перестройку, тогда все скомпилировалось правильно.
Крис Дэвис

7

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

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


Я пытался очистить и восстановить ваше решение, но не повезло. Попытался удалить / добавить / очистить / перестроить только проект приложения WPF, но все равно не повезло. :(
Грег

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

5

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

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


1
Ах, спасибо за это. Мой переносимый проект прекрасно компилировался в Xamarin Studio, но из-за этого он не работал в Visual Studio. Я думаю, что XS делает некоторую «магию», чтобы позволить ей компилироваться, когда неявные ссылки отсутствуют.
Никола Яроччи

5

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

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


4

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


4

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

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


3

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

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

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

Бум Шанкар.


2

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


2

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


2

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

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

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


1
У меня была похожая проблема с плохим слиянием в VS 2019. Проект успешно скомпилирован, но решение не найдено. На самом деле была ошибка для этого проекта (очень странно). Сбой из-за ссылки на дополнительный файл, который был ранее удален, но затем повторно добавлен после слияния. Я удалил файл, очистил файл .csproj, перестроил, и все ссылки снова начали работать.
Cryptc

2

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

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

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

1

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


1

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

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

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

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


1

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

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

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


1

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

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

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

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


1

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

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

1

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

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


Это была точная проблема для меня. Я удалил System.Core и перестроил, ошибки сразу решили сами. Спасибо миллион за то, что
избавил


1

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


1

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


Где я могу отредактировать название сборки, чтобы изменить его на правильное имя?
Matt123

1
в файле проекта (.csproj) вручную или щелкнув правой кнопкой мыши на проекте -> Свойства
user1121956

0

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


0

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

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

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


0

Я получил эту ошибку, пытаясь сделать сборку с помощью сборки 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.


0

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

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


0

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

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


0

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


0

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

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

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

введите описание изображения здесь

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

введите описание изображения здесь


Я думаю, вы обнаружите, что это работает, только если открыта панель «Свойства» (щелкните правой кнопкой мыши проблемную ссылку и выберите «Свойства».) Теперь кто-нибудь может объяснить, почему это работает?
Qwertie
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.