Не удалось найти тип или имя пространства имен, но все в порядке?

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

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

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

Например, это произойдет, когда приложение настроено для целевой платформы .Net 4 Client Profile, а проект, на который оно ссылается, нацелен на полную платформу .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, а затем вы ссылаетесь на эти старые проекты из новый проект)

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

Update-Package –reinstall

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

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

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

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

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

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

Сделать это:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Бум Шанкар.

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

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

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

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

Я столкнулся с этой проблемой при обновлении существующих проектов с VS2008 до VS2012. Я обнаружил, что два проекта (единственные два, которые я создал) были нацелены на разные .Net Framework (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 через блокнот и удалил повторяющиеся записи. В моем случае сработало.

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

Это даже происходит в Visual Studio 2017.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хорошо, спустя годы, используя VS 2017 .NET Core 2.2 Razor Pages, я чувствую, что этот ответ может кому-то помочь. Если бы это была змея, она бы меня укусила. Я перебрасывал вещи, менял имена, переименовывал модели, и вдруг я получил эту ошибку:

Ошибка CS0246 Не удалось найти тип или имя пространства имен «UploadFileModel» (вам не хватает директивы using или ссылки на сборку?)

Это было подчеркнуто красным на моей странице .chstml Razor. (после исправления не подчеркивается):

@page
@model UploadFileModel

Итак, наконец, и, к счастью, я нашел код от кого-то еще, который я изначально использовал, и вот, пространство имен не включает имя файла .cshtml !!!

Вот моя плохая фиктивная ошибка, отшлепанная именем страницы в пространстве имен:

namespace OESAC.Pages.UploadFile
{
    public class UploadFileModel : PageModel
    {

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

namespace OESAC.Pages
{
    public class UploadFileModel : PageModel
    {

И низко и вот, все ошибки исчезли !! Я такой глупый. Но вы знаете, MS сделала этот материал .NET C # MVC по-настоящему запутанным для нас, не компьютерных ученых. Я постоянно спотыкаюсь о шнурки, пытаясь выяснить названия моделей, названия страниц и синтаксис для их использования. Это не должно быть так сложно. Ну что ж. Надеюсь, ошибка и решение кому-то помогут. Ошибка была правильной, нет пространства имен с именем "UploadFileModel", ха-ха.

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

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

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

Я думаю, что проблема в инструментах Visual Studio, тем более, что я только что обновил их.

Была такая же проблема после слияния нового кода с проектом vs2019. Перезапускает VS, выгружает и перезагружает проекты, чтобы убедиться, что все проекты в решении имеют одинаковые ToolsVersion= и TargetFrameworkVersion. Ничего из этого не помогло.

У меня был случай проекта Substrate, когда не удалось найти скин пространства имен (в скин проекта).

Наконец, я открыл Substrate.csproj и проверил все ProjectReference Include записи. Остальные присутствовали, но не было ссылки на скин, хотя скин действительно отображался в поле флажка в небольшом диалоговом окне зависимостей проекта. Таким образом, диалоговое окно зависимостей проекта установило флажок для Skin (и сохранило его где-то), но не изменило Substrate.csproj. Затем я добавил ProjectReference Include вручную, убедившись, что у меня есть правильный путь и GUID для проекта скина.

<ProjectReference Include="..\Skin\Skin.csproj">
  <Project>{1ad4b5d7-5014-4f5f-983e-2c59ac0e0028}</Project>
  <Name>Skin</Name>
</ProjectReference>

Затем я сохранил Substrate.csproj, и проблема была решена. Как говорили другие, это проблема с инструментами VS

Проверьте действие сборки для .cs файла, содержащего отсутствующий тип. Убедитесь, что это компилятор C #.

1. Щелкните файл .cs, содержащий отсутствующий тип.
2. Нажмите F4, чтобы открыть Свойства.
3. Убедитесь, что для параметра Действие сборки установлено значение Компилятор C #.

До:

После:

В моем случае у меня был файл, созданный внешней зависимостью (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 и щелкнуть один из желтых восклицательных знаков.

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

Эта проблема возникла после перехода с VS 2019 Enterprise на VS 2019 Professional. Хотя ошибка отображалась в окне ошибок, я мог без проблем построить проект. Пробовал много решений из этого потока и других, таких как выравнивание целевых фреймворков, удаление и повторная ссылка, удаление файла .suo и т. Д. Что сработало для меня, так это просто удаление проекта в моем локальном репозитории и его повторное клонирование из удаленного репозитория.

Боролся с этим некоторое время, и не в первый раз. Раньше это обычно было несоответствие конфигурации, но на этот раз это не так.

На этот раз оказалось, что в моем приложении для параметра Auto-Generate Binding Redirects установлено значение true.

В самом деле, если я установлю true в моей библиотеке, тогда моя библиотека получит эту ошибку для типов в пространстве имен Microsoft.Reporting, а если я установлю true в моем приложении, то мое приложение получит эту ошибку для типов из моей библиотеки.

Вдобавок кажется, что значение по умолчанию false для моей библиотеки, но true для моего приложения. Поэтому, если я не укажу ни один из них, моя библиотека будет построена нормально, но мое приложение получит ошибку для моей библиотеки. Итак, я должен специально установить его на false в моем приложении, иначе я получу эту ошибку без указания причины.

Я также обнаружил, что я получу это сообщение независимо от настройки, если проект не использует sdk csproj. Как только я конвертирую в sdk csproj, настройка имеет значение.

Кроме того, в моем случае все это, похоже, связано с пакетом Microsoft.ReportingServices.ReportViewerControl.Winforms nuget, который находится в моей корневой библиотеке.

Я получил эту ошибку при использовании системы; после добавления нового проекта библиотеки в мое решение VS2019. Добавление пакета Newtonsoft.Json (текущая версия) в проект библиотеки устранило проблему, поскольку зависимости для Newtonsoft.Json включали NETStandard.Library в разделе «Зависимости» для библиотеки и отображали значок предупреждения. В основном проекте была ошибка, пока я не установил Newtonsoft.Json, поэтому я предположил, что он будет работать и для библиотеки; и это произошло.

В моем случае я выгружаю проект, затем:

1. Открыл myProject.csproj и обновил ToolsVersion="4.0" до ToolsVersion="12.0" (я использую vs 2017) (используя ответ Паулюса https://stackoverflow.com/a/64552201/1594487).

2. Из myProject.csproj удалены следующие строки:

   <Import Project="..\packages\EntityFramework.6.4.0\build\EntityFramework.props" Condition="Exists('..\packages\EntityFramework.6.4.0\build\EntityFramework.props')" />
   <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
   

И проблема решена.

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

Удалите сборку из GAC (папка C: \ WINDOWS \ assembly - выберите сборку, щелкните правой кнопкой мыши и удалите). потому что решение сохраняет ссылку с использованием guid, и если этот guid находится в GAC, оно будет продолжать использовать версию GAC для компиляции.