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

Использование VS2012, работающего над приложением VB.NET WPF. У меня есть простое учебное приложение MusicPlayer, которое я использую для изучения WPF. Я преобразовываю С# версию учебника в 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".

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Ответ 2

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

например: -

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

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

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

Ответ 8

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

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

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

Ответ 9

У меня была та же проблема, и в моем случае 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.

Ответ 10

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

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

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

Ответ 11

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

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

Ответ 12

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

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

Ответ 13

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

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

Ответ 14

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

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

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

Ответ 15

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

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

Ответ 16

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

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

Ответ 17

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

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

Ответ 18

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

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

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

Ответ 19

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

Ответ 20

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

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

Ответ 21

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

Ответ 22

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

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

Ответ 23

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

Ответ 24

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

Ответ 25

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

firstDepth.secondDepth.Fubar

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

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

firstDepth.secondDepth

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

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

Ответ 26

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

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

Ответ 27

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

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

Ответ 28

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

Ответ 29

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

Ответ 30

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