Подтвердить что ты не робот

Тега не существует в пространстве имен XML

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

Я получаю сообщение об ошибке для ресурсного словаря, который я делаю (и позже слияния), что тег 'ModelBindings' не существует в пространстве имен XML 'clr-namespace: Company.Project.Module.Folder; assembly = Company.Project.module

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

Вот несколько бит кода для словаря ресурсов

Список пространства имен

xmlns:modulemodel="clr-namespace:Company.Project.Module.Folder;assembly=Company.Project.Module"

Создание ресурса для ссылки

<modulemodel:ModelBindings x:Key="ModuleModelBindings"/>

Как и ошибки других людей, intellisense говорит о своей кошерности. Кроме того, список xmlns был создан с помощью autocomplete intellisense и переименован вручную. Ничего не работало.

Я также попытался переместить все в app.xaml, и он все равно дал мне ту же ошибку.

Если я удаляю тело файла ResourceDictionary, код компилируется отлично, но все привязки разбиты.

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

Изменить: Вот лучшее, что я могу сделать с точки зрения отображения словаря ресурсов, который я использую

<SharedResourceDictionary
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:modulemodel="clr-namespace:Company.Project.Module.Folder;assembly=Company.Project.Module"
                    >
    <modulemodel:ModelBindings x:Key="ModuleModelBindings"/>

</SharedResourceDictionary>

Если я заменил SharedResourceDictionary на ResourceDictionary, произойдет такая же ошибка.

app.xaml и приведенный выше SharedResourceDictionary сравниваются в пространстве имен Company.Project.Main и содержат ссылки на оба варианта, где определяется SharedResourceDictionary, а также различные проекты модулей, которые я ввел в код выше

Решение

Похоже, это была ошибка пользователя. Но это может случиться с другими. Когда я скопировал определение xmlns: moduleviewmodel из его исходного файла, мне пришлось добавить сборку = часть самостоятельно. Как я уже сказал, я сделал это сам, а также использовал автозаполнение, следуя из набора "xmlns: moduleviewmodel =". Прямо перед тем, как мы обнаружили ошибку, мы снова попробовали автозаполнение, потому что обнаружили, что существует одно из 7 пространств имен, не генерирующих ошибку. Именно тогда я заметил, что есть письмо на пути сборки, которое не было заглавным, что должно быть. Самое странное, что автозаполнение фактически вставляет эту ошибку самостоятельно. Пока мы компилировали, что я заметил ошибочное письмо. Более странная вещь заключается в том, что после того, как я исправил все пути вручную, мы снова попробовали автозаполнение, и это правильно написало.

Я не знаю причины ошибочного автозаполнения, но с фиксированной буквой, которую он компилирует просто отлично.

Теперь мне просто интересно, будет ли кто-нибудь верить, что автозаполнение менялось на меня!

4b9b3361

Ответ 1

Похоже, это была ошибка пользователя. Но это может случиться с другими. Когда я скопировал определение xmlns:moduleviewmodel из его исходного файла, мне пришлось добавить сборку = часть самостоятельно. Как я уже сказал, я сделал это сам, а также использовал автозаполнение, следуя из набора "xmlns: moduleviewmodel =". Прямо перед тем, как мы обнаружили ошибку, мы снова попробовали автозаполнение, потому что обнаружили, что существует одно из 7 пространств имен, не генерирующих ошибку. Именно тогда я заметил, что есть письмо на пути сборки, которое не было заглавным, что должно быть. Самое странное, что автозаполнение фактически вставляет эту ошибку самостоятельно. Пока мы компилировали, что я заметил ошибочное письмо. Более странная вещь заключается в том, что после того, как я исправил все пути вручную, мы снова попробовали автозаполнение, и это правильно написало.

Я не знаю причины ошибочного автозаполнения, но с фиксированной буквой, которую он компилирует просто отлично.

Теперь мне просто интересно, будет ли кто-нибудь верить, что автозаполнение менялось на меня!

Ответ 2

В соответствии с этой статьей вы просто выполните следующие действия:

С

XMLNS: ZZZ = "CLR-имен: YYY; сборка = YYY"

TO:

XMLNS: ZZZ = "CLR-имен: YYY; сборка ="

оставить пустое значение для сборки =

Это решение, которое работает для меня.

Ответ 3

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

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

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

Ответ 4

Проверьте предупреждения в списке ошибок, в моем случае там, где есть сообщения о неразрешенных ссылках .Net 4.5.1, в то время как моя целевая структура проекта была 4.5

Ответ 5

У меня была совершенно другая причина этой ошибки:

Я пытался использовать класс из сборки A, поэтому я

1) добавила ссылку на эту сборку на мой проект,

2) добавлена ​​ссылка на сборку B, которая используется сборкой A, в мой проект,

3), добавленный в мой XAML

 xmlns:assemblyA="clr-namespace:A;assembly=A"

3), добавленный в мой код

using A;

Это не сработало, у меня эта ошибка "Тег не существует".

Что помогло, добавляли

using B;

в моем коде, хотя я ничего не использую непосредственно из сборки B.

Ответ 6

Если у вас есть пользовательский контроль в той же сборке, что и форма WPF, убедитесь, что вы избавились от сборной части при импорте пространства имен

Неверный импорт: xmlns: usercontrol = "clr-namespace: CCFARKS.UserControls; сборка = CCFARKS"

Corret: xmlns: usercontrol = "clr-namespace: CCFARKS.UserControls"