Choisir entre ClickOnce et Windows Installer

Michael Sanford
Xambi Solutions, Inc.

Janvier 2005

Résumé: Michael Sanford examine en détail la technologie ClickOnce .NET Framework 2.0 et la compare à la technologie Windows Installer existante. Michael conclut en faisant des recommandations sur l’utilisation de chaque technologie. (15 pages imprimées)

Contenu

Introduction
Vue d’ensemble de Windows Installer
Produits, fonctionnalités et composants
Fonctionnalités de Windows Installer
Vue d’ensemble de ClickOnce
Principales différences
Comment choisir ?
Utiliser à la fois Windows Installer et ClickOnce
Conclusion

Introduction

L’une des fonctionnalités les plus intéressantes lors de la démonstration du PDC 2004 était la nouvelle technologie de déploiement ClickOnce. Avec un ensemble de fonctionnalités impressionnant, ClickOnce est certain d’être une technique populaire pour le déploiement d’applications, mais qu’en est-il de Windows Installer ? Dans cet article, nous allons examiner les fonctionnalités de ClickOnce et mettre en évidence les principales différences entre les deux technologies en cours de route. Enfin, nous fournirons des conseils sur le moment où chacune de ces technologies de déploiement doit être utilisée.

Vue d’ensemble de Windows Installer

Microsoft a introduit Windows Installer pour la première fois en 1999 en réponse aux commentaires des clients sur les défis rencontrés lors du déploiement d’applications. Plus précisément, ils ont souligné les faiblesses suivantes dans les technologies d’installation existantes :

• Ils n’ont pas pu gérer de manière cohérente et fiable les ressources partagées telles que les composants COM, les contrôles ActiveX, etc. Ce problème est communément appelé « DLL Hell ».
• Ils n’ont pas pu fournir de fonctionnalités de personnalisation standard.
• Ils ne permettaient pas à une application de se réparer ou de se maintenir une fois installée.
• Ils n’ont pas pu fournir un mécanisme permettant d’installer des parties d’une application à la demande.
• Ils n’ont pas pu fournir un mécanisme cohérent permettant à l’installation d’interagir avec le système d’exploitation.

Windows Installer est un composant au niveau système inclus dans tous les systèmes d’exploitation à partir de Windows 2000. Lorsque les technologies d’installation traditionnelles s’appuyaient sur des scripts et des formats de fichier propriétaires, Windows Installer utilise un format de fichier ouvert, semblable à une base de données, pour décrire une application, ses ressources et les opérations nécessaires pour l’installer correctement. La structure interne du format de base de données, y compris ses définitions standard de table et de colonne, se trouve dans la section Windows Installer du Kit de développement logiciel (SDK) de plateforme. Vous trouverez la dernière version du Kit de développement logiciel (SDK) à l’adresse https://www.microsoft.com/msdownload/platformsdk/sdkupdate/.

Les packages Windows Installer sont stockés dans un fichier avec une extension de fichier « msi ». Bien que le format de ces fichiers soit une implémentation propriétaire basée sur le stockage structuré OLE, le contenu d’un fichier msi est facilement accessible à l’aide des outils fournis avec le Kit de développement logiciel (SDK) de plateforme. L’outil d’édition msi principal fourni par le KIT de développement logiciel (SDK) de plateforme est nommé « Orca ». Comme le montre la figure 1 ci-dessous, la structure logique d’un fichier msi est assez similaire à celle d’une base de données relationnelle.

Figure 1. Affichage du contenu d’un fichier msi avec Orca

En plus des outils fournis par le Kit de développement logiciel (SDK) de plateforme, il existe plusieurs outils tiers disponibles qui facilitent considérablement la tâche de création et d’administration msi. Voici quelques-uns des principaux fournisseurs :

• InstallShield (http://www.installshield.com)
• Sage (http://www.wise.com)
• Zéro G (http://www.zerog.com)

Produits, fonctionnalités et composants

Les packages Windows Installer s’appuient sur une structure logique de produits, de fonctionnalités et de composants pour diviser une application en unités cohérentes de fonctionnalités. Les fonctionnalités sont l’entité de niveau le plus bas avec laquelle un utilisateur peut interagir avec l’installation, tandis que les composants sont l’entité de niveau le plus bas avec laquelle le développeur d’installation travaille. Par exemple, une application graphique peut se composer de deux fonctionnalités : une fonctionnalité d’application de base qui installe l’exécutable de l’application (.exe) et une fonctionnalité clipart qui installe une collection facultative de cliparts. La fonctionnalité principale de notre installation fictive peut être composée de deux composants. Le premier composant peut servir de conteneur du fichier exécutable principal de l’application et des entrées de Registre dont il dépend pour démarrer correctement. Le deuxième composant de la fonctionnalité de base peut inclure un .dll partagé et les informations d’inscription COM qui doivent être enregistrées dans le registre pour que le sous-système COM le reconnaisse.

Fonctionnalités de Windows Installer

Windows Installer est une technologie complexe avec un nombre important de fonctionnalités de personnalisation et de configuration. L’exploration de toutes les fonctionnalités de Windows Installer dépasse le cadre de cet article. Au lieu de cela, nous allons examiner rapidement certaines des fonctionnalités les plus importantes.

• **Programmabilité
  **Windows Installer fournit un ensemble robuste d’API et une interface Automation complète qui permet aux applications d’interagir avec Windows Installer, à la fois dans le cadre du processus de création et dans le cadre du processus d’installation et de maintenance.
• Personnalisation
  Le comportement d’exécution d’un package d’installation peut être personnalisé de différentes manières. Par exemple, une installation peut être développée avec la prise en charge de la définition d’options spécifiques sur la ligne de commande, ou un fichier de transformation spécial peut être créé qui modifie réellement le contenu du fichier msi au moment de l’installation, modifiant ainsi le comportement de l’installation. Le Kit de développement logiciel (SDK) de plateforme et la plupart des fournisseurs d’outils tiers prennent en charge la création de fichiers de transformation.
• Installer à la demande
  Windows Installer prend en charge un concept appelé publicité, qui permet d’installer des parties individuelles d’une application (ou l’ensemble de l’application) uniquement lorsque l’utilisateur en a besoin. Grâce à une intégration approfondie au système d’exploitation, Windows Installer est en mesure de détecter quand une application, ou une fonctionnalité spécifique d’une application, est nécessaire. Par exemple, si une application capable de modifier des fichiers .foo est installée, Windows Installer case activée pour s’assurer que l’application est installée et l’installer si nécessaire lorsque l’utilisateur double-clique sur un fichier .foo dans Windows Explorer.
• Résilience
  Comme windows Installer peut installer une application ou une fonctionnalité à la demande, il est également en mesure de réparer une application lorsque l’utilisateur interagit avec elle. Par exemple, lorsqu’un utilisateur provoque l’exécution d’une application en cliquant sur un raccourci du menu Démarrer ou en double-cliquant sur un fichier associé, Windows Installer peut intercepter la demande et vérifier que les éléments appropriés de l’application sont correctement installés. Si un problème est détecté, une réparation se produit avant l’exécution de l’application.
• Installation transactionnelle
  Une grande partie du fonctionnement interne de Windows Installer est consacrée à s’assurer que l’exécution d’une installation n’aura pas d’impact négatif sur votre système si quelque chose de critique échoue pendant l’installation. Pour ce faire, Windows Installer crée un « script » interne qui indique exactement ce qui doit être fait pour installer correctement l’application. Si un problème se produit pendant l’installation, le script peut essentiellement inverser toutes les actions qui ont été effectuées, laissant ainsi le système dans son état d’origine.
• Résilience de la source
  Un aspect important de la capacité de Windows Installer à réparer une application une fois qu’elle a été installée est qu’elle a parfois besoin d’accéder à une copie de la source d’installation d’origine. Par exemple, si Windows Installer détermine qu’un fichier critique est manquant ou endommagé, il doit obtenir une copie propre de ce fichier. La résilience source est un mécanisme qui permet à Windows Installer de rechercher à plusieurs emplacements l’installation d’origine, puis d’inviter l’utilisateur à entrer le média s’il est introuvable à un autre emplacement. Les emplacements sources peuvent être le système de fichiers local, un partage réseau ou une URL Internet. Windows Installer 3.0 a également amélioré ces fonctionnalités, ce qui permet aux administrateurs de gérer plus facilement les emplacements sources.
• Mises à niveau et mise à jour corrective
  Un cycle de vie de produit classique ne se termine pas une fois que l’application a été correctement installée. Aussi agréable que ce soit, la réalité est que la plupart des applications doivent être mises à jour ou corrigées pour déployer des correctifs ou de nouvelles fonctionnalités. Windows Installer prend en charge la création et la distribution de correctifs au niveau des octets pour le déploiement de correctifs logiciels et de mises à niveau afin de distribuer des mises à jour d’application plus complètes. Windows Installer 3.0 a apporté des améliorations significatives à la mise à jour corrective en prenant en charge le séquencement des correctifs et la possibilité de désinstaller des correctifs.
• Prise en charge de l’environnement managé
  Dans les grands environnements d’entreprise, les systèmes sont souvent verrouillés pour empêcher les utilisateurs d’installer des applications non autorisées et de mettre en danger l’intégrité de ce système. Windows Installer comprend plusieurs fonctionnalités qui permettent à certaines installations msi d’être « bénies » par l’administrateur système pour s’exécuter dans ce type d’environnement verrouillé.

Vue d’ensemble de ClickOnce

ClickOnce est une toute nouvelle technologie de déploiement qui fait partie du .NET Framework version 2.0 et qui a fait l’objet d’une première démonstration au PDC 2004 à Los Angeles. ClickOnce vise à apporter la simplicité du déploiement d’applications web aux applications clientes intelligentes, tout en fournissant un environnement d’exécution sécurisé. Pour déployer une application avec ClickOnce, vous devez simplement placer les fichiers d’application sur un serveur web, un partage de fichiers ou le système de fichiers local et fournir à l’utilisateur un lien vers le manifeste de l’application.

Si vous développez avec Visual Studio 2005, la publication d’une application avec ClickOnce est une tâche triviale, grâce à l’Assistant Publication. Pour accéder à l’Assistant Publication, cliquez simplement avec le bouton droit sur le nom du projet dans le Explorateur de solutions, puis sélectionnez Publier dans le menu contextuel. Vous pouvez également accéder à l’Assistant à partir de l’onglet Publier de la boîte de dialogue Propriétés du projet.

Figure 2 : Assistant Publication de Visual Studio 2005

Un déploiement ClickOnce est contrôlé par l’utilisation de deux fichiers manifeste XML : un manifeste de déploiement et un manifeste d’application.

Manifeste de déploiement

Le manifeste de déploiement est utilisé pour décrire le déploiement de l’application. Il inclut l’emplacement du manifeste de l’application, les fichiers décrits dans le manifeste de l’application et la version de la version la plus récente que les clients doivent exécuter.

<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1
    assembly.adaptive.xsd" manifestVersion="1.0"
    xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns="urn:schemas-
    microsoft-com:asm.v2" xmlns:asmv1="urn:schemas-microsoft-
    com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"
    xmlns:xrml="urn:mpeg:mpeg21:2003:01-REL-R-NS"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<assemblyIdentity name="My Test App.application" version="1.0.0.20"
    publicKeyToken="7726c4d654f5bf83" language="neutral"
    processorArchitecture="msil" xmlns="urn:schemas-microsoft
    -com:asm.v1" />
<description asmv2:publisher="Xambi Solutions" asmv2:product="My Test
    App" asmv2:supportUrl="http://michael
    -dev2/WindowsApplication1/Support.htm" xmlns="urn:schemas
    -microsoft-com:asm.v1" />
<deployment install="true">
<subscription>
<update>
<expiration maximumAge="3" unit="days" />
</update>
</subscription>
<deploymentProvider
    codebase="http://michael_dev2/WindowsApplication1/My%20Test%20App
    .application" />
</deployment>
<dependency>
<dependentAssembly codebase="My Test App_1.0.0.20\My Test 
    App.exe.manifest" size="4908">
<assemblyIdentity name="My Test App.exe" version="1.0.0.20"
    publicKeyToken="7726c4d654f5bf83" language="neutral" 
    processorArchitecture="msil" />
<hash>
<dsig:Transforms>
<dsig:Transform Algorithm="urn:schemas-microsoft
    -com:HashTransforms.Identity" />
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>GANTD3FaR5KJiqnEluecM05wtss=</dsig:DigestValue>
</hash>
</dependentAssembly>
</dependency> 
<Signature Id="StrongNameSignature" 
    xmlns="http://www.w3.org/2000/09/xmldsig#" />
<!-- Details Omitted for Brevity -->
</asmv1:assembly>

Manifeste d’application

Le manifeste de l’application est utilisé pour décrire l’application, les assemblys, les fichiers, les ressources et les autorisations nécessaires au bon fonctionnement de l’application. En outre, le manifeste de l’application détermine également l’emplacement où se trouveront les mises à jour.

<?xml version="1.0" encoding="utf-8"?> <asmv1:assembly 
    manifestVersion="1.0" xsi:schemaLocation="urn:schemas-microsoft
    -com:asm.v1 assembly.adaptive.xsd"
    xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns="urn:schemas
    -microsoft-com:asm.v2" xmlns:asmv1="urn:schemas-microsoft
    -com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <asmv1:assemblyIdentity name="My Test App.exe" version="1.0.0.20"
    publicKeyToken="7726c4d654f5bf83" language="neutral"
    processorArchitecture="msil" type="win32" />
<asmv2:configuration configFile="My Test App.exe.config"
    xmlns="urn:schemas-microsoft-com:asm.v1" />
<entryPoint>
<assemblyIdentity name="My Test App" version="1.0.0.0"
    publicKeyToken="7726C4D654F5BF83" language="neutral"
    processorArchitecture="msil" />
<commandLine file="My Test App.exe" parameters="" />
</entryPoint>
<trustInfo>
<security>
<applicationRequestMinimum>
<PermissionSet class="System.Security.PermissionSet" version="1"
    ID="Custom">
<IPermission class="System.Security.Permissions.EnvironmentPermission,
    mscorlib, Version=2.0.3600.0, Culture=neutral,
    PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" /> <IPermission class="System.Security.Permissions.FileDialogPermission,
    mscorlib, Version=2.0.3600.0, Culture=neutral,
    PublicKeyToken=b77a5c561934e089" version="1" Access="Open" /> <IPermission
    class="System.Security.Permissions.IsolatedStorageFilePermission,
    mscorlib, Version=2.0.3600.0, Culture=neutral,
    PublicKeyToken=b77a5c561934e089" version="1"
    Allowed="DomainIsolationByUser" UserQuota="10240" />
<IPermission class="System.Security.Permissions.SecurityPermission,
    mscorlib, Version=2.0.3600.0, Culture=neutral,
    PublicKeyToken=b77a5c561934e089" version="1" Flags="Execution" /> <IPermission class="System.Security.Permissions.UIPermission, mscorlib,
    Version=2.0.3600.0, Culture=neutral,
    PublicKeyToken=b77a5c561934e089" version="1"
    Window="SafeTopLevelWindows" Clipboard="OwnClipboard" /> <IPermission class="System.Windows.Forms.WebBrowserPermission, System,
    Version=2.0.3600.0, Culture=neutral,
    PublicKeyToken=b77a5c561934e089" version="1" Level="Restricted" /> <IPermission class="System.Drawing.Printing.PrintingPermission,
    System.Drawing, Version=2.0.3600.0, Culture=neutral,
    PublicKeyToken=b03f5f7f11d50a3a" version="1" Level="SafePrinting"/> </PermissionSet>
<defaultAssemblyRequest permissionSetReference="Custom" /> </applicationRequestMinimum>
</security>
</trustInfo>
<dependency>
<dependentAssembly codebase="My Test App.exe" size="12288"> <assemblyIdentity name="My Test App" version="1.0.0.0"
    publicKeyToken="7726C4D654F5BF83" language="neutral"
    processorArchitecture="msil" />
<hash>
<dsig:Transforms>
<dsig:Transform Algorithm="urn:schemas-microsoft
    -com:HashTransforms.Identity" />
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <dsig:DigestValue>xx4Nai4Nr7Bp5R7xtyqO8gAVsSk=</dsig:DigestValue> </hash>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly preRequisite="true">
<assemblyIdentity name="Microsoft-Windows-CLRCoreComp"
    version="2.0.3600.0" />
</dependentAssembly>
</dependency>
<file name="My Test App.exe.config" size="1222">
<hash>
<dsig:Transforms>
<dsig:Transform Algorithm="urn:schemas-microsoft
    -com:HashTransforms.Identity" />
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>BdHEVcmEBWqRZGitWdDZ/vAGGmQ=</dsig:DigestValue> </hash>
</file>
<Signature Id="StrongNameSignature"
    xmlns="http://www.w3.org/2000/09/xmldsig#">
<!-- Details Omitted for Brevity -->
</Signature>
</asmv1:assembly> 

Une fois l’application et les manifestes de déploiement créés, ils doivent simplement être copiés vers l’emplacement de déploiement, ainsi que les fichiers d’application requis. Il est important de noter que le manifeste de déploiement n’a pas besoin d’être stocké au même emplacement que le manifeste d’application. Par exemple, le manifeste de déploiement peut être expédié sur un disque physique. Lorsqu’il est activé, le manifeste de déploiement indique au moteur ClickOnce où trouver le manifeste de l’application. Il s’agit d’une fonctionnalité importante de ClickOnce, car elle vous permet de vous assurer que les utilisateurs obtiennent la dernière version de votre application dès la première installation, plutôt que d’installer une version à partir du disque, puis de demander immédiatement une mise à jour.

Lorsque l’utilisateur lance votre application, ClickOnce installe ou met à jour votre application en fonction des paramètres contenus dans votre manifeste de déploiement. Si votre application nécessite des autorisations élevées, l’utilisateur est invité à accorder les autorisations requises :

Figure 3. L’utilisateur est interrogé sur les autorisations requises

Cliquez sur le lien Plus d’informations dans le coin inférieur droit de cette boîte de dialogue pour afficher la boîte de dialogue d’informations ci-dessous.

Figure 4. Informations supplémentaires sur l’avertissement de sécurité

Enfin, une fois l’application en cours d’exécution, nous pouvons voir dans la barre de titre à partir de laquelle l’application a été déployée et une icône spéciale superposée à l’icône des applications. Lorsque nous pointons notre pointeur de souris sur cette icône, nous pouvons voir un message spécial indiquant le contexte de sécurité dans lequel l’application s’exécute.

Figure 5. Message d’information sur l’environnement de sécurité

Note Lors de l’écriture d’applications .NET qui peuvent s’exécuter dans un environnement sécurisé, il est très important que les exceptions de sécurité soient gérées explicitement pour s’assurer que l’application reste stable et que l’utilisateur comprend ce qui s’est produit lorsqu’une exception de sécurité se produit.

Principales différences

Maintenant que j’ai examiné rapidement les fonctionnalités de Windows Installer et ClickOnce, vous remarquerez que chaque technologie était des objectifs très différents. Pour illustrer plus en détail ce point, considérez la matrice suivante :

Comme je l’ai mentionné précédemment, chacune de ces technologies a été conçue et développée avec un ensemble d’objectifs complètement différent. Ni l’un ni l’autre n’est destiné à remplacer l’autre. ClickOnce offre un ensemble très convaincant de fonctionnalités, dont la plupart sont introuvables dans la technologie Windows Installer. Ces fonctionnalités sont spécifiquement destinées aux développeurs qui créent des applications clientes intelligentes basées sur .NET Framework qui n’ont pas d’exigences de configuration sophistiquées. Windows Installer est une technologie de déploiement beaucoup plus large qui est intrinsèquement conçue pour être extensible et capable de gérer n’importe quel défi de déploiement, y compris les applications .NET.

Comment choisir ?

Quand il s’agit de votre choix dans les technologies de déploiement, vous n’avez pas besoin de vous limiter à une seule option. La clé consiste à choisir l’outil approprié pour le travail approprié. Bien qu’il n’y ait pas de règle unique ou de réponse simple, il existe des instructions générales que vous pouvez utiliser pour vous aider à prendre la meilleure décision en fonction de vos besoins spécifiques.

• L’application installe-t-elle des composants COM ?
• L’application nécessite-t-elle l’inscription de composants pour COM-Interop ?
• L’application installe-t-elle des services ?
• L’application doit-elle s’installer à un emplacement spécifique ou au Global Assembly Cache (GAC) ?
• L’application a-t-elle des composants installés de manière conditionnelle, en fonction du système d’exploitation ou de l’environnement d’exécution ?
• L’application nécessite-t-elle une entrée utilisateur au moment de l’installation ?
• L’application nécessite-t-elle une configuration de services au niveau du système, tels qu’Active Directory ou COM+?
• Une fois l’application installée, crée-t-elle des fichiers, écrit-elle dans le Registre ou affecte-t-elle le système d’une manière quelconque qui laisserait des ressources derrière elle lors de la suppression de l’application ?

Si vous avez répondu oui à l’une de ces questions, Windows Installer est aujourd’hui le meilleur choix pour vos besoins. Toutefois, si vous n’avez pas besoin de traiter les scénarios décrits dans la liste ci-dessus, ClickOnce est un excellent candidat pour votre solution de déploiement. Si vous souhaitez tirer parti des avantages distincts fournis par ClickOnce, il est essentiel de comprendre les fonctionnalités de ClickOnce au début de votre processus de conception d’application. Le déploiement d’une version antérieure d’une application avec ClickOnce, mais la réalisation tardive d’un besoin de passer à Windows Installer créerait un chemin de mise à niveau difficile qui peut être évité grâce à une planification préalable minutieuse.

Utiliser Windows Installer et ClickOnce

Oui, c’est vrai ! Vous m’avez bien entendu. Maintenant que j’ai établi un argument pour savoir à quel point ces deux technologies sont différentes dans leur implémentation, je vais secouer votre monde en vous disant comment vous pouvez les utiliser ensemble.

Windows Installer fournit des fonctionnalités avancées pour interagir avec l’utilisateur lors d’une installation. Souvent, il s’agit d’une étape critique dans le processus de déploiement. La capacité d’une installation à interroger le système cible pour s’assurer qu’il répond aux exigences minimales de l’application est essentielle. En outre, la plupart des applications ont tendance à avoir une certaine interaction avec l’environnement d’exploitation. Cela peut inclure l’écriture de fichiers journaux sur le disque, le stockage de données dans le Registre, etc. Une application bien comportementée doit avoir la possibilité d’propre ces données spécifiques à l’application lorsqu’elles sont supprimées du système. Tous ces concepts de déploiement clés sont absents du paradigme ClickOnce.

En revanche, Windows Installer a un article de mise à jour et de mise à jour corrective, mais il n’est pas aussi élégant et facile à gérer que celui de ClickOnce.

Avec un peu de réflexion, de planification et d’ingéniosité, nous pouvons tirer parti des deux technologies pour créer un modèle de déploiement avec le meilleur des deux mondes.

Conception du programme d’installation de Windows Installer

Le concept de base ici consiste à créer une installation externe basée sur la technologie Windows Installer. Cette installation externe assume la responsabilité d’inspecter et d’interroger le système avant l’installation de l’application. Il peut interagir avec l’utilisateur, collecter et stocker des informations de configuration, installer des assemblys partagés dans le GAC, etc. Au moment de la désinstallation, il assume la responsabilité de nettoyer les ressources qui auraient généralement été laissées par notre application. Par exemple, il peut désinstaller des fichiers, supprimer les fichiers journaux créés au moment de l’exécution, désinstaller des services, supprimer des assemblys du GAC, etc.

Brancher notre application ClickOnce dans notre installation est à nouveau une tâche assez simple. Étant donné que les applications ClickOnce peuvent être activées via une URL Internet ou intranet, nous pouvons simplement créer un raccourci sur le système cible qui pointe vers le manifeste de l’application. Pour ce faire, nous pouvons utiliser Windows Installer pour créer un fichier .url à la volée au moment de l’installation. Un fichier .url est un type spécial de raccourci conforme au format de fichier .ini standard.

[InternetShortcut]

URL=http://www.myserver.com/myapp/v1_0/myapp.application

À l’aide de Windows Installer pour créer ce fichier INI, nous n’avons besoin d’ajouter qu’une seule ligne à la table IniFile.

Une implémentation bien conçue de cette technique nécessitera d’autres modifications dans notre fichier msi pour garantir que notre installation effectue toutes les tâches requises par notre application, mais j’espère que cela vous a donné un aperçu de ce qui est possible lorsque vous tirez parti des meilleures parties de chaque technologie de déploiement.

Conclusion

Pour les applications qui ne sont pas limitées par leurs limitations fonctionnelles, ClickOnce est une excellente technologie de déploiement qui offre des avantages précieux et un modèle de mise à jour qui était auparavant disponible uniquement pour les applications web. Pour les applications avec des exigences plus sophistiquées, Windows Installer reste la technologie de déploiement de choix. Chacune de ces technologies de déploiement partage l’objectif commun d’installer de manière fiable votre application, mais les similitudes s’arrêtent là. Vous pouvez être sûr que les fonctionnalités de ClickOnce augmenteront à l’avenir, mais vous pouvez également être sûr que Windows Installer est là pour rester. En attendant, faites preuve de créativité et apprenez à les aimer tous les deux!

À propos de l’auteur

Michael Sanford est président et architecte logiciel en chef pour Xambi Solutions (http://www.xambi.com). Avant de former Xambi, Michael était président et chef de la direction d’ActiveInstall Corporation, qui a été acquise par Zero G Software. ActiveInstall a obtenu une notoriété pour ses solutions de création Windows Installer. Michael est microsoft certified solution developer (MCSD), Microsoft Certified Systems Engineer (MCSE) et MVP Windows Installer. Vous pouvez lire le blog de Michael à l’adresse http://msmvps.com/michael.