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

Ответ 1

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

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

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

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

Итак, чтобы сделать это более ясным:

• Проект A предназначен для структуры профиля клиента
• Проект 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

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

Update-Package –reinstall

Ответ 3

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

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

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

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

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

Сделать это:

1. Я щелкнул правой кнопкой мыши мое решение в обозревателе решений и выбрал "Свойства",
2. Затем в "Common Properties" я выбрал "Project Dependencies".
3. Затем в раскрывающемся меню "Проекты" я выбрал проект, который полагался на библиотеку, и
4. Проверьте флажок рядом с библиотекой, найденной в разделе "Зависит от",

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

Ответ 4

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

Ответ 5

Он может работать, чтобы закрыть и перезапустить Visual Studio. Иногда кажется, что он "застрял"

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

У нас был странный случай, который я только что зафиксировал в решении. Перед оператором "using" в основном проекте был скрытый/пробельный символ. Этот проект будет прекрасно работать, и веб-сайт работал нормально, но проект unit test, который ссылался на него, не мог быть создан.

Ответ 11

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

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

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

Бум Шанкар.

Ответ 12

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

Ответ 13

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

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

Ответ 14

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

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

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

Ответ 15

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

Ответ 16

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

Ответ 17

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

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

например. EntityFramework6.dll и EntityFramework.dll.

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

Ответ 18

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

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

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

Ответ 19

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

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

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

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

Ответ 20

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

Ответ 21

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

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

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

Ответ 22

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

• Перезапустить Visual Studio
• Очистить проект, который не удалось создать.
• Восстановить проект.

Ответ 23

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

Ответ 24

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

Ответ 25

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

Ответ 26

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

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

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

Ответ 27

В моем случае я вошел в свойства решения и убедился, что "Build" был проверен в конфигурации для обоих проектов. Мой основной проект не проверял его.

Ответ 28

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

Ответ 29

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

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

Ответ 30

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

Не знаю, почему это сработало.