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

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

например: -

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

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

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

Я видел, как эта проблема исчезла, очистив Xaml Design Shadow Cache. У меня была проблема с Visual Studio 2015 Update 1.

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

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

Процесс:

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

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

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

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

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

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

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

• В решении исследуйте проект node, содержащий xaml
• Щелкните правой кнопкой мыши проект и выберите "Выгрузить проект"
• Щелкните правой кнопкой мыши проект и выберите "Обновить проект", Убедитесь, что ваш проект по-прежнему выбран как "проект запуска". Если нет:
• Щелкните правой кнопкой мыши проект и выберите "Сделать как проект запуска"

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

Иисус... Это еще проблема пять лет спустя в Visual Studio 2017. Поскольку я новичок в WPF, я был уверен, что проблема была чем-то мне, но нет, все скомпилировано и работает правильно.

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

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

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

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

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

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

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

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

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

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

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

• Проверка всех флажков в столбце сборки на странице: Решение → Свойства → Свойства конфигурации
• Изменение конфигураций решений от Отладки до Отпустите или наоборот.

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

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

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

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

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

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

Ни один из вышеперечисленных не работал.

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

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

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

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

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

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

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

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

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

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

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

У меня также много проблем с этим! Intellisense помогает мне заполнить пространство имен и все остальное, но компилятор плачет. Я перепробовал все, что нашел в этой и других темах. Однако, в моем случае, что помогло в конце, это написать что-то вроде этого: xmlns: util = "clr-namespace: LiveSpielTool.Utils; assembly ="

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

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

firstDepth.secondDepth.Fubar

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

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

firstDepth.secondDepth

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

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

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

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

Добавление в кучу.

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

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

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

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

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

Чтобы уточнить: дизайнер WPF может сообщить: "Имя XXX не существует в пространстве имен...", даже если имя существует в пространстве имен, а проект строит и работает очень хорошо, если событие post-build удаляет DLL проекта из папки сборки (bin\Debug, bin\Release и т.д.). В Visual Studio 2015 у меня есть личный опыт.

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

VB.NET не автоматически добавляет информацию о пространстве имен на основе структуры папок, как это делается на С#. Я думаю, что я перехожу к тому же учебнику, что и вы (Teach Yourself WPF за 24 часа), и делает то же самое преобразование в VB.

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

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

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