Я получаю:
имя типа или пространства имен не найдено
ошибка для приложения C # WPF в VS2010. Эта область кода компилировалась нормально, но внезапно я получаю эту ошибку. Я попытался удалить using
ссылку на проект и утверждение, закрыть VS2010 и перезапустить, но все же у меня есть эта проблема.
Любые идеи, почему это может происходить, когда кажется, что я делаю правильные вещи, ссылки и using
заявления?
Я также отметил в VS2010, что intellisense для этого пространства имен работает нормально, поэтому кажется, что VS2010 имеет ссылку на проект и видит пространство имен с одной стороны, но во время компиляции его не видит?
Ответы:
Это может быть результатом несовместимости версии .Net Framework между двумя проектами.
Это может произойти двумя способами:
Например, это произойдет, когда приложение настроено на целевую платформу .Net 4 Client Profile, а проект, на который оно ссылается, нацелено на полную платформу .Net 4.
Итак, чтобы прояснить это:
Решение в этом случае состоит в том, чтобы либо обновить целевой объект приложения (проект 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
меня было несколько ошибок во всем решении, включая другую версию этого пакета. Я обновил во всем, то это, наконец, запустить. Также исправлены ссылки в файлах package.json с 45 на 452, поскольку я также изменил целевую версию назад.Я понятия не имею, почему это сработало, но я удалил ссылку на проект, который VS2015 сообщал мне, что не может найти, и добавил его снова. Решил проблему. Я пытался очистить, построить и перезапустить VS безрезультатно.
источник
При создании решения я получал ту же ошибку (не удалось найти тип или пространство имен ''). Ниже я увидел предупреждение о том, что «ссылка не может быть разрешена» и что «сборка существует на диске».
Я был очень смущен, потому что моя DLL была очень четко в том месте, на которое ссылалась ссылка. VS, казалось, не выдвигал на первый план никаких ошибок, пока я не попытался построить решение.
Я наконец понял проблему (или по крайней мере то, что я подозреваю, была проблема). Я строил файл библиотеки в том же решении. Таким образом, несмотря на то, что он существовал на диске, он перестраивался в этом месте (каким-то образом в процессе перестройки библиотеки мой другой проект - в том же решении - который ссылался на библиотеку, должен был решить, что библиотека не существует)
Когда я щелкнул правой кнопкой мыши по проекту и построил его только вместо всего решения, я не получил ошибку.
Чтобы решить эту проблему, я добавил библиотеку в качестве зависимости к проекту, который ее использовал.
Сделать это:
Это гарантирует, что проект библиотеки будет построен первым.
источник
Сначала я хотел бы убедиться, что информация, сгенерированная вашим проектом, не повреждена. Сделайте чистку и восстановите свое решение.
Если это не помогает, одна вещь, которую я видел в прошлом для дизайнерских проблем, - это открытие проекта оконных форм, а затем закрытие его снова. Это маленькая курица, так что не задерживай дыхание.
источник
Ситуация, с которой я столкнулся, была более сложной: первый проект нацелен на полный фреймворк 4.0 с
Microsoft.Bcl.Async
установленным пакетом. Второй проект предназначен для полной версии 4.0, но не будет компилироваться при ссылке на один класс проекта.После того, как я установил пакет Async NuGet на второй проект, он скомпилировался нормально.
источник
В моем случае, я считаю, что ссылка в VisualStudio имеет треугольник и восклицательный знак, как это изображение,
затем, я щелкаю правой кнопкой мыши, удаляю его и снова добавляю ссылку на dll, проблема была решена.
источник
Этот работал для меня. В вашем классе, где определено имя класса, например: Открытый класс ABC, удалите один символ и немного подождите. Ваш список ошибок увеличится, потому что вы изменили имя. Теперь верните символ, который вы ввели. Это сработало для меня, надеюсь, это сработает и для вас. Удачи!!!
источник
У меня была похожая проблема: компилятору не удалось обнаружить папку внутри того же проекта , поэтому директива using, ссылающаяся на эту папку, вызвала ошибку. В моем случае проблема возникла из-за переименования папки . Несмотря на то, что я обновил пространство имен всех классов в этой папке, информация о проекте почему-то не удалось обновить. Я перепробовал все: удаление файла .suo и папок bin и obj, очистка решения, перезагрузка проекта - ничего не помогло. Я решил проблему, удалив папку и классы внутри нее, создав новую папку и создав новые классы в этой новой папке (простое перемещение классов внутри новой папки не помогло).
PS: в моем случае я работал над веб-приложением, но эта проблема может возникать в разных типах проектов.
источник
[Facepalm] Моя проблема заключалась в том, что я добавил зависимость в C ++ в способе ведения дел.
Перейдите к проекту, который не будет создан, откройте папку «Ссылки» в обозревателе решений и посмотрите, есть ли ваша зависимость в списке.
Если нет, вы можете «Добавить ссылку» и выбрать зависимость на вкладке «Проекты».
Бум Шанкар.
источник
У нас был странный случай, который я только что исправил в решении. Перед оператором «использование» в основном проекте был скрытый / пробельный символ. Этот проект будет хорошо работать, и веб-сайт будет работать нормально, но проект модульного тестирования, который ссылается на него, не может быть построен.
источник
Я столкнулся с этой проблемой при обновлении существующих проектов с VS2008 до VS2012. Я обнаружил, что два проекта (только два, которые я создал) были нацелены на разные .Net Frameworks (3.5 и 4.0). Я решил эту проблему на вкладке «Приложение» проектов, убедившись, что в обоих проектах был «.NET Framework 4» в поле «Целевая платформа».
источник
Если были те же ошибки, моя история была следующей: после неудачного слияния (через git) один из моих файлов .csproj имел дублированные
compile
записи, такие как:Если у вас есть большое решение и более 300 сообщений в окне ошибок, трудно обнаружить эту проблему. Итак, я открыл поврежденный файл .csproj через блокнот и удалил дублированные записи. Работал в моем случае.
источник
У меня была та же проблема, что и обсуждалась: VS 2017 подчеркивает класс в ссылочном проекте как ошибку, но решение работает нормально, и даже intellisense работает.
Вот как мне удалось решить эту проблему:
источник
Вы также можете попробовать устранение код , который вы думаете , у вас возникли проблемы с и увидеть , если она компилируется без каких - либо ссылок на этот код. Если нет, исправляйте ошибки до тех пор, пока он не скомпилируется снова, а затем верните ваш подозрительный код проблемы. Иногда я получаю странные ошибки о классах или методах, которые, как я знаю, являются правильными, когда компилятору не нравится что-то еще. Как только я исправляю то, от чего на самом деле зацикливаются, эти «фантомные» ошибки исчезают.
источник
Я знаю, что это пинает мертвую лошадь, но у меня была эта ошибка и рамки, где хорошо. Моя проблема в основном заключалась в том, что интерфейс не может быть найден, но все же он хорошо собран. Поэтому я подумал: «Почему именно этот интерфейс, когда другие работают нормально?»
В итоге я получил доступ к сервису, используя WCF с интерфейсом конечной точки, который использовал Entity Version 6, а остальные проекты использовали версию 5. Вместо NuGet я просто скопировал пакеты nuget в локальный репозиторий для повторного использования и перечислил их по-разному.
например, EntityFramework6.dll против EntityFramework.dll .
Затем я добавил ссылки на клиентский проект и poof, моя ошибка ушла. Я понимаю, что это крайний случай, так как большинство людей не будут смешивать версии Entity Framework.
источник
Добавление моего решения в микс, потому что оно было немного другим, и мне понадобилось время, чтобы разобраться.
В моем случае я добавил новый класс в один проект, но поскольку мои привязки управления версиями не были установлены, мне нужно было сделать файл доступным для записи вне Visual Studio (через VC). Я отменил сохранение в Visual Studio, но после того, как я сделал файл доступным для записи вне VS, я снова нажал Save All в VS. Это непреднамеренно привело к тому, что новый файл класса не был сохранен в проекте .. однако ... Intellisense по-прежнему показывал его синим и действительным в ссылочных проектах, даже когда я пытался перекомпилировать файл, он не был найден и получил ошибка типа не найдена. Закрытие и открытие Visual Studio все еще показывали проблему (но если бы я обратил внимание, что файл класса отсутствовал при повторном открытии).
Как только я понял это, исправление стало простым: с файлом проекта, доступным для записи, зачитал отсутствующий файл в проект. Теперь все хорошо.
источник
Я была такая же проблема. Однажды ночью мой проект скомпилирует на следующее утро ОШИБКИ !.
В конце концов я узнал, что визуальная студия решила «подправить» некоторые из моих ссылок и указать их в другом месте. например:
System.ComponentModel.ISupportInitialize каким-то образом стал "blahblah.System.ComponentModel.ISupportInitialize"
Весьма грубо для противников, если вы как я
источник
Это событие произошло в Visual Studio 2017.
источник
Мой случай был таким же, как обсуждалось здесь, но ничего не решил, пока я не удалил
System.Core
ссылку из списка ссылок (без него все работало нормально)надеюсь, что это поможет кому-то, потому что эта проблема довольно расстраивает
источник
Для решения этой проблемы также может помочь удалить и заново создать
*.sln.DotSettings
файл соответствующего решения.источник
В моем случае у меня был класс, который был указан в соответствующей исходной папке, но не регистрировался в обозревателе решений. Мне нужно было щелкнуть правой кнопкой мыши по проекту> Добавить существующий элемент и вручную выбрать тот класс, который, как он сказал, отсутствует. Тогда все работало нормально!
источник
В моем случае проблема заключалась в том, что после изменения пространства имен на точно такое же, как и в другом проекте (намеренно), имя сборки также было изменено VS, поэтому было две сборки с одинаковым именем, одна переопределяла другую.
источник
В моем случае у меня был файл, созданный с помощью внешней зависимости (xsd2code), и почему-то его файлы designer.cs не были правильно обработаны VS. Создание нового файла в Visual Studio и вставка в него кода помогли мне.
источник
Всем, кто получает эту ошибку при попытке опубликовать свой сайт в Azure, ни одно из представленных выше перспективных решений не помогло мне. Я был в одной лодке - моё решение строилось само собой. В итоге мне пришлось
Немного больно, но это был единственный способ опубликовать свой сайт в Azure.
источник
Я получил эту ошибку, пытаясь сделать сборку с помощью сборки Visual Studio Team Services, работающей на моем локальном компьютере в качестве агента.
Это нормально работало в моей обычной рабочей области, и я смог открыть файл SLN в папке агента локально, и все скомпилировано нормально.
Рассматриваемая DLL была сохранена в проекте как
Lib/MyDLL.DLL
и ссылки на это в файле csproj:Оказалось, что буквально просто не нашел файл, несмотря на путь подсказки. Я думаю, что, возможно, 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
раздел и нажать на один из желтых восклицательных знаков.Через несколько секунд ошибки разметки исчезли.
источник