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




подключить что (25)

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

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

Я получаю:

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

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

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

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


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

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

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

Бум Шанкар.


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

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


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

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

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

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


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

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

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


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

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

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


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


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

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

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

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


Я получил эту ошибку, пытаясь сделать сборку с помощью сборки 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 Could not resolve this reference. Could not locate the assembly затем убедитесь, что DLL находится в доступном месте для msbuild.

Я как-то обманул и нашел сообщение, в котором говорилось Considered "Reference\bin\xxx.dll" и просто скопировал туда Considered "Reference\bin\xxx.dll" .


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


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

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

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


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


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

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


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

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


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

Update-Package –reinstall

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

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


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


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

Хочешь эту помощь :)


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


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

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

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

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

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

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

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


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


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


Пожалуйста, закройте все вкладки в VS, если они открыты.

Затем нажмите «Создать» -> «Чистое решение».

следующий щелчок build-> rebuild solution

Теперь откройте файл xaml.

Надеюсь, что это сработает





c# visual-studio-2010 namespaces reference directive