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

Question

Я получаю:

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

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

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

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

Answer 1

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

Answer 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 через блокнот и удалил дублированные записи.Работал в моем случае.

Answer 3

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

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

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

@page
@model UploadFileModel

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

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

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

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

namespace OESAC.Pages
{
    public class UploadFileModel : PageModel
    {

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

Перейдите к этой справке:)

Answer 7

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

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

Answer 8

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

Answer 9

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

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

Answer 10

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