Вирішення питань, пов’язаних з помилками завантаження конструктора WPF, Microsoft Docs

Оновлено: Листопад 2007

Windows Presentation Foundation (WPF) для Visual Studio (конструктор) включає багатофункціональний візуальний конструктор, що розширюється, для створення XAML-коду. Якщо файл XAML не завантажується в конструктор, є кілька варіантів усунення несправностей. У цьому розділі наводяться деякі поради та описуються способи, що дозволяють усунути помилки завантаження WPF (конструктор).

Примітка.

Багато способів, описаних у цьому розділі, також застосовні до засобу Expression Blend.

Етапи усунення несправностей

Наведені нижче дії допоможуть усунути помилки завантаження WPF (конструктор).

Прочитайте всі отримані повідомлення про винятки.

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

Визначте, чи проблема не обумовлена конкретною реалізацією.

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

Використовуйте Visual Studio для переходу в код під час розробки. Для отримання додаткових відомостей див. Покроковий посібник. Налагодження елементів управління WPF під час розробки.

Визначте, чи є проблемою помилка завантаження.

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

Перегляньте код, який завантажується під час розробки.

Існує два підходи до запису коду, що також виконується під час розробки. Перший підхід полягає в написанні коду захисту шляхом перевірки вхідних параметрів для класів. Другий підхід полягає у перевірці активності режиму розробки викликом методу GetIsInDesignMode. Щоб отримати додаткові відомості, див. Написання коду для часу розробки нижче.

Перегляньте інші області коду.

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

Якщо проблеми залишаються, можна перейти на форум розробників WPF на MSDN (англійською мовою), щоб зв'язатися з іншими розробниками WPF (конструктор). Для надсилання звіту про можливі проблеми та можливі пропозиції скористайтеся веб-сайтом Visual Studio та .NET Framework. Feedback (англійською мовою).

Написання коду для часу розробки

Переконайтеся, що код виконується як під час розробки, так і під час виконання. Якщо код виконується під час розробки, не слід вважати, що Application.Current є програмою, що розробляється. Наприклад, під час використання засобу Expression Blend Current є Expression Blend. Під час розробки MainWindow не є головним вікномрозроблюваної програми. До типових операцій, що викликають збій настроюваного елемента управління під час розробки, відносяться:

приведення типу Current до підкласів Application, що налаштовуються,

приведення типу MainWindow до підкласів Window, що налаштовуються,

створення посилань на ресурси із Application.Resources. Примірник часу розробки Application відрізняється від програми, що розробляється і має інші ресурси,

відсутність перевірки повернення методом Application.Current або Application.MainWindow значення null. Якщо Visual Studio не створює об'єкт програми, Application.Current може повертати значення null,

відсутність перевірки повернення методом Assembly.GetEntryAssembly значення null. Для середовища Visual Studio цей метод повертає значення null.

Існує два підходи до написання коду часу розробки. Перший підхід полягає в написанні коду захисту шляхом перевірки вхідних параметрів класів, таких як перетворювачі значень. Другий підхід полягає у перевірці активності режиму розробки викликом методу GetIsInDesignMode.

Перевірка вхідних параметрів необхідна для деяких реалізацій, оскільки для деяких вхідних даних середовище розробки надає типи, які відрізняються від тих, що надає середовище виконання.

Зазвичай, для селекторів стилю та перетворювачів значень потрібен один із цих підходів для правильної роботи під час розробки.

Перетворювачі значень

У реалізації реалізації IValueConverter повинна проводитися перевірка на наявність значення null і на очікуваний тип першого параметра методу Convert. У наступному XAML-коді показується прив'язка до Application.Current, яка під час розробки призводить до збою, якщо перетворювач значеньреалізований неправильно.

Прив'язка викликає виняток під час розробки, так як Application.Current посилається на додаток конструктора замість програми, що розробляється. Щоб уникнути виключення, перетворювач значень повинен перевіряти свої вхідні параметри або активність режиму розробки.

Наступний приклад коду показує, як перевіряти вхідні параметри в перетворювачі значень, що повертає значення true, якщо два вхідні параметри задовольняють конкретній бізнес-логіці.

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

Селектори стилю

Налаштовані селектори стилю також повинні бути реалізовані для запуску в режимі розробки. У наступному XAML-коді показаний селектор шаблону, в якому під час виконання використовується властивість Application.MainWindow для визначення ресурсу, що повертається у вигляді DataTemplate. Під час розробки цей ресурс може бути недоступним, тому навантаження SelectTemplate повертає значення null під час розробки.

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

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

За замовчуванням UserControl і ресурси елементів керування, які можна настроїти під час виконання, можуть бути недоступні під час розробки. При додаванні елементів керування, що настроюються, і користувацьких елементів керування в Page або Window в області конструктора створюється екземпляр елемента керування. Ресурси у файлі App.xaml недоступні для UserControl і екземплярів елементів керування, що настроюються,завантажені на сторінку або у вікно.

Щоб ресурси були доступні під час розробки, додайте їх до окремого словника ресурсів та увімкніть словник у файл App.xaml та XAML-код елемента керування. Змініть посилання StaticResource на посилання DynamicResource. У цьому прикладі показано, як зробити словник ресурсів загальним, щоб його ресурси були доступні під час розробки.

Синтаксис Pack URI

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

Такі посилання стосуються програми, а не DLL-бібліотеки. Використання посилання на ресурс локальної щодо програми в DLL-бібліотеці файлі робить DLL-бібліотеку залежною від ресурсів батьківської програми. Такий метод не забезпечує достатньої надійності та не гарантує працездатності під час розробки.

Замість використання посилань на ресурси, що стосуються програми, додайте ресурси безпосередньо до DLL-бібліотеки та використовуйте посилання на ресурси на основі компонента. Для отримання додаткових відомостей див. розділ URI типу "pack" у Windows Presentation Foundation.

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

Поради щодо програмування

Нижче наведено деякі поради щодо програмування при роботі з WPF (конструктор).

Якщо потрібно завантажити елемент управління в WPF (конструктор), необхідно вказати методи отримання та встановлення середовища CLR для всіх визначених властивостей залежностей. Щоб отримати додаткові відомості, див. розділ Користувацькі властивості залежностей.

Графічні елементи ComboBox не підтримуються.

Щоб використатисторонній елемент керування Windows Forms, створіть тип UserControl, який має екземпляр елемента керування від стороннього виробника у своїй колекції Controls. Для отримання додаткових відомостей див. Покроковий посібник. Розміщення стороннього елемента керування Windows Forms у програмі WPF.

Час розробки для FlowDocument безпосередньо не підтримується. Якщо потрібно використовувати WPF (конструктор) для вбудованого FlowDocument, спочатку помістіть FlowDocument в елемент керування Frame, який потім можна використовувати WPF (конструктор).