Vue d'ensemble des compléments WPF
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 UIs 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
- 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 Compléments et extensibilité.
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 encodeurs 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 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.
.gif "Remarque") Remarque |
|---|
Pour des informations détaillées sur les compléments, consultez Compléments et extensibilité. |
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 UIs 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 UIs, 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'UI 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 UIs à 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 UI à 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 UI 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'UI des services fournis par un complément diffère de l'UI 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 UI.
Le complément est une interface utilisateur. Un complément est une UI, 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'UI 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'UI 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 la communication à distance 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 Making Objects Remotable. |
Les types d'UI WPF 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'UI 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 UIs 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'UI 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 UI à 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 UI, il doit déclarer une méthode avec une valeur de retour de type INativeHandleContract.
L'UI transmise entre le complément et l'application hôte doit dériver directement ou indirectement de FrameworkElement.
L'UI retournée par le complément doit être convertie d'un FrameworkElement en un INativeHandleContract avant de passer par la limite d'isolation.
L'UI 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 UI, consultez Comment : créer un complément qui retourne une interface utilisateur.
Le complément est une interface utilisateur
Lorsqu'un complément est une UI, 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é.
Pour obtenir un exemple expliquant comment implémenter un complément d'UI, consultez Comment : créer un complément qui est une interface utilisateur.
Retour de plusieurs interfaces utilisateur à partir d'un complément
Les compléments proposent souvent plusieurs UIs affichables par les applications hôtes. Par exemple, supposons un complément qui est une UI fournissant aussi des informations d'état à l'application hôte, également sous la forme d'une UI. 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.
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 XAML browser applications (XBAPs) 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 XBAPs, 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.
Configuration du pipeline et du complément pour un déploiement ClickOnce
Les XBAPs sont téléchargés et exécutés dans un dossier sûr du cache de déploiement ClickOnce. Pour qu'une application XBAP héberge 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 projet d'assembly de pipeline et 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 XBAPs 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 réalisé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 UIs (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'UI dans l'application hôte.
Dans les scénarios de compléments d'UI simples, ces détails sont tout ce dont un développeur a besoin. Dans des scénarios plus complexes, en particulier ceux 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 en intégrant la prise en charge de l'UI afin de comprendre ses avantages et ses limitations.
Fondamentalement, WPF ne transmet pas d'UI d'un complément à une application hôte ; au lieu de cela, WPF transmet le handle de fenêtre Win32 de l'UI en utilisant l'interopérabilité WPF. Ainsi, lorsqu'une UI 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'UI 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 UIs, identifiées par les handles de fenêtre, à partir des UIs WPF. Pour plus d'informations, consultez Interopérabilité WPF et Win32.
En résumé, INativeHandleContract, ViewToContractAdapter et ContractToViewAdapter existent pour permettre de transmettre le handle de fenêtre d'une UI WPF d'un complément à une application hôte, où il est encapsulé par un HwndHost et où l'UI 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 UIs des compléments WPF sont affichées à partir des applications hôtes à l'aide d'une classe interne dérivée de HwndHost, ces UIs sont contraintes par les capacités de HwndHost en ce qui concerne les services de l'UI 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 des fonctionnalités supplémentaires, notamment :
Tabulation entre l'UI d'une application hôte et l'UI d'un complément. Notez que le modèle de programmation "Le complément est une UI" 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 UIs de compléments affichées à partir des UIs 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'UI 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 UI", le seul moyen de transmettre le handle de fenêtre de l'UI d'un complément au-delà de la limite d'isolation consiste à appeler ViewToContractAdapter.
Pour le modèle de programmation "Le complément est une UI", 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 UI 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 le 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 UIs de compléments affichées à partir d'applications hôtes impliquent également des limitations :
Les UIs 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 Vue d'ensemble des régions de technologie).
Les services de l'UI 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'UIs du complément. Pour fournir ces services au complément, vous devez mettre à jour le pipeline.
L'UI 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 UIs 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'UI du complément ainsi que l'UI 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 UI de complément a la valeur true, le complément est alors invisible. Cette remarque s'applique même si l'UI du complément est opaque à 100 % (autrement dit, la propriété Opacity a la valeur 1).
L'UI 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'UI 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'UI 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'UI d'un complément.
Les événements de souris générés pour l'UI du complément ne sont ni reçus ni déclenchés par l'application hôte, et la propriété IsMouseOver de l'UI de l'application hôte a la valeur false.
Lorsque le focus se déplace entre des contrôles dans l'UI 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'UI d'un complément apparaît en blanc à l'impression.
Tous les répartiteurs (consultez Dispatcher) créés par l'UI 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'UI du complément d'arrêter ses répartiteurs.
Si l'UI 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).