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

Использование 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.

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

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

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

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

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

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

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

например: -

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

Я видел, как эта проблема решается путем очистки теневого кэша дизайна 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. Восстановите решение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В моем случае решение имело два проекта, один из которых содержал модели (скажем, имя проекта и сборки было 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» . После этого я смог нормально скомпилировать.

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

firstDepth.secondDepth.Fubar

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

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

firstDepth.secondDepth

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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