ім'я <…> не існує у просторі імен clr-просторі імен <…>


84

У мене є невеликий додаток WPF, який раніше компілювався просто чудово, але це вже не так. Насправді не можу сказати, з якого моменту він припинив будівництво. Це просто добре працювало один день, а наступного - ні.

Ось структура проекту:

введіть тут опис зображення

Інших проектів або зовнішніх посилань, окрім стандартних dll-файлів .net, немає.

Ось елемент керування користувача, звідки виникла проблема:

<UserControl x:Class="TimeRecorder.HistoryUserControl"
         xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
         xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
         xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
         xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
         xmlns:local="clr-namespace:TimeRecorder.ViewModel"
         xmlns:framework="clr-namespace:TimeRecorder.Framework"
         mc:Ignorable="d" Height="Auto" Width="Auto" Padding="5">
<UserControl.Resources>
    <local:HistoryViewModel x:Key="ViewModel"/>
    <framework:BoolToColorConverter x:Key="ColorConverter"/>
</UserControl.Resources>
<StackPanel DataContext="{StaticResource ViewModel}">

І ось помилка, яку я отримую: http://i48.tinypic.com/5u1u8w.png

Зверніть увагу, що це не просто один файл на скріншоті, а всі посилання, які я додаю подібним чином у xaml у всіх файлах керування користувачами / вікнах у цьому проекті.

Отже, файл є, простір імен у файлі правильний, ім’я простору / класу у файлі xaml (на моє розуміння) правильне. Я отримую intellisense, коли ввожу xaml, тому він знаходить файли нормально, але не коли він компілюється.

Найпоширенішим рішенням для цього в інших публікаціях була версія .net framework. На даний момент встановлено .Net Framework 4 як для мого основного, так і для тестового проекту. Повна версія не профіль клієнта.

Ось, що, на мою думку, я переплутав: у менеджері конфігурацій для обох проектів платформа встановлена ​​на будь-який процесор, але в один момент при спробі вирішити це я помітив, що для основного проекту встановлено x86, а для тестового проекту - будь-який ЦП. Тому я додав будь-який процесор вручну для основного проекту в менеджер конфігурацій. Однак я, чесно кажучи, не знаю, чи правильно я це зробив, чи навіть мав би це робити. Отже, як додаткове запитання, чи є спосіб перезапустити менеджер конфігурацій до стану за замовчуванням? Чи буде це щось сказати для головної проблеми? Не знаю, чи завжди для основного проекту було встановлено x86 чи ні, чи я якось змінив його на x86, а потім він зламався. Як уже згадувалося, цей проект деякий час складався просто чудово.


FYI, ви можете прочитати ProgressTimeSpentUserControl.xaml. Можливо, ви захочете зробити кращу роботу, розмиваючи її;)
ItNotALie.

Ніякого biggie :) Це просто тимчасовий файл, в якому я тестував деякі речі, де, оскільки інші є частиною проекту з відповідними моделями подання, тому мій OCD сказав мені позначити його як нерелевантний;)
ardal

2
У мене була дуже подібна проблема 2 дні тому - я базікав з диспетчером конфігурацій, намагаючись встановити все для побудови як "будь-який процесор", а не як x86, і він перестав будувати. Я виявив, що зробив дві речі - по-перше, я залишив це в режимі звільнення, а по-друге, менеджер конфігурації збірки, збірка в деяких випадках не була позначена для побудови. Моє виправлення полягало в тому, щоб пройти всі доступні режими (x86, змішані платформи та будь-який процесор) і встановити всі збірки для побудови. Це звучить як одна з тих речей, про яку ви будете збивати себе за те, що не думаєте, коли виявите, що не так!
Джей

Подібне запитання (з робочою відповіддю): stackoverflow.com/questions/28216096/…
Олекса

Для тих, хто приземлився тут у 2018 році .NET 4.6.1, я перезапустив VS, потім відновив, і він почав працювати. Безумовно, витратив більше часу, ніж мав би думати, що десь маю тип-о.
Mwspencer

Відповіді:


143

Кожного разу, коли це траплялося зі мною, я просто перезапускав візуальну студію, відновлював рішення, і воно працювало чудово .. не можу сказати, чому


17
Одне слід додати - лише коли я перезапускаю VS з правами адміністратора, проект успішно створюється. Зі звичайними дозволами рішення для повторного запуску та відновлення не допомогло.
Sevenate

1
Просто збережіть рішення, яке спричиняє проблему. Запустіть VS в режимі адміністратора та запустіть "відновити все" з файлу рішення. це спрацювало. дуже моторошний.
pollaris 02.03.17

12
Сумно бачити, що це все ще не вирішено через 5 років. З VS 2017 існує та сама проблема, і все те саме рішення все ще працює!
CodeHacker

@gil kr У мене були подібні проблеми з ксамарином та його XML. Я виявив, що переміщення проекту з мережевої папки в локальну папку вирішило проблему. Цікаво, чи так це тут.
vdidxho 01.03.18

3
Це не вирішило моєї проблеми, навіть починаючи з прав адміністратора.
MindRoasterMir

30

На додаток до повідомлення "не існує у просторі імен", я також отримував повідомлення від дизайнера про те, що він не може відображати вікно для цілей x64 та ARM.

Я щойно виявив, що переключення збірки в режим x86, рішення відновлення, потім перехід до режиму x64, а потім відновлення знову усуває [обидві] проблеми.

Просто відновлення рішення x64 нічого не дало.


5
Є ще один крок. Ви повинні відновити x86, а потім відкрити xaml у конструкторі. І лише тоді поверніться до x64.
Dzienny

2
Я спробував перезапустити візуальну студію, а потім відновити, але все ще отримував ту ж помилку. @Jerry - твоє рішення саме для мене спрацювало у VS2012.
Barrie

Джеррі, це звучить сумнівно, але твоє рішення працює! Я скомпілював свій проект для AnyCPU, але якось скомпілював під x86, а потім назад вирішив цю проблему. Я підозрюю, що AnyCPU може повернутися до x86, але через помилку в VS ця частина коду не була створена, якщо не скомпілювати її під x86.
Wayne Lo

Так, будь-які ІНШІ помилки на додаток до "не існує у просторі імен" повинні бути вирішені спочатку.
pollaris

Все-таки трапилося зі мною у VS2017. Закриття та повторне відкриття VS не спрацювало. Але ваше рішення зробило.
Гордон Сліш,

14

Я виявив, що допомогло (особливо, якщо ця помилка трапляється в App.xaml), - це прокоментувати посилання (посилання), які доставляють вам проблеми, відновлювати, а потім коментувати. Я думаю, що це робить, це дозволяє фактично будувати весь проект замість того, щоб зупиняти збірку через помилку.

З того, що я можу зібрати, додаток намагається побудувати файли в певному порядку, тому, коли App.xamlабо, мабуть, будь-які інші помилки файлів класу у посиланні, файл, що викликає помилку, не був скомпільований належним чином, отже, чому це не так не знайду файл у цьому просторі імен.


3
Ви мали право ідея , коли ви сказали: the app is trying to build the files in a certain order. Це змусило мене заглянути в мій .csprojфайл. Було App.xaml.csспочатку місце. Потім я перемістив його під файл, який показав цю помилку, відновити, і помилка зникла. ДЯКУЮ!
Стефан

Це рішення працювало для мене, коли інші ні. спасибі
RamWill

12

Це те, що працювало для мене у Visual Studio 2012 (оновлення 3).

  • Перезапустіть Visual Studio
  • Додайте поточну збірку до оголошення простору імен xmlns:framework="clr-namespace:TimeRecorder.Framework;assembly=MyAssembly
  • Build -> Build Solution

працював у мене VS2015 Professional update3, дякую :)
EricG

Можна перевірити, це працює і на Visual Studio 2019.
Двадцять

9

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


7

У мене була подібна проблема. У моєму випадку мені довелося зробити наступне

  • видалити посилання розмітки з xaml (у цьому прикладі <local:HistoryViewModel x:Key="ViewModel"/>)
  • побудувати клас (у цьому прикладі файлу, який містить HistoryViewModelклас)
  • Після його створення додайте посилання розмітки в xaml
  • будувати знову

Вищезгаданий метод спрацював для мене.


Дивіться мою відповідь, щоб зрозуміти, чому це вирішило вашу проблему.
jaysoncopes

6

Що у мене вийшло: - Переключити конфігурацію рішення з Налагодження на Випуск - Переключити назад конфігурацію з Реліз на Налагодження


Дивно. Це спрацювало і на мене. Також робив чисті збірки у кожному випуску.
GeoffCoope

4

Вийшов у цей випуск сьогодні разом із Visual Studio 2017 Community Edition. Перепробував усі пропозиції тут (скинути VS 2017, змінив з x64 на x32 і назад і т. Д.) Та з інших джерел безрезультатно. Intellisense знає, що все є, але я щоразу отримував ту саму помилку.

У будь-якому випадку, моє виправлення виявилося дуже простим ... хіба не завжди, коли ви витратили пару годин на вирішення проблеми!

В основному, я зробив наступне ...

  1. Видаліть код, що порушує правила, із файлу xaml (у моєму випадку лише 3 рядки)
  2. Створіть проект, щоб отримати успішну збірку
  3. У цей момент макет чарівно з’явився у вікні дизайнера, що було хорошим знаком!
  4. Повторно встав код, який я видалив у пункті 1., включаючи запис xmlns:
  5. У цей момент ви не повинні отримувати жодних блакитних вивілок ... сподіваємось
  6. Побудуйте проект знову

Здається, що, отримавши успішну збірку, він повинен скинути `` щось '' у VS та / або збірці. Після успішної збірки спробуйте вставити код ще раз.


Це насправді було єдиним, що працювало у мене. Ось чому я ненавиджу VisualStudio з XAML. Цей хакерський тип гри з конфігураціями неприйнятний.
Гоку

3

Жодне з рішень не працювало для мене. Я виправив це так:

  • Видаліть dll бібліотеки зі списку посилань
  • Завантажте вихідний код бібліотеки (а не лише файл dll)
  • Створіть проект бібліотеки, щоб отримати новий файл DLL
  • Додайте новий файл dll до посилань основного проекту

3

Якби ця проблема кружляла по колу, витрачаючи кілька годин. Я перемістив окрему бібліотеку керування користувачем у проект, щоб вона була скомпільована в проекті, а не на посилання на DLL. Це зламало весь проект, тому я тоді ретельно перевірив усі простори імен, шляхи та імена файлів. Спробував видалити файли obj, змінюючи між випуском та налагодженням, між x86 та AnyCPU. Відкриваючи збереження всіх, перекомпілювати все одно не буде ніякої радості.

Пам'ятайте, що раніше мала подібну проблему, помилка, позначена у VS2013, не була безпосередньо пов'язана з тим, де мені довелося змінити XAML, а за допомогою

x:Name="myControl"

на всіх елементах управління, замість

Name="myControl"

це виправили.


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

Ти мій герой.
Холден

3

Я змінив цільову структуру Моє застосування ".Net Framework 4.5" на ".Net Framework 4.6", і це спрацювало!


Я змінив ціль з 4.6.1 на 4.6, і це також спрацювало.
GisMofx

2

Ось дивний приклад подібного:

<UserControl x:Class="Gtl.Ui.Controls.WaitControl"
         xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
         xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
         xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
         xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
         xmlns:controls="clr-namespace:Gtl.Ui.Controls"
         mc:Ignorable="d" 
         d:DesignHeight="120" d:DesignWidth="120"             
         Background="Transparent">
...
</UserControl>

буде компілювати (VS2013).

<UserControl x:Class="Gtl.Ui.Controls.WaitControl"
         xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
         xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
         xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
         xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
         xmlns:controls="clr-namespace:Gtl.Ui.Controls"
         mc:Ignorable="d" 
         d:DesignHeight="120" d:DesignWidth="120"             
         Background="Transparent"
         IsVisibleChanged=onIsVisibleChanged>
...
</UserControl>

видає помилку "тип Ui не знайдено в Gtl.Ui.Gtl" (і я запевняю вас, що метод обробника існує в коді-позаду). Навколо цього є додавання обробника до конструктора класу, але давай Microsoft, wtf триває?


Я не згоден із наведеними коментарями Цей тип "розширення контексту" часто корисний для виявлення причини такої помилки, яка НЕ ​​ТІЛЬКИ спричинена умовами OP.
CJBrew

2

Я зіткнувся з такою ж проблемою, коли намагався викликати простір імен у xaml. показував, що клас недоступний у просторі імен. Я багато шукав. Нарешті, я виявив, що ця проблема стосується VS. Я використовую VS 2013. Я спробував наступні кроки:

  1. Збірка -> Менеджер конфігурацій -> Платформа активного рішення -> Змінено на x64 та x86 та будь-який процесор.
  2. Закрили VS і знову відкрили.
  3. Зміна

    xmlns:VM="clr-namespace:MyFirstAppViewModel"
    

    до

    xmlns:VM="clr-namespace:MyFirstAppViewModel;assembly=ViewModel"
    

2

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

Крок 1) Спочатку видаліть усі помилки, що спричиняють код, із файлу XAML або .cs та побудуйте та запустіть проект, натиснувши F5.

Крок-2) Додайте додайте помилку, що спричиняє код у XAML, по черзі.


1
  • я б порекомендував перейменувати, x:Key="ViewModel"можливо, є глюк
  • а якщо ви вводите local:, VS показує вам HistoryViewModel?
  • також перевірте, чи Classє вашpublic


1

Я виявив, що запуск команди "Запустити аналіз коду" заново збирає все і майже завжди вирішує проблему (проект правою кнопкою миші> Аналіз> Запуск аналізу коду). Це також, як правило, відновлює файли ресурсів, щоб можна було знаходити рядки тощо.


За винятком того, що я недавно виявив, навіть це не спрацює. Мені довелося закрити VS і перезапустити. О, добре ...
Джефф,

1

Перепробував усі рішення у цій темі, але жодне не спрацювало. Це виявилося причиною конфігурації рішення. Мою програму WPF було встановлено для побудови для X64 через деякі власні залежності, які цього потребують, але конфігурація рішення все ще була встановлена ​​для AnyCPU для проекту. Створення нової конфігурації X64 для проекту в диспетчері конфігурацій рішення дозволило дизайнеру XAML нарешті розпізнати мій тип і простір імен.


1

Перш ніж додати простір імен у файл .xaml, переконайтеся, що у вас не виникає помилок компіляції через наявний код.

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


0

Для мене це періодична проблема. Одного разу я знайшов рішення, переглядаючи вкладку Попередження . Це була проблема з версією .NET Framework, і в ній було зазначено таке:

Попередження 9 Основне посилання "myDll" не вдалося вирішити, оскільки воно було побудоване в рамках ".NETFramework, Version = v4.5.2". Це вища версія, ніж поточна цільова структура ".NETFramework, Версія = v4.0".


0

Існує глюк з їх буферизацією макетів об’єктів. Якщо щось перейменовано або переміщено, воно втрачається. Що мені зазвичай вдається, це створити абсолютно новий клас і скопіювати весь старий код, змусити його працювати в новому класі, а потім видалити оригінальний клас. Іноді після того, як ви запускаєте його та запускаєте з новою назвою класу, ви можете спробувати перейменувати його назад на початкове ім'я (але зазвичай ні)


0

Я використовував xmlns: local = "using: MyRootNamespace.ChildNamespace" у заголовку .xaml, і я перетворив його на xmlns: local = "clr-namespace: MyRootNamespace.ChildNamespace" ... ну, я просто дозволив intellisense робити робота, і вона спрацювала.


0

Проблема полягає в тому, що під час створення цілі x86 для вихідного шляху для конкретного проекту встановлюється bin \ x86 \ Debug. Схоже, суміш Expression це зовсім не подобається. Здається, його цікавить лише те, що в bin \ Debug.

Якщо ви змінили шлях (и) виводу для проекту x86 на bin \ debug, наприклад, тоді я впевнений, ви виявите, що це спрацює. Ну, у мене все одно працює :)


0

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


0

Я стикався з тим самим питанням. Ви отримуєте цю помилку, але все-таки ви можете успішно побудувати свій проект. Незручність полягає в тому, що ви не бачите проектування інтерфейсу користувача (або просто хочете очистити код і видалити дратівливі хиткі рядки). Читаючи багато публікацій, пробують кілька речей, але наступні роботи нагадують шарм.

Спробував це у Visual Studio 2019:

Клацніть правою кнопкою миші на своєму Рішенні -> Властивості -> Властивості конфігурації, а потім змініть конфігурації проекту з Налагодження на Випуск або навпаки.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.