Vue d'ensemble des compléments Windows Presentation Foundation

Article
08/22/2008

Mise à jour : novembre 2007

Le .NET Framework inclut un modèle de complément que les développeurs peuvent utiliser pour créer des applications prenant en charge l'extensibilité des compléments. Ce modèle de complément permet la création de compléments qui s'intègrent aux fonctionnalités des applications et les étendent. Dans certains scénarios, les applications doivent également afficher les interfaces utilisateur fournies par les compléments. Cette rubrique montre comment WPF optimise le modèle de complément .NET Framework pour prendre en charge ces scénarios, l'architecture sur laquelle ils s'appuient, ses avantages et ses limitations.

Cette rubrique comprend les sections suivantes.

Composants requis
Exemples
Vue d'ensemble des compléments
Vue d'ensemble du modèle de complément .NET Framework
Compléments WPF
Le complément retourne une interface utilisateur
Le complément est une interface utilisateur
Retour de plusieurs interfaces utilisateur à partir d'un complément
Compléments et applications du navigateur XAML
Architecture des compléments WPF
Avantages des compléments WPF
Limitations des compléments WPF
Optimisation des performances
Rubriques connexes

Composants requis

Il convient de connaître le modèle de complément .NET Framework. Pour plus d'informations, consultez Vue d'ensemble des compléments.

Exemples

Cette rubrique s'appuie sur les exemples suivants pour montrer comment WPF étend le modèle de complément .NET Framework :

Complément qui retourne une interface utilisateur, exemple, couvert dans la section Le complément retourne une interface utilisateur de cette rubrique.
Complément qui est une interface utilisateur, exemple, couvert dans la section Le complément est une interface utilisateur de cette rubrique.
Complément fournissant plusieurs interfaces utilisateur, exemple, couvert dans la section Retour de plusieurs interfaces utilisateur à partir d'un complément de cette rubrique.
Complément avec un XBAP comme application hôte, exemple, couvert dans la section Compléments et applications du navigateur XAML de cette rubrique.

Vue d'ensemble des compléments

Pour éviter la complexité qu'impliquent le redéploiement et la recompilation d'applications en vue d'incorporer les nouvelles fonctionnalités, les applications mettent en œuvre des mécanismes d'extensibilité qui permettent aux développeurs (tant internes que tiers) de créer d'autres applications qui s'y intègrent. La méthode la plus courante de prise en charge de ce type d'extensibilité consiste à utiliser des compléments (également appelés « modules complémentaires », « add-ins » et « plug-ins »). Voici quelques exemples d'applications réelles qui exposent l'extensibilité avec des compléments :

Modules complémentaires d'Internet Explorer
Plug-ins Windows Media Player.
Compléments Visual Studio.

Par exemple, le modèle de complément Windows Media Player permet aux développeurs tiers d'implémenter des « plug-ins » qui étendent cette application de différentes façons, notamment en créant des décodeurs et des codeurs des formats multimédias qui ne sont pas pris en charge en mode natif par Windows Media Player (par exemple, DVD, MP3), des effets audio et des apparences. Chaque modèle de complément est construit pour exposer les fonctionnalités uniques d'une application, bien que plusieurs entités et comportements soient communs à tous les modèles de compléments.

Les trois principales entités de solutions d'extensibilité des compléments classiques sont les contrats, les compléments et les applications hôtes. Les contrats définissent la manière dont les compléments s'intègrent aux applications hôtes de deux manières :

Les compléments s'intègrent aux fonctionnalités implémentées par les applications hôtes.
Les applications hôtes exposent les fonctionnalités des compléments auxquels elles s'intègrent.

Pour pouvoir utiliser des compléments, les applications hôtes doivent les rechercher et les charger au moment de l'exécution. Par conséquent, les applications qui prennent en charge des compléments ont les responsabilités supplémentaires suivantes :

Découverte : recherche de compléments adhérant aux contrats pris en charge par les applications hôte.
Activation : chargement, exécution et établissement de la communication avec les compléments.
Isolation : utilisation de domaines ou de processus d'application pour établir des limites d'isolation protégeant les applications des problèmes potentiels de sécurité et d'exécution avec les compléments.
Communication : autorisation pour les compléments et les applications d'hôte à communiquer entre eux au travers des limites d'isolation par des méthodes d'appel et le passage de données.
Gestion de la durée de vie : chargement et déchargement des domaines et des processus d'application de façon propre et prédictible (consultez Vue d'ensemble des domaines d'application).
Suivi des versions : garantie que les applications hôte et les compléments peuvent encore communiquer lorsque de nouvelles versions de l'un ou l'autre sont créées.

Enfin, le développement d'un modèle de complément fiable est une tâche non triviale. Pour cette raison, le .NET Framework fournit une infrastructure pour la génération de modèles de compléments.

Remarque :
Pour des informations détaillées sur les compléments, consultez Vue d'ensemble des compléments.

Vue d'ensemble du modèle de complément .NET Framework

Le modèle de complément .NET Framework, qui se trouve dans l'espace de noms System.AddIn, contient un jeu de types conçus pour simplifier le développement d'une extensibilité des compléments. L'unité fondamentale du modèle de complément .NET Framework est le contrat, qui définit la manière dont une application hôte et un complément communiquent l'un avec l'autre. Un contrat est exposé à une application hôte à l'aide d'une vue spécifique de l'application hôte du contrat. De même, une vue spécifique au complément du contrat est exposée au complément. Un adaptateur est utilisé pour permettre à une application hôte et un complément de communiquer entre leurs vues respectives du contrat. Les contrats, les vues et les adaptateurs sont appelés "segments" et un jeu de segments connexes constitue un pipeline. Les pipelines sont la fondation sur laquelle le modèle de complément .NET Framework prend en charge la découverte, l'activation, l'isolation de sécurité et l'isolation d'exécution (qui utilise aussi bien les domaines d'application que les processus), la communication, le management de la durée de vie et le suivi des versions.

Toutes ces prises en charge permettent aux développeurs de générer des compléments qui s'intègrent aux fonctionnalités d'une application hôte. Toutefois, certains scénarios requièrent que les applications hôtes affichent les interfaces utilisateur fournies par les compléments. Du fait que chaque technologie de présentation dans le .NET Framework a son propre modèle pour implémenter les interfaces utilisateur, le modèle de complément .NET Framework ne prend en charge aucune technologie de présentation particulière. Au lieu de cela, WPF étend le modèle de complément .NET Framework avec la prise en charge de l'interface utilisateur pour les compléments.

Compléments WPF

WPF, utilisé conjointement avec le modèle de complément .NET Framework, vous permet de prendre en charge divers scénarios nécessitant que les applications hôtes affichent les interfaces utilisateur à partir de compléments. Plus particulièrement, ces scénarios sont pris en charge par WPF avec les deux modèles de programmation suivants :

Le complément retourne une interface utilisateur. Un complément retourne une interface utilisateur à l'application hôte par le biais d'un appel de méthode, comme défini par le contrat. Ce scénario est utilisé dans les cas suivants :
- L'apparence d'une interface utilisateur retournée par un complément dépend des données ou des conditions existant uniquement au moment de l'exécution, par exemple les rapports générés dynamiquement.
- L'interface utilisateur des services fournis par un complément diffère de l'interface utilisateur des applications hôtes qui peuvent utiliser le complément.
- Le complément exécute principalement un service pour l'application hôte et signale l'état à cette dernière avec une interface utilisateur.
Le complément est une interface utilisateur. Un complément est une interface utilisateur, comme défini par le contrat. Ce scénario est utilisé dans les cas suivants :
- Un complément ne fournit pas de services autres que le fait d'être affiché, par exemple une publicité.
- L'interface utilisateur des services fournis par un complément est commune à toutes les applications hôtes qui peuvent utiliser ce complément, comme une calculatrice ou un sélecteur de couleurs.

Ces scénarios requièrent que les objets de l'interface utilisateur puissent être transmis entre les domaines des applications hôtes et des applications complémentaires. Étant donné que le modèle de complément .NET Framework repose sur l'accès distant pour communiquer entre des domaines d'applications, les objets échangés entre ces derniers doivent être accessibles à distance.

Un objet accessible à distance est une instance d'une classe qui effectue une ou plusieurs des opérations suivantes :

Dérive de la classe MarshalByRefObject.
Implémente l'interface ISerializable.
L'attribut SerializableAttribute lui est appliqué.

Remarque :
Pour plus d'informations sur la création d'objets .NET Framework accessibles à distance, consultez Rendre des objets accessibles à distance. Pour une vue d'ensemble de l'accès à distance, consultez Vue d'ensemble de l'accès distant .NET Framework.

Les types d'interface utilisateurWPF ne sont pas accessibles à distance. Pour résoudre ce problème, WPF étend le modèle de complément .NET Framework pour permettre l'affichage de l'interface utilisateur WPF créée par des compléments à partir d'applications hôtes. Cette prise en charge est fournie par deux types de WPF : l'interface INativeHandleContract et deux méthodes statiques implémentées par la classe FrameworkElementAdapters : ContractToViewAdapter et ViewToContractAdapter. À un niveau élevé, ces types et méthodes sont utilisés de la manière suivante :

WPF requiert que les interfaces utilisateur fournies par les compléments soient des classes directement ou indirectement dérivées de FrameworkElement, par exemple des formes, des contrôles, des contrôles utilisateur, des panneaux de disposition et des pages.
Chaque fois que le contrat déclare qu'une interface utilisateur sera transmise entre le complément et l'application hôte, elle doit être déclarée comme un INativeHandleContract (et non un FrameworkElement) ; INativeHandleContract est une représentation accessible à distance de l'interface utilisateur du complément qui peut être transmise à travers les limites d'isolation.
Avant d'être transmis à partir du domaine d'application du complément, un FrameworkElement est conditionné comme un INativeHandleContract en appelant ViewToContractAdapter.
Après avoir été transmis au domaine d'application de l'application hôte, le INativeHandleContract doit être reconditionné comme un FrameworkElement en appelant ContractToViewAdapter.

L'utilisation de INativeHandleContract, ContractToViewAdapter et ViewToContractAdapter dépend du scénario spécifique. Les sections suivantes décrivent chaque modèle de programmation.

Le complément retourne une interface utilisateur

Pour qu'un complément retourne une interface utilisateur à une application hôte, les conditions suivantes sont nécessaires :

L'application hôte, le complément et le pipeline doivent être créés, comme décrit dans la documentation de Compléments et extensibilité de .NET Framework.
Le contrat doit implémenter IContract et, pour retourner une interface utilisateur, il doit déclarer une méthode avec une valeur de retour de type INativeHandleContract.
L'interface utilisateur transmise entre le complément et l'application hôte doit dériver directement ou indirectement de FrameworkElement.
L'interface utilisateur retournée par le complément doit être convertie d'un FrameworkElement en un INativeHandleContract avant de passer par la limite d'isolation.
L'interface utilisateur retournée doit être convertie d'un INativeHandleContract en un FrameworkElement après être passée par la limite d'isolation.
L'application hôte affiche le FrameworkElement retourné.

Pour obtenir un exemple expliquant comment implémenter un complément qui retourne une interface utilisateur, consultez Comment : créer un complément qui retourne une interface utilisateur. Pour l'exemple complet, consultez Complément qui retourne une interface utilisateur, exemple.

Le complément est une interface utilisateur

Lorsqu'un complément est une interface utilisateur, les conditions suivantes sont nécessaires :

L'application hôte, le complément et le pipeline doivent être créés, comme décrit dans la documentation de Compléments et extensibilité de .NET Framework.
L'interface du contrat pour le complément doit implémenter INativeHandleContract.
Le complément transmis à l'application hôte doit dériver directement ou indirectement de FrameworkElement.
Le complément doit être converti d'un FrameworkElement en un INativeHandleContract avant de passer par la limite d'isolation.
Le complément doit être converti d'un INativeHandleContract en un FrameworkElement après être passé par la limite d'isolation.
L'application hôte affiche le FrameworkElement retourné.

Retour de plusieurs interfaces utilisateur à partir d'un complément

Les compléments proposent souvent plusieurs interfaces utilisateur affichables par les applications hôtes. Par exemple, supposons un complément qui est une interface utilisateur fournissant aussi des informations d'état à l'application hôte, également comme une interface utilisateur. Un complément de ce type peut être implémenté à l'aide d'une combinaison de techniques provenant des modèles Le complément retourne une interface utilisateur et Le complément est une interface utilisateur.

Pour obtenir un exemple complet illustrant cette implémentation, consultez Complément fournissant plusieurs interfaces utilisateur, exemple.

Compléments et applications du navigateur XAML

Dans les exemples présentés jusque-là, l'application hôte a été installée comme une application autonome. Toutefois, les applications du navigateur XAML (XBAP) peuvent également héberger des compléments, bien que ceux-ci s'accompagnent des conditions de création et d'implémentation supplémentaires suivantes :

Le manifeste de l'application XBAP doit être configuré spécialement pour télécharger le pipeline (dossiers et assemblys) et l'assembly de complément dans le cache de l'application ClickOnce sur l'ordinateur client, dans le même dossier que XBAP.
Le code de XBAP permettant de découvrir et de charger des compléments doit utiliser le cache de l'application ClickOnce pour XBAP comme l'emplacement du complément et du pipeline.
XBAP doit charger le complément dans un contexte de sécurité spécial si le complément fait référence à des fichiers à part qui se trouvent au site d'origine ; en cas d'hébergement par XBAP, les compléments ne peuvent faire référence qu'à des fichiers à part qui se trouvent au site d'origine de l'application hôte.

Ces tâches sont décrites en détail dans les sous-sections suivantes.

Remarque :
Pour l'implémentation complète d'un XBAP qui héberge un complément, consultez Complément avec un XBAP comme application hôte, exemple.

Configuration du pipeline et du complément pour un déploiement ClickOnce

Les XBAP sont téléchargés et exécutés dans un dossier sûr du cache de déploiement ClickOnce. Pour qu'un XBAP héberger un complément, le pipeline et l'assembly du complément doivent également être téléchargés dans ce dossier sûr. Pour cela, vous devez configurer le manifeste de l'application de sorte qu'il comprenne le pipeline et l'assembly du complément à télécharger. Cette opération peut être effectuée le plus facilement dans Visual Studio, bien que le pipeline et l'assembly du complément doivent se trouver dans le dossier racine du projet XBAP de l'hôte pour que Visual Studio puisse détecter les assemblys de pipeline.

Par conséquent, la première étape consiste à générer le pipeline et l'assembly du complément à la racine du projet XBAP en définissant la sortie de génération de chaque assembly de pipeline et projets d'assembly de complément. Le tableau suivant indique les chemins de sortie de génération des projets d'assembly de pipeline et de complément se trouvant dans le même dossier de solution et racine que le projet XBAP de l'hôte.

Tableau 1 : Chemins de sortie de la génération des assemblys de pipeline hébergés par un XBAP

Projet d'assembly de pipeline	Chemin de sortie de la génération
Contrat	..\HostXBAP\Contracts\
Vue de complément	..\HostXBAP\AddInViews\
Adaptateur côté complément	..\HostXBAP\AddInSideAdapters\
Adaptateur côté hôte	..\HostXBAP\HostSideAdapters\
Complément	..\HostXBAP\AddIns\WPFAddIn1

L'étape suivante consiste à spécifier les assemblys de pipeline et l'assembly de complément comme fichiers de contenu XBAP dans Visual Studio en effectuant les opérations suivantes :

Inclusion de l'assembly de pipeline et de complément dans le projet en cliquant avec le bouton droit sur chaque dossier de pipeline dans l'Explorateur de solutions et en choisissant Inclure dans le projet.
Affectation de la valeur Contenu à l'option Action de génération de chaque assembly de pipeline et de complément dans la fenêtre Propriétés.

La dernière étape consiste à configurer le manifeste de l'application de manière à inclure les fichiers d'assembly de pipeline et de complément à télécharger. Les fichiers doivent se trouver dans les dossiers à la racine du dossier du cache ClickOnce que l'application XBAP occupe. La configuration peut être effectuée dans Visual Studio en effectuant les opérations suivantes :

Cliquez avec le bouton droit sur le projet XBAP, puis cliquez sur Propriétés, Publier et enfin Fichiers d'application.
Dans la boîte de dialogue Fichiers d'application, attribuez aux options État de la publication et Groupe de téléchargement de chaque pipeline et DLL de complément les valeurs Inclure (Automatique) et (Requis), respectivement.

Utilisation du pipeline et du complément à partir de la base de l'application

Lorsque le pipeline et le complément sont configurés pour le déploiement de ClickOnce, ils sont téléchargés dans le même dossier de cache ClickOnce que XBAP. Pour utiliser le pipeline et le complément à partir de XBAP, le code de XBAP doit les obtenir à partir de la base de l'application. Les différents types et membres du modèle de complément .NET Framework permettant d'utiliser des pipelines et des compléments fournissent une prise en charge spéciale de ce scénario. Dans un premier temps, le chemin est identifié par la valeur d'énumération ApplicationBase. Vous utilisez cette valeur avec les surcharges des membres du complément adéquats permettant d'utiliser des pipelines incluant les éléments suivants :

Accès au site d'origine de l'hôte

Pour veiller à ce qu'un complément puisse référencer des fichiers à partir du site d'origine, le complément doit être chargé avec l'isolation de sécurité équivalente à l'application hôte. Ce niveau de sécurité est identifié par la valeur d'énumération AddInSecurityLevel.Host, et est transmis à la méthode Activate lorsqu'un complément est activé.

Architecture des compléments WPF

Au niveau le plus élevé, comme nous l'avons observé, WPF permet aux compléments .NET Framework d'implémenter des interfaces utilisateur (directement ou indirectement dérivées de FrameworkElement) à l'aide de INativeHandleContract, ViewToContractAdapter et ContractToViewAdapter. Il en résulte qu'un FrameworkElement est retourné à l'application hôte, affiché à partir de l'interface utilisateur dans l'application hôte.

Dans les scénarios de compléments d'interface utilisateur simples, ces détails sont tout ce dont un développeur a besoin. Dans des scénarios plus complexes, en particulier qui essaient d'utiliser des services WPF supplémentaires tels qu'une disposition, des ressources et la liaison de données, il convient d'avoir une connaissance plus approfondie de la manière dont WPF étend le modèle de complément .NET Framework avec la prise en charge de l'interface utilisateur afin de comprendre ses avantages et ses limitations.

Fondamentalement, WPF ne transmet pas d'interface utilisateur d'un complément à une application hôte ; au lieu de cela, WPF transmet le handle de fenêtre Win32 de l'interface utilisateur en utilisant l'interopérabilité WPF. Ainsi, lorsqu'une interface utilisateur est transmise d'un complément à une application hôte, les événements suivants se produisent :

Du côté complément, WPF acquiert un handle de fenêtre pour l'interface utilisateur qui sera affichée par l'application hôte. Le handle de fenêtre est encapsulé par une classe WPF interne dérivée de HwndSource et implémente INativeHandleContract. Une instance de cette classe est retournée par ViewToContractAdapter et est marshalée du domaine d'application du complément au domaine d'application de l'application hôte.
Du côté application hôte, WPF reconditionne le HwndSource comme une classe WPF interne dérivée de HwndHost et consomme INativeHandleContract. Une instance de cette classe est retournée par ContractToViewAdapter à l'application hôte.

HwndHost existe pour afficher les interfaces utilisateur, identifiées par les handles de fenêtre, à partir des interfaces utilisateur WPF. Pour plus d'informations, consultez Vue d'ensemble de l'interopérabilité WPF et Win32.

En résumé, INativeHandleContract, ViewToContractAdapter et ContractToViewAdapter existent pour permettre de transmettre le handle de fenêtre d'une interface utilisateur WPF d'un complément à une application hôte, où il est encapsulé par un HwndHost et l'interface utilisateur de l'application hôte est affichée.

Remarque :
Du fait qu'elle obtienne un HwndHost, l'application hôte ne peut pas convertir l'objet retourné par ContractToViewAdapter en le type en lequel elle est implémentée par le complément (par exemple, un UserControl).

De par sa nature, HwndHost a certaines limitations qui affectent la manière dont les applications hôtes peuvent l'utiliser. Toutefois, WPF étend HwndHost avec plusieurs fonctionnalités pour les scénarios complémentaires. Ces avantages et limitations sont décrits ci-dessous.

Avantages des compléments WPF

Étant donné que les interfaces utilisateur des compléments WPF sont affichées à partir des applications hôtes à l'aide d'une classe interne dérivée de HwndHost, ces interfaces utilisateur sont contraintes par les fonctionnalités de HwndHost en ce qui concerne les services de l'interface utilisateur WPF, comme les dispositions, les rendus, la liaison de données, les styles, les modèles et les ressources. Toutefois, WPF étend sa sous-classe HwndHost interne avec les fonctionnalités supplémentaires, notamment :

Tabulation entre l'interface utilisateur d'une application hôte et l'interface utilisateur d'un complément. Notez que le modèle de programmation "Le complément est une interface utilisateur" requiert que l'adaptateur côté complément remplace QueryContract pour permettre la tabulation, que le complément présente un niveau de confiance suffisant ou partiel.
Respect des spécifications d'accessibilité des interfaces utilisateur de compléments affichées à partir des interfaces utilisateur des applications hôtes.
Permettre aux applications WPF de s'exécuter sans risque dans plusieurs scénarios de domaines d'application.
Empêcher l'accès illégal aux handles de fenêtre de l'interface utilisateur des compléments lorsque ces derniers s'exécutent avec l'isolation de sécurité (autrement dit, un sandbox de sécurité présentant un niveau de confiance partiel). L'appel de ViewToContractAdapter garantit cette sécurité :
- Pour le modèle de programmation "Le complément retourne une interface utilisateur", le seul moyen de transmettre le handle de fenêtre de l'interface utilisateur d'un complément via la limite d'isolation consiste à appeler ViewToContractAdapter.
- Pour le modèle de programmation "Le complément est une interface utilisateur", il convient de remplacer QueryContract sur l'adaptateur côté complément et d'appeler ViewToContractAdapter (comme indiqué dans les exemples précédents), de même qu'il faut appeler l'implémentation QueryContract de l'adaptateur côté complément à partir de l'adaptateur côté hôte.
Fournir une protection contre l'exécution de plusieurs domaines d'application. Du fait des limitations qu'impliquent les domaines d'application, les exceptions non gérées qui sont renvoyées dans les domaines d'application complémentaires entraînent l'arrêt complet de l'application, y compris en présence d'une limite d'isolation. Toutefois, WPF et le modèle de complément .NET Framework offrent une solution simple à ce problème et améliorent la stabilité des applications. Un complément WPF qui affiche une interface utilisateur crée un Dispatcher pour le thread sur lequel s'exécute le domaine d'application, si l'application hôte est une application WPF. Vous pouvez détecter toutes les exceptions non gérées qui se produisent dans le domaine d'application en gérant l'événement UnhandledException du Dispatcher du complément WPF. Vous pouvez obtenir Dispatcher à partir de la propriété CurrentDispatcher.

Limitations des compléments WPF

Au-delà des avantages que WPF ajoute aux comportements par défaut fournis par HwndSource, HwndHost et les handles de fenêtre, les interfaces utilisateur de compléments affichées à partir d'applications hôtes impliquent également des limitations :

Les interfaces utilisateur de compléments affichées à partir d'une application hôte ne respectent pas le comportement de découpage de cette dernière.
Le concept d'espace de rendu dans les scénarios d'interopérabilité s'applique également aux compléments (consultez Interopérabilité de WPF : vue d'ensemble des zones de fenêtre et de l'espace de rendu).
Les services de l'interface utilisateur d'une application hôte, tels que l'héritage de ressources, la liaison de données les commandes, ne sont pas automatiquement disponibles pour l'interfaces utilisateur du complément. Pour fournir ces services au complément, vous devez mettre à jour le pipeline.
L'interface utilisateur d'un complément ne peut pas être pivotée, mise à l'échelle, inclinée ou transformée de quelque autre manière (consultez Vue d'ensemble des transformations).
Le contenu des interfaces utilisateur de compléments qui est restitué par des opérations de dessin à partir de l'espace de noms System.Drawing peut inclure une fusion alpha. Toutefois, l'interface utilisateur du complément ainsi que l'interface utilisateur de l'application hôte qui comprennent ce contenu doivent être opaques à 100 % ; en d'autres termes, la propriété Opacity doit avoir la valeur 1 dans les deux interfaces.
Si la propriété AllowsTransparency d'une fenêtre de l'application hôte qui contient une interface utilisateur de complément a la valeur true, le complément est alors invisible. Cette remarque s'applique même si l'interface utilisateur du complément est opaque à 100 % (autrement dit, la propriété Opacity a la valeur 1).
L'interface utilisateur d'un complément doit apparaître au-dessus d'autres éléments WPF dans la même fenêtre de niveau supérieur.
Aucune partie de l'interface utilisateur d'un complément ne peut être restituée à l'aide d'un VisualBrush. Au lieu de cela, le complément peut prendre une capture instantanée de l'interface utilisateur générée afin de créer une bitmap qui peut être transmise à l'application hôte à l'aide de méthodes définies par le contrat.
Les fichiers multimédia ne peuvent pas être lus à partir d'un MediaElement dans l'interface utilisateur d'un complément.
Les événements de souris générés pour l'interface utilisateur du complément ne sont ni reçus ni déclenchés par l'application hôte, et la propriété IsMouseOver de l'interface utilisateur de l'application hôte a la valeur false.
Lorsque le focus se déplace entre des contrôles dans l'interface utilisateur d'un complément, les événements GotFocus et LostFocus ne sont ni reçu ni déclenchés par l'application hôte.
La partie d'une application hôte qui contient l'interface utilisateur d'un complément apparaît en blanc à l'impression.
Tous les répartiteurs (consultez Dispatcher) créés par l'interface utilisateur du complément doivent être arrêtés manuellement avant que le complément propriétaire ne soit déchargé si l'exécution de l'application hôte se poursuit. Le contrat peut implémenter des méthodes qui permettent à l'application hôte de signaler le complément avant son déchargement, permettant ainsi à l'interface utilisateur du complément d'arrêter ses répartiteurs.
Si l'interface utilisateur d'un complément est un InkCanvas ou contient un InkCanvas, il n'est pas possible de décharger le complément.

Optimisation des performances

Par défaut, lorsque plusieurs domaines d'application sont utilisés, les différents assemblys .NET Framework requis par chaque application sont tous chargés dans le domaine des applications en question. En conséquence, le temps nécessaire à la création de domaines d'application et au démarrage des applications dans ces domaines peut affecter la performance. Toutefois, le .NET Framework offre un moyen de réduire le temps de démarrage en indiquant aux applications de partager des assemblys dans différents domaines d'application si ceux-ci sont déjà chargés. Pour ce faire, vous utilisez l'attribut LoaderOptimizationAttribute, qui doit être appliqué à la méthode de point d'entrée (Main). Dans ce cas, vous devez utiliser uniquement le code pour implémenter votre définition d'application (consultez Vue d'ensemble de la gestion d'applications).

Les exemples suivants, décrits précédemment, illustrent l'utilisation de LoaderOptimizationAttribute :

Voir aussi

Share via