Пространства имен XAML и сопоставление пространств имен для WPF XAML

Статья
12/17/2024

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

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

Пространство имен XAML на самом деле является расширением концепции пространства имен XML. Методы указания пространства имен XAML зависят от синтаксиса пространства имен XML, соглашения об использовании URI в качестве идентификаторов пространства имен, используя префиксы для предоставления средств для ссылки на несколько пространств имен из одного источника разметки и т. д. Основная концепция, добавляемая в определение пространства имен XML, заключается в том, что пространство имен XAML подразумевает как область уникальности использования разметки, так и влияет на то, как сущности разметки потенциально поддерживаются определенными пространствами имен CLR и ссылочными сборками. Это последнее соображение также зависит от концепции контекста схемы XAML. Но в целях работы WPF с пространствами имен XAML можно в целом рассматривать пространства имен XAML с точки зрения пространства имен XAML по умолчанию, пространства имен ЯЗЫКА XAML и любых дополнительных пространств имен XAML, сопоставленных разметкой XAML непосредственно с определенными пространствами имен CLR и ссылочными сборками.

Объявления пространства имен WPF и XAML

В объявлениях пространства имен в корневом теге многих файлов XAML вы обычно увидите два объявления пространства имен XML. Первое объявление сопоставляет общее пространство имен клиента WPF или платформы XAML в качестве значения по умолчанию:

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

Второе объявление сопоставляет отдельное пространство имен XAML, сопоставляя его (обычно) с префиксом x:.

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

Связь между этими объявлениями заключается в том, что сопоставление префикса x: поддерживает встроенные компоненты, которые являются частью определения языка XAML, и WPF является одной реализацией, которая использует XAML в качестве языка и определяет словарь своих объектов для XAML. Поскольку использование словаря WPF будет гораздо более распространено, чем встроенные использования XAML, словарь WPF назначается значением по умолчанию.

Конвенция с префиксом x: для сопоставления встроенных функций языка XAML поддерживается шаблонами проектов, образцами кода и документацией по языковым функциям в этом SDK. Пространство имен XAML определяет множество часто используемых функций, которые необходимы даже для базовых приложений WPF. Например, чтобы присоединить любой код программной части к XAML-файлу через частичный класс, необходимо указать этот класс в качестве атрибута x:Class в корневом элементе соответствующего XAML-файла. Или любой элемент, определенный на странице XAML и который должен быть использован в качестве ресурса с ключом, должен иметь атрибут x:Key для данного элемента. Дополнительные сведения об этих и других аспектах XAML см. в XAML в WPF или в подробностях синтаксиса XAML.

Сопоставление с пользовательскими классами и сборками

Пространства имен XML можно сопоставить с сборками с помощью ряда маркеров в объявлении префикса xmlns, аналогично тому, как стандартные пространства имен WPF и XAML-встроенные пространства имен XAML сопоставляются с префиксами.

Синтаксис принимает следующие возможные именованные токены и следующие значения:

clr-namespace: пространство имен CLR, объявленное в сборке, содержащей общедоступные типы для предоставления в виде элементов.

assembly= Сборка, содержащая некоторые или все из указанных пространств имен CLR. Обычно это значение является только именем сборки, а не путем и не включает расширение (например, .dll или .exe). Путь к этой сборке должен быть установлен в качестве ссылки на проект в файле проекта, содержащем XAML, который вы пытаетесь сопоставить. Чтобы добавить версионирование и подписание строгим именем, значение assembly может быть строкой, определенной AssemblyName, а не просто именем строки.

Обратите внимание, что символ, разделяющий маркер clr-namespace от его значения, является двоеточием (:) в то время как символ, разделяющий маркер assembly от его значения, является знаком равенства (=). Символ, используемый между этими двумя маркерами, является точкой с запятой. Кроме того, не включайте пробелы в объявлении.

Пример базового настраиваемого сопоставления

Следующий код определяет пример пользовательского класса:

namespace SDKSample {  
    public class ExampleClass : ContentControl {  
        public ExampleClass() {  
        ...  
        }  
    }  
}

Namespace SDKSample  
    Public Class ExampleClass  
        Inherits ContentControl  
         ...  
        Public Sub New()  
        End Sub  
    End Class  
End Namespace

Затем этот пользовательский класс компилируется в библиотеку, которая для параметров проекта (не показана) называется SDKSampleLibrary.

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

Теперь, когда у вас есть библиотека, содержащая класс, и ссылка на неё указана в параметрах проекта, вы можете добавить следующее соответствие префикса в составе корневого элемента в XAML:

xmlns:custom="clr-namespace:SDKSample;assembly=SDKSampleLibrary"

Чтобы объединить все это вместе, ниже приведен код XAML, который включает кастомное сопоставление вместе с типичным сопоставлением по умолчанию и x: сопоставлениями в корневом теге, а затем использует ссылку с префиксом для создания экземпляра ExampleClass в этом UI.

<Page x:Class="WPFApplication1.MainPage"  
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"  
    xmlns:custom="clr-namespace:SDKSample;assembly=SDKSampleLibrary">  
  ...  
  <custom:ExampleClass/>  
...  
</Page>

Сопоставление с текущими сборками

assembly можно опустить, если ссылка на clr-namespace определена в той же сборке, что и код приложения, ссылающийся на пользовательские классы. Или эквивалентный синтаксис для этого случая — указать assembly=без строкового маркера после знака равенства.

Пользовательские классы нельзя использовать в качестве корневого элемента страницы, если они определены в той же сборке. Частичные классы не нужно сопоставлять; Необходимо сопоставить только классы, которые не являются частичным классом страницы в приложении, если вы планируете ссылаться на них как элементы в XAML.

Сопоставление пространств имен CLR с пространствами имен XML в сборке

WPF определяет атрибут CLR, который используется процессорами XAML для сопоставления нескольких пространств имен CLR с одним пространством имен XAML. Этот атрибут, XmlnsDefinitionAttribute, размещается на уровне сборки в исходном коде, создающем сборку. Исходный код сборки WPF использует этот атрибут для сопоставления различных распространенных пространств имен, таких как System.Windows и System.Windows.Controls, с пространством имен http://schemas.microsoft.com/winfx/2006/xaml/presentation.

XmlnsDefinitionAttribute принимает два параметра: имя пространства имен XML/XAML и имя пространства имен CLR. Более одного экземпляра XmlnsDefinitionAttribute может существовать для сопоставления нескольких пространств имен CLR с одним пространством имен XML. После сопоставлений элементы этих пространств имен также можно ссылаться без полной квалификации, если требуется, предоставив соответствующую инструкцию using на странице кода частичного класса. Дополнительные сведения см. в XmlnsDefinitionAttribute.

Пространства имен конструктора и другие префиксы из шаблонов XAML

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

Конструктор WPF для Visual Studio использует пространство имен конструктора, которое обычно сопоставляется с префиксом d:. Более поздние шаблоны проектов для WPF могут предварительно настроить это пространство имен XAML для поддержки обмена данными XAML между конструктором WPF для Visual Studio и другими средами разработки. Это пространство имен XAML конструктора используется для сохранения состояния проектирования во время переноса пользовательского интерфейса на основе XAML в конструкторе. Он также используется для таких возможностей, как d:IsDataSource, которые позволяют использовать источники данных времени выполнения в конструкторе.

Еще один префикс, который вы можете встретить, это mc:. mc: используется для совместимости разметки и использует шаблон совместимости разметки, который не обязательно зависит от XAML. В некоторой степени функции совместимости разметки можно использовать для обмена XAML между платформами или через другие границы поддерживающей реализации, работы с контекстами схемы XAML, обеспечения совместимости для ограниченных режимов в конструкторах и т. д. Дополнительные сведения о концепциях совместимости разметки и их связи с WPF см. в разделе Язык функций совместимости разметки (mc:).

Загрузка WPF и загрузка сборок

Контекст схемы XAML для WPF интегрируется с моделью приложения WPF, которая, в свою очередь, использует определяемую средой CLR концепцию AppDomain. В следующей последовательности описывается, как контекст схем для XAML интерпретирует процесс загрузки сборок или поиска типов во время выполнения или в период проектирования, основанный на использовании AppDomain в WPF и других факторах.

Выполните итерацию по AppDomain, чтобы найти уже загруженную сборку, которая соответствует всем аспектам имени, начиная с последней загруженной сборки.
Если имя квалифицировано, вызовите Assembly.Load(String) с использованием квалифицированного имени.
Если короткое имя + маркер открытого ключа для квалифицированного имени соответствует сборке, из которой была загружена разметка, возвратите эту сборку.
Используйте короткое имя и маркер открытого ключа для вызова Assembly.Load(String).
Если имя не задано, вызовите Assembly.LoadWithPartialName.

Loose XAML не использует третий шаг; отсутствует сборка, из которой он загружается.

Скомпилированный XAML для WPF (созданный с помощью XamlBuildTask) не использует уже загруженные сборки из AppDomain (шаг 1). Кроме того, имя должно быть всегда полностью определено в выходных данных XamlBuildTask, поэтому шаг 5 не применяется.

Скомпилированный BAML (созданный с помощью PresentationBuildTask) использует все шаги, хотя BAML также не должен содержать неквалифицированные имена сборок.

Поделиться через