Partager via

Espaces de noms XAML et mappage d'espace de noms pour XAML WPF

Cette rubrique explique plus en détail la présence et l’objectif des deux mappages d’espaces de noms XAML comme souvent trouvés dans la balise racine d’un fichier XAML WPF. Il décrit également comment produire des mappages similaires pour l’utilisation d’éléments définis dans votre propre code et/ou dans des assemblys distincts.

Qu’est-ce qu’un espace de noms XAML

Un espace de noms XAML est vraiment une extension du concept d’un espace de noms XML. Les techniques de spécification d’un espace de noms XAML reposent sur la syntaxe de l’espace de noms XML, la convention d’utilisation d’URI en tant qu’identificateurs d’espace de noms, en utilisant des préfixes pour fournir un moyen de référencer plusieurs espaces de noms à partir de la même source de balisage, et ainsi de suite. Le concept principal ajouté à la définition XAML de l’espace de noms XML est qu’un espace de noms XAML implique à la fois une étendue d’unicité pour les utilisations de balisage et influence également la façon dont les entités de balisage sont potentiellement sauvegardées par des espaces de noms CLR spécifiques et des assemblys référencés. Cette dernière considération est également influencée par le concept d’un contexte de schéma XAML. Toutefois, à des fins de fonctionnement de WPF avec des espaces de noms XAML, vous pouvez généralement considérer les espaces de noms XAML en termes d’espace de noms XAML par défaut, d’espace de noms de langage XAML et d’espaces de noms XAML supplémentaires mappés par votre balisage XAML directement à des espaces de noms CLR de stockage spécifiques et à des assemblys référencés.

Déclarations des espaces de noms XAML et WPF

Dans les déclarations d’espace de noms dans la balise racine de nombreux fichiers XAML, vous verrez qu’il existe généralement deux déclarations d’espace de noms XML. La première déclaration mappe l’espace de noms XAML du client / framework WPF global comme valeur par défaut :

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

La deuxième déclaration mappe un espace de noms XAML distinct, le mappant (généralement) au préfixe x:.

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

La relation entre ces déclarations est que le mappage de préfixes x: prend en charge les intrinsèques qui font partie de la définition du langage XAML, et WPF est une implémentation qui utilise XAML comme langage et définit un vocabulaire de ses objets pour XAML. Étant donné que les utilisations du vocabulaire WPF seront beaucoup plus courantes que les utilisations intrinsèques XAML, le vocabulaire WPF est mappé comme valeur par défaut.

La convention de préfixe x: pour le mappage de la prise en charge des intrinsèques du langage XAML est suivie de modèles de projet, d’exemples de code et de la documentation des fonctionnalités de langage au sein de ce Kit de développement logiciel (SDK). L’espace de noms XAML définit de nombreuses fonctionnalités couramment utilisées qui sont nécessaires même pour les applications WPF de base. Par exemple, pour joindre n’importe quel code-behind à un fichier XAML via une classe partielle, vous devez nommer cette classe comme attribut x:Class dans l’élément racine du fichier XAML approprié. Ou bien, tout élément tel que défini dans une page XAML que vous souhaitez accéder en tant que ressource clé doit avoir le jeu d’attributs x:Key défini sur l’élément en question. Pour plus d'informations sur ces et d'autres aspects de XAML, consultez XAML dans WPF ou Syntaxe XAML en Détail.

Mappage aux classes et assemblys personnalisés

Vous pouvez mapper des espaces de noms XML à des assemblys à l’aide d’une série de jetons dans une déclaration de préfixe xmlns, de la même manière que les espaces de noms XAML WPF et XAML intrinsèques standard sont mappés aux préfixes.

La syntaxe prend les valeurs et les jetons nommés possibles suivants :

clr-namespace: Espace de noms CLR déclaré dans l’assembly contenant les types publics à exposer comme éléments.

assembly= L’assembly qui contient une partie ou l’ensemble de l’espace de noms CLR référencé. Cette valeur est généralement simplement le nom de l’assembly, et non le chemin d’accès, et n’inclut pas l’extension (par exemple, .dll ou .exe). Le chemin d’accès à cet assembly doit être établi en tant que référence de projet dans le fichier projet qui contient le code XAML que vous essayez de mapper. Pour incorporer le contrôle de version et la signature de nom fort, la valeur assembly peut être une chaîne telle que définie par AssemblyName, plutôt que par le nom de chaîne simple.

Notez que le caractère séparant le jeton clr-namespace de sa valeur est un signe deux-points (:) alors que le caractère séparant le jeton assembly de sa valeur est un signe égal (=). Le caractère à utiliser entre ces deux jetons est un point-virgule. En outre, n’incluez aucun espace blanc n’importe où dans la déclaration.

Exemple de mappage personnalisé de base

Le code suivant définit un exemple de classe personnalisée :

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

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

Cette classe personnalisée est ensuite compilée dans une bibliothèque, qui conformément aux paramètres du projet (non affichés) est nommée SDKSampleLibrary.

Pour référencer cette classe personnalisée, vous devez également l’inclure comme référence pour votre projet actuel, que vous feriez généralement à l’aide de l’interface utilisateur de l’Explorateur de solutions dans Visual Studio.

Maintenant que vous disposez d’une bibliothèque contenant une classe et d’une référence à celle-ci dans les paramètres du projet, vous pouvez ajouter le mappage de préfixe suivant dans le cadre de votre élément racine en XAML :

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

Pour le mettre ensemble, voici le code XAML qui inclut le mappage personnalisé ainsi que les mappages par défaut et x : typiques dans la balise racine, puis utilise une référence préfixée pour instancier ExampleClass dans cette interface utilisateur :

<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>

Mappage aux assemblys actuels

assembly pouvez être omis si la clr-namespace référencée est définie dans le même assembly que le code d’application qui référence les classes personnalisées. Ou, une syntaxe équivalente pour ce cas consiste à spécifier assembly=, sans élément de chaîne suivant le signe égal.

Les classes personnalisées ne peuvent pas être utilisées comme élément racine d’une page si elles sont définies dans le même assembly. Les classes partielles n’ont pas besoin d’être mappées ; seules les classes qui ne sont pas la classe partielle d’une page de votre application doivent être mappées si vous envisagez de les référencer en tant qu’éléments en XAML.

Mappage d’espaces de noms CLR à des espaces de noms XML dans un assembly

WPF définit un attribut CLR consommé par des processeurs XAML afin de mapper plusieurs espaces de noms CLR à un espace de noms XAML unique. Cet attribut, XmlnsDefinitionAttribute, est placé au niveau de l’assembly dans le code source qui produit ce dernier. Le code source de l’assembly WPF utilise cet attribut pour mapper les différents espaces de noms communs, tels que System.Windows et System.Windows.Controls, à l’espace de noms http://schemas.microsoft.com/winfx/2006/xaml/presentation.

Le XmlnsDefinitionAttribute prend deux paramètres : le nom de l’espace de noms XML/XAML et le nom de l’espace de noms CLR. Plusieurs XmlnsDefinitionAttribute peuvent exister pour mapper plusieurs espaces de noms CLR au même espace de noms XML. Une fois mappés, les membres de ces espaces de noms peuvent également être référencés sans qualification complète, si vous le souhaitez, en fournissant l’instruction using appropriée dans la page code-behind de la classe partielle. Pour plus d’informations, consultez XmlnsDefinitionAttribute.

Espaces de noms concepteurs et autres préfixes de modèles XAML

Si vous utilisez des environnements de développement et/ou des outils de conception pour WPF XAML, vous remarquerez peut-être qu’il existe d’autres espaces de noms /préfixes XAML définis dans le balisage XAML.

Le concepteur WPF pour Visual Studio utilise un espace de noms de concepteur qui est généralement mappé au préfixe d:. Les modèles de projet plus récents pour WPF peuvent pré mapper cet espace de noms XAML pour prendre en charge l’échange du code XAML entre le concepteur WPF pour Visual Studio et d’autres environnements de conception. Cet espace de noms de conception XAML permet de perpétuer l’état de conception lors de l’échange bidirectionnel d’interfaces utilisateur basées sur XAML dans le concepteur. Il est également utilisé pour des fonctionnalités telles que d:IsDataSource, qui activent les sources de données d’exécution dans un environnement de conception.

Un autre préfixe que vous pouvez voir mappé est mc:. mc: concerne la compatibilité des balisages et tire parti d’un modèle de compatibilité de balisage qui n’est pas nécessairement spécifique au code XAML. Dans une certaine mesure, les fonctionnalités de compatibilité du balisage peuvent être utilisées pour échanger XAML entre les infrastructures ou sur d’autres limites d’implémentation de stockage pour travailler entre des contextes de schémas XAML, fournir la compatibilité pour des modes limités dans les concepteurs, etc. Pour plus d’informations sur les concepts de compatibilité du balisage et leurs rapports à WPF, consultez Fonctionnalités de langage pour la compatibilité du balisage (mc:).

WPF et chargement des assemblys

Le contexte de schéma XAML pour WPF s’intègre au modèle d’application WPF, qui utilise à son tour le concept CLR défini par AppDomain. La séquence suivante décrit comment le contexte de schéma XAML interprète le chargement des assemblies ou la recherche des types à l'exécution ou à la conception, en fonction de l'utilisation par WPF de AppDomain et d'autres facteurs.

  1. Itérez au sein de AppDomain, en recherchant un assembly déjà chargé qui correspond à tous les aspects du nom en commençant par l’assembly le plus récemment chargé.

  2. Si le nom est qualifié, appelez Assembly.Load(String) sur le nom qualifié.

  3. Si la combinaison nom court + jeton de clé publique d’un nom qualifié correspond à l’assembly à partir duquel le balisage a été chargé, renvoyez cet assembly.

  4. Utilisez le nom court + jeton de clé publique pour appeler Assembly.Load(String).

  5. Si le nom n’est pas qualifié, appelez Assembly.LoadWithPartialName.

Le XAML libre n’utilise pas l’étape 3 ; il n’y a pas de chargement à partir de l’assembly.

Le code XAML compilé pour WPF (généré via XamlBuildTask) n’utilise pas les assemblys déjà chargés à partir de AppDomain (étape 1). En outre, le nom ne doit jamais être non qualifié à partir de la sortie de XamlBuildTask ; donc l’étape 5 ne s’applique pas.

La bibliothèque BAML compilée (générée via PresentationBuildTask) utilise toutes les étapes, bien que BAML ne contienne pas non plus de noms d’assembly non qualifiés.

Voir aussi

  • Last updated on