Vue d'ensemble WPF Add-Ins

Le .NET Framework inclut un modèle de complément que les développeurs peuvent utiliser pour créer des applications qui prennent en charge l’extensibilité du complément. Ce modèle de complément permet la création de compléments qui s’intègrent aux fonctionnalités d’application et étendent celles-ci. Dans certains scénarios, les applications doivent également afficher des interfaces utilisateur fournies par des compléments. Cette rubrique montre comment WPF augmente le modèle de complément .NET Framework pour activer ces scénarios, l’architecture derrière elle, ses avantages et ses limitations.

Conditions préalables

La connaissance du modèle d'extension .NET Framework est requise. Pour plus d’informations, consultez Compléments et extensibilité.

Vue d’ensemble de Add-Ins

Afin d’éviter les complexités de la recompilation et du redéploiement d’applications pour incorporer de nouvelles fonctionnalités, les applications implémentent des mécanismes d’extensibilité qui permettent aux développeurs (à la fois à la fois tiers et tiers) de créer d’autres applications qui s’intègrent avec eux. La façon la plus courante de prendre en charge ce type d’extensibilité consiste à utiliser des compléments (également appelés « modules complémentaires » et « plug-ins »). Voici quelques exemples d’applications réelles qui exposent l’extensibilité avec des compléments :

• Modules complémentaires Internet Explorer.

• Plug-ins du lecteur Windows Media.

• Compléments Visual Studio.

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

Les trois principales entités des solutions d’extensibilité de complément standard sont contrats, compléments et applications hôtes. Les contrats définissent comment les compléments s’intègrent aux applications hôtes de deux façons :

• Les compléments s’intègrent aux fonctionnalités implémentées par les applications hôtes.

• Les applications hôtes exposent des fonctionnalités afin que les compléments puissent s'intégrer.

Pour que les compléments soient utilisés, les applications hôtes doivent les trouver et les charger au moment de l’exécution. Par conséquent, les applications qui prennent en charge les compléments ont les responsabilités supplémentaires suivantes :

• Découverte : recherche de compléments qui respectent les contrats pris en charge par les applications hôtes.

• Activation : chargement, exécution et établissement de la communication avec les compléments.

• Isolation : utilisation de domaines d’application ou de processus pour établir des limites d’isolation qui protègent les applications contre les problèmes potentiels de sécurité et d’exécution avec les compléments.

• Communication : Permettre aux compléments et aux applications hôtes de communiquer entre eux à travers des frontières d'isolation en appelant des méthodes et en transmettant des données.

• Gestion de la durée de vie : chargement et déchargement des domaines et processus d’application de manière propre et prévisible (voir Domaines d’application).

• Contrôle de version : s’assurer que les applications hôtes et les compléments peuvent toujours communiquer lorsque de nouvelles versions de l’une ou l’autre sont créées.

En fin de compte, le développement d’un modèle de complément robuste est une entreprise non triviale. Pour cette raison, .NET Framework fournit une infrastructure permettant de créer des modèles de complément.

Vue d’ensemble du modèle Add-In .NET Framework

Le modèle de complément .NET Framework, dans l'espace de noms System.AddIn, contient un ensemble de types conçus pour simplifier le développement de l'extensibilité des compléments. L’unité fondamentale du modèle de complément .NET Framework est le contrat, qui définit la façon dont une application hôte et un complément communiquent entre eux. Un contrat est exposé à une application hôte à l’aide d’une vue du contrat spécifique à l’application hôte. De même, une vue spécifique au module complémentaire du contrat est exposée au module complémentaire. Un adaptateur permet à 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 ensemble de segments connexes constitue un pipeline. Les pipelines sont la base sur laquelle le modèle de complément .NET Framework prend en charge la découverte, l’activation, l’isolation de la sécurité, l’isolation de l’exécution (à l’aide de domaines d’application et de processus), la communication, la gestion de la durée de vie et le contrôle de version.

La somme de cette prise en charge permet aux développeurs de créer des compléments qui s’intègrent aux fonctionnalités d’une application hôte. Toutefois, certains scénarios nécessitent que les applications hôtes affichent les interfaces utilisateur fournies par les compléments. Étant donné que chaque technologie de présentation du .NET Framework a son propre modèle pour implémenter des interfaces utilisateur, le modèle de complément .NET Framework ne prend pas en charge une technologie de présentation particulière. Au lieu de cela, WPF étend le modèle de module complémentaire .NET Framework avec prise en charge de l'UI pour les modules complémentaires.

Add-Ins WPF

WPF, conjointement avec le modèle de complément .NET Framework, vous permet de traiter un large éventail de scénarios qui nécessitent des applications hôtes pour afficher des interfaces utilisateur à partir de compléments. En particulier, ces scénarios sont traités par WPF avec les deux modèles de programmation suivants :

1. Le complément retourne une interface utilisateur. Un complément retourne une interface utilisateur à l’application hôte via un appel de méthode, tel que 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 qui existent uniquement au moment de l’exécution, telles que les rapports générés dynamiquement.

   • L’interface utilisateur pour les 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 effectue principalement un service pour l’application hôte et signale l’état à l’application hôte avec une interface utilisateur.

2. Le complément est une interface utilisateur. Un complément est une interface utilisateur, telle que définie par le contrat. Ce scénario est utilisé dans les cas suivants :

   • Un complément ne fournit pas de services autres que ceux affichés, tels qu’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 nécessitent que les objets d’interface utilisateur puissent être transmis entre l’application hôte et les domaines d’application de complément. Étant donné que le modèle de complément .NET Framework s’appuie sur la communication à distance pour communiquer entre les domaines d’application, les objets passés entre eux doivent être accessibles à distance.

Un objet remotable 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 est appliqué.

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

1. WPF exige que les interfaces utilisateur fournies par des compléments sont des classes qui dérivent directement ou indirectement de FrameworkElement, telles que des formes, des contrôles, des contrôles utilisateur, des panneaux de disposition et des pages.

2. Chaque fois que le contrat déclare qu'une interface utilisateur sera passée entre le complément et l'application hôte, elle doit être déclarée comme une INativeHandleContract (et non comme une FrameworkElement); INativeHandleContract est une représentation à distance de l’interface utilisateur du complément qui peut être transmise entre les frontières d'isolation.

3. Avant d’être transmis à partir du domaine d’application du complément, un FrameworkElement est empaqueté en tant que INativeHandleContract, par un appel à ViewToContractAdapter.

4. Après avoir été transmis au domaine d'application de l'application hôte, INativeHandleContract doit être reconditionné en FrameworkElement en appelant ContractToViewAdapter.

La façon dont INativeHandleContract, ContractToViewAdapteret ViewToContractAdapter sont utilisées dépend du scénario spécifique. Les sections suivantes fournissent des détails pour chaque modèle de programmation.

Add-In retourne une interface utilisateur

Pour qu’un complément retourne une interface utilisateur à une application hôte, les éléments suivants sont requis :

1. L’application hôte, le complément et le pipeline doivent être créés, comme décrit par la documentation sur les compléments et l’extensibilité .NET Framework.

2. Le contrat doit implémenter IContract et, pour retourner une interface utilisateur, le contrat doit déclarer une méthode avec une valeur de retour de type INativeHandleContract.

3. L’interface utilisateur passée entre le complément et l’application hôte doit dériver directement ou indirectement de FrameworkElement.

4. L'interface utilisateur retournée par le complément doit être convertie d'un FrameworkElement à un INativeHandleContract avant de traverser la limite d'isolation.

5. L’interface utilisateur retournée doit être convertie d’un INativeHandleContract à un FrameworkElement après avoir franchi la limite d’isolation.

6. L’application hôte affiche le retour FrameworkElement.

Pour obtenir un exemple qui montre comment implémenter un complément qui retourne une interface utilisateur, consultez Créer un Add-In qui renvoie une interface utilisateur.

Add-In est une interface utilisateur

Lorsqu’un complément est une interface utilisateur, les éléments suivants sont requis :

1. L’application hôte, le complément et le pipeline doivent être créés, comme décrit par la documentation sur les compléments et l’extensibilité .NET Framework.

2. L’interface de contrat pour le complément doit implémenter INativeHandleContract.

3. Le complément passé à l’application hôte doit dériver directement ou indirectement de FrameworkElement.

4. Le complément doit être converti d’un FrameworkElement à un INativeHandleContract avant de traverser la limite d’isolation.

5. Le complément doit être converti d’un INativeHandleContract à un FrameworkElement après avoir franchi la limite d’isolation.

6. L’application hôte affiche le retour FrameworkElement.

Pour obtenir un exemple qui montre comment implémenter un complément sous forme d'interface utilisateur, consultez Créer un Add-In sous forme d'interface utilisateur.

Retour de plusieurs interfaces utilisateur à partir d’un Add-In

Les compléments fournissent souvent plusieurs interfaces utilisateur pour que les applications hôtes s’affichent. Par exemple, considérez un complément qui est une interface utilisateur qui fournit également des informations d’état à l’application hôte, également en tant qu’interface utilisateur. Un complément tel que celui-ci peut être implémenté à l’aide d’une combinaison de techniques provenant de la Add-In Renvoie une interface utilisateur et Add-In Est un modèle d’interface utilisateur .

applications de navigateur Add-Ins et XAML

Dans les exemples jusqu’à présent, l’application hôte a été une application autonome installée. Toutefois, les applications de navigateur XAML (XBAPs) peuvent également héberger des compléments, mais avec les exigences de build et d’implémentation supplémentaires suivantes :

• Le manifeste de l’application XBAP doit être spécialement configuré pour télécharger le pipeline (dossiers et assemblages) ainsi que l'assemblage de complément dans le cache d'application ClickOnce sur l'ordinateur client, dans le même dossier que le XBAP.

• Le code XBAP pour découvrir et charger les compléments doit utiliser le cache d'application ClickOnce pour le XBAP comme pipeline et emplacement des compléments.

• Le XBAP doit charger le complément dans un contexte de sécurité spécial si le complément fait référence à des fichiers libres situés sur le site d’origine ; lorsqu’ils sont hébergés par des XBAPs, les compléments ne peuvent référencer que des fichiers libres situés sur le 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 des Add-In pour le déploiement ClickOnce

Les XBAPs sont téléchargés et exécutés à partir d’un dossier sécurisé dans le cache de déploiement ClickOnce. Pour qu’un XBAP héberge un complément, le pipeline et l’assembly du complément doivent également être téléchargés dans le dossier sécurisé. Pour ce faire, vous devez configurer le manifeste de l’application pour inclure à la fois le pipeline et l’assembly de complément à télécharger. Cela s’effectue le plus facilement dans Visual Studio, bien que le pipeline et l’assembly de complément doivent se trouver dans le dossier racine du projet XBAP hôte afin que Visual Studio détecte les assemblys de pipeline.

Par conséquent, la première étape consiste à générer l’assembly de pipeline et de complément à la racine du projet XBAP en définissant la sortie de build de chaque assembly de pipeline et projets d’assembly de complément. Le tableau suivant montre les chemins de sortie de compilation pour les projets d'assemblage de pipeline et le projet d'assemblage de module complémentaire qui se trouvent dans le même dossier de solution et racine que le projet XBAP hôte.

Tableau 1 : Chemins de sortie de build pour les assemblies de pipeline hébergés par une application XBAP

L’étape suivante consiste à spécifier les assemblys de pipeline et l’assembly de complément en tant que fichiers de contenu XBAPs dans Visual Studio en procédant comme suit :

1. Pour inclure l'assemblage de pipeline et de complément dans le projet, cliquez avec le bouton droit sur chaque dossier de pipeline dans l'Explorateur de solutions et choisissez Inclure dans le projet.

2. Définir l’action de génération de chaque assembly de pipeline et de l’assembly de complément sur Contenu depuis la fenêtre Propriétés.

La dernière étape consiste à configurer le manifeste de l’application pour inclure les fichiers d’assembly de pipeline et le fichier d’assembly de complément à télécharger. Les fichiers doivent se trouver dans des dossiers à la racine du dossier dans le cache ClickOnce occupé par l’application XBAP. La configuration peut être obtenue dans Visual Studio en procédant comme suit :

1. Cliquez avec le bouton droit sur le projet XBAP, cliquez sur Propriétés, cliquez sur Publier, puis sur le bouton Fichiers d’application .

2. Dans la boîte de dialogue Fichiers d’application , définissez l’état de publication de chaque DLL de pipeline et de complément sur Include (Auto) et définissez le groupe de téléchargement pour chaque DLL de pipeline et de complément sur (obligatoire).

Utilisation du pipeline et du Add-In à partir de l'Application Base

Lorsque le pipeline et le complément sont configurés pour le déploiement ClickOnce, ils sont téléchargés dans le même dossier de cache ClickOnce que le XBAP. Pour utiliser le pipeline et le module complémentaire à partir du XBAP, le code XBAP doit les récupérer depuis la base de l'application. Les différents types et membres du modèle d'extension .NET Framework pour l’utilisation de pipelines et de compléments offrent un support spécifique pour ce scénario. Tout d’abord, le chemin d’accès est identifié par la valeur d’énumération ApplicationBase . Vous utilisez cette valeur avec des surcharges des membres de complément pertinents pour utiliser des pipelines qui incluent les éléments suivants :

• AddInStore.FindAddIns(Type, PipelineStoreLocation)

• AddInStore.FindAddIns(Type, PipelineStoreLocation, String[])

• AddInStore.Rebuild(PipelineStoreLocation)

• AddInStore.Update(PipelineStoreLocation)

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

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

WPF Add-In Architecture

Au niveau le plus élevé, comme nous l’avons vu, WPF permet aux compléments .NET Framework d’implémenter des interfaces utilisateur (qui dérivent directement ou indirectement de FrameworkElement) à l’aide de INativeHandleContract, ViewToContractAdapter et ContractToViewAdapter. Le résultat est que l'application hôte reçoit un FrameworkElement, qui est affiché dans l'interface utilisateur de l'application hôte.

Pour les scénarios de complément d’interface utilisateur simples, il s’agit autant de détails qu’un développeur en a besoin. Pour les scénarios plus complexes, en particulier ceux qui tentent d’utiliser des services WPF supplémentaires tels que la disposition, les ressources et la liaison de données, des connaissances plus détaillées sur la façon dont WPF étend le modèle de complément .NET Framework avec prise en charge de l’interface utilisateur est nécessaire pour 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 pour l’interface utilisateur à l’aide de l’interopérabilité WPF. Par conséquent, lorsqu’une interface utilisateur à partir d’un complément est passée à une application hôte, les événements suivants se produisent :

• Du côté du module complémentaire, WPF acquiert une poignée 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 qui dérive de HwndSource et implémente INativeHandleContract. Une instance de cette classe est retournée par ViewToContractAdapter, et est transférée du domaine d’application du module externe vers le domaine d’application de l’application hôte.

• Côté application hôte, WPF repackage le HwndSource sous forme de classe WPF interne qui dérive 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 des descripteurs de fenêtre, à partir des interfaces utilisateur WPF. Pour plus d’informations, consultez WPF et Win32 Interoperation.

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

Par sa nature, HwndHost certaines limitations affectent la façon dont les applications hôtes peuvent les utiliser. Toutefois, WPF s'enrichit de plusieurs fonctionnalités pour les scénarios de complément HwndHost. Ces avantages et limitations sont décrits ci-dessous.

Avantages WPF Add-In

Étant donné que les interfaces utilisateur du complément WPF sont affichées à partir d'applications hôtes à l'aide d'une classe interne qui dérive de HwndHost, ces interfaces utilisateur sont limitées par les fonctionnalités de HwndHost en ce qui concerne les services d'interface utilisateur WPF tels que la disposition, le rendu, la liaison de données, les styles, les modèles et les ressources. Toutefois, WPF augmente sa sous-classe interne HwndHost avec des fonctionnalités supplémentaires qui incluent les éléments suivants :

• Navigation entre l’interface utilisateur d’une application principale et l’interface utilisateur d’un complément. Notez que le modèle de programmation « complément (add-in) pour l'interface utilisateur » nécessite que l’adaptateur côté complément surclasse QueryContract pour activer la tabulation, que le complément soit entièrement approuvé ou partiellement approuvé.

• Respect des exigences d’accessibilité pour les interfaces utilisateur de complément affichées à partir des interfaces utilisateur de l’application hôte.

• Activation des applications WPF pour s’exécuter en toute sécurité dans plusieurs scénarios de domaine d’application.

• Prévenir l’accès illégal aux gestions de fenêtre de l’interface utilisateur du complément lorsque les compléments s’exécutent avec un isolement de sécurité (autrement dit, un environnement de sécurité à confiance partielle). L’appel ViewToContractAdapter garantit cette sécurité :

  • Pour le modèle de programmation « complément retourne une interface utilisateur », la seule façon de passer le handle de la fenêtre de l'interface utilisateur du complément au-delà de la limite d’isolation consiste à appeler ViewToContractAdapter.

  • Pour le modèle de programmation « complément est une interface utilisateur », il est nécessaire de remplacer la méthode QueryContract dans l’adaptateur côté complément et d’appeler ViewToContractAdapter (comme dans les exemples précédents), ainsi que d'appeler l’implémentation de QueryContract de l’adaptateur côté complément depuis l’adaptateur côté hôte.

• Fourniture de plusieurs protections d’exécution de domaine d’application. En raison de limitations liées aux domaines d'application, les exceptions non gérées levées dans les domaines d'application d'extension provoquent l'arrêt brutal de l'application entière, même si la limite d'isolation existe. Toutefois, WPF et le modèle de complément .NET Framework offrent un moyen simple de contourner ce problème et d’améliorer la stabilité de l’application. Un complément WPF qui affiche une interface utilisateur crée un Dispatcher, associé au thread sur lequel le domaine d'application s'exécute, 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 UnhandledExceptionDispatcherdu complément WPF. Vous pouvez obtenir le Dispatcher à partir de la propriété CurrentDispatcher.

WPF Add-In Limitations

Au-delà des avantages que WPF ajoute aux comportements par défaut fournis par HwndSource, HwndHostet les handles de fenêtre, il existe également des limitations pour les interfaces utilisateur de complément affichées à partir d’applications hôtes :

• Les interfaces utilisateur de complément affichées par une application hôte ne respectent pas le comportement de recadrage de l'application hôte.

• Le concept d’espace aérien dans les scénarios d’interopérabilité s’applique également aux compléments (voir Vue d’ensemble des régions technologiques).

• Les services d’interface utilisateur d’une application hôte, tels que l’héritage des ressources, la liaison de données et la commande, ne sont pas automatiquement disponibles pour les interfaces utilisateur de complément. Pour fournir ces services au complément, vous devez mettre à jour le pipeline.

• Une interface utilisateur de complément ne peut pas être pivotée, mise à l’échelle, inclinée ou autrement modifiée par une transformation (voir Vue d’ensemble des transformations).

• Le contenu à l'intérieur des interfaces utilisateur du complément, rendu par des opérations de dessin provenant de l'espace de noms System.Drawing, peut inclure un mélange alpha. Toutefois, l’interface utilisateur d’un complément et l’interface utilisateur de l’application hôte qui le contient doivent être 100% opaques ; en d’autres termes, la Opacity propriété sur les deux doit être définie sur 1.

• Si la AllowsTransparency propriété d’une fenêtre dans l’application hôte qui contient une interface utilisateur de module complémentaire est définie sur true, le module complémentaire est invisible. Cela est vrai même si l’interface utilisateur du complément est de 100% opaque (autrement dit, la Opacity propriété a la valeur 1).

• Une interface utilisateur de complément doit apparaître sur 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 rendue à l’aide d’un VisualBrush. Au lieu de cela, le complément peut prendre un instantané de l’interface utilisateur générée pour 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édias ne peuvent pas être lus à partir d’une MediaElement interface utilisateur de complément.

• Les événements de souris générés pour l’interface utilisateur du module complémentaire ne sont ni reçus ni déclenchés par l’application hôte, et la propriété de l'interface utilisateur IsMouseOver de l’application hôte a la valeur false.

• Lorsque le focus se déplace entre les contrôles d’une interface utilisateur de complément, les événements GotFocus et LostFocus ne sont ni reçus ni émis par l’application hôte.

• La partie d’une application hôte qui contient une interface utilisateur de complément s’affiche en blanc lors de l’impression.

• Tous les répartiteurs (voir Dispatcher) créés par l'interface utilisateur du module complémentaire doivent être fermés manuellement avant que le module complémentaire propriétaire ne soit déchargé si l'application hôte continue son exécution. Le contrat peut implémenter des méthodes permettant à l'application hôte de notifier le complément avant qu'il ne soit déchargé, afin que l'interface utilisateur du complément puisse arrêter ses répartiteurs.

• Si l'interface utilisateur d'un complément est une InkCanvas ou contient un InkCanvas, vous ne pouvez pas 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 de cette application. Par conséquent, le temps nécessaire à la création de nouveaux domaines d’application et au démarrage d’applications peut affecter les performances. Toutefois, le .NET Framework vous permet de réduire les temps de démarrage en demandant aux applications de partager des assemblys entre les domaines d’application s’ils sont déjà chargés. Pour ce faire, utilisez l’attribut LoaderOptimizationAttribute , qui doit être appliqué à la méthode de point d’entrée (Main). Dans ce cas, vous devez utiliser uniquement du code pour implémenter votre définition d’application (voir Vue d’ensemble de la gestion des applications).

Voir aussi

• LoaderOptimizationAttribute
• Compléments et extensibilité
• Domaines d’application
• Vue d’ensemble de la communication à distance .NET Framework
• Création d’objets à distance
• Sujets de type "comment faire"