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

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

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

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

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

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

для этого:

1. я щелкнул Правой Кнопкой Мыши по моему решению в обозревателе решений и выбрал "Properties"
2. затем в "общие свойства" я выбрал "зависимости проекта".
3. затем в раскрывающемся меню "проекты" я выбрал проект, который полагался на библиотеку, и
4. флажок рядом с библиотекой найдено в разделе "зависит от"

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

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

Update-Package –reinstall

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

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

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

сложнее ситуации я столкнулся был: Проект one нацелен на полную платформу 4.0 с помощью установлен. Проект два нацелен на полную платформу 4.0, но не будет компилироваться при ссылке на проект одного класса.

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

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

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

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

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

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

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

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

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

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

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

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

Бум Шанкар.

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

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

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

например EntityFramework6.dll файлы и EntityFramework.dll файлы.

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

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

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

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

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

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

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

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

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

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

в моем случае у меня был файл, построенный внешней зависимостью (xsd2code) и каким-то образом его дизайнером.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 туда вместо этого.

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

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

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

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

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

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

Hop эта помощь:)

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

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