Ім'я не існує в помилці простору імен у XAML

Використання VS2012, що працює над програмою VB.NET WPF. У мене є просте підручник для MusicPlayer, який я використовую для вивчення WPF. Я перетворюю версію навчального посібника на C # в крок за кроком.

У додатку є 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"

(об’єкт, визначений у a <Grid>)

  <c:UpdatingMediaElement Name="MyMediaElement" />

(відображається помилка) Імені "UpdatingMediaElement" не існує в просторі імен "clr-namespace: MusicPlayer.Controls".

Не знаєте, що не так або як це виправити?

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

Спробуйте зробити це:

• У VS клацніть правою кнопкою миші на Вашому рішення -> Властивості -> Властивості конфігурації

• Відкриється нове діалогове вікно, спробуйте змінити конфігурації проекту з Налагодження на Випуск або навпаки.

Після цього переобладнайте своє рішення. Це може вирішити вашу проблему.

Якщо збірка відрізняється від простору імен, в якій міститься ваш клас, вам потрібно чітко вказати її.

колишній: -

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

Я бачив цю проблему, очистивши кешований тінь кеша Xaml. У мене виникла проблема з оновленням Visual Studio 2015 1.

У Visual Studio 2015 Кеш розташований тут:

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

Процес:

1. Клацніть правою кнопкою миші на рішенні в Провіднику рішень і виберіть "Очистити рішення"
2. Shutdown Visual Studio
3. Видаліть папку ShadowCache
4. Відновив проект Visual Studio
5. Відновіть рішення

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

У моєму випадку це було через інші помилки компіляції . Коли інші помилки були вирішені, ця, здавалося б, пов’язана помилка також була видалена зі списку. Особливо помилки внизу списку помилок та на нещодавно змінених сторінках.

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

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

Через Subversion я помітив, що я, очевидно, змінив ціль платформи побудови проекту на x64. Це була єдина зміна, яку я вніс. Після внесення цієї зміни код працював короткий час, перш ніж почав показувати ту саму помилку, яку ви зазнали. Я змінив ціль платформи на x86, щоб перевірити, і раптом мій дизайнер знову працював. Згодом я змінив його назад на x64, і проблема повністю зникла. Я підозрюю, що дизайнер будує якийсь кешований код у x32, а зміна платформи збірки x64 порушує його, коли ви вносите зміни коду.

Не знаю, якщо це допоможе комусь іншому

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

Можливо, інше рішення, коли проект збирається, але відображається помилка XAML:

1. У дослідженні рішення на вузлі проекту, що містить xaml
2. Клацніть правою кнопкою миші на проект та оберіть 'Unload Project'
3. Клацніть правою кнопкою миші на проект та виберіть "Перезавантажити проект". Переконайтеся, що проект все ще обраний як "проект запуску". Якщо ні :
4. Клацніть правою кнопкою миші на проект та виберіть "Встановити як проект запуску"

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

Ісусе ... Це ще проблема через п'ять років у Visual Studio 2017. Оскільки я новачок у WPF, я був впевнений, що проблема якимось чином я, але ні, все складено та працює правильно.

Я спробував відновити, очистити та відновити, переключившись між виведеннями x86 / x64, перезавантаживши Windows, очистивши папку ShadowCache, додавши "; Assembly = {моє головне ім'я збірки}" до декларації простору імен XML, нічого не вийшло! Єдине, що зробило:

Поставте мій статичний клас команд (у моєму випадку справа стосувалася того, щоб дизайн виявив мої команди WPF) у його окрему збірку та змінив назву складання замість цієї.

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

Це не вирішується шляхом відновлення рішення (ані перегляд дизайну, ані помилка "Ім'я не існує в просторі імен")

Я думаю, що це було тому, що я грав з налаштуваннями Solution -> Properties> Configuration Properties

Нарешті я вирішив проблему з 2 робочими місцями:

1. Позначте всі прапорці на Стовпці збірки сторінки: Рішення -> Властивості -> Властивості конфігурації
2. Зміна конфігурацій рішення з налагодження на випуск або навпаки.

Я думаю, що це помилка в Visual Studio2012 Update 2.

Ця ж проблема стикається з Visual Studios 2013, Service Pack 4. Я також спробував її з Visual Studios 2015 Preview з тими ж результатами.

Це лише обмеження візуалізатора WPF, якого команда Visual Studios не встановила. Як доказ, побудова в режимі x86 дозволяє візуалізатору, а побудова в режимі x64 вимикає його.

Як не дивно інтеліссенс працює для Visual Studios 2013, Service Pack 4.

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

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

Схоже, цю проблему можна вирішити через різноманітні "хитрощі".

У моєму випадку я будував / відновлював / очищав все рішення, а не лише проект, над яким працював у рамках рішення. Щойно я натиснув "Створити [мій проект]", повідомлення про помилку зникло.

Спробуйте перевірити посилання на збірку. Якщо у посиланнях на проект є жовтий знак оклику, виникла проблема, і ви отримаєте всілякі помилки.

Якщо ви знаєте, що посилання на проект є правильним, перевірте рамку цільової. Наприклад, наявність проекту, що використовує 4,5-базовий посилання на проект, з рамкою 4.5.2, не є гарною комбінацією.

Рішенням для мене було розблокувати збірку DLL. Повідомлення про помилки, які ви отримуєте, не вказують на це, але дизайнер XAML відмовляється завантажувати те, що воно називає "пісочне" складання. Ви можете бачити це у вікні виводу під час створення. DLL-файли блокуються, якщо їх завантажувати з Інтернету. Щоб розблокувати сторонні DLL-файли третьої сторони:

1. Клацніть правою кнопкою миші файл DLL в Провіднику Windows і виберіть Властивості.
2. У нижній частині вкладки Загальне натисніть кнопку "Розблокувати" або прапорець.

Примітка. Розблокуйте DLL-файли, лише якщо ви впевнені, що вони безпечні.

У моєму випадку управління користувачам було додано до основного проекту. Я спробував різні рішення вище, але безрезультатно. Або я отримаю неправильну розмітку, але рішення збирається і працює, або я б додав xmlns: c = "clr-namespace: MyProject; Assembly = MyProject", і тоді розмітка відобразиться, але я отримаю помилку компіляції тег не існує в просторі імен XML.

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

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

У моєму випадку рішення мало два проекти: один, що містить моделі (скажімо, назва проекту та збірки - Моделі ), а інший - з переглядами та моделями перегляду (відповідно до нашої конвенції: проект, назва збірки та простір імен за замовчуванням були Моделі. Монітор ) . Проект Models.Monitor посилався на проект «Моделі».

У проекті Models.Monitor в одному з xaml я включив таке простір імен: xmlns: monitor = "clr-namespace: Models.Monitor"

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

1. xmlns: monitor = "Простір імен clr: 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" . Після цього мені вдалося скласти штрафи.

У моєму випадку у мене був простір імен і написано клас точно так само, наприклад, один з моїх просторів імен був

firstDepth.secondDepth.Fubar

який містить власні класи (наприклад, firstDepth.secondDepth.Fubar.someclass)

але я також мав клас " Fubar " у просторі імен

firstDepth.secondDepth

який текстуально відповідає тому самому, що і вище.

Не робіть цього

У моєму випадку проблема була пов’язана з деякими фантомними файлами в каталозі 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 була такою ж назвою збірки, що і посилається на dll. Тому переконайтеся, що у жодному з ваших проектів немає дублюючих імен збірок.

У мене рішення зберігалося на мережевій папці, і кожного разу, коли я його відкривав, я отримував би попередження про ненадійні джерела. Я перемістив його на локальний диск, і помилка "Простір імен не існує" також зникла.

Спробуйте також клацнути правою кнопкою миші свій проект-> властивості та змінити ціль платформи на будь-який процесор і відновити її, після чого вона працюватиме. Це працювало для мене

Ця проблема також може бути викликана, якщо збірка, на яку ви посилаєтесь, насправді не побудована. Наприклад, якщо ваш xaml знаходиться в Assembly1 і ви посилаєтесь на клас також у Assembly1, але ця збірка має помилки і не будується, ця помилка буде показана.

Мені це здається дурним, але в моєму випадку я зірвав під управлінням користувача і в результаті мав всілякі помилки в пов'язаних класах. Коли я намагався їх виправити, я почав із відповідних помилок, не розуміючи, що xaml покладається на вбудовані збірки, щоб знайти ці посилання (на відміну від коду c # / vb, який може опрацювати це ще до того, як створити).

У мене була додана збірка як проект - спочатку видалили DDL, який був доданий спеціально до посилань на dll - це зробили.

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

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