Choix entre ClickOnce et programme d’installation de Windows

 

Michael Sanford
Xambi Solutions, Inc.

Janvier 2005

Résumé: Michael Sanford examine en détail la technologie .NET Framework 2.0 ClickOnce 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 du programme d’installation Windows
Produits, fonctionnalités et composants
Fonctionnalités du programme d’installation Windows
Vue d’ensemble de ClickOnce
Principales différences
Comment choisir ?
Utiliser le programme d’installation Windows et le ClickOnce
Conclusion

Introduction

L’une des fonctionnalités les plus intéressantes de la démonstration de 2004 PDC était la nouvelle technologie de déploiement ClickOnce. Avec un ensemble de fonctionnalités impressionnant, ClickOnce est sûr d’être une technique populaire pour le déploiement d’applications, mais qu’en est-il de Windows Installer ? Dans cet article, nous allons découvrir les fonctionnalités de ClickOnce et mettre en évidence les principales différences entre les deux technologies. Enfin, nous fournirons des conseils sur l’utilisation de chacune de ces technologies de déploiement.

Vue d’ensemble du programme d’installation Windows

Microsoft a d’abord introduit Windows Installer 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 n’ont pas permis à une application de réparer ou de se maintenir une fois qu’elle a été installée.
  • Ils n’ont pas pu fournir un mécanisme permettant aux parties d’une application d’être installées à la demande.
  • Ils n’ont pas pu fournir un mécanisme cohérent pour que l’installation interagit avec le système d’exploitation.

Windows Programme d’installation est un composant au niveau du système inclus dans tous les systèmes d’exploitation commençant par Windows 2000. Lorsque les technologies d’installation traditionnelles s’appuient sur des scripts et des formats de fichiers propriétaires, Windows Programme d’installation utilise un format de fichier ouvert et de 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 de table et de colonne standard, se trouve dans la section Programme d’installation Windows du Kit de développement logiciel (SDK) plateforme. La dernière version du Kit de développement logiciel (SDK) est disponible à l’adresse https://www.microsoft.com/msdownload/platformsdk/sdkupdate/.

Windows packages du programme d’installation 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 d’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 illustré dans 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

Outre les 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 :

Produits, fonctionnalités et composants

Windows packages installer reposent 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 fonctionne. Par exemple, une application graphique peut comporter deux fonctionnalités : une fonctionnalité d’application principale qui installe l’exécutable de l’application (.exe) et une fonctionnalité clipart qui installe une collection facultative de clipart. La fonctionnalité principale de notre installation fictive peut être composée de deux composants. Le premier composant peut agir en tant que conteneur du fichier exécutable principal de l’application et les entrées de Registre dont il dépend pour démarrer correctement. Le deuxième composant de la fonctionnalité principale 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 reconnaît.

Fonctionnalités du programme d’installation Windows

Windows Installer est une technologie complexe avec un nombre significatif de fonctionnalités de personnalisation et de configuration. L’exploration de toutes les fonctionnalités de Windows Programme d’installation dépasse la portée 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 Programme d’installation, tant dans le cadre du processus de création que 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 façons. 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, ce qui modifie 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 aux parties individuelles d’une application (ou à l’ensemble de l’application) d’être installées uniquement lorsque l’utilisateur en a besoin. Grâce à une intégration approfondie au système d’exploitation, Windows programme d’installation est en mesure de détecter lorsqu’une application ou une fonctionnalité spécifique d’une application est nécessaire. Par exemple, si une application est installée capable de modifier des fichiers .foo, Windows programme d’installation vérifie que l’application est installée et l’installe si nécessaire lorsque l’utilisateur double-clique sur un fichier .foo dans l’Explorateur Windows.
  • Résilience
    Comme Windows Programme d’installation peut installer une application ou une fonctionnalité à la demande, il est également en mesure de réparer une application lorsque l’utilisateur interagit avec lui. Par exemple, lorsqu’un utilisateur entraîne l’exécution d’une application en cliquant sur un raccourci de menu Démarrer ou en double-cliquant sur un fichier associé, Windows Programme d’installation est en mesure d’intercepter la demande et de 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 des fonctionnements internes de Windows Installer est consacrée à garantir que l’exécution d’une installation n’affectera pas négativement votre système si quelque chose de critique échoue pendant l’installation. Windows Programme d’installation effectue cette opération en créant un « script » interne de ce qui doit être fait pour installer correctement l’application. Si un problème se produit lors de l’installation, le script peut essentiellement inverser toutes les actions qui ont été effectuées, ce qui laisse le système dans son état d’origine.
  • Résilience source
    Un aspect important de la capacité de Windows installer pour réparer une application après son installation est que, parfois, il devra accéder à une copie de la source d’installation d’origine. Par exemple, si Windows programme d’installation 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 Programme d’installation de rechercher dans plusieurs emplacements de rechercher l’installation d’origine, puis d’inviter l’utilisateur à entrer le média s’il n’est pas trouvé à 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 serait le cas, 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 Programme d’installation prend en charge la création et la distribution de correctifs de niveau octet pour le déploiement de correctifs et de mises à niveau pour distribuer des mises à jour d’application plus complètes. Windows Installer 3.0 a introduit des améliorations significatives apportées à 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 de grands environnements d’entreprise, les systèmes sont souvent verrouillés pour empêcher les utilisateurs d’installer des applications non fiables et de mettre à risque l’intégrité de ce système. Windows Programme d’installation comprend plusieurs fonctionnalités qui permettent à certains installations basées sur 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 nouvelle technologie de déploiement qui est fournie dans le cadre du .NET Framework version 2.0 et a été la première démonstration à PDC 2004 à Los Angeles. ClickOnce se concentre sur l’apport de 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 Publier, 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 Project.

Figure 2 : Assistant publication Visual Studio 2005

Un déploiement ClickOnce est contrôlé via 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 d’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 correctement l’application, les assemblys, les fichiers, les ressources et les autorisations nécessaires pour que l’application fonctionne correctement. En outre, le manifeste de l’application détermine également l’emplacement où se trouvent 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 que les manifestes d’application et de déploiement ont été créés, ils doivent simplement être copiés à 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é dans le même emplacement que le manifeste de l’application. Par exemple, le manifeste de déploiement peut être livré sur un disque physique. Lors de l’activation, 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 à partir de la première installation, plutôt que d’installer une version à partir du disque, puis d’exiger 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

En cliquant sur le lien Plus d’informations dans le coin inférieur droit de cette boîte de dialogue, la boîte de dialogue d’information apparaît ci-dessous.

Figure 4. Plus d’informations sur l’avertissement de sécurité

Enfin, une fois l’application en cours d’exécution, nous pouvons voir dans la barre de titre où l’application a été déployée et une icône spéciale superposition de 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 passé lorsqu’une exception de sécurité se produit.

Principales différences

Maintenant que j’ai examiné rapidement les fonctionnalités du programme d’installation Windows et de l’ClickOnce, vous remarquerez que chaque technologie était très différente. Pour illustrer ce point, tenez compte de la matrice suivante :

Tâche ClickOnce Windows Installer
Installer des fichiers X X
Créer des raccourcis X X
Associer des extensions de fichier X X
Installer des services   X
Installer sur GAC   X
Gérer ODBC   X
Gérer COM+   X
Écrire dans le Registre   X
Publicité   X
Self-Repair   X
Autorisations de fichier/dossier/Registre   X
Interaction utilisateur au moment de l’installation   X
Installation pour tous les utilisateurs   X
Actions personnalisées lors de l’installation/désinstallation   X
Conditions d’installation/interrogation du système   X
Mise à jour automatique et planification X  
Mises à jour forcées X  
Bac à sable de sécurité X  
Télécharger/installer des assemblys à la demande X  
Restauration vers la version précédente X  

Comme je l’ai mentionné précédemment, chacune de ces technologies a été conçue et développée avec un ensemble complètement différent d’objectifs. Aucun n’est destiné à remplacer l’autre. ClickOnce offre un ensemble très attrayant de fonctionnalités, dont la plupart ne sont pas trouvées dans Windows technologie 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 de configuration sophistiquée. Windows Programme d’installation est une technologie de déploiement beaucoup plus large conçue pour être extensible et capable de gérer tout défi de déploiement, y compris les applications .NET.

Comment choisir ?

En ce qui concerne 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 bon travail. Bien qu’il n’y ait pas de règle unique ou de réponse simple, il existe certaines recommandations générales que vous pouvez utiliser pour vous aider à prendre la meilleure décision pour 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 dispose-t-elle de composants qui sont 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 la configuration des 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-il dans le Registre ou affecte-t-elle le système de manière à laisser les ressources derrière elles lorsque l’application est supprimée ?

Si vous avez répondu oui à l’une de ces questions, aujourd’hui Windows Programme d’installation est le meilleur choix pour vos besoins. Toutefois, si vous n’avez pas besoin d’aborder 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, la compréhension des fonctionnalités de ClickOnce tôt dans votre processus de conception d’application est essentielle. Le déploiement d’une version anticipée d’une application avec ClickOnce, mais en retardant la réalisation d’une nécessité de passer à Windows programme d’installation, créerait un chemin de mise à niveau difficile qui peut être évité par le biais d’une planification préalable minutieuse.

Utiliser le programme d’installation Windows et le ClickOnce

Oui, c’est vrai! Tu m’as entendu bien. Maintenant que j’ai créé un cas pour la façon dont ces deux technologies sont différentes dans leur implémentation, je vais secouer votre monde en disant comment vous pouvez les utiliser ensemble.

Windows Programme d’installation 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’elle 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 des données dans le Registre, etc. Une application bien comporte l’occasion de nettoyer ces données spécifiques à l’application lorsqu’elle est supprimée du système. Tous ces concepts de déploiement sont des concepts de déploiement clés manquants dans le paradigme ClickOnce.

En revanche, Windows Programme d’installation a une histoire de mise à jour et de mise à jour corrective, mais il n’est pas presque aussi élégant et facile à gérer que celui de ClickOnce.

Avec un peu de pensée, 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 de la configuration du programme d’installation Windows

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

Le branchement de notre application ClickOnce dans notre installation est encore une tâche assez simple. Étant donné que ClickOnce applications 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 Programme d’installation 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 standard .ini.

[InternetShortcut]

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

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

Nom de la colonne Valeur Notes
IniFile URLShortcut1 Clé primaire
FileName My App.url Nom du fichier .url. La partie principale de ce nom est ce que l’utilisateur verra. Dans ce cas, le raccourci affiche « Mon application ».
DirProperty MyShortcutFolder Nom de clé primaire d’un répertoire défini dans l’installation. Cela identifie l’emplacement où le raccourci sera créé.
Section InternetShortcut Section principale écrite dans le fichier ini.
Clé : URL Partie clé de la paire clé/valeur.
Value http://www.myserver.com/myapp/v1_0/myapp.application URL réelle du manifeste de l’application.
Action 0 La valeur 0 indique que la valeur doit être créée ou mise à jour si elle existe déjà.
Composant MyComponent Référence au composant responsable de l’installation/désinstallation de notre raccourci.

Une implémentation bien conçue de cette technique nécessite des modifications supplémentaires 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 fourni 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 précédemment disponible uniquement pour les applications web. Pour les applications avec des exigences plus sophistiquées, Windows Programme d’installation reste la technologie de déploiement de choix. Chacune de ces technologies de déploiement partage l’objectif commun d’installation fiable de votre application, mais les similitudes se terminent par 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 ici pour rester. En attendant, obtenez de la 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é acquis par Zero G Software. ActiveInstall a obtenu une notorié pour ses solutions Windows Installer Authoring. Michael est un développeur de solutions certifiées Microsoft (MCSD), Microsoft Certified Systems Engineer (MCSE) et un Windows Installer MVP. Vous pouvez lire le blog de Michael à http://msmvps.com/michael.