Choisir entre ClickOnce et Windows Installer

Michael Sanford Xambi Solutions, Inc.

Résumé : Michael Sanford fait le point sur la technique de ClickOnce de .NET Framework 2.0 et la compare à celle de Windows Installer. Michael conclut par des recommandations sur les situations dans lesquelles chacune de ces techniques doit être utilisée. (15 pages imprimées)

Cet article a été traduit de l'anglais dont voici le lien  

Sur cette page

Introduction
Présentation de Windows Installer
Produits, fonctions et composants
Caractéristiques de Windows Installer
Présentation de ClickOnce
Principales différences
Comment choisir ?
Utilisez à la fois Windows Installer et ClickOnce
Conclusion

Haut de page

Introduction

La technologie de déploiement ClickOnce a constitué l'une des nouveautés les plus intéressantes de la conférence PDC 2004. Avec son lot impressionnant de fonctions, ClickOnce est une technique prometteuse de déploiement d'applications. Mais qu'en est-il de Windows Installer ? Dans cet article, nous allons approfondir les caractéristiques de ClickOnce et présenter les principales différences entre les deux techniques. En conclusion, nous fournirons quelques recommandations sur les situations dans lesquelles chacune de ces techniques doit être utilisée.

Haut de page

Présentation de Windows Installer

Microsoft a introduit Windows Installer en 1999, en réponse aux remarques des clients qui devaient relever de véritables défis pour déployer leurs applications. Les clients mentionnaient plus précisément les faiblesses suivantes des techniques d'installation existantes :

• Elles ne permettaient pas une gestion cohérente et fiable des ressources telles que les composants COM ou les contrôles ActiveX. On parlait alors de l'« enfer des DLL » (DLL Hell).

• Elles n'offraient pas, en standard, de possibilités de personnalisation des applications.

• Elles ne fournissaient pas aux applications les moyens de s'autoréparer ou de s'automaintenir après leur installation.

• Elles ne permettaient pas d'installer, à la demande, certains éléments d'une application.

• Elles n'offraient pas de mécanisme cohérent pour que l'installation interagisse avec le système d'exploitation.

Windows Installer est un composant de niveau système intégré à tous les systèmes d'exploitation à partir de Windows 2000. Alors que les techniques d'installation traditionnelles reposent sur des scripts et des formats de fichiers propriétaires, Windows Installer utilise un format de fichier ouvert, similaire à celui d'une base de données, pour décrire une application, ses ressources et les opérations nécessaires pour l'installer correctement. Vous trouverez la structure interne du format de base de données, y compris sa table standard et les définitions de colonne, dans la section Windows Installer du kit de développement Platform SDK. Vous trouverez la dernière version du kit de développement SDK à l'adresse http://www.microsoft.com/msdownload/platformsdk/sdkupdate/  .

Les packages de Windows Installer sont stockés dans un fichier portant l'extension « msi ». Bien que le format de ces fichiers soit une implémentation propriétaire basée sur un stockage structuré OLE, il est aisé d'accéder au contenu d'un fichier msi à l'aide des outils fournis dans le kit Platform SDK. Le principal outil d'édition msi fourni par le kit Platform SDK a pour nom de code « Orca ». Comme l'illustre la figure 1 ci-dessous, la structure logique d'un fichier msi est très proche de celle d'une base de données relationnelle.

Figure 1. Illustration du contenu d'un fichier msi avec Orca

Outre ceux fournis par le kit de développement Platform SDK, il existe plusieurs outils tiers qui facilitent considérablement la création et l'administration de fichiers msi. Les principaux éditeurs sont les suivants :

• InstallShield (http://www.installshield.com/    )

• Wise (http://www.wise.com/    )

• Zero G (http://www.zerog.com/    )

Haut de page

Produits, fonctions et composants

Les packages de Windows Installer reposent sur une structure logique de produits, fonctions et composants qui décompose l'application en unités cohérentes de fonctionnalités. Les fonctions sont les entités du plus bas niveau qui permettent à l'utilisateur d'interagir avec l'installation alors que les composants sont les entités du plus bas niveau avec lesquelles le développeur de l'installation travaille. Ainsi, une application graphique peut être composée de deux fonctions : une fonction d'application centrale qui installe l'exécutable de l'installation (.exe) et une fonction d'images clipart qui installe une collection facultative d'images. La fonction principale de notre installation fictive peut comprendre deux composants. Le premier peut agir comme conteneur du fichier principal exécutable de l'application et des entrées de registre dont il dépend pour démarrer correctement. Le second peut comprendre un fichier .dll partagé et des informations d'inscription COM à enregistrer dans le registre pour que le sous-système COM les reconnaisse.

Haut de page

Caractéristiques de Windows Installer

Windows Installer est une technologie complexe offrant un nombre important de possibilités de personnalisation et de configuration. Cet article n'a pas pour objet d'explorer toutes les caractéristiques de Windows Installer. Nous allons simplement aborder les plus importantes d'entre elles.

• Programmabilité
  Windows Installer fournit un ensemble substantiel d'API ainsi qu'une interface d'automation complète permettant aux applications d'interagir avec Windows Installer, aussi bien dans le cadre du processus de création que pendant les processus d'installation et de maintenance.

• Personnalisation
  Il est possible de personnaliser de différentes façons le comportement, à l'exécution, d'un package d'installation. Vous pouvez ainsi développer une application prenant en charge la définition d'options spécifiques sur la ligne de commande ou créer un fichier spécial de transformation qui modifie le contenu du fichier msi au moment de l'installation, changeant de ce fait le comportement de l'installation. Le kit Platform SDK et la plupart des outils d'éditeurs tiers prennent en charge la création de fichiers de transformation.

• Installation à la demande
  Windows Installer prend en charge le concept dit de publication qui permet d'installer chaque élément d'une application (ou son intégralité) en fonction des seuls besoins de l'utilisateur. Grâce à son intégration au système d'exploitation, Windows Installer est capable de détecter si une application ou une de ses fonctions spécifiques est nécessaire. S'il existe une application susceptible d'éditer les fichiers .foo, par exemple, Windows Installer vérifie qu'elle est installée. Au besoin, il l'installe lorsque l'utilisateur double-clique sur un fichier .foo dans l'Explorateur Windows.

• Résilience
  De la même façon qu'il peut installer une application ou une fonction à la demande, Windows Installer peut réparer une application lorsque l'utilisateur interagit avec elle. Ainsi, lorsqu'un utilisateur souhaite exécuter une application en cliquant sur un raccourci du menu Démarrer ou en double-cliquant sur un fichier associé, Windows Installer est capable d'intercepter la requête et de vérifier que les éléments appropriés de l'application sont installés correctement. S'il détecte un problème, il lance une réparation avant l'exécution de l'application.

• Installation transactionnelle
  Une bonne part de l'action interne de Windows Installer est destinée à s'assurer que l'exécution d'une installation ne va pas pénaliser votre système si une opération essentielle du processus échoue. Windows Installer effectue cette vérification en créant un « script » interne des tâches à réaliser pour installer correctement l'application. Si un problème se produit pendant l'installation, le script peut annuler toutes les actions qui ont été entreprises et rétablir l'état initial du système.

• Résilience de la source
  Dans le cadre de la réparation d'une application après son installation, Windows Installer présente une caractéristique importante : il doit pouvoir accéder à une copie de la source d'origine de l'installation. Par exemple, si Windows Installer détermine qu'un fichier essentiel est manquant ou endommagé, il doit rechercher une copie intacte de ce fichier. La résilience de la source est un mécanisme qui permet à Windows Installer de rechercher l'installation d'origine dans plusieurs emplacements, puis d'inviter l'utilisateur à insérer le support correspondant s'il ne parvient pas à la trouver dans les autres emplacements. Un système de fichiers local, un partage réseau ou une URL Internet sont des exemples d'emplacement des sources. Windows Installer 3.0 a amélioré cette fonctionnalité et permet aux administrateurs de gérer plus facilement l'emplacement des sources.

• Mises à jour et correctifs
  Le cycle de vie d'un produit type ne s'arrête pas à l'installation de l'application. En réalité, la plupart des applications doivent être mises à jour ou modifiées pour permettre le déploiement de correctifs ou de nouvelles fonctions. Windows Installer prend en charge la création et la distribution de correctifs au niveau des octets. Ceci permet de déployer les correctifs et les mises à niveau en vue de distribuer des mises à jour d'application plus complètes. Dans sa version 3.0, Windows Installer a apporté des améliorations substantielles à l'application de correctifs en prenant en charge les séquences de correctifs et la possibilité de désinstaller ces derniers.

• Prise en charge des environnements gérés
  Dans un environnement de grande entreprise, il n'est pas rare que les systèmes soient verrouillés pour empêcher les utilisateurs d'installer des applications malveillantes qui remettent en cause l'intégrité de ces systèmes. Windows Installer comprend plusieurs fonctions permettant que certaines installations msi soient approuvées par l'administrateur système et puissent être exécutées dans ce type d'environnement verrouillé.

Haut de page

Présentation de ClickOnce

ClickOnce est une toute nouvelle technique de déploiement qui fait partie de la version 2.0 de .NET Framework. Elle a été présentée pour la première fois à la conférence PDC 2004 de Los Angeles. ClickOnce a pour but de faciliter le déploiement d'applications Web sur des applications client intelligentes, tout en garantissant un environnement d'exécution fiable. Pour déployer une application avec ClickOnce, il vous suffit de placer ses fichiers sur un serveur Web, un système de partage de fichiers ou un système de fichiers local, puis de fournir à l'utilisateur le lien vers le manifeste de l'application.

Si vous développez en Visual Studio 2005, la publication d'une application à l'aide de ClickOnce est une tâche très simple grâce à l'Assistant Publication. Pour accéder à cet Assistant, il vous suffit de cliquer avec le bouton droit de la souris sur le nom du projet dans l'Explorateur de solutions et de choisir Publier dans le menu contextuel. Vous pouvez également y accéder à partir de l'onglet Publier de la boîte de dialogue Propriétés du projet.

Figure 2. Assistant Publication de Visual Studio 2005

Le déploiement ClickOnce est contrôlé à l'aide de deux fichiers de manifeste XML : un manifeste de déploiement et un manifeste d'application.

Manifeste de déploiement

Le manifeste de déploiement sert à décrire le déploiement de l'application. Il comprend l'emplacement du manifeste d'application, les fichiers décrits dans celui-ci et le numéro 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>
<deploymentProvide
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 d'application sert à décrire l'application, les assemblys, les fichiers, les ressources et les autorisations nécessaires au fonctionnement de l'application. En outre, il indique l'emplacement des 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 de déploiement et d'application ont été créés, ils doivent simplement être copiés dans l'emplacement de déploiement avec 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 d'application. Ainsi, le manifeste de déploiement peut être expédié vers un disque physique. Une fois activé, il indiquera au moteur de ClickOnce où trouver le manifeste d'application. Cette fonction de ClickOnce est importante dans la mesure où elle permet de s'assurer que les utilisateurs ont la dernière version de l'application dès la première installation. Elle vous évite d'installer une version à partir d'un disque puis de rechercher immédiatement une mise à jour.

Lorsque l'utilisateur lance votre application, ClickOnce installe celle-ci ou la met à jour en fonction des paramètres de votre manifeste de déploiement. Si votre application nécessite des autorisations plus élevées, le système demandera à l'utilisateur les autorisations requises :

Figure 3. L'utilisateur se voit demander les autorisations requises

Lorsque l'utilisateur clique sur le lien Plus d'Infos dans le coin inférieur droit de cette boîte de dialogue, la fenêtre d'information ci-dessous s'affiche.

Figure 4. Informations complémentaires sur les avertissements de sécurité

Une fois que l'application est opérationnelle, l'emplacement à partir duquel elle a été déployée s'affiche dans la barre de titre et une icône spéciale se superpose à l'icône d'application. Lorsque vous placez le pointeur de la souris sur cette icône, un message spécial vous informe du contexte de sécurité dans lequel l'application est exécutée.

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

Remarque Lors de l'écriture d'applications .NET destinées à être exécutées dans un environnement sécurisé, il est très important que les exceptions de sécurité soient gérées de manière explicite. Ainsi, l'application reste stable et l'utilisateur comprend ce qui s'est passé en cas d'exception de sécurité.

Haut de page

Principales différences

Après cette rapide présentation des caractéristiques de Windows Installer et de ClickOnce, vous avez constaté les objectifs de chacune de ces techniques étaient très différents. Pour illustrer notre propos, examinons le tableau suivant :

Comme je l'ai mentionné plus haut, chacune de ses techniques a été conçue et développée avec des objectifs totalement divergents. Aucune des deux n'est censée remplacer l'autre. ClickOnce offre un ensemble de fonctions très intéressantes, dont la plupart ne figurent pas dans Windows Installer. Elles sont destinées spécifiquement aux développeurs créant des applications clientes intelligentes sur .NET Framework qui n'ont pas d'exigences particulières en termes de configuration. Windows Installer est une technique d'application de bien plus grande envergure, conçue à l'origine pour être extensible et permettre de surmonter tous les obstacles en matière de déploiement, y compris les applications .NET.

Haut de page

Comment choisir ?

En matière de choix de technique de déploiement, vous n'êtes pas tenu de vous limiter à une seule option, le tout étant de choisir l'outil approprié à la tâche requise. Bien qu'il n'existe pas de règle ni de réponse unique, certaines directives générales peuvent vous aider à prendre la décision qui convient à vos besoins.

• L'application installe-t-elle des composants COM ?

• Nécessite-t-elle l'enregistrement des composants pour COM-Interop ?

• Installe-t-elle des services ?

• Doit-elle être installée à un emplacement spécifique ou dans le GAC (cache de l'assembly global) ?

• A-t-elle des composants installés de façon conditionnelle en fonction du système d'exploitation ou de l'environnement d'exécution ?

• Nécessite-t-elle l'intervention de l'utilisateur au moment de l'installation ?

• Nécessite-t-elle une configuration des services de niveau système, tels que Active Directory ou COM+ ?

• Une fois installée, crée-t-elle des fichiers, écrit-elle dans le registre ou affecte-t-elle le système de sorte qu'il reste des ressources après sa suppression ?

Si vous avez répondu oui à l'une de ces questions, Windows Installer constitue aujourd'hui le meilleur choix pour vos besoins. Si, toutefois, vous n'êtes pas concerné par les scénarios décrits dans la liste ci-dessus, ClickOnce est l'option qui convient à votre solution de déploiement. Si vous souhaitez tirer parti des avantages spécifiques de ClickOnce, il est indispensable que vous compreniez très tôt dans le processus de conception de votre application les possibilités de cette technique. Si vous déployez une première version d'application avec ClickOnce puis constatez un peu tard que vous avez besoin de passer à Windows Installer, vous risquez de rencontrer des difficultés pour la mise à niveau. Afin d'éviter des écueils, planifiez soigneusement le déploiement à l'avance.

Haut de page

Utilisez à la fois Windows Installer et ClickOnce

Voilà la solution ! Oui, c'est bien ça. Maintenant que j'ai développé un argumentaire sur les différences d'implémentation de ces deux techniques, je vais vous déstabiliser en affirmant qu'il est possible d'utiliser ensemble les deux approches.

Windows Installer fournit des fonctions avancées pour interagir avec l'utilisateur pendant l'installation. Il s'agit souvent d'une étape cruciale dans le processus de déploiement. Il est important qu'une installation puisse interroger le système cible pour s'assurer qu'il satisfait aux exigences minimales de l'application. En outre, la plupart des applications ont tendance à interagir avec l'environnement d'exploitation. Cette interaction peut se traduire par l'écriture de fichiers journaux sur le disque, le stockage de données dans le registre, etc. Une application bien conçue doit avoir la possibilité de nettoyer ces données spécifiques de l'application lors de sa suppression du système. Tous ces éléments sont autant de concepts clés du déploiement qui ne figurent pas dans ClickOnce.

En revanche, Windows Installer a tout un processus de mise à jour et de correctif qui n'est pas aussi lisse et aussi 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 qui tire le meilleur parti des deux techniques.

Conception du programme d'installation de Windows Installer

Le concept de base consiste à créer une installation externe reposant sur la technique de Windows Installer. Cette installation se charge d'inspecter et d'interroger le système avant que l'application ne soit installée. Elle peut interagir avec l'utilisateur, collecter et stocker des informations de configuration, installer des assemblys dans le GAC, etc. Au moment de la désinstallation, elle se charge de nettoyer les ressources qu'en temps normal l'application aurait laissées. Elle peut ainsi désinstaller les fichiers, supprimer les fichiers journaux créés au moment de l'exécution, désinstaller les services, supprimer les assemblys du GAC, etc.

Intégrer notre application ClickOnce à notre installation est ensuite un jeu d'enfant. Comme les applications ClickOnce peuvent être activées via des URL Internet ou intranet, il nous suffit de créer, sur le système cible, un raccourci pointant vers le manifeste d'application. Pour ce faire, nous pouvons utiliser Windows Installer afin de créer un fichier .url à la volée, au moment de l'installation. Un fichier .url est un type spécial de raccourci, compatible avec le format de fichier standard .ini.

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

En utilisant Windows Installer pour créer ce fichier INI, il nous suffit ensuite d'ajouter une simple ligne dans la table IniFile.

Haut de page

Conclusion

Pour les applications qui ne sont pas limitées au niveau fonctionnel, ClickOnce se révèle être une excellente technique de déploiement qui fournit des avantages considérables et un modèle de mise à jour réservé jusqu'à présent aux seules applications Web. Pour les applications aux besoins plus complexes, Windows Installer reste la solution de déploiement toute indiquée. Ces techniques de déploiement partagent le même objectif de fiabilité lors de l'installation de votre application, mais les similitudes s'arrêtent là. Soyez sûr que si les fonctionnalités de ClickOnce sont amenées à se développer à l'avenir, Windows Installer est également fait pour durer. En attendant, soyez créatif et apprenez à les apprécier tous les deux !

Haut de page

À propos de l'auteur

Michael Sanford est président et architecte logiciel en chef de Xambi Solutions (http://www.xambi.com/    ). Avant de créer Xambi, Michael a occupé le poste de Président-directeur général de ActiveInstall Corporation, qui a été racheté par Zero G Software. ActiveInstall est connu pour ses solutions de création pour Windows Installer. Michael est Microsoft Certified Solution Developer, Microsoft Certified Systems Engineer et Windows Installer MVP. Vous pouvez consulter son blog sur le site http://msmvps.com/michaelhttp://msmvps.com/michael    .

Haut de page