Mettez des Add-ins dans votre application avec le Framework 3.5

Le modèle de développement proposé permet de découper le travail à effectuer en trois parties (trois types de tâches distinctes). Chaque partie sera prise en charge par un développeur différent (ce n'est pas une obligation, juste une possibilité de fractionner le travail). Vous aurez donc, par ordre de difficulté croissante.

Le développeur d'add-in. Un accent a été mis sur le besoin de faciliter au maximum le travail du développeur de compléments. Son seul souci doit être de coder les fonctionnalités de son add-in, pas de s'occuper des mécanismes de « versionning », d'isolation, etc. Ainsi, la création d'un add-in peut se résumer à ce bout de code :

    [AddIn("mon addin", Version = "1.0.0.0",)]
    public class monAddin : VueAddIn

Deux choses sont à noter. La première est l'ajout d'un tag AddIn (permettant de spécifier quelques métadonnées telles qu'une description, un numéro de version, etc.). La deuxième est qu'un add-in doit dériver d'une vue (Interface ou classe abstraite). Cette vue représente la façon dont l'add-in est vu par l'hôte (la façon dont l'hôte va se servir de l'add-in).

Le développeur de l'hôte. Celui-ci n'a pas un travail très difficile non plus. Il lui suffit de quelques lignes de codes pour découvrir, activer puis utiliser un add-in. Voici à peu près le code à utiliser :

IList<AddInToken> tokens = AddInStore.FindAddIns(typeof(AddInType), addinPath);

foreach(AddinToken token in tokens)
{
    AddInType addinInstance = token.Activate<AddInType>(AddInSecurityLevel.FullTrust);
}

Le développeur du pipeline. C'est ce dernier qui aura la tâche la plus délicate. Il devra développer un modèle permettant à l'hôte et à ses add-ins de communiquer entre eux, indépendamment de la version de l'un ou l'autre. Nous allons dans la prochaine partie détailler les différents composants du pipeline.

• Via des vues/types (au sens objet) et répertoires spécifiques.
• Lecture des métadonnées sans avoir besoin de charger ou activer l'add-in.
• Aucune déclaration (contrairement aux objets COM) n'a besoin d'être faite sur la machine pour ajouter un add-in à un hôte. Un simple copier/coller peut suffire.
• Le pipeline et les add-ins sont physiquement séparés (répertoires différents).

• Sélection du contexte d'isolation (utilisation d'un domaine d'application personnalisé ou création d'un nouveau / utilisation d'un processus différent).
• Création du pipeline en chargeant les assemblies correspondantes.
• Instanciation de l'add-in.
• L'add-in est retourné à l'hôte sous forme de vue.

• Entre l'hôte et l'add-in.
• Entre les add-ins.

• L'hôte peut à tout moment demander à décharger un add-in.
• Déchargement automatique lorsqu'il n'existe plus aucune référence à l'add-in dans l'hôte.

• Les add-ins doivent s'exécuter avec des permissions égales ou inférieures à celle de l'hôte.
• Une énumération permet de spécifier le niveau de sécurité accordé à l'add-in (Full Trust, Internet, Intranet).
• Possibilité de spécifier un ensemble personnalisé de permissions.

Créez un nouveau projet de type Bibliothèque de classes dans le dossier Partie_AddIn et nommez-le Addin.Vue.

Dans les propriétés du projet sous l'onglet Build, définissez le chemin de sortie sur ..\output\Pipeline\AddInViews.

La vue sera représentée par une classe abstraite et décorée par l'attribut AddInBase. Ajoutez une référence à System.AddIn.

using System.AddIn.Pipeline;

namespace Addin.Vue
{
    // Classe de base pour notre addin. 
    // Définit comment l'addin reçoit les appels de l'hôte
    [AddInBase]
    public abstract class VueAddInSauverDocCotéAddIn
    {
        public abstract bool EnregistrerDoc(String cheminFichier, String texte);
    }
}

Cette classe représente la classe de base des add-ins. Toute personne souhaitant développer un add-in pour notre éditeur devra faire dériver son add-in de cette classe. Tout ce que l'add-in connait de l'hôte se trouve dans cette classe. L'add-in sait simplement que l'hôte (via le pipeline) va l'appeler via la fonction EnregistrerDoc.

Chaque add-in dérive de la vue lui correspondant et sera déployé dans son propre répertoire.

Créez un nouveau projet de type Bibliothèque de classes dans le dossier Partie_AddIn\AddIns et nommez-le AddIn.TXT.

Dans les propriétés du projet sous l'onglet Build, définissez le chemin de sortie sur ..\output\Pipeline\AddIns\AddIn.TXT.

Attention à bien séparer les chemins de sortie des Add-ins. Si vous créez un deuxième Add-in (par exemple AddIn.PDF) celui -ci devra avoir pour chemin de sortie ..\output\Pipeline\AddIns\AddIn.PDF.

Ajoutez une référence à la vue (AddIn.Vue), mais veillez à mettre sa propriété Copy Local à FALSE (la dll de la vue ne doit pas être déployée avec l'add-in).

Ajoutez aussi une référence à System.AddIn.

Créez donc une classe SauverEnTXT qui dérive de la classe VueAddInSauverDocCotéAddIn et décorée par l'attribut AddIn. Ce dernier vous permet de spécifier les métadonnées de l'add-in. Il ne reste plus qu'à écrire le code de la méthode EnregistrerDoc.

using Addin.Vue;
using System.AddIn;
using System.IO;

namespace AddIn.TXT
{
    [AddIn("Format texte",
    Version = "1.0.0.0",
    Description = "AddIn permettant d'enregistrer un document sous format texte",
    Publisher = "Badger")]
    public class SauverEnTXT : VueAddInSauverDocCotéAddIn
    {
        public override bool EnregistrerDoc(string cheminFichier, string texte)
        {
            StreamWriter sw = File.CreateText(cheminFichier);
            sw.Write(texte);
            sw.Close();
            return true;
        }
    }
}

L'adaptateur côté add-in permet de convertir la vue de l'add-in pour qu'elle corresponde au Contrat.

Créez un nouveau projet de type Bibliothèque de classes dans le dossier Partie_AddIn et nommez-le AddIn.Adaptateurs. Vous y mettrez toutes les classes servant d'adaptateur pour les différentes versions des vues. Dans notre exemple nous n'aurons besoin que d'un seul adaptateur.

Dans les propriétés du projet sous l'onglet Build, définissez le chemin de sortie sur ..\output\Pipeline\AddInSideAdapters.

Ajoutez une référence à la vue (AddIn.Vue) et au contrat (Contrat), mais veillez à mettre leur propriété Copy Local à FALSE.

Ajoutez aussi des références à System.AddIn et System.AddIn.Contract.

Créez une classe AdaptateurVueAddInVersContratSauverDoc dérivant de ContractBase et implémentant le contrat IContratSauverDoc. N'oubliez pas de décorer la classe avec l'attribut AddInAdapter.

Créez ensuite un constructeur prenant en paramètre la vue qu'il est censé convertir (dans notre cas VueAddInSauverDocCotéAddIn) et gardez une référence à cette vue via un champ privé. Il ne reste plus qu'à écrire le code de la méthode EnregistrerDoc provenant du contrat que nous implémentons.

using System.AddIn.Pipeline;
using Addin.Vue;
using System.AddIn;

namespace AddIn.Adaptateurs
{
   // Encapsule une instance de VueAddInSauverDocCotéAddIn 
   // pour pouvoir l'exposer en tant que IContratSauverDoc
   [AddInAdapter]
   public class AdaptateurVueAddInVersContratSauverDoc : ContractBase, Contrats.IContratSauverDoc
   {
       private VueAddInSauverDocCotéAddIn _vue;
       
       // Constructeur avec un seul paramètre (l'addin) obligatoire
       public AdaptateurVueAddInVersContratSauverDoc(VueAddInSauverDocCotéAddIn vue)
       {
           this._vue = vue;
       }

       Bool EnregistrerDoc(string chemin, string texte)
       {
           return this._vue.EnregistrerDoc(chemin, texte);
       }
   }
}

La vue côté hôte définit la façon dont l'hôte voit l'add-in. Tout ce que l'hôte connait de l'add-in se trouve dans cette classe. L'hôte ne manipulera finalement que des types vue.

Créez un nouveau projet de type Bibliothèque de classes dans le dossier Partie_Hote et nommez-le Hote.Vue.

Dans les propriétés du projet sous l'onglet Build, définissez le chemin de sortie sur ..\output (au même niveau que l'hôte).

La vue que nous appellerons VueAddInSauverDocCotéHote sera représentée par une classe abstraite contenant les méthodes dont se servira l'hôte.

namespace Hote.Vue
{
    // Définit comment sera vu un addin (de type sauverDoc) par l'hôte
    public abstract class VueAddInSauverDocCotéHote
    {
        public abstract bool EnregistrerDoc(String cheminFichier, String texte);
    }

}

Il est chargé de convertir le contrat afin qu'il corresponde à ce que voit l'hôte (c'est-à-dire la vue).

Créez un nouveau projet de type Bibliothèque de classes dans le dossier Partie_Hote et nommez-le Hote.Adaptateurs. Vous y mettrez les différents adaptateurs dont vous aurez besoin. Dans notre cas nous n'en créerons qu'un seul.

Dans les propriétés du projet sous l'onglet Build, définissez le chemin de sortie sur ..\output\Pipeline\HostSideAdapters.

Ajoutez une référence à la vue (Hote.Vue) et au contrat (Contrat), mais veillez à mettre leur propriété Copy Local à FALSE (les dll du contrat et de la vue ne doivent pas être déployées avec l'adaptateur).

Ajoutez aussi des références à System.AddIn et System.AddIn.Contract.

Créez une classe AdaptateurContratSauverDocVersVueHote dérivant de la vue VueAddInSauverDocCotéHote. N'oubliez pas de décorer la classe avec l'attribut HostAdapter.

Créez ensuite un constructeur prenant en paramètre le contrat qu'il est censé convertir (dans notre cas IContratSauverDoc) et gardez-en une référence via un champ privé. Il ne reste plus qu'à implémenter la méthode abstraite EnregistrerDoc provenant de la vue dont nous dérivons.

using Hote.Vue;
using Contrats;
using System.AddIn.Pipeline;

namespace Hote.Adaptateurs
{    
    // Convertit une instance de type IContratSauverDoc afin de la rendre 
    // accessible à l'hôte 
    // (qui ne manipule que des objets de type VueAddInSauverDocCotéHote)
    [HostAdapter]
    public class AdaptateurContratSauverDocVersVueHote : VueAddInSauverDocCotéHote
    {
        private IContratSauverDoc _contrat;

        // Constructeur avec un seul paramètre (l'adaptateur coté l'addin) 
        // obligatoire
        public AdaptateurContratSauverDocVersVueHote(IContratSauverDoc contrat)
        {
            this._contrat = contrat;
        }

        public override bool EnregistrerDoc(string cheminFichier, string texte)
        {
            return this._contrat.EnregistrerDoc(cheminFichier, texte);
        }
    }
}

Créez un nouveau projet de type Windows Application dans le dossier Partie_Hote et nommez-le Hote.Adaptateurs.

Dans les propriétés du projet sous l'onglet Build, définissez le chemin de sortie sur ..\output. Définissez de plus ce projet en tant que projet de démarrage.

Ajoutez aussi une référence à System.AddIn ainsi qu'à la vue (Hote.Vue). L'hôte n'a besoin d'aucune autre référence (adaptateur ou add-in).

L'approche consistant à utiliser des attributs afin de définir un add-in a comme avantage la facilité d'utilisation. Le développeur a juste à créer une classe héritant de la classe abstraite de base, à appliquer l'attribut AddIn sur cette classe et c'est parti ! Cela a cependant l'inconvénient d'alourdir le processus de découverte des add-ins. Il faut en effet examiner chaque assembly afin de déterminer s'il s'agit d'un add-in et auquel cas de quel type d'add-in nous avons à faire. Ce processus est trop lourd pour être exécuté par exemple à chaque démarrage de l'application hôte. Il existe donc un système permettant de mettre en cache les informations concernant les add-ins afin d'y accéder sans devoir réinspecter chaque assembly à chaque fois.

III-G-2-a. La mise en cache des informations▲

AddInStore.Update(addinRoot);

III-G-2-b. Recherche d'add-ins▲

// Set the add-ins discovery root directory to be the current directory
string addinRoot = Environment.CurrentDirectory;

// Update the add-ins cache and pipeline components cache. 
AddInStore.Update(addinRoot);

// On liste tous les addins de type AddInSauverDocVueHote
Collection<AddInToken> addins =  AddInStore.FindAddIns(typeof(VueAddInSauverDocCotéHote), addinRoot);

//remplissage de la combobox contenant la liste des addins
this.comboBoxFormats.DataSource = addins;
this.comboBoxFormats.DisplayMember = "Name";

Une fois que la liste des add-ins disponibles est chargée et que vous avez sélectionné l'add-in que vous voulez utiliser, il reste une dernière étape avant son utilisation : son activation.

Côté hôte l'activation se fait en une ligne de code et permet de renvoyer un objet de type VueAddInSauverDocCotéHote (qui est la classe représentant la vue de l'add-in par l'hôte) :

//on récupère l'addintoken sélectionné dans la combobox
AddInToken addinToken = this.comboBoxFormats.SelectedItem as AddInToken;

//activation de l'addin correspondant
VueAddInSauverDocCotéHote addinInstance = addinToken.Activate<VueAddInSauverDocCotéHote>(AddInSecurityLevel.Internet);

Nous utilisons la méthode Activate de l'objet AddInTokens (voir plus haut) représentant l'add-in à activer. Il existe trois versions de la méthode Activate prenant en charge des paramètres différents. Mais dans tous les cas, il s'agit de définir les autorisations de sécurité qui seront assignées à l'add-in. Dans l'exemple ci-dessus, nous lui passons en paramètre le niveau de sécurité correspondant au jeu d'autorisations Internet. Il existe d'autres jeux d'autorisations prédéfinis que vous pouvez utiliser :

Si vous ne trouvez pas votre bonheur dans cette liste, sachez qu'une autre version de la méthode Activate permet de passer en paramètre votre propre jeu d'autorisations. Une troisième version permet de fournir votre propre AppDomain.

Mais derrière cette relative simplicité (une ligne de code) se cache un mécanisme quelque peu plus complexe. Vous n'y avez peut-être pas prêté attention, mais si vous regardez le code que nous avons écrit jusqu'à présent vous remarquerez que nous n'avons pas instancié le moindre objet. Nous n'avons créé ni add-in ni adaptateur et pourtant nous nous retrouvons (grâce à la méthode Activate) avec une instance côté hôte que nous allons pouvoir utiliser. Que s'est-il donc passé lors de l'appel à cette méthode ? Voyons un peu plus en détail les différentes étapes par lesquelles est passé le système. N'hésitez pas à vous référer au schéma représentant l'organisation de l'exemple pour mieux comprendre.

• Un domaine d'application (appDomain) est créé avec les permissions spécifiées lors de l'appel à la méthode Activate.
• L'assembly contenant l'add-in est chargée dans cet appDomain à travers un appel à la méthode Assembly.LoadFrom().
• Le constructeur sans argument de l'add-in est appelé (via réflexion) pour en créer une instance dans cet appDomain. Comme l'add-in dérive d'une classe abstraite (dans notre cas VueAddInSauverDocCotéAddIn) se trouvant dans une autre assembly, cette dernière est aussi chargée dans l'appDomain. A ce point nous avons donc une instance de l'add-in s'exécutant dans son propre appDomain. Il nous faut maintenant la connecter à l'hôte.
• Une instance de l'adaptateur côté add-in (dans notre cas AdaptateurVueAddInVersContratSauverDoc) est construite en lui passant en paramètre de son constructeur l'instance de notre add-in (typée en tant que VueAddInSauverDocCotéAddIn). Cet adaptateur implémente le contrat (IContratSauverDoc) et dérive de MarshalByRefObject par l'intermédiaire de la classe ContractBase. Ainsi, il peut « vivre » à la fois dans l'appDomain de l'hôte et dans celui de l'add-in. Tous les appels provenant de l'appDomain de l'hôte passeront au travers d'un proxy et seront exécutés dans l'appDomain de l'add-in.
• Le code d'activation renvoie à l'appDomain de l'hôte l'adaptateur typé en tant que contrat qu'il implémente (dans notre cas IContratSauverDoc).
• Une instance de l'adaptateur coté hôte (AdaptateurContratSauverDocVersVueHote) est construite dans l'appDomain de l'hôte avec l'adaptateur côté add-in (AdaptateurVueAddInVersContratSauverDoc) passé en paramètre de son constructeur.
• Enfin, le code d'activation retourne à l'hôte l'adaptateur côté hôte (AdaptateurVueAddInVersContratSauverDoc) typé en tant que vue (VueAddInSauverDocCotéHote).

L'activation nous a renvoyé un objet de type VueAddInSauverDocCotéHote (qui est classe représentant la vue de l'add-in par l'hôte). Nous pouvons donc utiliser cet objet et appeler sa méthode qui permet l'enregistrement du texte dans un fichier :

//chemin correspond à l'emplacement de sauvegarde 
addinInstance.EnregistrerDoc(chemin, richTextBox1.Text);

En bout de chaine, le code de l'add-in est exécuté et un fichier texte est créé contenant le texte tapé dans la richTextBox. Du mois, en théorie. Car en pratique l'exécution de ce code va provoquer une jolie exception :

Il s'agit d'une exception de sécurité nous informant que le code de notre add-in ne dispose pas des droits pour pouvoir accéder au système de fichier de l'ordinateur. Pour mieux comprendre, remontons un peu en arrière lors de la phase d'activation. Nous avions en effet activé l'add-in avec le jeu de sécurité correspondant à la zone Internet. L'add-in ne possède ainsi que peu de droits, et n'a notamment pas accès au système de fichier de l'ordinateur. Pour résoudre ce problème, nous avons plusieurs solutions. Nous pourrions modifier le jeu de sécurité et en choisir un qui accorde plus de droits à l'add-in :

AddInSecurityLevel.FullTrust

Cependant l'add-in se retrouverait ici avec plus de droits que nécessaire.

La meilleure méthode (tout est relatif) est de construire un jeu personnalisé de permissions :

//création du jeu de permission
PermissionSet perms = new PermissionSet(PermissionState.None);
perms.AddPermission(new SecurityPermission(SecurityPermissionFlag.Execution));
perms.AddPermission(new FileIOPermission(FileIOPermissionAccess.AllAccess, chemin));

try
{                
   //activation de l'addin
    VueAddInSauverDocCotéHote addinInstance = addinToken.Activate<VueAddInSauverDocCotéHote>(perms);

    //utilisation de l'addin
    addinInstance.EnregistrerDoc(chemin, richTextBox1.Text);
}
catch (Exception ex)
{                
    MessageBox.Show(ex.Message);
}

Pour cela nous créons un objet PermissionSet qui contiendra les différentes permissions accordées à l'add-in (plus exactement au domaine d'application de l'add-in). Puis nous y ajoutons deux permissions.

La première est une permission que l'on oublie parfois (et l'on reste ainsi longtemps à se demander pourquoi le code ne fonctionne pas), mais qui est indispensable dans notre cas : c'est la permission donnée au code de s'exécuter. Sans cette autorisation, le code managé ne peut pas s'exécuter. Vous pouvez donc donner toutes les autorisations que vous voulez, si l'autorisation d'exécution n'est pas présente cela ne servira à rien.

Une fois l'autorisation d'exécution donnée, il faut donner à l'add-in le droit en écriture afin qu'il puisse créer le fichier texte demandé. C'est ce que nous faisons en créant un objet FileIOPermission et en lui passant en paramètre le type d'accès de fichier demandé (dans notre cas, tous les accès) et le fichier sur lequel s'exercent ces autorisations. Nous donnons ainsi ici un accès total seulement à l'emplacement où l'on veut sauvegarder le fichier.

Et cette fois-ci le code s'exécute sans problème. Vous pouvez donc jouer très finement avec les autorisations qui seront accordées aux add-ins de vos applications.

Il est possible à l'hôte de décharger l'add-in après utilisation. Pour cela, une ligne de code suffit :

// Récupération de l'AddInController pour l'add-in et fermeture de celui-ci
AddInController.GetAddInController(addinInstance).Shutdown();

La méthode ShutDown coupe le pipeline communication entre l'add-in et l'hôte. Elle se charge aussi de décharger le domaine d'application de l'add-in.

L'hôte attend une nouvelle fonctionnalité de l'add-in. Il faut donc refléter ce changement dans la façon dont l'hôte voit l'add-in, c'est-à-dire dans la vue VueAddInSauverDocCotéHote.

Pour cela, nous allons modifier la vue et lui rajouter la méthode GetExtentionDoc qui permettra à l'hôte d'utiliser cette nouvelle fonctionnalité.

namespace Hote.Vue
{
    /// <summary>
    /// Définit comment sera vu un addin (de type sauverDoc) par l'hôte
    /// </summary>
    public abstract class VueAddInSauverDocCotéHote
    {
        public abstract bool EnregistrerDoc(String cheminFichier, String texte);

        public abstract String GetExtentionDoc();
    }
}

Nous modifions aussi l'adaptateur côté hôte.

using Contrats;
using System.AddIn.Pipeline;
using Hote.Vue;

namespace Hote.Adaptateurs
{
    /// <summary>
    /// Convertit une instance de type IContratSauverDoc afin de la rendre accessible à l'hôte 
    /// (qui ne manipule que des objets de type VueAddInSauverDocCotéHote)
    /// </summary>
    [HostAdapter]
    public class AdaptateurContratSauverDocVersVueHote : VueAddInSauverDocCotéHote
    {
        private IContratSauverDocV2 _contrat;

        /// <summary>
        /// Constructeur avec un seul paramètre (l'adaptateur coté l'addin) obligatoire
        /// </summary>
        /// <param name="contrat"></param>
        public AdaptateurContratSauverDocVersVueHote(IContratSauverDocV2 contrat) 
        {
            this._contrat = contrat;
        }

        public override bool EnregistrerDoc(string cheminFichier, string texte)
        {
            return this._contrat.EnregistrerDoc(cheminFichier, texte);
        }

        public override string GetExtentionDoc()
        {
            return this._contrat.GetExtentionDoc();
        }
    }
}

Au sein de l'hôte, nous n'effectuerons que très peu de changements. Après l'appel à la méthode EnregistrerDoc nous affichons une boite de dialogue indiquant le format d'enregistrement :

MessageBox.Show("Texte sauvegardé sous format: "+addinInstance.GetExtentionDoc());

Comme vous le voyez, les changements dans le pipeline côté hôte se résument dans notre cas à la modification des classes afin de prendre en compte la nouvelle fonctionnalité.

Dans le dossier Partie_AddIn créez un nouveau projet de type bibliothèque de classes et nommez-le AddIn.VueV2.

Créez une classe VueAddInSauverDocCotéAddInV2 :

using System.AddIn.Pipeline;

namespace Addin.Vue
{
    /// <summary>
    /// Classe de base pour notre addin. Définit comment l'addin reçoit les appels de l'hôte
    /// </summary>
    [AddInBase]
    public abstract class VueAddInSauverDocCotéAddInV2
    {
        public abstract bool EnregistrerDoc(String cheminFichier, String texte);

        public abstract String GetExtentionDoc();
    }
}

Cette classe définit la façon dont l'add-in sera appelé par l'application version 2.

N'oubliez pas de définir le chemin de sortie sur ..\output\Pipeline\AddInViews.

Nous allons créer un nouvel add-in qui sera directement compatible avec la version 2 de l'application. Cet add-in permettra de sauvegarder une chaine de caractères dans un fichier XML.

Dans le dossier add-in créez un nouveau projet

using Addin.VueV2;
using System.AddIn;
using System.Xml.Linq;

namespace AddIn.XML
{
    [AddIn("Format xml",
    Version = "1.0.0.0",
    Description = "AddIn permettant d'enregistrer un document sous format xml",
    Publisher = "Badger")]
    public class SauverEnXML : VueAddInSauverDocCotéAddInV2
    {

        public override bool EnregistrerDoc(string cheminFichier, string texte)
        {
            XDocument doc = new XDocument();

            XElement element = new XElement("root", 
                new XElement("data", texte)
                );

            doc.Add(element);                    

            doc.Save(cheminFichier);

            return true;
        }

        public override string GetExtentionDoc()
        {
            return "XML";
        }
    }
}

Dans les propriétés du projet sous l'onglet Build, définissez le chemin de sortie sur ..\output\Pipeline\AddIns\AddIn.XML.

Ajoutez une référence à la vue (AddIn.VueV2), mais veillez à mettre sa propriété Copy Local à FALSE (la dll de la vue ne doit pas être déployée avec l'add-in).

Il ne reste plus que l'adaptateur côté add-in. Créez une nouvelle classe dans le projet AddIn.Adaptateurs (qui existe déjà) et nommez-la AdaptateurVueAddInVersContratSauverDocV2.

Définissez le chemin de sortie sur ..\output\Pipeline\ Add-inSideAdapters.

Ajoutez une référence à la vue (AddIn.VueV2) et au contrat, mais veillez à mettre leur propriété Copy Local à FALSE.

using System.AddIn.Pipeline;
using Addin.VueV2;
using System.AddIn;

namespace AddIn.Adaptateurs
{
    /// <summary>
    /// Encapsule une instance de VueAddInSauverDocCotéAddInV2 pour pouvoir l'exposer en tant que IContratSauverDocV2
    /// </summary>
    [AddInAdapter]
    public class AdaptateurVueAddInVersContratSauverDocV2 : ContractBase, Contrats.IContratSauverDocV2
    {
        private VueAddInSauverDocCotéAddInV2 _vue;

        /// <summary>
        /// Constructeur avec un seul paramètre (l'addin) obligatoire
        /// </summary>
        /// <param name="vue"></param>
        public AdaptateurVueAddInVersContratSauverDocV2(VueAddInSauverDocCotéAddInV2 vue)
        {
            this._vue = vue;
        }

        #region IContratSauverDocV2 Members

        bool Contrats.IContratSauverDocV2.EnregistrerDoc(string chemin, string texte)
        {
            return this._vue.EnregistrerDoc(chemin, texte);
        }

        public string GetExtentionDoc()
        {
            return this._vue.GetExtentionDoc();
        }

        #endregion
    }
}

Comme vous avez pu le constater, la création d'un add-in spécialement dédié à la version 2 de l'application se fait exactement de la même façon que pour la version 1. Il faut simplement créer une nouvelle vue et un nouvel adaptateur correspondant au nouveau contrat.

Faisons un petit état des lieux de notre nouveau pipeline afin de mieux comprendre les modifications à effectuer.

L'add-in SauverEnTXT implémente la vue VueAddInSauverDocCotéAddIn alors que les add-ins directement conçus pour la version 2 de l'application implémentent la vue VueAddInSauverDocCotéAddInV2. Nous ne pouvons pas modifier le code de l'add-in. Nous devons pouvoir le réutiliser tel quel. Il nous faut donc garder la vue VueAddInSauverDocCotéAddIn dans le pipeline.

Le contrat IContratSauverDoc n'existe plus. Un nouveau contrat a fait son apparition : IContratSauverDocV2. L'adaptateur AdaptateurVueAddInVersContratSauverDoc qui implémentait le contrat IContratSauverDoc va donc devoir disparaître.

Le défi est donc de transformer l'ancienne vue VueAddInSauverDocCotéAddIn afin qu'elle corresponde au nouveau contrat IContratSauverDocV2. Pour cela, nous allons créer un adaptateur AdaptateurVueAddInVersContratSauverDocV1toV2.

Dans le projet AddIn.Adaptateur (qui existe déjà), commencez par supprimer l'ancien adaptateur AdaptateurVueAddInVersContratSauverDoc.

Créez ensuite un nouvel adaptateur AdaptateurVueAddInVersContratSauverDocV1toV2 implémentant le contrat IContratSauverDocV2.

Ajoutez une référence à l'ancienne vue (AddIn.Vue) et au contrat, mais veillez à mettre leur propriété Copy Local à FALSE.

using Addin.Vue;
using System.AddIn;

namespace AddIn.Adaptateurs
{
    // Encapsule une instance de VueAddInSauverDocCotéAddIn 
    //pour pouvoir l'exposer en tant que IContratSauverDocV2
    [AddInAdapter]
    public class AdaptateurVueAddInVersContratSauverDocV1toV2 : ContractBase, Contrats.IContratSauverDocV2
    {
        private VueAddInSauverDocCotéAddIn _vue;

        // Constructeur avec un seul paramètre (l'addin) obligatoire
        public AdaptateurVueAddInVersContratSauverDocV1toV2(VueAddInSauverDocCotéAddIn vue)
        {
            this._vue = vue;
        }

        #region IContratSauverDocV2 Members

        public boolEnregistrerDoc(string chemin, string texte)
        {
            return this._vue.EnregistrerDoc(chemin, texte);
        }

        // on adapte car l'addin V1 n'a pas de méthode renvoyant une extension
        public string GetExtentionDoc()
        {
            return "Inconnu";
        }

        #endregion
    }
}

Le point intéressant se trouve dans la méthode GetExtentionDoc. L'add-in ne prenant pas en charge cette fonctionnalité, l'adaptateur est obligé de ruser. Il renvoie simplement la chaine de caractères « Inconnu ».

L'adaptateur fait donc croire à l'hôte que l'add-in implémente la fonctionnalité permettant de renvoyer l'extension du fichier. Lorsque l'hôte voudra obtenir l'extension sur un add-in ne prenant pas compte cette fonctionnalité, l'adaptateur interceptera cette demande et renverra une chaine de caractères quelconque. Ainsi, même un ancien add-in pourra fonctionner avec la nouvelle version de l'application, c'est là toute la force des adaptateurs au sein du pipeline.