Déploiement d’un projet VSTO multi-users avec Wix Toolset

Problématique :

Imaginons un client X qui souhaite ajouter de nouvelles fonctionnalités à son instance de Microsoft Office (Outlook, Word, Excel ou même PowerPoint).

Pour ce faire nous lui proposerons de lui développer un composant VSTO qu’il installera sur son environnement.

Cependant monsieur X souhaites que sur une machine où est installé l’add-in, tous les autres utilisateurs qui peuvent se connecter dessus puissent y avoir accès sans avoir à réinstaller à chaque fois le composant.

Que génère un projet VSTO ?

Lorsqu’on build un projet VSTO, les fichiers suivants sont générés

img1

Si on choisit de publier la solution, un fichier exécutable est généré pour installer l’add-in (ne pas déployer directement un fichier .vsto)

img2.jpg

Si on lance le setup.exe, l’add-in sera bien intégré à MS Office en fonction de l’outil ciblé mais uniquement pour l’utilisateur courant. Ce qui n’est pas vraiment adapté au souhait de monsieur X.

Nous utiliserons alors WIX Toolset pour générer un pack d’intallation multi-user.

Installation de Wix Toolset

Wix Toolset est disponible sur http://wixtoolset.org/ avec une documentation détaillée ainsi que quelques exemples. Une fois téléchargé et installé, Wix Toolset est automatiquement intégré à Visual Studio (peut nécessiter un redémarrage pour le prendre en compte).

Une fois installé, Visual studio propose les templates suivants :

img3.jpg

Création d’un package Wix pour un complément VSTO

Dans une solution contenant un projet VSTO, ouvrir l’assistant d’ajout de nouveau projet et sélectionner « Setup project » et saisir un nom pour ce projet.

Le projet d’installation Wix contient un fichier Product.wxs qui contiendra le code XML décrivant les étapes de l’installation – copie de fichiers, écritures en registre, etc..

img4

Un nouveau fichier Product.wxs est généré avec le code suivant :


<?xml version="1.0" encoding="UTF-8"?>

<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">

<Product Id="*" Name="MySetupProject" Language="1033" Version="1.0.0.0" Manufacturer="" UpgradeCode="ac3a3a9a-5a7a-4f7e-9348-190437ffb6b9">

<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />

<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />

<MediaTemplate />

&nbsp;

<Feature Id="ProductFeature" Title="MySetupProject" Level="1">

<ComponentGroupRef Id="ProductComponents" />

</Feature>

</Product>

<Fragment>

<Directory Id="TARGETDIR" Name="SourceDir">

<Directory Id="ProgramFilesFolder">

<Directory Id="INSTALLFOLDER" Name="MySetupProject" />

</Directory>

</Directory>

</Fragment>

<Fragment>

<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">

<!-- TODO: Remove the comments around this Component element and the ComponentRef below in order to add resources to this installer. -->

<!-- <Component Id="ProductComponent"> -->

<!-- TODO: Insert files, registry keys, and other resources here. -->

<!-- </Component> -->

</ComponentGroup>

</Fragment>

</Wix>

 

Avant de commencer, et ce pour faciliter les choses, nous allons référencer le projet VSTO au projet WIX. Cependant, Visual Studio n’est pas encore capable de lier un projet Wix avec un projet d’autre type tel que VSTO. Cela reste néanmoins très simple de le faire à la main et permettra de gagner beaucoup de temps par la suite lors de la compilation du package.

Pour ce faire, il faut ouvrir le fichier .wixproj avec un éditeur (Notepad++ par exemple) ainsi que le fichier CSPROJ du projet VSTO.

img5

Dans le fichier Wixproj il faut donc ajouter un nouvel élément ItemGroup comme sur le screenshot ci-dessus. Il faut alors renseigner trois choses :

  • Path du projet csproj
  • Nom du projet csproj
  • Guid du projet csproj (prendre celui défini dans le fichier csproj lui-même)

Une fois cette action terminée, retour sur Visual Studio pour commencer à travailler sur le package.


Attention, le contenu du package diffèrera en fonction de la configuration Windows/Microsoft Office de la machine ciblée. En effet, l’écriture des registres ne se fera pas au même endroit suivant l’OS et l’Office en place.

Dans les éléments de code présentés, pour éviter toute duplication, les éléments différents seront surlignés d’une couleur différente suivant la configuration :

Windows 32 bits / Office 32 bits

Windows 64 bits / Office 32 bits

Windows 64 bits / Office 64 bits


 

La section Fragment suivante peut être retirée :


<Fragment>

<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">

<!-- TODO: Remove the comments around this Component element and the ComponentRef below in order to add resources to this installer. -->

<!-- <Component Id="ProductComponent"> -->

<!-- TODO: Insert files, registry keys, and other resources here. -->

<!-- </Component> -->

</ComponentGroup>

</Fragment>

 

Partons donc à partir la section suivante, qui permet de définir le répertoire d’installation nommé « MySetupProject » créé dans le répertoire Program Files ou Program Files x86 suivant l’OS)


<Fragment>

<Directory Id="TARGETDIR" Name="SourceDir">

<Directory Id="ProgramFilesFolder">  (ProgramFiles64Folder pour un OS 64 bits)

<Directory Id="INSTALLFOLDER" Name="MySetupProject" >

…

</ Directory >

</Directory>

</Directory>

</Fragment> 

 

 

Dans l’élément Directory(INSTALLFOLDER), on va décrire les composants à installer :

Nous remarquons l’utilisation de $(var.OutlookAddInProject.TargetPath) ,possible grâce au fait que l’on ait référencé le projet CSPROJ plus tôt et qui nous permettra de ne pas se poser de question sur les paths des fichiers sources. On compile le projet Wix et il se charge lui-même d’aller chercher les fichiers générés par le projet VSTO pour les intégrer au package d’installation.

 

  • Dll de l’addIn :

<Component Id="CMP_AddIn">

<File Id="FILE_AddIn"

Source="$(var.OutlookAddInProject.TargetPath)"

KeyPath="yes" />

</Component>

 

  • Dll du manifeste d’application :

<Component Id="CMP_Manifest">

<File Id="FILE_Manifest"

Source="$(var.OutlookAddInProject.TargetPath).manifest"

KeyPath="yes" />

</Component> 

 

  • Fichier VSTO :

Dans ce composant il faudra préciser les clés de registre à écrire avec les valeurs correspondantes. La racine du registre doit être fixée à HKLM pour permettre à tous les utilisateurs de la machine d’avoir accès à l’add-in.

Attention au path du register à ateindre qui diffère suivant la configuration :

Key= »Software\Microsoft\Office\Outlook\Addins\OutlookAddInProject »

Key= » SOFTWARE\Wow6432Node\Microsoft\Office\Outlook\Addins\OutlookAddInProject »

Key= »Software\Microsoft\Office\Outlook\Addins\OutlookAddInProject »>


<File Id="FILE_Vsto" Source="$(var.OutlookAddInProject.TargetName).vsto"

KeyPath="yes" />

<RegistryKey Root="HKLM" Key="voir ci-dessus pour les valeurs---"

<RegistryValue Name="Description"

Value="My Outlook Add-In"

Type="string"

Action="write" />

<RegistryValue Name="FriendlyName"

Value="OutlookAddInProject"

Type="string"

Action="write" />

 

  • Dll Microsoft.Office.Tools.Common :

<Component Id="CMP_ToolsCommon">

<File Id="FILE_ToolsCommon"

Source="$(var.NaefOutlookAddIn.TargetDir)Microsoft.Office.Tools.Common.v4.0.Utilities.dll" KeyPath="yes" />

</Component>

 

  • Dll Microsoft.Office.Tools.Outlook :

<Component Id="CMP_ToolsOutlook">

<File Id="FILE_ToolsOutlook" Source="$(var.NaefOutlookAddIn.TargetDir)Microsoft.Office.Tools.Outlook.v4.0.Utilities.dll" KeyPath="yes" />

</Component>

 

Une fois les composants décrits, il faut les référencer dans le produit. Pour chaque composant on va ajouter dans l’élément Feature un élément ComponentRef avec comme Id celui de chaque composant comme suit :

 


<Feature Id="ProductFeature" Title="MySetupProject" Level="1">

<ComponentRef Id="CMP_AddIn" />

<ComponentRef Id="CMP_Manifest" />

<ComponentRef Id="CMP_Vsto" />

<ComponentRef Id="CMP_ToolsCommon" />

<ComponentRef Id="CMP_ToolsOutlook" />

</Feature>

 

Il reste un dernier élément à ajouter dans la section produit :


<Media Id="1" Cabinet="OutlookAddInProject.cab" EmbedCab="yes"/>

 

Sans cette ligne, à la compilation seront générés un fichier msi comprenant le package d’intallation et un fichier .cab .

L’ajout de cette ligne permet d’embarquer le fichier cab à l’intérieur du fichier .msi et de n’avoir au final qu’un seul fichier à transmettre pour le déploiement.

Ne pas oublier non plus de définir la config de build pour le package 64bits (windows 64bits + office 64bits) en X64 sinon la compilation ne se fera pas.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s