Имя не существует в ошибке пространства имен в XAML


126

Использование VS2012 для работы с приложением VB.NET WPF. У меня есть простое учебное приложение MusicPlayer, которое я использую для изучения WPF. Я постепенно конвертирую версию учебника C # в VB.NET.

В приложении есть 2 класса, которые находятся в одном пространстве имен. Я могу ссылаться на пространство имен в XAML, но когда я пытаюсь ссылаться на объект класса в XAML, я получаю сообщение об ошибке и не могу скомпилировать.

Странно то, что IntelliSense отлично работает как со ссылкой на пространство имен через тег xmlns: c =, так и при вводе объекта класса с помощью <c: Но объект подчеркнут, и при попытке построить или работать в конструкторе возникают ошибки.

Файлы классов .vb находятся в папке \ Controls. Основное корневое пространство имен проекта намеренно оставлено пустым. Класс кодируется так ...

Namespace MusicPlayer.Controls
    Public Class UpdatingMediaElement
       .... code here
    End Public
End Namespace

Xaml выглядит так

(пространство имен определено в <Window >теге

xmlns:c="clr-namespace:MusicPlayer.Controls"

(объект, определенный в а <Grid>)

  <c:UpdatingMediaElement Name="MyMediaElement" />

(отображается ошибка) Имя UpdatingMediaElement не существует в пространстве имен clr-namespace: MusicPlayer.Controls.

Не знаете, что не так или как это исправить?


13
У меня сработал перезапуск визуала. (никогда не недооценивайте силу перезапуска)
Фалак

1
Небольшая помощь для тех, кто борется с этим: убедитесь, что ваш класс является общедоступным.
Borzh

Ответы:


234

Когда вы пишете код wpf, и VS сообщает, что «Имя ABCDE не существует в пространстве имен clr-namespace: ABC». Но вы можете полностью успешно построить свой проект, есть лишь небольшое неудобство, потому что вы не видите дизайн пользовательского интерфейса (или просто хотите очистить код).

Попробуйте сделать это:

  • В VS щелкните правой кнопкой мыши свое решение -> Свойства -> Свойства конфигурации

  • Откроется новый диалог, попробуйте изменить конфигурацию проекта с Debug на Release или наоборот.

После этого перестройте свое решение. Это может решить вашу проблему.


4
Это все еще происходит в Visual Studio 2015 Update 1. Ваше решение сработало - спасибо!
Саймон Смит

4
Возможно, нет, но я обнаружил, что простое переключение между режимами Debug и Release на панели инструментов работает независимо.
ketura 03

35
Подтверждено в VS 2017 версии 15.2 (26430.15) в июле 2017 года. Просто изменилось в раскрывающемся списке с Debug на Release, скомпилировано, и ошибка исчезла, изменилась обратно и скомпилирована, и ошибка все еще исчезла.
Тедд Хансен

7
Кажется, что VS17 особенно упрям ​​- пытался изменить Rel / Dbg, изменить x64 / x86, удалить папки ShadowCache, ComponentCache, Bin / Obj, все еще есть "ошибки", и дизайнер не работает для этого очень маленького приложения (другие приложения с вроде 50 просмотров WPF работают нормально). Произошло внезапно и не может уйти. Была эта проблема раньше много раз, но впервые на VS17 и не могу ее исправить сейчас. Тем не менее, это лучший ответ, поскольку он работал много раз раньше.
bokibeg

7
Мне нравится, как я возвращаюсь к этому ответу, и я уже проголосовал за него ... 2,5 года назад.
Матье Гиндон,

51

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

например: -

xmlns:Local="clr-namespace:MusicPlayer.Controls;assembly=MusicPlayer"

1
Хотя поначалу казалось, что моя проблема решена, по-прежнему возникает та же ошибка. Однако сейчас я даже больше не могу строить решение.
Bouke

6
@bouke Очистите раствор и восстановите его
Васант Шрирам

Отлично, спасибо. Это действительно помогло
Кейт

Это сделало это для меня. Странно то, что конвертеры находились в той же сборке, что и файл xaml ... Но они находились в другом пространстве имен.
Джонатан Альфаро

Спасибо, сборка отсутствовала.
Teroneko

31

Я видел, как эта проблема решается путем очистки теневого кэша дизайна Xaml. У меня возникла проблема с обновлением 1 для Visual Studio 2015.

В Visual Studio 2015 кэш находится здесь:

%localappdata%\Microsoft\VisualStudio\14.0\Designer\ShadowCache

Обработать:

  1. Щелкните правой кнопкой мыши решение в обозревателе решений и выберите «Чистое решение».
  2. Завершение работы Visual Studio
  3. Удалите папку ShadowCache
  4. Повторно открыл проект Visual Studio
  5. Восстановите решение

И вуаля, больше никаких ошибок пространства имен.


7
К сожалению, для меня это ничего не изменило. По-прежнему занимаюсь этим раздражающим почти через год. : /
Khale_Kitha

3
Спасибо! Это сработало для меня. Печально видеть, что эти уловки все еще необходимы в VS15
Ocab19

4
Вы можете использовать% localappdata% \ Microsoft \ VisualStudio \ 14.0 \ Designer \, чтобы сразу перейти в нужную папку
Maxence,

1
Ужасно иметь дизайнера, который работает только в том случае, если вы создаете решение. Представьте, что вы говорите дизайнеру автомобилей, чтобы он построил машину целиком, прежде чем увидеть ее дизайн.
Пол Маккарти

26

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

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


2
Обратите внимание, что сборка / компиляция решила эту проблему для меня, хотя у меня не было других несвязанных ошибок компиляции. Похоже, окна XAML не всегда знают о новых классах, пока вы не выполните компиляцию.
HK1,

1
Это был лучший совет для меня, но поскольку @ HK1 иногда нет других записей в списке ошибок компилятора ... ошибок в списке нет, но есть другие ошибки. Чтобы увидеть их, закомментируйте или удалите строки, отмеченные ошибкой пространства имен, скомпилируйте снова, и тогда вы увидите другие ошибки компилятора. Измените их, и строки, ранее отмеченные ошибкой пространства имен, будут исправны, когда вы их восстановите.
SERWare

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

23

Попробуйте изменить целевую платформу сборки на x86 и собрать проект.

Я заметил через Subversion, что я, по-видимому, изменил цель платформы сборки проекта на x64. Это было единственное изменение, которое я сделал. После внесения этого изменения код некоторое время работал, прежде чем начал показывать ту же ошибку, что и вы. Я изменил целевую платформу на x86 для тестирования, и внезапно мой дизайнер снова начал работать. Впоследствии я снова поменял его на x64, и проблема полностью исчезла. Я подозреваю, что дизайнер создает какой-то кешированный код в x32, и изменение платформы сборки x64 ломает его, когда вы вносите изменения в код.


У меня это повторялось, и я могу подтвердить, что это решает проблему для меня. Вы можете вернуться к x64 после сборки на x86.
teynon

Это сработало и для меня в VS 2012 ... после нескольких часов попыток понять что-то логичное. Спасибо, Том!
Брайан Гринуэй

Переход на x86 и обратно на x64 устранил здесь проблему, поэтому спасибо за то, что вдохновил меня попробовать это. Я даже закрыл VS, удалил bin и obj и перестроил вместе с другими предложениями, и до этого ничего не помогало.
Grault

Да, это также сработало для меня с обновлением VS2015 Update 2. Однако мне было необходимо перезагрузить мои внешние файлы dll и также восстановить их.
SezMe

С VS2015U2 у меня все еще возникает эта проблема в x64. Отлично работает на любом процессоре. Переключение вперед и назад у меня не работает.
DaleyKD

7

Не знаю, поможет ли это кому-то еще

Я новичок в WPF и все еще новичок в VB.net - поэтому я предполагал, что эта ошибка была вызвана тем, что я делал саммит глупо ........ предположим, что я действительно был! Мне удалось избавиться от этого, переместив мой проект с общего диска на один из моих локальных дисков. Ошибка исчезла, проект компилируется отлично, проблем нет - пока. Похоже, у VS2015 все еще есть проблемы с проектами, хранящимися на общем диске.


2
Так и было у меня, переместил на свой vm (на котором разрабатываю) и бум проблем нет. Спасибо!
Марио Таке

Похоже, так было и со мной. Перемещение их на локальный диск (вместо общего сетевого ресурса - как настроено Parallels для небольшого объединения файловой системы Mac и Windows), устраняет проблему.
ckittel

7

Возможно, другое решение, когда проект компилируется, но отображается ошибка XAML:

  1. В исследовании решения на узле проекта, содержащем xaml
  2. Щелкните проект правой кнопкой мыши и выберите «Выгрузить проект».
  3. Щелкните проект правой кнопкой мыши и выберите «Перезагрузить проект». Убедитесь, что ваш проект по-прежнему выбран как «запускаемый проект». Если не :
  4. Щелкните проект правой кнопкой мыши и выберите «Установить как запускаемый проект».

Не нужно перестраивать или закрывать визуальную студию.


6

Господи ... Спустя пять лет в Visual Studio 2017 это все еще проблема. Так как я новичок в WPF, я был уверен, что проблема была каким-то образом во мне, но нет, все скомпилировано и работает правильно.

Я пробовал перестроить, очистить и перестроить, переключиться между выходом x86 / x64, перезагрузить Windows, очистить папку ShadowCache, добавить "; assembly = {my main assembly name}" в объявление пространства имен XML, ничего не сработало! Единственное, что сделал:

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


2

У меня была та же проблема, и в моем случае представление дизайна разметки попросило меня перестроить решение и не показало мне макет формы с этим сообщением:, Design view is unavailable for x64 and ARM target platformsили Build the Project to update Design view.

Это не решается путем перестройки решения (ни представление дизайна, ни ошибка «Имя не существует в пространстве имен»)

Я думаю, это потому, что я играл с настройками в Solution -> Properties> Configuration Properties.

Наконец-то я решил проблему с двумя заданиями:

  1. Установите все флажки в столбце сборки на странице: Решение -> Свойства -> Свойства конфигурации
  2. Изменение конфигурации решения с Debug на Release или наоборот.

Я думаю, что это ошибка в Visual Studio2012 Update 2.


2

Та же проблема характерна для Visual Studios 2013, Service Pack 4. Я также попробовал это с Visual Studios 2015 Preview с теми же результатами.

Это просто ограничение визуализатора WPF, которое команда Visual Studios не исправила. В качестве доказательства, сборка в режиме x86 включает визуализатор, а сборка в режиме x64 отключает его.

Как ни странно, intellisense работает для Visual Studios 2013, Service Pack 4.


2

Недавно у меня возникла эта проблема с использованием VS 2015 Update 3 для моего проекта WPF в .NET 4.6.2. Копия моего проекта была в сетевой папке , я переместил ее локально, и проблема была решена.

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


1

Похоже, эту проблему можно решить с помощью множества «уловок».

В моем случае я собирал / перестраивал / очищал все решение, а не только проект, над которым я работал в рамках решения. Как только я щелкнул «Создать [мой проект]», сообщение об ошибке исчезло.


1

Попробуйте проверить ссылки на сборки. Если у вас есть желтый восклицательный знак на ссылках на проекты, значит, это проблема, и вы получите всевозможные ошибки.

Если вы знаете, что ссылка на проект верна, проверьте Target framework. Например, наличие проекта, использующего фреймворк 4.5, ссылающегося на проект с фреймворком 4.5.2, не является хорошей комбинацией.


Другими словами, версия .NET Framework проекта не может быть старше, чем версия .NET Framework указанного проекта.
icernos 03

1

Решением для меня было разблокировать сборочные DLL. Сообщения об ошибках, которые вы получаете, не указывают на это, но конструктор XAML отказывается загружать то, что он называет «изолированными» сборками. Вы можете увидеть это в окне вывода при сборке. Библиотеки DLL блокируются, если они загружаются из Интернета. Чтобы разблокировать библиотеки DLL сторонней сборки:

  1. Щелкните правой кнопкой мыши файл DLL в проводнике Windows и выберите «Свойства».
  2. Внизу вкладки «Общие» нажмите кнопку или флажок «Разблокировать».

Примечание. Разблокируйте библиотеки DLL, только если вы уверены, что они безопасны.


У меня это сработало - я загрузил проект из Dropbox и получал ошибку. Мне также пришлось удалить ShadowCache
geometrikal

1

В моем случае пользовательский элемент управления был добавлен в основной проект. Я пробовал различные решения выше, но безрезультатно. Либо я получу Invalid Markup, но решение будет скомпилировано и работать, либо я добавлю xmlns: c = "clr-namespace: MyProject; assembly = MyProject", и тогда разметка будет отображаться, но я получу ошибку компиляции, которая тег не существует в пространстве имен XML.

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


1

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

В моем случае решение имело два проекта, один из которых содержал модели (скажем, имя проекта и сборки было Models ), а другой содержал представления и модели представления (согласно нашему соглашению: проект, имя сборки и пространство имен по умолчанию были Models.Monitor ) , The Models.Monitor упомянул проект Models.

В проекте Models.Monitor в один из xaml я включил следующее пространство имен: xmlns: monitor = "clr-namespace: Models.Monitor"

Я подозреваю, что MsBuild и Visual Studio тогда вызвали ошибку, поскольку они пытались найти тип «Монитор» в сборке «Модели» . Чтобы решить эту проблему, я попробовал следующее:

  1. xmlns: monitor = "clr-namespace: Models.Monitor; assembly =" - что допустимо, если пространство имен находится в той же сборке согласно https://msdn.microsoft.com/en-us/library/ms747086(v=vs 0,110) .aspx
  2. также попробовал явное объявление пространства имен: xmlns: monitor = "clr-namespace: Models.Monitor; assembly = Models.Monitor"

Ничего из вышеперечисленного не помогло.

В конце концов я сдался и по мере работы переместил UserControl, который я пытался использовать, в другое пространство имен: «ModelsMonitor» . После этого я смог нормально скомпилировать.


1

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

firstDepth.secondDepth.Fubar

который содержит свои собственные классы (например, firstDepth.secondDepth.Fubar.someclass)

но у меня также был класс Fubar в пространстве имен

firstDepth.secondDepth

который текстуально разрешается в то же самое, что и пространство имен Fubar выше.

Не делай этого


1

В моем случае проблема была связана с некоторыми фантомными файлами в каталоге obj проекта. Следующее исправило проблему для меня:

  • Чистый проект
  • Выход VS
  • rm -rf / obj / *
  • Вызов VS и перестройка

1

У меня тоже много проблем с этим! Intellisense помогает мне заполнить пространство имен и все остальное, но компилятор плачет. Я перепробовал все, что нашел в этой и других темах. Однако в моем случае в конечном итоге помогло написать что-то вроде этого:

xmlns:util="clr-namespace:LiveSpielTool.Utils;assembly="

Оставить имя сборки пустым. Понятия не имею почему. Но здесь об этом упоминалось. Я должен добавить, что разрабатываю сборку, поэтому атрибут сборки может иметь смысл. Но ввести название сборки не получилось. Так странно.


0

VB.NET не добавляет автоматически информацию о пространстве имен на основе структуры папок, как это делается в C #. Думаю, я прохожу то же самое учебное пособие, что и вы («Выучите себя WPF за 24 часа»), и делаю такое же преобразование в VB.

Я обнаружил , что вам нужно вручную добавить информацию о пространстве имен для обоих в XAML класса и XAML.VB код позади , чтобы иметь возможность использовать Namespaces , как описано в книге. Даже в этом случае VB не назначает пространство имен сборке автоматически, как это делается в VB.

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


0

На странице свойств решения проверьте платформу сборки, которая содержит «UpdatingMediaElement», и сборки, которые содержат какие-либо суперклассы и интерфейсы, из которых подклассы или реализует «UpdatingMediaElement». Похоже, что платформа всех этих сборок должна быть «AnyCPU».


0

Другая возможная причина: событие после сборки - это удаление библиотеки DLL проекта из папки сборки.

Чтобы уточнить: конструктор WPF может сообщить «Имя XXX не существует в пространстве имен ...», даже если имя действительно существует в пространстве имен и проект строится и работает нормально, если событие после сборки удаляет DLL проекта из папка сборки (bin \ Debug, bin \ Release и т. д.). У меня есть личный опыт работы с этим в Visual Studio 2015.


0

Хорошо, к сожалению, ни один из этих советов не помог мне. В конце концов мне удалось решить проблему. Кажется, что Visual Studio плохо работает с сетевыми дисками. Я решил эту проблему, переместив проект с общего диска на локальный и перекомпилировав. Больше никаких ошибок.


Этот ответ представлен как минимум дважды выше.
pdschuller

0

Добавляем в стопку.

У меня имя сборки приложения WPF было тем же именем сборки, что и у библиотеки, на которую указывает ссылка. Поэтому убедитесь, что ни в одном из ваших проектов нет повторяющихся имен сборок.


0

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


0

Также попробуйте щелкнуть правой кнопкой мыши свой проект-> свойства и изменить цель платформы на Любой ЦП и перестроить, тогда он будет работать. Это сработало для меня


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

0

Эта проблема также может быть вызвана, если сборка, на которую вы ссылаетесь, на самом деле не построена. Например, если ваш xaml находится в Assembly1 и вы ссылаетесь на класс также в Assembly1, но эта сборка содержит ошибки и не строится, эта ошибка будет отображаться.

Мне это кажется глупым, но в моем случае я разорвал пользовательский элемент управления и в результате получил всевозможные ошибки в связанных классах. Когда я пытался исправить их все, я начал с рассматриваемых ошибок, не понимая, что xaml полагается на построенные сборки для поиска этих ссылок (в отличие от кода C # / vb, который может решить это еще до сборки).


0

Я добавил сборку как проект - сначала удалил ddl, который был добавлен специально к ссылкам на dll - что и сделало.


0

У меня все время возникает эта проблема. Мои представления находятся в проекте библиотеки настраиваемых элементов управления WPF (вариант библиотеки классов). Я могу ссылаться на готовые сборки, но не могу ссылаться на какой-либо код в другом проекте того же решения. Как только я перенесу код в тот же проект, что и xaml, он распознан.


0

В моем случае эта проблема возникнет, если архитектура программы wpf не совсем такая же, как и у зависимостей. Предположим, у вас есть одна зависимость - x64, а другая - AnyCPU. Тогда, если вы выберете x64, тип в AnyCPU dll будет «не существует», в противном случае тип в x64 dll будет «не существует». Вы просто не можете эмитировать их обоих.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.