it-swarm.com.ru

Имя не существует в ошибке пространства имен в 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».

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

94
Jeff Davis

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

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

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

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

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

178
Toan Darkprince

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

например: -

xmlns:Local="clr-namespace:MusicPlayer.Controls;Assembly=MusicPlayer"
47
Vasanth Sriram

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

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

23
teynon

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

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

22
Jasper H Bojsen

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

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

19
Iman Abidi

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

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

7
Supa Stix

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

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

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

5
Simon

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

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

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

3
Jonas

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

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

2
gbdavid

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

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

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

2
Trevy Burgess

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

Он не может быть решен путем перестроения решения (ни представление конструктора, ни ошибка «Имя не существует в пространстве имен»)

Я думаю, что это потому, что я играл с настройками на Решение -> Свойства> Свойства конфигурации

Я наконец решил проблему с 2 работами:

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

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

2
Ehsan Abidi

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

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

1
gusmally

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

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

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

1
Jordan

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

  • Чистый проект
  • Результат VS
  • rm -rf/obj/*
  • Вызвать VS и восстановить
1
eric gilbertson

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

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

1
Kevin Cook

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

В моем случае у решения было два проекта, один из которых содержал модели (скажем, имя проекта и сборки было Models), а другой содержал представления и модели представлений (согласно нашему соглашению: проект, имя сборки и пространство имен по умолчанию были Models.Monitor). 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.110) .aspx
  2. также пробовал явное объявление пространства имен: xmlns: monitor = "clr-namespace: Models.Monitor; Assembly = Models.Monitor"

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

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

1
Sandip

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

0
user1040323

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

firstDepth.secondDepth.Fubar

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

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

firstDepth.secondDepth

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

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

0
Sean

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

0
jgong

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

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

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

0
Jeremy

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

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

0
R.T.

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

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

0
Tommy Andersen

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

0
Corne

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

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

0
kad81

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

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

0
le_fritz

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

0
Cauly

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

0
PI Mike

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

0
Kevin S. Miller

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

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

0
Ceres

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

0
Noahm888