Ce document est un ajout au manuel que nous … · Visual Basic 2005 – Déploiement d'une application 236 Tout ça était parfait… en autant que tout le monde suive les normes,

Insérer à la page 231 du manuel « Visual Basic 2005 – Introduction », version 3.0

Copyright © 2004-2006 Jacques Bourgeois

Ce document est un ajout au manuel que nous fournissons avec notre cours d’introduction à Visual Basic. Il est incomplet sans le manuel original. Toute reproduction ou utilisation en dehors de ce contexte est interdite à moins d’autorisation écrite de Jacques Bourgeois ([email protected])

Chapitre 6

Déploiement d'une application

► Stratégies de déploiement

► Fenêtre de commande

► Strong name

► Déploiement XCopy

► Déploiement ClickOnce

► Installation Windows conventionnelle

► Le projet de déploiement

Visual Basic 2005 – Déploiement d'une application 235

Vous êtes prêt

Ça y est, votre application fonctionne à merveille, performante, sans aucun bogue, presque sans utiliser le clavier ou la souris… sur votre station de développement.

Il reste à l’installer chez ceux qui vous ont payé pour la développer.

Dans certaines circonstances, une installation .NET est aussi simple que de copier un répertoire. Mais dans la vraie vie, les circonstances simples sont rares, et alors là, le niveau de complexité d’une installation .NET peut être de plusieurs ordres de grandeur au-dessus de ce que c’était pour des applications Windows traditionnelles, alors que les notions de sécurités étaient secondaires et que le Web et Windows étaient pratiquement deux entités indépendantes.

Il y aura aussi un petit handicap, tant que l’infrastructure .NET ne sera pas installée sur toutes les stations de travail. .NET devrait éventuellement venir avec Windows, mais ce n’est pas le cas présentement.

Notre but dans cette section du cours, qui est essentielle à moins que vous ne vous « amusiez » à créer des petites applications pour vos besoins personnels, est de vous présenter les différentes alternatives, avec des exemples concrets des mécanismes de déploiement les plus couramment utilisés.

Stratégies de déploiement

La majorité des applications modernes – et il est évident que vous ne développerez pas des applications « antiques » avec Visual Basic .NET – sont composées d’une foule de petits fichiers. Ce n’est pas nouveau, c’est comme ça depuis l’arrivée des environnements graphiques multitâches comme Windows.

Au début, les règles d’installation étaient très simples :

• L’application dans un dossier au choix de l’usager.

• Tout le reste dans le dossier système de Windows, puis enregistré dans la base de registres.

• Si le dossier système contient déjà un fichier que vous voulez y installer, vous vérifiez les versions, et vous écrasez celui qui s’y trouve déjà si votre version à vous est plus récente.


Tout ça était parfait… en autant que tout le monde suive les normes, ce qui n’était souvent pas le cas. Comme Windows n’intervenait pas dans les installations1, n’importe qui pouvait faire n’importe quoi, de sorte que ce n’importe qui pouvait passer outre aux règles. Une application qui ne veut plus partir parce que l’ocx version 9.8 dont elle a besoin a été écrasé par une version 1.0, c’est courant. Avoir 6 copies d’un même dll un peu partout sur l’ordinateur, sans jamais trop savoir lequel est en mémoire2 quand notre application en a besoin, c’est aussi courant.

Et ce sans compter les communications avec les applications roulant sur des plateformes autres que Windows.

Le développement d’applications Web a amené un semblant de solution en simplifiant le déploiement et en étant universel : tu mets tout sur le site Web et c’est fait. Comme l’entreprise a plus de contrôle sur son site Web que sur l’environnement Windows des utilisateurs, on réglait un grand nombre de problèmes.

Mais on en amenait de nouveaux à cause des limites intrinsèques des interfaces Web, du besoin d’avoir une connexion en permanence avec le serveur et une gestion de la sécurité souvent plus complexe parce que le site doit être visible sur Internet pour permettre le travail distant.

.NET venant fusionner les environnements Windows et Web, étant bâti dès le départ avec de la sécurité, et étant multiplateforme3, il peut corriger tous les problèmes (ou presque), et ce sans briser la compatibilité avec les anciennes applications. La séparation entre Windows et .NET est transparente pour l’utilisateur, mais permet un environnement d’une stabilité encore jamais rencontrée. Une application Windows roule dans Windows, et une application .NET roule dans .NET.

Soyons précis, .NET ne remplace pas le système d’exploitation. Il s’installe simplement comme une couche par-dessus. Alors que les applications Windows traditionnelles s’adressent à Windows dès qu’elles ont besoin de mémoire ou d’un dll, les applications .NET s’adressent à l’infrastructure .NET qui, en arrière-plan, finit utilise Windows, mais en gérant elle-même les assignations de mémoire et l’utilisation des dll dans son propre environnement.

1 Windows Installer est venu changer tout ça, mais pour des questions de compatibilité avec les anciennes applications, les problèmes existent encore, même si moins fréquents. 2 Windows empêche que deux copies (donc deux versions) d’un même dll soient simultanément en mémoire. Si la 2.0 est déjà chargée quand vous lancez votre application, c’est celle-là qui est utilisée, même si la version 9.8 est installée correctement dans le dossier système et que c’est celle-là dont a besoin votre application. 3 Pas entièrement, mais ça s’améliore continuellement.


Une application Windows peut utiliser des dll locaux, installés dans le Global Assembly Cache ou sur le réseau, faire appel à des services Web, afficher du contenu en HTML, ce qui peut rendre son déploiement beaucoup plus complexe qu’avant.

Une application Web a des droits restreints sur la station des utilisateurs, à moins de changer la configuration de la sécurité, ce qui peut devenir un travail à plein temps dans certaines entreprises.

Une bonne stratégie de déploiement commence dès la conception de l’application. Bien que du code dans un module, une classe compilée en dll ou en Web service, ce soit le même code, les façons d’appeler ce code ou de s’y « connecter » sont différentes.

Si vous commencez à écrire des routines dans un module et que vous vous rendez compte plus tard qu’il serait utile de séparer votre gros programme en plusieurs petites applications individuelles pour les différents types d’utilisateurs, vous allez regretter de n’avoir pas suivi notre cours avancé sur les objets et de ne pas avoir conçu le tout dans une librairie de classes4.

Si vous avez développé vos routines principales sous forme de services Web mais que vos patrons ou clients reviennent sur leur décision quant aux connections haute vitesse pour les usagers mobiles, la performance risque d’en prendre un coup.

Et qui est blâmé quand la performance est mauvaise?

Cas pratique : le calcul des taxes Qui n’a pas un jour ou l’autre à inclure dans une des applications des routines de calcul des taxes. Nous allons ici faire une petite analyse semblable à celle que vous devriez faire avant de cliquer sur l’icône de Visual Studio. Et gardez en tête que c’est une fonctionnalité bien simple dans une application, mais que vous devriez vous questionner de la même façon sur presque toutes les opérations demandées à votre programme.

Plusieurs options s’offrent à vous :

• Une méthode de calcul des taxes incorporée dans un module d’une application Windows, installée localement sur la station de l’utilisateur.

Pas commode du tout. Quand le taux ou le mécanisme de calcul change, il faut recopier la routine dans toutes les applications qui l’utilisent, les recompiler individuellement et les redéployer. On oublie ça!

4 Bien que nous n’ayons pas abordé ce sujet en détail durant le cours, vous vous rendez probablement compte à quel point l’utilisation des objets facilite notre travail. Vous aussi, vous pouvez concevoir vos applications à partir d’objets plutôt qu’à partir de méthodes traditionnelles.


• Développer l’application comme une application Web.

On simplifie les mises à jour, l’installation d’une application Web se faisant une seule fois et ne nécessitant pas de passer sur toutes les stations. Quand la taxe change, on modifie simplement la version de l’application qui est sur le site Web. On perd cependant la possibilité de travailler sans être connecté, et on réduit les possibilités au niveau des interfaces.

Pas possible. On y va donc d’une application Windows.

• Un dll installé dans le dossier de l’application.

On vient de se simplifier la tâche. On n’a pas à recompiler individuellement chacune des applications, seulement le dll. Il ne reste qu’à le recopier dans chaque dossier où un assemblage en a besoin. C’est moins complexe quand il y a un changement, mais reste qu’il faut pouvoir déterminer quelles sont les applications qui l’utilisaient dans le passé, et trouver où elles ont été installées chez chaque utilisateur. Finalement pas vraiment un avantage, si ce n’est qu’on n’a qu’une seule recompilation à faire.

• Un dll installé dans le GAC (page 31) de chaque station de travail.

Il est alors partagé par toutes les applications de l’ordinateur. On n’a qu’à le recompiler et à l’installer une seule fois à un endroit bien précis sur chacune des stations de travail qui en ont besoin. Ça commence à être plus intéressant, mais ça nécessite quand même une distribution à tous nos usagers. Rediriger les applications vers la nouvelle version du dll risque par ailleurs de demander une intervention supplémentaire.

Dans une petite entreprise de 10 employés, c’est relativement simple, mais si vous êtes l’Hydro Québec…

• Dans le cas où vous décidez d’y aller avec l’idée du GAC, il y a une possibilité supplémentaire : installer le truc comme un service Windows.

Un service est une application qui fonctionne continuellement, en arrière-plan. Les exemples les plus courants sont un logiciel antivirus, qui est là en permanence, et ne nécessite aucune intervention de l’utilisateur, sauf pour le configurer, le mettre à jour ou réagir quand un virus est détecté.

Si vos gens ont souvent à calculer la taxe, dans des applications variées, cette approche peut s’avérer intéressante. Le service étant toujours présent, il est disponible instantanément quand on en a besoin. Ça peut en améliorer la performance.

Mais comme il est toujours présent, il demande continuellement des ressources dans Windows, même quand il n’est pas utilisé. Ça peut diminuer la performance, annulant le gain qu’on visait peut-être par cette approche. Ce n’est d’ailleurs pas le type d’application pour laquelle les services ont été conçus. Si c’était le cas, vous auriez constamment dans l’environnement des dizaines de petites applications résidentes en attente et ne faisant rien.

Pas terrible comme idée non plus.


• Un dll installé sur le réseau interne

Parfait! Un seul dll pour tout le monde. Ça va engorger un peu la bande passante, parce que chaque fois que quelqu’un veut calculer la taxe, il doit y avoir une communication aller-retour avec le serveur, et que le tout se fait en XML, qui passe le montant de 10.95 $ en quelques dizaines d’octets seulement.

Mais en échange, la mise à jour est d’une simplicité désarmante, surtout si on doit la faire à tous les deux jours parce qu’on doit appliquer des taxes différentes dans les 54 états américains5 et les 12 provinces canadiennes6, sans compter la succursale qu’on vient d’ouvrir au Mexique.

Le 30 décembre – on s’y prend un peu d’avance – on recompile l’ancien projet après l’avoir modifié. Le 31 décembre au soir, on va simplement entrer au boulot quelques minutes pour installer sur le réseau le nouveau dll qui calcule maintenant la TVQ au nouveau taux de 2.3%, et qui ne tient plus compte de la TPS étant donné que le gouvernement libéral a enfin tenu sa promesse d’il y a 30 ans d’abolir la TPS quand il serait au pouvoir.

Le 2 janvier, tout le monde entre au travail et calcule ses taxes au nouveau taux, sans même s’en rendre compte. Tout le monde sauf… les travailleurs mobiles et ceux qui ont la chance de travailler en pantoufles et robe de chambre à partir de la maison et qui ne se connectent que rarement aux données de l’entreprise sur l’intranet, parce qu’ils n’ont pas la haute vitesse.

• Juste pour rendre les choses plus simples ☺, on peut aussi configurer un dll installé sur le réseau comme un Remote Service. Un dll qui est chargé et qui roule en permanence sur le réseau en attendant qu’une application l’appelle.

Ça évite d’avoir à lancer le dll chaque fois qu’un utilisateur veut calculer la taxe, ce qui serait onéreux en temps serveur.

• Pour régler le problème des utilisateurs en pantoufles dans leur salon ou une chambre d’hôtel, un service Web installé sur le serveur Web de l’entreprise.

Un service Web n’est rien d’autre qu’un dll auquel on accède par l’Internet. Comme tout le monde a l’Internet, tout le monde y a accès7.

C’est un monde idéal où, en fait, vous n’avez même plus le problème de mise à jour, parce qu’à bien y penser, vous n’avez peut-être même pas à écrire le code du service Web.

Quand votre application veut calculer la TPS, elle appelle le service Web à http://MinistreDuRevenu.qc.ca/CalculeTVQ, et voilà le travail. C’est le gouvernement qui fait la mise à jour, pas vous. On n’en est pas encore là, mais ça ne devrait pas tarder… nous avons eu des gens du ministère dans nos cours ☺.

5 Porto Rico n’est pas vraiment un état, mais presque. 6 Nanuvik n’est pas vraiment une province, mais presque. 7 Vous pouvez souvent programmer des dll sans trop penser à la sécurité, mais à partir du moment où tout le monde y a accès, on ne peut plus passer à côté.


En plus, comme ça deviendrait compliqué de maintenir les adresses Internet pour les 54 états américains et les 12 provinces canadiennes, sans compter la succursale qu’on vient d’ouvrir au Mexique, une compagnie de Salt Lake City a décidé de louer un service Web auquel vous pouvez vous abonner, et votre application s’y connecte pour faire les calculs de taxe partout dans le monde. Ils se spécialisent dans les taxes et s’occupent de tenir à jour leur service Web. De votre côté, vous vous occupez de votre application sans vous soucier des taxes.

Important Nous croyons qu’il est important de noter qu’il ne faut pas croire qu’à cause du ton léger sur lequel nous abordons le sujet, toute cette discussion est une fabulation. Il s’agit ici d’un exemple tout à fait plausible, la technologie .NET permettant ce genre de développement. Microsoft l’encourage d’ailleurs fortement, quoique un peu trop à notre avis (très personnel).

Note : ce qui suit est une opinion personnelle. Si on écoute Microsoft et quelques autres, un service Web, c’est la fin du monde tel qu’on le connaît, et tous les autres trucs, comme les formulaires Windows, ne sont là que pour les demeurés. Plus personne ne programme (sauf les concepteurs de services Web), tout le monde se « plogue » sur des services Web. Il y a quelques années, on disait aussi que Java allait remplacer tous les autres langages. Or il est en train de se faire remplacer lui-même.

Et ce sera aussi la fin du monde pour vous la journée où le lien http avec l’intranet, Québec ou votre fournisseur de service de Salt Lake City ne fonctionnera pas parce que votre fournisseur de lien haute vitesse8 a un pépin technique ou vient de déménager pour Tombouctou sans avertir d’avance. Qu’advient-il de votre application quand Salt Lake City (ou un des douzaines de fournisseurs spécialisés dont vous avez loué les services pour votre application) fait faillite ou passe au feu?

L’idée est donc problématique pour le calcul de taxes dont on a besoin dans presque toutes nos applications stratégiques. Désolé, vous repasserez à la caisse un peu plus tard, un de nos 50 fournisseurs est en panne.

Mais dans certaines circonstances, particulièrement si vous les développez à l’interne pour vos besoins à vous, les services Web peuvent s’avérer être une approche très intéressante.

• Une application ClickOnce (page 249), nouvelle technologie apparentée au One-Touch Deployment dans la version 2003.

C’est une application Windows, déployée et mise à jour automatiquement, sans intervention de l’utilisateur et avec un minimum d’intervention de la part des programmeurs et des gestionnaires de système.

8 Ça fait déjà 2 fournisseurs externes dont vous êtes dépendant seulement pour calculer les taxes.


C’est tout nouveau, mais ça marche, et c’est un des aspects les plus emballants de la version 2005. Ça marchait aussi dans la version 2003, mais avec des contraintes qui empêchaient beaucoup son utilisation.

__________

Comme vous pouvez le constater, et comme plusieurs le disent, programmer en Visual Basic est très facile. C’est le déploiement qui est compliqué. Il n’y a pas de solution miracle, ni de solution idéale. Comme c’est souvent le cas en informatique, malgré qu’elle laisse croire à des possibilités sans limites, toute solution que vous adopterez quant au déploiement de vos applications (en fait, surtout le déploiement des composantes utilisées par vos applications) sera un compromis. Le but est de faire le meilleur compromis possible.

Nous seulement devez-vous tenir compte de où les différentes composantes seront installées, mais aussi de « comment » elles seront déployées.

Vous pouvez tout mettre dans le même paquet pour faciliter un déploiement XCopy (page 248) et l’installation est très facile, l’application est certaine d’avoir tout ce dont elle a besoin (en autant que l’environnement .NET soit présent). La mise à jour peut cependant devenir un cauchemar.

Vous préférerez peut-être créer un programme d’installation, qui peut être un simple fichier batch ou VBScript, un fichier .exe construit juste pour ça en vous aidant des objets du namespace System.Configuration.Install, un fichier .msi généré par un projet de déploiement Visual Studio (page 261) ou un logiciel commercial dispendieux mais reconnu comme Install Shield (www.macrovision.com/products/flexnet_installshield).

Il n’est pas rare de voir un mélange d’approches.

L’installation peut devenir un cauchemar.

Et une fois qu’on est réveillé de celui-là, ce sont les communications entre les composantes qui peuvent causer des problèmes. Les ennuis de connexion réseau sont devenus relativement rares et les communications Internet de plus en plus rapides et fiables. Mais si un dll requis par l’application est inaccessible, même s’il est tout petit et ne fournit qu’une seule méthode, .NET va refuser de lancer le programme.

Notez que cette complexité n’est pas un problème de Visual Basic, de .NET, d’Internet ou de Windows. Même si nous sommes programmeurs avant d’être philosophes, nous ne pouvons plus passer à côté : c’est un problème de modernité. Même les menuisiers ont à répondre à des questions du même genre. Dans le temps, assembler deux planches, ce n’était pas compliqué : un marteau et un ou plusieurs clous. Aujourd’hui, y’a aussi les vis, les gougeons, une panoplie de colles, et tous les trucs « tel qu’annoncé à la télé ». Utilisez le mauvais truc, et les planches ne tiendront pas ensemble.

Prendre les bonnes décisions dans les premières étapes de la planification de l’application est donc très important. Une fois que l’application est terminée, il faut aussi s’assurer que les pièces du casse-tête vont bien s’imbriquer les unes


dans les autres. Il suffit qu’un morceau ne soit pas à la bonne place pour qu’on soit incapable de faire fonctionner la « patente ».

Si c’est bien fait, une fois que c’est fait, ça reste bien fait. Vous ne risquerez plus, comme c’était le cas avant .NET, de voir votre application se « casser » ou se mettre à se comporter bizarrement quelques semaines ou quelques mois9 après son installation à cause d’autres installations qui viennent détruire la vôtre. Microsoft a appris beaucoup depuis le lancement de Windows en 1985, et comme .NET casse avec la compatibilité et n’a plus à supporter d’anciennes applications, ils peuvent finalement mettre à profit leur expérience et corriger les erreurs du passé.

Fenêtre de commande

Important Dans ce chapitre, nous allons utiliser plusieurs outils qui ne sont pas disponibles dans l’environnement Visual Studio, et doivent être lancés sur une ligne de commande DOS, ce qui demande normalement de connaître le chemin d’accès des outils.

Malheureusement, ces outils sont éparpillés un peu partout dans l’environnement, et leur localisation change parfois d’une version à l’autre.

Pour pouvoir les utiliser plus facilement, lancez la fenêtre de commande par le Command Prompt que vous trouverez dans les Visual Studio .NET Tools sous Start►Programs...Microsoft Visual Studio… (Démarrer►Programmes...Microsoft Visual Studio…) dans Windows.

Ce raccourci rajoute dans le PATH de l’environnement DOS le chemin d’accès à tous les outils .NET, de sorte que vous n’avez pas à savoir où ils sont localisés et à taper des commandes incorporant le chemin d’accès.

Strong name

Plusieurs des types d’installation étudiés ici demandent que l’application soit signée électroniquement. Nous allons donc aborder le déploiement en voyant comment vous pouvez signer vos assemblages, qu’il s’agisse d’applications ou de dll.

9 Ceci dit sous toute réserve, étant donné qu’on ne fait que commencer à déployer des applications .NET, et que la majorité des applications .NET actuellement installées ont été développées et installées à l’interne. L’avenir pourrait toujours vous causer des surprises, mais en théorie, vous avez entre les mains quelque chose de robuste.


Notez que même si une application Web n’utilise pas ces mécanismes, les dll qu’elle utilise sont habituellement signés. Il est donc utile de comprendre le concept.

Important Dans le cadre d’une séance de formation condensée comme celle-ci, toute discussion que nous pourrions avoir sur les mécanismes de signature électronique serait inévitablement incomplète, et en sécurité, incomplet = pas sécuritaire, donc inutile. Nous préférons donc nous limiter à donner la base des concepts qui sont essentiels pour pouvoir fonctionner en Visual Basic .NET, en vous avisant très clairement que si c’est important pour vous, il vous faudra étudier la question plus en profondeur.

Au minimum, un assemblage est identifié par son simple name, qui est une combinaison des éléments suivants :

• Le nom du fichier.

• Le numéro de version.

• La culture (langue, séparateur décimal, etc.).10

Pour assurer une reconnaissance complète et pouvoir être sécuritaire, ce n’est pas suffisant. N’importe qui peut reproduire un dll ayant le même nom de fichier, le même numéro de version et la même culture qu’un dll déjà installé, l’écraser et se faire passer pour Microsoft ou pour vous.

Pour ce faire, on va ajouter un 4e élément d’identification, une signature électronique appelée un strong name11. On dit qu’un fichier possède un strong name quand il possède les quatre attributs suivants. :

• Le nom du fichier.

• Le numéro de version.

• La culture (langue, séparateur décimal, etc.).

• Une signature (public token) propre au concepteur de l’assemblage.

Un assemblage qui ne possède qu’un nom simple peut éventuellement causer des problèmes :

• Être confondue avec une autre possédant le même nom simple. C’était la cause de beaucoup des problèmes d’installation dans le passé. Windows était incapable de faire la différence entre Toto.dll version 34.6 qui a une grosseur de 1.2Ko et Toto.dll version 0.01 qui a une grosseur de 0.4Mo.

10 Si la culture n’a pas été spécifiée lors de la compilation de l’assemblage, elle est considérée comme étant « neutre ». On ne spécifie la culture que pour les dll. La culture de l’application est déterminée par le code, en ajustant la culture du thread sur lequel roule l’application (page 299). 11 La documentation fait parfois mention d’un shared name, une « traînerie » des premières versions bêta.


• Être modifiée après sa compilation sans que .NET puisse s’en rendre compte : mauvaise transmission électronique, support (disque dur ou CD) corrompu, intervention malveillante (virus), etc.

Un Strong name permettra à l’environnement d’exécution de .NET d’empêcher que ces problèmes ne surviennent.

.NET utilise le strong name pour s’assurer qu’un n’a pas été modifié, et que les assemblages utilisés par une application sont exactement ceux qui ont utilisés lors de la compilation. Il assure que l’application est telle qu’elle a été conçue, sans aucune corruption possible.

Ça permet aussi à .NET de faire la discrimination entre plusieurs versions du même assemblage installées dans un environnement donné. Fini ce qu’on appelait communément le DLL Hell.

Si une application ne peut être lancé telle que compilée, bit pour bit, incluant les fichiers dont elle dépend, .NET refuse de la lancer.

Pour pouvoir faire certains type d’installation, comme le déploiement ClickOnce (page 249) ou installer vos composantes partagées dans le GAC (page 31), vous devrez absolument avoir un strong name. Un dll compilé avec un nom simple doit absolument résider dans le répertoire de l’installation, ce qui limite énormément les stratégies de déploiement.

Important Les assemblages avec un nom simple ne contiennent, en autant que .NET est concerné, aucune notion de numéro de version. Si vous voulez éviter des problèmes éventuels de mise à jour ou de compatibilité entre les composantes, compilez toujours avec un strong name.

À moins de développer des applications personnelles ou des applications de démonstration (comme par exemple pour un cours), vous n’utiliserez à peu près jamais les noms simples.

Mais si la performance est pour vous plus importante que la sécurité ou un support plus facile de vos applications, sachez que l’utilisation d’un strong name a un impact négatif sur le temps de chargement de l’assemblage, et peut rendre plus complexes les mises à jour des applications.

Le mécanisme implique qu’au moment de la compilation, une application est encryptée avec un code contenu dans une clé privée (un fichier localisé dans votre environnement de programmation). Cette clé privée est conservée par le programmeur qui ne doit en aucun cas la fournir à quelqu’un d’autre, sauf d’autres programmeurs appelés à utiliser la même « signature ».

Pour pouvoir exécuter l’application, celle-ci doit être validée avec une deuxième clé, appelée une clé publique. Il s’agit simplement d’une information permettant de valider que l’application a bien été signée avec votre clé privée. Vous distribuez la clé publique à tous les gens qui doivent utiliser votre application.


Création d’un strong name Certains utilisent la même clé pour tous leurs projets. D’autres utilisent une clé distincte pour chaque projet. Microsoft suggère habituellement la deuxième approche, et ils prêchent par l’exemple : tous les dll du framework sont signés avec une clé unique.

Nous sommes de leur avis et considérons que la gestion d’un grand nombre de clés peut devenir complexe. N’oubliez pas que si vous compilez exactement le même assemblage deux fois avec des clés différentes, le système les considérera comme deux assemblages complètement distincts, ce qui mènera dans bien des circonstances le système à installer deux copies d’un même dll.

Les clés privées et publiques sont conservées dans un fichier qui sera utilisé par le compilateur pour signer l’assemblage. Le mécanisme est tout à fait transparent pour le programmeur. Votre rôle consiste uniquement à créer ce fichier et le référencer pour que le compilateur sache qu’il doit l’utiliser.

Ce fichier reste chez vous. Vous ne le distribuez pas avec votre application. Normalement, la clé publique est incorporée dans l’application elle-même au moment de la compilation. Il y a cependant des alternatives. Consultez l’aide en ligne à Strong Name Tool si vous avez des besoins particuliers.

Visual Studio 2005

La clé est créée à partir des propriétés du projet, dans l’onglet Signing, en sélectionnant New dans la liste de clés, qui contient déjà les clés utilisées dans le projet courant. Vous pouvez aussi faire un Browse pour aller chercher une clé existante.

Comme la clé va éventuellement servir à vous identifier, on suggère d’ajouter un mot de passe12. Ce mot de passe vous sera redemandé chaque fois que vous voudrez signer un projet avec cette clé. Ça empêche un « voleur » de fichier de pouvoir utiliser votre clé pour signer ses propres projets.

Le compilateur insiste pour que la clé réside dans le dossier du projet. Si vous partagez une clé, vous en aurez donc une copie dans chaque projet.

Activer la case à cocher Sign the assembly est suffisant pour que la signature soit appliquée au projet à la compilation.

12 Les clés protégées par un mot de passe seront générées dans un fichier portant l’extension .pfx, les autres dans un .snk.


Visual Studio 2002 et 2003

La notion de clé protégée par un mot de passe n’existe pas, et l’environnement de Visual Studio ne vous fournit pas d’interface pour créer et référencer la clé.

Vous devez utiliser un logiciel sur ligne de commande : Sn.exe.

Sn va générer le fichier contenant les clés privées et publiques.

⇒ Lancez la fenêtre de commande (voir page 242).

⇒ Une fois dans la fenêtre de commande : SN –k Toto.snk

Sn n’ajoute pas d’extension au nom de fichier si vous n’en spécifiez pas. On recommande snk, qui est reconnu par le système comme une strong name key.

Utilisation de la clé privée

⇒ Générer la clé ne signe pas votre projet. Pour ce faire, dans Visual Studio 2005, vous devez aller dans l’onglet Signing des propriétés de projet, activer la cache à cocher Sign the assembly, et faire pointer à votre fichier.

La case Delay sign only génère une clé temporaire qui est utilisée uniquement durant le développement. C’est normalement utilisé dans les compagnies où les programmeurs ne sont pas autorisés à utiliser la signature électronique de la compagnie. Comme l’environnement .NET ne traite pas les assemblages signés de la même façon que les autres, particulièrement pour les librairies de classes (dll), ça permet de fonctionner, dans l’environnement de développement comme si l’application était signée. Un administrateur passe ensuite avec la « vraie » signature sur la version finale avant de la déployer.

2002-2003 Vous devez faire manuellement le travail fait automatiquement par l’environnement dans la version 2005, en ajoutant la ligne suivante dans le fichier AssemblyInfo.vb qui accompagne votre projet. Remplacer <Fichier> par le nom du fichier contenant vos clés, incluant le chemin d’accès : <Assembly: AssemblyKeyFileAttribute("<Fichier>")> Pour une signature temporaire : <Assembly: AssemblyDelaySign()>

Le compilateur va détecter la présence de cet attribut et signer votre assemblage en y incorporant la clé publique.

Un strong name permet d’assurer l’intégrité d’une application. Comme une application ne vient généralement pas toute seule dans son exe, mais avec une ribambelle de dll, on ne peut assurer l’intégrité de l’application si un des dll n’est pas signé. Il pourrait être remplacé par un autre, et compromettre ainsi la sécurité.


Important Pour pouvoir compiler avec un strong name, toutes les références doivent donc aussi avoir été compilées avec un strong name.

Interop / DLL com Le besoin de signer tous les dll utilisés par un assemblage qui a été signé avec un strong name cause un petit problème particulier pour les fichiers interop, ces dll intermédiaires qui sont créés pour pouvoir appeler un dll ActiveX à partir d’un assemblage .NET (voir page 84). En effet, un interop est compilé automatiquement par le système quand vous référencez le dll ActiveX, et c’est fait sans signature, ce qui empêche la compilation avec strong name des assemblages qui utilisent l’interop.

Pour corriger ce problème, vous devez compiler manuellement le fichier interop plutôt que de laisser l’environnement de programmation le faire pour vous. Pour ce faire, utilisez l’application TlbImp.exe, qui est fournie dans les outils de Visual Studio. Lancez cette application à partir d’une fenêtre de commande (page 242) et créez l’interop à partir de la type library 13 du dll que vous voulez référencer.

⇒ Création d’un interop signé scripting.dll à partir du serveur ActiveX scrrun.dll : TlbImp scrrun.dll /out:scripting.dll /keyfile:JBFI.snk

Un assemblage interop signé de cette façon est dit primaire (primary interop assembly).

Une fois ce travail fait, plutôt que de référencer le dll dans l’onglet COM, vous le référencez avec un Browse vers l’interop que vous avez créé, à partir de l’onglet .NET de la fenêtre de références.

Signature digitale Si vous voulez aller un peu plus loin, particulièrement pour des applications Web où l’on exige généralement plus de sécurité, vous pouvez créer une signature digitale Authenticode, un standard de Microsoft.

C’est un mécanisme de signature que vous ajoutez au strong name, pas une alternative. Un interop permet de valider qu’un assemblage et ses composantes sont tels qu’ils étaient lors de la compilation, rien de plus. Une signature Authenticode permet en plus d’identifier le créateur de la composante.

13 Dans le monde COM, la type library joue une partie du rôle du manifeste dans .NET, en listant toutes les classes, propriétés et méthodes disponibles dans le dll. Dans la majorité des cas, cette librairie est incorporée dans le dll, et vous n’avez qu’à référencer ce dernier. Pour diminuer la taille des dll ou pour des besoins de documentation ou de sécurité, certains programmeurs préfèrent parfois séparer le dll et la type library, qui est alors enregistrée dans des fichiers portant l’extension .olb ou .tlb. Dans de tels cas, c’est ce fichier séparé qui doit être utilisé lors de l’appel à TlbImp.


Comme vous créez vous-même une signature Authenticode, elle n’est pas aussi fiable qu’un certificat fourni par une compagnie privée, ce que vous demanderont parfois certains clients comme les banques ou l’armée. Le plus connu de ces fournisseurs de signatures est Verisign (www.verisign.com).

Authenticode peut cependant s’avérer suffisant pour une application intranet ou pour un échange d’applications entre partenaires qui se font confiance. Il a l’avantage d’être gratuit.

Si l’utilisation d’une signature digitale plus élaborée que le strong name vous intéresse, consultez l’aide en ligne à MakeCert.exe, Cert2Spc.exe, ChkTrust.exe et SignCode.exe, qui sont les outils utilisés pour créer et valider des certificats.

Déploiement XCopy

On n’installe pas une application, on la déploie14.

Il y a tant de façons de s’y prendre que le terme « installation » devient un peu limitatif. Le programme peut-être exécuté à partir d’un .exe installé sur la station de travail, soit dans une fenêtre Windows, soit dans une Console ou dans un navigateur Internet. Il peut être installé sur la station de travail, sur un serveur réseau ou sur un serveur Web. Et comme une application moderne est généralement morcelée en plusieurs dll, on peut se retrouver avec toute une gamme de combinaisons de ces différentes localisations. Il est souhaitable qu’une application soit entièrement .NET, mais il est fort possible, surtout en ces premières années de diffusion de l’environnement, qu’il utilise une certaine quantité de code inclus dans des serveurs COM.

L’infrastructure .NET doit être installée sur la station voulant utiliser votre application, de même que le msvbvm60.dll de Visual Basic 6 si vous utilisez des composantes créées en Visual Basic 6, et le ou les mfc (Microsoft Foundation Classes) correspondant aux dll C++.

Paradoxalement, l’installation peut, dans certains cas, devenir d’une simplicité incroyable.

Une petite application .NET à 100% peut parfois être installée en copiant tout bêtement les fichiers propres à l’application ainsi que les composantes dont elle a besoin dans un dossier quelconque de la station de travail de l’utilisateur.

14 Certains auteurs parlent aussi de la « publier ».


C’est ce qu’on appelle une installation XCopy, en référence à la vieille commande MS-DOS qui permettait de copier des fichiers en lots. Vous pouvez d’ailleurs réellement installer certaines applications en utilisant une instruction XCopy dans une fenêtre de commande DOS ou à partir d’un fichier batch (.bat). Les plus modernes préféreront faire glisser des fichiers d’un dossier à l’autre dans Windows Explorer. Pour ceux qui ont eu à préparer des installations pour des applications Windows conventionnelles, ça ressemble à un cadeau du bon Dieu.

Une installation XCopy risque cependant d’être assez rare.

Elle exige en effet qu’au minimum, l’infrastructure .NET soit déjà installée sur la station de travail de l’utilisateur. Il faut que les librairies .NET, donc tous les dll contenant les classes .NET, soient disponibles.

Si c’est le cas, des applications comme celle que nous avons utilisée durant le cours peuvent effectivement s’installer correctement avec un XCopy.

Notez que si votre application contient des fichiers qui doivent être modifiés par les usagers, la technique du XCopy souffre d’un handicap majeur si vous voulez distribuer vos applications sur des CD comme c’est de plus en plus courant de le faire : les fichiers copiés seront en lecture seule et donc non modifiables. Il vous faudra intervenir d’une façon quelconque pour changer les attributs de ces fichiers.

Elle exige aussi qu’en dehors des composantes intrinsèques de .NET, toutes les composantes utilisées par votre application (librairies de classes externes, contrôles que vous pourriez avoir achetés de tierces parties, fichiers de données) puissent fonctionner correctement à partir du dossier ou des sous-dossiers où vous effectuez le XCopy.

Ce n’est pas toujours le cas. Ce qui est bien dommage, parce qu’entre une installation XCopy et une installation un peu plus dirigée, il y a un abîme de différences.

Contrairement à une application déployée par ClickOnce, mécanisme étudié ci-dessous, une application installée par copie n’a pas à posséder de signature digitale.

Déploiement ClickOnce

C’est mécanisme de déploiement privilégié par Microsoft pour les applications conçues dans Visual Studio 2005.

2002-2003 L’équivalent de ClickOnce s’appelait autrefois No-Touch Deployment. L’idée était sensiblement la même, mais l’implémentation était très différente et beaucoup plus limitée. Cherchez l’aide en ligne pour la technique à suivre. Bien que ça soit utilisé dans certaines entreprises, on préfère habituellement une installation standard, par l’intermédiaire de Windows Installer, une technique étudiée à la page 260.


L’application et ses dll sont installés dans un dossier du serveur Web ou du réseau de l’entreprise. Les utilisateurs lancent l’application à partir d’une page Web ou d’une icône pointant au server Web où à un dossier.

L’application et les composantes requises sont téléchargées et installées sur la station de travail par un mécanisme d’installation très simple. La copie locale peut être ultérieurement utilisée même s’il n’y a pas de connexion réseau. Quand l’appareil est connecté cependant, les nouvelles versions des assemblages sont détectées et installées automatiquement. On parle alors d’une Installed application.

Si vous préférez, vous pouvez configurer ClickOnce pour une Launched application. Dans un tel cas, l’application est copiée du serveur sur la station de travail, mais n’est pas installée. L’utilisateur n’a pas d’icône pour la lancer ultérieurement, il devra retourner sur la page Web à partir de laquelle il a lancé l’application, et l’application ne sera pas disponible s’il n’a pas de connexion Internet.

ClickOnce combine tous les avantages d’une application Windows (disponible hors réseau, interfaces sophistiquées, etc.) avec la facilité de mise à jour d’une application Web (une nouvelle version est automatiquement disponible).

Avantages et désavantages sur Windows Installer Les avantages sont à la fois simples et très importants

• Les mises à jour sont grandement facilitées. Elles sont faciles à configurer à partir du réseau et complètement transparentes pour l’utilisateur.

• Une installation ClickOnce utilisant des composantes COM n’a pas à utiliser la base de registre, et on peut donc avoir plusieurs versions différentes des composantes COM roulant en parallèle (side-by-side execution), ce qui n’est pas possible avec une installation standard.

• ClickOnce permet au besoin de ramener facilement une application à une version antérieure si on détecte des problèmes avec une nouvelle version. Pour faire la même chose dans Windows Installer, il faut généralement désinstaller la nouvelle version avant de réinstaller la vieille.

Les limites de cette solution sont cependant telles que ça la rend impraticable dans certaines circonstances. C’est considéré comme une application provenant de l’intranet ou de l’Internet, alors par défaut, la sécurité empêche une application ClickOnce de faire bien des choses comme par exemple :

• Vous ne pouvez spécifier le dossier d’installation, il est géré par le framework et créé avec un nom cryptique15 sous C:\Documents and Settings\<Utilisateur>\Local Settings\Apps.

• Ne peut s’installer en tant que service ou dans le GAC.

15 Quelque chose comme 2TVB0OTC.214\PJJZGQ9T.CGL.


• Ne peut travailler avec la base de registre.

• Ne peut travailler dans les fichiers locaux. Elle peut cependant utiliser de l’Isolated Storage pour lire et écrire dans des fichiers locaux privés.

• Impossible de personnaliser les installations (comme par exemple de demander à l’utilisateur s’il préfère une application anglaise ou française16) ou de faire des installations conditionnelles.

Important Une application déployée sous ClickOnce n’ayant pas les mêmes droits qu’une application Windows standard, la décision de déployer selon ce mécanisme doit être pris au tout début du projet de développement.

Publication d’une application ClickOnce

Sécurité

Une application ClickOnce étant installée à partir d’une connexion http, on se butte inévitablement à des problèmes de sécurité. Pour pouvoir installer une application avec ce mécanisme, vous devez donc dans un premier temps signer électroniquement l’application et ses manifestes (concept étudié à la page 259).

L’application elle-même est signée avec un strong name (page 245) après avoir activé la case à cocher Sign the assembly dans l’onglet Signing des propriétés du projet.

Pour signer les manifestes, activez l’option Sign the ClickOnce manifest. Sélectionnez ensuite une clé. Une discussion en profondeur sur le choix et l’acquisition ou la création d’une clé déborde du cadre de ce cours. La procédure est présentée à la page 245. Vous trouverez de l’information supplémentaire à partir de la page How to: Sign Application and Deployment Manifests de l’aide en ligne.

Si vous créez vous-mêmes votre clé à partir de Visual Studio, assurez-vous de créer une clé avec mot de passe (extension .pfx) puisque seules ces clés sont acceptables pour signer une installation ClickOnce.

Sans être familier avec les concepts de signature, vous pouvez toujours faire des essais en utilisant une clé temporaire, créée par le bouton [Create Test Certificate] dans l’onglet Signing.

Une application installée à partir d’un disque compact est considérée comme locale et s’installe sans poser de question à l’utilisateur, ayant automatiquement presque tous les droits sur la station.

16 L’application peut gérer ce genre d’options à l’interne, mais elle devra dans cet exemple précis avoir été conçue bilingue, le processus d’installation par défaut ne permettant pas à l’utilisateur de choisir entre deux versions différentes.


Une application ClickOnce est cependant installée à partir de l’intranet ou de l’Internet, et ses droits sont limités par défaut. Lors de son installation, l’utilisateur se fait demander s’il accorde des droits à l’application, ce qui peut être « mêlant » pour certains.

Pour simplifier l’installation, vous pouvez toujours demander à l’administrateur des stations de vous fournir un trust licence file, un fichier que vous pouvez joindre à votre application lors de la compilation pour lui donner des droits étendus chez les utilisateurs. Consultez l’aide en ligne à How to Specify a Trust License for a ClickOnce Application, en n’oubliant pas de jeter un coup d’œil aux See Also dans le bas de la page.

Exemple concret

Une autre alternative est de configurer les permissions requises par votre application dans le code. La sécurité .NET est un sujet complexe et nous n’entrerons pas dans les détails. Les curieux pourront passer quelques heures dans l’aide en ligne en cherchant les entrées parlant du code access security.

Mais pour simplifier la tâche, Microsoft a créé une interface qui vous permettra de définir facilement les droits requis, et qui générera le code nécessaire pour vous. Voici un exemple de son utilisation à partir de notre application de test.

⇒ Passez dans Project►<projet> Properties...Security.

⇒ Activez la case à cocher Enable ClickOnce Security Settings pour activer l’onglet.

Par défaut, la sécurité est réglée à full trust, comme une application installée à partir du réseau ou d’un CD. Vous devez changer ce comportement si l’installation se fait à partir de l’intranet ou de l’Internet.

⇒ Indiquez qu’il s’agit d’une partial trust application et qu’elle sera exécutée à partir du Local intranet.


Vous noterez entre autres que l’environnement indique qu’une application provenant de l’intranet ne possède pas la FileIOPermission, et ne pourra donc pas utilise le système de fichiers standard sur le disque dur de l’utilisateur si on l’installe à partir de l’intranet. Par contre elle possède l’IsolatedStoragePermission, qui permet d’utiliser des fichiers dans un répertoire isolé créé et géré par .NET. On y revient un peu plus loin.

⇒ Cliquez sur le bouton [Calculate Permissions]. L’application est compilée puis analysée pour voir si elle répond aux droits d’une application provenant de l’intranet. Ce n’est pas le cas pour la nôtre. L’outil ne vous indique malheureusement pas quelles permissions ont échoué l’analyse, uniquement que dans son état actuel, l’application ne peut rouler qu’en mode full thrust, donc être installée localement avec un programme d’installation Windows standard.

⇒ Vous pouvez cependant vous aider en réglant l’environnement de débogage pour qu’il fonctionne comme si l’application provenait d’un URL donné plutôt que de rouler localement comme c’est le cas dans Visual Studio. Vous pouvez régler l’environnement en ce sens sous le bouton [Advanced] de l’onglet Security après avoir spécifié que vous voulez un partial trust. Si vous activez Debug this application with the selected permission set, l’environnement de développement exécute l’application en sandbox mode, comme si elle provenait de l’intranet.

⇒ Si vous lancez alors l’application, vous aurez une erreur de sécurité parce que l’application tente d’écrire sur le disque dur et que c’est interdit par une application provenant de l’intranet.

On vous offre cependant suffisamment d’information pour que vous puissiez régler le problème.


Important Attendre à la fin du développement pour déterminer d’où sera installée votre application est mortel. Comme vous pouvez le constater, les changements à apporter peuvent être majeur. C’est donc une décision à prendre dès le départ. Les réglages que nous venons d’activer pour notre application auraient dû être faits dès le début du développement pour une application destinée à être installée par ClickOnce.

Comme indiqué sur la première ligne, dans ce cas précis, nous pourrions régler le problème en utilisant un IsolatedStorageFileStream plutôt qu’un fichier installé dans le répertoire de l’application.

L’isolated storage est un système de répertoire créé par .NET et réservé à l’application qui en fait la demande. Comme le programme ne peut pas écrire n’importe où sur le disque dur et que le répertoire ne peut être utilisé par d’autres applications, le mécanisme est considéré comme sécuritaire et requiert donc un niveau de sécurité plus faible que les fichiers auxquels on accède par System.IO.

⇒ Une autre alternative serait d’ajouter la permission requise au projet, ce que vous pouvez faire en activant Add Permission to the project dans la liste d’actions en bas de la fenêtre d’erreur.

Si vous retournez dans les propriétés du projet après avoir activé cette option, vous constaterez que le FileIOPermission est maintenant réglé à Include.

Important Ça ne donne pas automatiquement le droit à votre application d’écrire sur le disque dur de l’utilisateur.

L’environnement a simplement ajouté la ligne suivante dans le manifeste d’installation de l’application (le fichier app.manifest) :

<IPermission class="System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" />

On n’a pas nécessairement réglé le problème, mais il sera détecté à l’installation, pas à l’exécution, indiquant à l’administrateur qu’il doit configurer la sécurité de l’ordinateur pour accorder les FileIOPermission à notre application17.

Vous pouvez donc vous entendre avec l’administrateur pour qu’il accorde à votre application des droits qu’elle n’a pas par défaut. Comme pour tout le reste, c’est cependant quelque chose qui doit être convenu à l’avance, avant de commencer à coder.

17 Un sujet qui déborde du cadre de ce cours mais qui nécessite d’être expliqué brièvement. Le framework s’installe avec des options de sécurité par défaut. Ces dernières peuvent cependant être ajustées à partir du panneau de configuration. On pourrait y changer les propriétés du FileIOPermission pour accepter qu’une application particulière ait les droits même si ce n’est pas une application locale. Pour simplifier ce travail dans une entreprise, on peut aussi définir ces droits en fonction de la signature (strong name) ou de la provenance (site web), ce qui évite d’avoir à gérer ces droits individuellement pour chaque application.


Publication

Une fois l’application configurée correctement, vous pouvez préparer le mécanisme d’installation en la publiant, par Build►Publish <Projet>

⇒ L’onglet Publish dans les propriétés de projet vous offre cependant un peu plus de contrôle, alors c’est lui que nous allons étudier pour notre démonstration.

⇒ Publishing Location est l’endroit où l’application elle-même sera copiée. Ça peut être un site http ou ftp, ou un répertoire réseau ou local.

Un répertoire local pourrait ensuite être copié sur un CD pour la distribution de votre application.

Important Le framework 2.0 doit être installé sur le serveur. Autrement, la publication fonctionne, mais vous ne pouvez installer l’application. Internet Explorer se contente alors d’afficher le manifeste sans déclencher l’installation de l’application.

⇒ Installation URL détermine le point d’accès de l’installation / mise à jour pour l’utilisateur. C’est la localisation du programme setup.exe ou de la page Web qui lancera l’installation. Ça peut être différent de l’endroit où vous publiez l’application elle-même.

⇒ Install Mode and Settings permet de spécifier si l’application va être installée localement ou pas. L’installation locale a le gros avantage de permettre son utilisation pour les gens qui ne sont pas en ligne, entre autres sur les portables, et rend le lancement de l’application plus simple pour l’utilisateur qui n’aura qu’à cliquer sur une icône comme pour une application Windows standard.

⇒ [Application Files] permet de contrôler quels fichiers seront installés. Par défaut18, ce sont les fichiers suivants :

• L’application et son fichier de configuration, qui ne sont pas configurables.

• Les dll référencés et dont la propriété Copy Local a été réglée à True dans l’onglet References des propriétés de projet.

• Tous les fichiers de votre projet dont la propriété Build Action a été réglée à Content dans la fenêtre de propriété.

18 Vous savez qu’un fichier suit le défaut quand son Publish Status est réglé à Include (Auto).


[F1] à partir de l’onglet vous indiquera la signification des différentes valeurs de Publish Status. Le défaut (Required) indique que le fichier sera installé en même temps que l’application, et que l’installation en entier échouera si un des fichiers requis ne peut être installé pour une raison quelconque. Si vous créez et spécifiez un nom de groupe, le fichier ne sera pas installé par défaut. Il devra être téléchargé ultérieurement par du code, en appelant la méthode DownloadFileGroup de la classe System.Deployment.ApplicationDeployment. Ça pourrait permettre par exemple de personnaliser l’installation chez différents utilisateurs.

⇒ [Prerequesites] est un don des dieux pour ceux qui ont travaillé dans les anciennes versions de Visual Studio. Il permet de définir les logiciels externes dont votre application a besoin. À l’installation, le système détectera ceux qui manquent et les téléchargera automatiquement du site Web du fournisseur.

Notez que deux versions de Windows Installer sont présentées. La version 3.1 est préférable, mais ne fonctionne pas sur Windows 98 et ME.

⇒ [Updates] règle définitivement un problème de taille dans les entreprises, et c’est probablement au travers de cette option que ClickOnce prend toute sa signification : vous y programmez d’avance la fréquence et les paramètres des mises à jour automatiques.

Notez que vous forcez ainsi les mises à jour, ce qui peut être intéressant dans les applications internes. Si vous développez des applications commerciales ou pour des clients pouvant avoir des besoins variés, vous devrez travaillez un peu / beaucoup plus en créant une interface permettant à l’utilisateur de faire lui-même les choix, mais le framework vous facilite un peu la tâche. Le namespace System.Deployment contient une série de classes et d’événements qui vous permettent d’utiliser ClickOnce à partir de l’application elle-même ou à partir d’une application de mise à jour séparée.

⇒ Les [Options] définissent certains paramètres et informations qui seront utilisés par l’application d’installation, comme sa langue d’affichage et le nom du fichier que les usagers devront référencer pour lancer l’installation.


Certaines options seront utilisées lors de la désinstallation, comme par exemple le Support URL, qui s’affiche sous l’option support de la fenêtre de désinstallation du panneau de configuration de Windows. Un lien hypertexte vers cette page sera aussi offert à l’utilisateur lorsqu’une mise à jour de l’application sera disponible.

Le Publisher Name sera utilisé pour créer une entrée pour l’application dans le menu Start►Programs (Démarrer►Programmes).

⇒ Vous spécifiez finalement le numéro de version de l’installation, qui est utilisé pour les mises à jour et/ou pour gérer des installations différentes d’une même version de l’application19, au travers de fichiers de configurations dont nous parlerons un peu plus loin.

Important Le numéro de version de l’installation (Publish Version) peut-être différent du numéro de version de l’application. À notre avis, comme il apparaît dans les fenêtres servant à désinstaller le logiciel, il est important de les synchroniser. Il ne viendrait jamais à l’esprit de quiconque que la désinstallation version 2 va désinstaller l’application version 3.

⇒ Un click sur [Publish Now] fait tout le travail de publication.

Important Si le bouton [Publish Now] n’est pas activé, c’est peut-être parce que vous n’avez pas signé l’application. Pour des raisons de sécurité, une application déployée avec ClickOnce doit absolument être signée. Voir Strong name, page 242.

⇒ Si vous l’activez sur notre application d’exemple, vous aurez probablement des erreurs de compilation. Un déploiement ClickOnce n’est possible que si tous les dll utilisés par l’application possèdent un strong name, ce qui n’est pas le cas dans la solution distribuée sur le CD de cours. Passez dans l’onglet Signing de chacun des projets pour définir un strong name et vous pourrez faire la publication.

19 Par exemple, la différence entre une version démo et une version régulière repose souvent uniquement sur les fichiers distribués, pas sur l’application elle-même. Vous distribuez peut-être une version administrateur nécessitant une application parallèle pour configurer certains paramètres. L’installation utilisateur n’aurait pas ces fichiers.


Il y a aussi un bouton [Publish Wizard] qui correspond au menu Build►Publish <projet>, mais son usage nous semble superflu étant donné que les paramètres ont déjà été spécifiés et que les choix offerts sont moins complets que ce qu’on trouve ailleurs dans l’onglet.

Installation

Si vous avez décidé que l’installation se ferait à partir d’un disque compact ou du réseau, l’installation se fait à partir d’un programme setup.exe qui a été ajouté avec les autres fichiers de l’installation.

Important Le serveur Web doit être configuré correctement pour que le tout fonctionne. Ce sujet déborde de notre cours, c’est le rôle de votre administrateur Web. Vous pouvez l’aider en faisant une recherche sur troubleshooting clickonce deployment dans l’aide en ligne de Visual Studio.

Si vous avez décidé que l’installation se ferait à partir d’un site Web, l’assistant de publication a créé pour vous sur ce site Web une page, appelée par défaut publish.htm, qui ressemble à celle-ci :

L’utilisateur n’a qu’à naviguer à la page et cliquer sur le bouton [Install]. Le mécanisme standard d’installation d’applications à partir d’Internet se met alors en branle, laissant le choix à l’utilisateur d’installer l’application directement, ou de télécharger un fichier Setup.exe qu’il pourra activer plus tard.

Important Parce que nous l’avions spécifié dans les prérequis, le framework 2.0 sera installé avant l’application s’il n’est pas déjà sur la station de l’utilisateur. Dans ce cas, l’utilisateur doit être administrateur de la station.


Mises à jour Pour déployer une mise à jour, vous relancez simplement le mécanisme de publication, en vous assurant d’incrémenter le numéro de version de l’installation.

Si vous avez activé les options de mise à jour automatique lors de la première installation, sous le bouton [Updates] de l’onglet [Publish], l’utilisateur sera avisé qu’il y a une nouvelle version quand il lancera l’application, et aura alors la possibilité de faire la mise à jour.

Manifestes Un déploiement ClickOnce est contrôlé par une série de fichiers, distribués en deux groupes : un manifeste de déploiement et un manifeste d’application.

Comme c’est à peu près toujours le cas de nos jours quand on parle de fichiers de configuration, ces manifestes sont des fichiers XML.

Ils sont créés par l’assistant de publication, et vous n’avez normalement pas à les manipuler. Mais il pourrait y avoir des problèmes ou vous pourriez vouloir modifier certains paramètres sans avoir à republier, d’où l’importance d’avoir une idée du mécanisme derrière tout ça.

Vous ne pouvez pas les consulter avec un double-clic, leur extension .manifest ayant été associée avec le mécanisme qui gère ClickOnce. Activer un de ces fichiers déclenche l’installation, un peu comme pour les fichiers .msi avec Windows Installer. Pour modifier ces fichiers, ouvrez-les manuellement dans Visual Studio, Notepad (Bloc-notes) ou une application pouvant lire des fichiers XML.

Manifeste de déploiement

Le manifeste de déploiement principal porte le nom de l’application suivi de l’extension .application (Ex : PhotoCat.application)

Ce fichier est consulté par ClickOnce à la première installation et quand il tente de déterminer si une mise à jour est disponible. Il contient les informations de base pour le déploiement, en particulier la localisation du manifeste de la version la plus récente de l’application.

Chaque version de l’application possède son propre manifeste dans un fichier séparé (Ex : PhotoCat_4_0_0_2.application), qui référence la localisation des fichiers d’installation ainsi que les paramètres de mise à jour.


Vous pourriez par exemple modifier ce fichier si vous décidez de changer comment les mises à jour se font, en remplaçant par exemple la section suivante :

<update> <beforeApplicationStartup /> </update>

par <update> <expiration maximumAge="7" unit="days" /> </update>

Plutôt que de vérifier les mises à jour chaque fois qu’elle est lancée, l’application le fera à tous les 7 jours.

Manifeste d’application

Décrit l’application, les assemblages, fichiers et ressources dont elle a besoin. Définit aussi les permissions dont l’application a besoin pour fonctionner correctement.

Il est constitué de deux fichiers, localisées dans le répertoire où l’application est installée et possédant l’extension .manifest (Ex : PhotoCat.manifest et PhotoCat.exe.manifest).

Installation Windows conventionnelle

Microsoft privilégie une installation ClickOnce pour les applications développées sur le framework 2.0, et nous avons donc concentré notre étude sur ce mécanisme. Il est cependant important de savoir qu’il y a une alternative, particulièrement pour les programmeurs Visual Studio 2002 et 2003 qui n’ont pas accès à ClickOnce.

Même dans la version 2005, certaines installations sont trop complexes pour un déploiement XCopy ou ClickOnce. C’est le cas entre autres de celles qui demandent d’installer des composantes dans le GAC ou à des endroits spécifiques.

Dans ces cas, vous devez concevoir une installation qui utilise Windows Installer.

C’est une application qui est fournie avec les systèmes d’opération (depuis Windows 2000 / ME) ou certains logiciels comme Microsoft Office. Pour Windows 98 ou NT, elle doit être téléchargée à partir du site Web de Microsoft ou installée à partir de Windows Update.

C’est devenu tellement commun qu’il y a tout à parier que vos utilisateurs l’ont déjà. Il faut cependant vous assurer qu’ils ont au minimum la version 2.0, qui est requise pour l’installation du framework. Elle est disponible à www.microsoft.com/downloads/release.asp?ReleaseID=32832.


Une installation Windows Installer est gérée par un fichier possédant l’extension .msi. C’est une petite base de données contenant les instructions d’installation. Il est aussi optionnellement possible d’y inclure une version comprimée des fichiers à installer. Cette approche permet de simplifier la distribution des installations, puisque tout est contenu dans un seul fichier. C’est ce genre de fichier qui est généré par l’outil de création d’installations de Visual Studio, que nous allons étudier à la page 261.

Windows Installer prend en charge toutes les installations faites sous Windows (sauf les installations ClickOnce qui sont gérées par le framework). Il maintient une base de données des tâches effectuées. Comme il y a un arbitre qui supervise les installations, on n’a plus (ou presque) les anciens problèmes d’applications qui ne suivaient pas les normes et s’installaient ou se désinstallaient de la mauvaise façon en finissant par corrompre d’autres logiciels sur le système.

Les spécifications du format d’un fichier .msi sont disponibles, mais sont très complexes. On va donc généralement utiliser un outil qui va écrire le .msi pour nous. Plusieurs logiciels commerciaux existent pour ce faire, les plus populaires étant InstallShield et Wise Install.

Ces logiciels offrent un très grand contrôle sur l’installation, mais ils sont relativement coûteux et lourds à utiliser. Dans bien des cas, vous pouvez vous contenter de créer un projet de développement directement dans Visual Studio20.

Le projet de déploiement

Cette portion du manuel n’est normalement pas couverte durant le cours et est fournie comme un supplément pour les utilisateurs des versions 2002 et 2003 qui n’ont pas accès au déploiement ClickOnce.

Important Cette section est une copie intégrale de notre manuel de cours pour la version 2003. La discussion et les prises d’écran du reste du chapitre couvrent donc Visual Studio 2003, qui est identique à la version 2002. Les exemples et références ne font pas parties des exemples du cours 2005; ils proviennent des dossiers VS2002 et VS2003 du CD de cours. Il y a un équivalent dans la version 2005 sous File►New...Projects…Other Project Types…Setup and Deployments qui est similaire. Microsoft privilégiant une installation ClickOnce, ils n’ont pas travaillé très fort sur les projets de déploiement qui sont restés presque pareils dans la version 2005. La discussion devrait donc être facile à suivre si jamais vous désirez utiliser ce mécanisme même dans la nouvelle version.

20 L’équivalent du vieux Setup and Deployment Wizard de VB6, mais en mieux,… et celui-là donne des résultats qui fonctionnent.


Visual Basic .NET vient avec un utilitaire pour vous aider à créer vos installations Il s’agit d’un modèle que vous allez utiliser pour créer un nouveau projet, un pour chaque installation que vous voulez préparer. Vous modifierez ce projet une fois que .NET aura fait sa part du travail, puis le compilerez, pour finalement prendre le résultat et mettre ça sur un CD21, sur le réseau ou votre site Web.

Vous pouvez commencer la préparation de votre projet de déploiement par File►New Project...Setup And Deployment Projects :

Vous serez peut-être porté à créer le nouveau projet sous celui que vous voulez installer, comme nous le faisons dans l’illustration en créant le projet d’installation PhotoCat22dans un dossier Setup situé sous notre dossier de projet.

⇒ Assurez-vous d’activer Add to Solution, à défaut de quoi vous vous retrouvez dans un projet d’installation vide et devrez manuellement faire tout le travail plutôt que de profiter de l’aide de l’assistant. Dans la version 2005, cette option est dans une liste déroulante qui affiche Create New Solution par défaut.

Vous avez à choisir entre plusieurs types d’installations :

• Un Cab Project comprime tous les fichiers nécessaires dans un fichier cabinet (.cab) qui peut être télédéchargé par Internet Explorer, qui s’occupera de l’installation. Quand Internet Explorer rencontre une référence à un fichier .cab dans une page Web, il installe automatiquement l’assemblage. Cette approche est généralement appropriée quand vous distribuez des composantes qui sont elles-mêmes utilisées à partir de la page Web.

• Un Merge Module n’est pas quelque chose qui peut s’installer en soi. C’est un fichier comprimé portant l’extension .msm, un type de fichier reconnu comme étant quelque chose de particulier par le Windows Installer. Les merge

21 Avec la librairie de classes .NET qui est généralement distribuée avec l’application pour s’assurer des mises à jour de l’infrastructure chez vos usagers, ça fait dès le départ un 15 Mo pour notre petite application, une fois comprimée dans le fichier .msi. On oublie les disquettes. 22 Le nom donné ici est utilisé un peu partout dans l’application d’installation. C’est donc généralement celui de votre projet, bien que dans notre exemple nous utilisions PhotoCat pour un projet qui s’appelle PhotoCatDep.


modules sont des bouts d’installation déjà préparés d’avance, qui sont référencés au moment de préparer un des autres types d’installation. Vous pourriez par exemple décider d’incorporer dans un merge module des images, des sons ou des entrées de registre qui sont communs à plusieurs applications et réutiliser ce regroupement d’éléments dans chacune de vos installations. Si le logo de la compagnie change, vous créez simplement un nouveau merge module et l’utilisez pour les prochaines mises à jour de vos différentes applications. Si vous créez un dll qui est lui-même dépendant d’autres dll, il vous faudra créer un merge module si vous voulez faciliter son inclusion dans des applications. L’inclusion du merge module dans la distribution assurera en effet que tous les dll nécessaires seront « ramassés » et installés correctement sur la station de destination.

• Un Setup est l’application d’installation standard sous Windows.

• Un Web Setup est une application d’installation semblable à la précédente, qui sera aussi exécutée par Windows Installer, mais qui est destinée à installer des composantes à partir d’un serveur Web.

• Le Setup Wizard un outil qui peut vous aider dans la création de n’importe lequel des 4 types d’installations précédentes, et c’est par lui que la majorité des programmeurs vont préparer leurs installations. C’est donc lui que nous allons utiliser dans le cours.

Le Setup Wizard Nous vous avons indiqué dans la section précédente que vous pouviez créer un nouveau projet d’installation à partir de File►New Project...Setup And Deployment Projects. Cette approche souffre cependant d’une grosse lacune : l’assistant n’est pas assez intelligent pour nous demander quel projet nous voulons installer, de sorte qu’il crée une installation ne contenant rien. Il faut faire tout le travail à la main.

Nous allons nous y prendre autrement, en incluant le projet d’installation à notre solution. La solution contiendra donc simultanément le projet de l’application elle-même + le projet d’installation.

⇒ Si ce n’est déjà fait, ouvrez le projet PhotoCatDep.

⇒ Activez File►Add Project...New Project, puis lancez le Setup Wizard à partir des modèles Setup and Deployment Projects.

⇒ Donnez un nom à votre projet et définissez où vous voulez le créer. Le dossier du projet PhotoCatDep contient déjà un répertoire Setup dans lequel nous avons créé un exemple de projet d’installation qui pourra être réutilisé éventuellement. Utilisez donc un dossier différent si vous travaillez à partir des exemples du cours.


⇒ Après un écran de présentation, l’assistant vous demande quel type de projet vous voulez créer. Pour notre démonstration, nous allons créer une application Windows standard, alors cochez Create a setup for a Windows Application.

⇒ Si vous tenez à ce que votre projet soit exactement semblable au nôtre pour mieux suivre le reste de la discussion, cochez les deux entrées qui le sont dans l’illustration.

Vous pouvez incorporer tout ce qui fait partie de l’application dans votre dossier de travail, même le code source si désiré. Normalement, vous allez vous contenter du Primary output, qui est simplement la version compilée de votre application, avec tous les assemblages dont elle dépend.

Vous pourriez cependant dans certaines circonstances ajouter quelques fichiers à votre système d’installation :

Si vous avez développé une application multilingue en utilisant des fichiers de ressources séparés pour les versions française, anglaise et espagnole23, vous pouvez incorporer tous les fichiers de ressource en activant Localized resources. Toutes les ressources seront distribuées, ce qui évite de créer une installation différente pour chaque langue.

23 Consultez l’aide en ligne à Resource Files si c’est quelque chose qui pourrait éventuellement vous intéresser.


Si une application est installée avec les Debug Symbols, l’installation comprendra une copie du fichier .pdb qui est généré pendant la compilation de l’application. Ce fichier contient des informations qui peuvent être utilisées par un débogueur. Si l’environnement de programmation .NET est installé et que l’utilisateur possède les droits de débogage sur la station ou l’application est exécutée, le débogueur de .NET sera invoqué si une erreur non gérée survient pendant que l’application est en cours d’utilisation. C’est un mécanisme appelé Just-In-Time Debugging que nous verrons plus en détail à la page 278.

Important Vous allez habituellement éviter d’incorporer les Debug Symbols dans la version que vous allez distribuer à vos usagers.

Un Content File est un fichier qui ne contient ni du code source, ni du code compilé. Ce sont les fichiers de votre projet dont la propriété Build Action a été réglée à Content dans la fenêtre de propriété : fichiers de données, documentation, etc. Activer cette case les ajoute à l’installation.

Si ça vous tente, vous pouvez toujours distribuer aussi votre code source en activant les Source Files.

⇒ À l’étape suivante, vous spécifiez tous les fichiers que .NET ne peut identifier parce qu’ils ne font pas intrinsèquement partie de votre projet. Ce sont généralement des fichiers de donnée ou de la documentation à installer en parallèle avec l’application, comme par exemple un fichier Lisez-moi. Si vous voulez suivre à la lettre notre exemple, référencez ici le fichier contenant la liste des sujets, PhotoCat.suj du dossier bin\Data du projet.

⇒ Une dernière petite révision, un clic sur [Finish] fait tout le travail… ou presque

Vous avez maintenant dans votre solution un deuxième projet (PhotoCat dans l’illustration) qui correspond à votre application d’installation24.

Le menu Build vous permet maintenant de compiler soit la solution (les deux projets en séquence), soit le projet qui est actuellement activé.

F5 compile les deux.

Vous constatez que l’assistant a récupéré les deux assemblages dont dépend votre application : JBLib et Photo.

24 Les curieux constateront que ce projet possède l’extension vdproj (probablement pour Visual Deployment Project) plutôt que le vbproj habituel.


Il inclut aussi dans le système de distribution un merge module qui contient le .NET Framework, mais que vous n’avez cependant pas le droit de redistribuer sous cette forme avec vos applications : dotnetfxredist_x86_enu.msm. Ce module est utilisé à l’interne par le compilateur, mais est désactivé. Si .NET n’est pas déjà installé chez les utilisateurs, vous devrez suivre la méthode indiquée à la page 274.25

La première partie du nom de ce module est évidente. Le x86 laisse poindre le jour où .NET pourra être utilisé dans un environnement autre que celui où roule Windows (x86 faisant référence à la famille de microprocesseurs Intel). enu signifie probablement English US, la version disponible dans notre environnement de développement.

Il a ajouté le fichier PhotoCat.suj que nous avions référencé lors d’une des étapes de l’assistant, et indique de façon générique qu’il va aussi inclure le résultat de la compilation de l’application (Primary Output) et les informations de débogage (Debug Symbols) que nous avions demandé d’inclure.

Ces fichiers ne sont pas copiés dans le dossier d’installation. Ils restent à leur endroit original et seront simplement intégrés au fichier d’installation quand vous lancerez la compilation qui le créera.

Important Un projet Web n’est pas la même chose qu’une application Windows ou un projet d’installation. Les menus s’adaptent et vont donc changer selon le type de projet. Quand votre solution contient deux types de projets différents, comme c’est le cas au point où nous en sommes, il est important d’être dans le bon projet pour avoir les bons menus. Vous passez d’un projet à l’autre en cliquant sur n’importe laquelle de ses composantes dans le Solution Explorer.

Modifier l’installation Vous allez probablement vouloir modifier le comportement de l’installation par rapport à ce qu’a généré l’assistant.

Propriétés de l’installation

Une partie des changements peut être effectuée dans la fenêtre de propriétés.

Dans un premier temps, l’assistant a récupéré le nom de notre entreprise dans l’entrée AssemblyCompany du fichier AssemblyInfo.vb. Le dossier d’installation par défaut de l’application sera Program Files suivi du nom de compagnie et du nom du projet, soit dans notre cas : Jacques Bourgeois – Formation Informatique Inc.\PhotoCat. Un peu long comme nom de répertoire.

25 Ici, Microsoft s’est complètement gouré. L’inclusion du merge module était le mécanisme par défaut dans la version bêta et simplifiait beaucoup notre travail de distribution.


⇒ Nous allons abréger à JBFI\PhotoCat en changeant la propriété Manufacturer à JBFI. Pour ce faire, cliquez sur le nom du projet d’installation et changez l’entrée dans la fenêtre de propriétés.

⇒ Vous pourriez aussi changer la Localization. Parce que nous travaillons dans Visual Basic anglais, l’assistant a inscrit anglais. Si vous changez Localization pour French, c’est la version française du Windows Installer qui sera invoquée, et ce même dans un Windows anglais, ce qui donne l’impression à l’utilisateur que c’est vous qui avez écrit le programme d’installation.

⇒ Vous pouvez au besoin changer toutes les informations qui semblent pertinentes. Pour une raison quelconque, certaines des entrées d’AssemblyInfo n’ont pas été récupérées par l’assistant, comme par exemple la Description.

Certaines de ces propriétés (ProductName et Manufacturer) servent pendant l’installation, et d’autres comme le ManufacturerURL26 sont visibles à partir d’un lien hypertexte Support Information qui apparaîtra avec votre application dans les options de désinstallation de l’installateur de Windows.

Malheureusement, Windows Installer ne tient plus compte de la localisation de votre application à ce niveau-ci, et la fenêtre ne s’affiche pas en français, mais dans la langue du système d’opération.

Notez que le numéro de version qui apparaît dans l’information de support est le numéro de version de l’application d’installation, pas celle de l’application qui est désinstallée. On va généralement vouloir synchroniser les deux en ajustant la propriété Version du projet d’assemblage à la même valeur que celle de l’application. Malheureusement, rien dans l’environnement ne fait ça automatiquement et il faut donc y penser chaque fois.

Prenez aussi note que le numéro de version d’une installation est composé de 3 chiffres, non pas de 4 comme le numéro de version d’un assemblage. Une erreur sera générée si vous inscrivez 4 chiffres dans la propriété Version.

26 Si vous spécifiez un URL, assurez-vous de mettre le http:// au début, sinon vous aurez une erreur mal libellée indiquant qu’il y a des caractères invalides dans l’adresse.


Propriétés des fichiers

Chacun des fichiers composant votre installation possède aussi une série de propriétés que vous voudrez peut-être changer dans certaines circonstances.

Par exemple, pour les fichiers de données comme PhotoCat.suj, il pourrait être avantageux de mettre leur propriété Permanent à True. Ça indiquera au Windows Installer qu’ils ne doivent pas être détruits si jamais l’utilisateur désinstalle l’application.

Certains fichiers de données peuvent être partagés entre plusieurs applications. Dans un tel cas, vous permettrez peut-être qu’ils ne soient pas permanents, mais voudrez vous assurer qu’ils ne soient détruits que lorsque la dernière application les utilisant sera détruite. Si SharedLegacyFile est à True, l’installateur s’occupera de tenir à jour un compteur indiquant le nombre d’installations et de désinstallations, qui lui permettra de savoir quand le fichier peut être effectivement détruit.

Si une composante exige Windows 2000 ou plus, vous pouvez entrer Version NT >= 5 dans la propriété Condition. Consultez l’aide en ligne à partir de la propriété pour plus d’informations.

Comme c’est toujours le cas en Visual Basic, s’il y a quelque chose qui peut être changé dans la configuration ou le comportement de quelque chose, c’est dans l’une de ces propriétés que vous pourrez probablement le faire.

Ajouter des éléments

Si vous avez besoin d’inclure certains éléments supplémentaires dans votre distribution, vous pouvez en rajouter par Project►Add. Vous trouverez là par exemple une entrée Project Output qui permet d’ajouter des éléments que vous avez peut-être oubliés en utilisant l’assistant. 27

27 Vous pouvez aussi simplement faire glisser des fichiers de Windows Explorer (L'Explorateur Windows) à la fenêtre listant les composantes de l’application


Enlever des éléments

Si vous voulez enlevez certaines options d’inclusion, soit parce que vous les avez activées par erreur en exécutant l’assistant, soit parce qu’elles ne sont plus nécessaires, comme par exemple les Debug Symbols que vous avez peut-être activés pour faire vos premiers tests d’installation, mais qui ne sont plus nécessaires pour la distribution finale, vous n’avez qu’à activer Remove dans le menu contextuel de l’option dans le Solution Explorer.

Dans le cas des Detected Dependencies, les dll dont votre application a besoin, si vous avez un contrôle très serré des environnements où sont installées vos applications, vous pourriez, en sachant que vos utilisateurs ont déjà une copie de ces assemblages installée chez eux, vouloir les exclure du projet d’installation pour diminuer sa taille et accélérer l’installation. Une option Exclude est disponible à cet effet dans le menu contextuel de chacune des entrées de la liste de dépendance. Notez que l’entrée n’est pas retirée de la liste quand vous l’excluez. Une petite icône indique simplement qu’elle ne sera pas incluse dans le fichier d’installation.

Définir les répertoires d’installation

Par défaut, tous les fichiers de l’installation vont être installés dans le dossier de l’application. Ce n’est pas toujours le cas, comme dans notre exemple. La librairie JBLib, qui sert à calculer la TPS et la TVQ, serait beaucoup plus à sa place dans le GAC. Par ailleurs, toute l’application a été conçue pour que les données soient dans un sous-dossier appelé Data. Le fichier PhotoCat.suj que nous distribuons avec notre installation devrait entre autres se retrouver dans Data.

⇒ Pour définir où vont s’installer les différents éléments composant l’application, activez tout d’abord le File System Editor par un View►Editor...File System. Ce menu n’est disponible que si le projet d’installation est sélectionné dans le Solution Explorer.

⇒ Vous pouvez créer automatiquement le dossier Data en activant Add►Folder dans le menu contextuel de l’entrée Application Folder, dans la section gauche de la fenêtre.

⇒ Pour que le fichier PhotoCat.suj s’y installe, faites-le simplement glisser de la section droite sur le dossier que vous venez de créer.

Si vous voulez ajouter des dossiers spéciaux à la liste de destinations possibles, activez Add Special Folder, qui apparaît si vous cliquez dans le fond de la fenêtre de gauche du File System Editor. Vous aurez ainsi des références qui s’ajusteront automatiquement lors de l’installation pour référencer le dossier système, le répertoire d’installation des polices, etc.

⇒ JBLib.dll devrait être installé dans le GAC. Créez tout d’abord une entrée pour le répertoire cache en sélectionnant Global Assembly Cache Folder dans le menu contextuel du panneau de gauche. Faites-y ensuite glisser JBLib.dll.


Important Pour pouvoir installer des assemblages dans le GAC, l’utilisateur qui installera votre application devra avoir des droits d’administrateur sur la station de travail. Si ce n’est pas le cas ou si vous ne savez pas, vous êtes peut-être mieux de laisser l’assemblage dans le même répertoire que l’application… et vos utilisateurs sont peut-être mieux d’avoir de gros disques durs ☺.

Notez que si vous tentez de faire la même chose avec Photo.dll, une Build Error est générée. Elle n’est pas très évidente mais apparaît dans la Task List.

Assembly 'Photo.dll' must have a shared name to be installed globally.

Important Pour pouvoir être installé dans le GAC, un assemblage doit avoir été compilé avec un Strong name, parfois appelé un shared name (voir page 242), ce qui n’est pas le cas de Photo.dll.

⇒ Photo.dll est un assemblage privé, qui doit donc être installé dans le même dossier que l’application qui l’utilise. Ramenez-le dans Application Folder.

Raccourcis

Vous pouvez créer automatiquement pour l’utilisateur un raccourci lui permettant de lancer notre application, soit à partir de son Desktop (Bureau), soit à partir du bouton [Start (Démarrer)] de Windows. L’installateur de Windows va s’occuper de créer les raccourcis appropriés une fois qu’il saura où est l’application. Il suffit de lui indiquer où doivent être installés ces raccourcis.

Nous allons créer un raccourci qui pourra activer notre application à partir de Démarrer►Programmes...JBFI.

⇒ Sous Application Folder, cliquez sur l’entrée Primary output from PhotoCatDep28 avec le bouton droit de la souris et activez la première option qui offre de créer un raccourci.

⇒ Le nom donné au raccourci peut être changé pour PhotoCat.

⇒ Dans le menu contextuel de User’s Program Menu, faites un Add►Folder et nommez le dossier résultant JBFI.

⇒ Faites glisser le raccourci que vous avez créé il y a quelques instants dans le nouveau dossier.

Windows Installer ajoutera automatiquement pour vous une entrée JBFI sous le menu Programme et y créera un raccourci permettant de lancer l’application là où elle aura été installée sur la station de travail.

28 C’est le résultat de la compilation, donc votre application.


Important La prochaine étape récupère une icône à partir de l’assemblage. Pour que ça fonctionne, vous devez avoir compilé l’assemblage que vous voulez installer (PhotoCatDep en ce qui nous concerne) au moins une fois.

⇒ Vous pouvez changer l’icône assignée au raccourci par la propriété Icon de la fenêtre de propriétés. Par défaut, l’interface cherche des fichiers .ico, mais vous pouvez pointer à l’icône incorporée dans l’application en navigant jusqu’au Application Folder et en pointant au Primary Output.

⇒ Le résultat final devrait donner quelque chose qui ressemble à ceci :

Autres modifications possibles

Nous allons nous arrêter là pour notre démonstration, les informations présentées jusqu’ici convenant à la plupart des applications. Si vous voulez aller un peu plus loin, l’environnement .NET vous offre toute une série d’autres options d’installation, accessibles au travers du menu View►Editor. Référez-vous à l’aide en ligne pour les détails de celles qui pourraient vous intéresser. Nous allons ici nous contenter d’une discussion sommaire.

Registry

Création d’entrées dans la base de registre.


File Types

Associer certaines extensions de fichier avec votre application. Quand les utilisateurs feront un double-clic sur un fichier possédant une des extensions que vous avez définies, votre application sera automatiquement lancée et recevra une ligne de commande contenant le nom du fichier activé.

User Interface

Permet de déterminer quelles fenêtres vont s’afficher lors de l’installation, et même ajouter vos propres formulaires, comme par exemple une fenêtre de garde (splash screen) personnalisée ou un formulaire d’enregistrement de l’utilisateur.

Vous pouvez y faire une différence entre une installation par un administrateur et un utilisateur usuel.

Custom Actions

Permet de spécifier des scripts ou des applications que l’installateur va appeler à certaines étapes de l’installation.

Par exemple, les fichiers ne faisaient pas partie de l’installation mais ayant été créés pendant son usage29 ne seront pas détruits par une désinstallation. Nous pourrions donc créer un script qui ferait ce travail et l’inscrire comme action à accomplir sous Uninstall pour qu’il soit automatiquement activé après une désinstallation.

Consultez l’aide en ligne pour plus de détails.

Launch Conditions

Deux entrées qui permettent de définir des conditions qui doivent être respectées avant que l’installateur de Windows n’entreprenne l’installation.

Search Target Machine indique des fichiers, des entrées dans la base de registre ou des composantes Windows Installer qui doivent être présentes sur la station de travail.

Launch Conditions oblige par exemple qu’une version spécifique de Windows ou d’un Service Pack, ou bien qu’une quantité minimum de mémoire vive soient disponibles.

Truc Si vous voulez aller plus loin que ce que permet l’assistant de Visual Studio, vous pouvez utiliser un outil commercial comme InstallShield. Microsoft fournit aussi gratuitement un outil d’édition du fichier .msi qui s’appelle Orca, et qui est disponible dans le Windows Installer SDK, que vous pouvez télécharger à http://www.microsoft.com/msdownload/platformsdk/sdkupdate/default.htm

29 Comme par le fichier de trace qui est créé par PhotoCat lorsqu’une erreur imprévue survient dans certaines compilations.


Compilation du projet d’installation Rien de bien spécial ici. Build►Build <nom du projet> ou Build►Build Solution. Dans ce deuxième cas, en autant que Project►Project Build Order n’ait pas été changé, l’application sera tout d’abord compilée pour vous assurer que vous avez une version bien à jour (assurez-vous de spécifier le bon Build, normalement Release pour la version finale), et ensuite le projet d’installation.

Le résultat de la compilation du programme d’installation est localisé dans un dossier de votre projet d’installation : soit Debug, soit Release, dépendant du Build qui est actif au moment de la compilation. Notez qu’il s’agit ici du Build de l’application d’installation, pas de l’application originale. Vous ne pouvez pas le changer par la liste disponible dans les barres d’outils, comme c’est le cas pour un projet standard. Vous devez passer par les propriétés du projet d’installation accessibles par son menu contextuel.

Important Si vos utilisateurs ont déjà Windows Installer 2.0 et la bonne version du Framework disponibles sur leur station de travail, c’est suffisant. Mais s’il manque un de ces deux composants, l’installation de fonctionnera pas.

Windows Installer 2.0 Le projet d’installation que nous avons créé jusqu’ici génère simplement, si vous le compilez, un fichier msi que l’utilisateur active pour lancer le processus. Le dossier PhotoCatMaj\Setup\PhotoCat\Release contient un exemple du résultat d’une compilation utilisant cette configuration. C’est suffisant, à condition que Windows Installer soit à jour sur les stations de travail de nos utilisateurs. Vous vous souviendrez que la version 2.0 était nécessaire pour pouvoir installer une application .NET.

Nous allons modifier le projet de telle sorte que l’installation se fasse à partir d’un programme Setup.exe qui va mettre à jour Windows Installer à la version 2.0 sur la station de travail.

Pour ce faire, vous devez tout d’abord obtenir de Microsoft une composante d’installation supplémentaire appelée bootstrapper, et disponible à http://msdn.microsoft.com/vstudio/downloads/tools/bootstrapper/

⇒ Dans les propriétés du projet d’installation, indiquez que vous voulez installer le Windows Installer Bootstrapper.

Cette opération devrait ajouter dans l’installation le programme Setup.exe et les composantes nécessaires à la mise à jour ou à l’installation de Windows Installer, mais pas l’environnement .NET.


Important Ça faisait tout le travail dans Visual Studio 2002, mais pour quelque raison, dans Visual Studio 2003, les fichiers nécessaires à la mise à jour de Windows Installer ne font pas partie du résultat. Vous devrez donc ajouter manuellement les fichiers InstMsiA.Exe et InstMsiW.Exe qui contiennent l’application.

PhotoCat\Setup\PhotoCat\Final contient un exemple du résultat d’une compilation utilisant cette configuration. Notez qu’il manque toujours le Framework, que nous ajoutons à l’étape suivante.

Environnement .NET

Important L’assistant d’installation assume que l’environnement .NET est déjà disponible chez l’utilisateur. Si c’est le cas, vous pouvez sauter cette section. Autrement, il est très important de rajouter cette étape, sinon votre application ne fonctionnera pas une fois installée.

Ici, Microsoft n’a définitivement pas fini son travail. L’environnement .NET fera éventuellement partie du système d’opération, mais ce n’est pas encore le cas. Ils assument pour le moment que les gestionnaires de système installeront .NET sur les stations de leurs utilisateurs. Ils n’ont pas inclus dans le mécanisme d’installation d’une application .NET la fonctionnalité pour installer .NET lui-même.

dotnetfx.exe

Important Vous devrez ajouter manuellement à votre système d’installation le fichier dotnetfx.exe, qui est l’installeur pour le .NET Framework.

Vous trouverez une copie de ce fichier dans le dossier dotNetFramework du CD Microsoft Windows Component Update (VSWCUD1) de Visual Studio.

Comme vous ferez éventuellement des mises à jour de .NET sur votre ordinateur de développement, il faudra aussi vous tenir à jour avec dotnetfx. Pour ce faire, visitez le site de Microsoft à l’adresse suivante : http://msdn.microsoft.com/downloads/default.asp?URL=/downloads/ sample.asp?url=/MSDN-FILES/027/001/829/msdncompositedoc.xml

Vous trouverez un lien vers ce site dans Documentation\Adresses Internet.htm des exemples pour le cours.

Ce n’est cependant pas tout, il faut installer dotnetfx.exe chez l’utilisateur de votre application, et les outils fournis par Visual Studio ne le feront pas pour vous. Vous pouvez :

• Guider vos utilisateurs pour qu’ils installent manuellement le truc en double-cliquant sur dotnetfx.exe avant de lancer le programme Setup.

• Concevoir une application ou un fichier batch qui fait le travail pour eux.

• Utiliser le bootstrapper, tel que décrit à la page précédente.


Dans le cas où vous opteriez pour la dernière solution, notez qu’il s’agit d’un « plug-in » qui s’intègre de façon transparente dans votre environnement Visual Studio. Une version française est disponible, mais elle ne fonctionne que si vous avez une version française de Visual Studio. Une fois installé, dotnetfx.exe est ajouté à tous vos projets d’installation lors de leur compilation, même s’il est exclu du projet dans le Solution Explorer.

Vous préférerez peut-être avoir dans votre entreprise une installation individuelle de l’environnement .NET ou utiliser un mécanisme de distribution différent. Dans ce cas : http://msdn.microsoft.com/Library/default.asp?url=/Library/ en-us/dnnetdep/html/vsredistdeploy.asp

Langue de l’environnement

Important Sous Windows 98, il est essentiel que la version de dotnetfx.exe soit dans la même langue que le système d’opération. Pour les autres versions de Windows, ça n’a pas d’importance.

L’environnement .NET envoie parfois des messages à l’utilisateur. La langue dans laquelle s’affichent ces informations est naturellement celle du framework installé sur l’ordinateur. En ce qui concerne le numéro de version, vous pouvez installer différentes versions du framework sur la même station. Vous ne pouvez cependant pas installer un framework anglais ET un framework français.

Dans un environnement multilingue comme ceux que nous rencontrons couramment ici, Microsoft recommande d’installer le framework anglais, plus des modules de prise en charge linguistique pour chaque langue supplémentaire. Vous trouverez le module français à l’adresse qui suit, et de là, vous pourrez au besoin récupérer des modules dans d’autres langues : http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=04DBAF2E-61ED-43F4-8D2A-CCB2BAB7B8EB

Pour accéder au site sans avoir à taper cette adresse, vous trouverez un lien sur notre site web à http://www3.sympatico.ca/jbfi/vb.htm. C’est la première entrée de la section Mise à jour.

Ces modules linguistiques ne sont devenus disponibles qu’en mars 2004 et nous n’avons pas eu le temps de « jouer » avec. Si vous le faites, pourriez-vous s.v.p. nous envoyer un compte rendu de votre expérience à [email protected]. Nous nous posons en particulier des questions à savoir si l'application s'ajuste automatiquement au module linguistique quand on change sa culture, et sur l'intégration du module linguistique à l'installation de nos propres applications.


Installation de l’application

Important Si vous utilisez l’exemple d’installation que nous avons construit depuis le début du chapitre, notez que puisqu’il contient un assemblage devant s’installer dans le GAC (JBLib), vous devez être administrateur de votre station de travail pour pouvoir installer l’application. Ce n’est généralement pas le cas dans les salles de formation.

Il est courant que même le formateur ne soit pas administrateur de sa station de travail et ne puisse pas vous faire une démonstration, alors nous allons illustrer abondamment cette section des prises d’écran pertinentes.

⇒ Vous n’avez qu’à faire un double-clic sur le fichier PhotoCat.msi qui a été généré par les opérations précédentes pour pouvoir lancer l’installation.

Vous trouverez une version prête à être utilisée dans le dossier PhotoCat\Setup\PhotoCat\Release des exemples de cours.

Dans le cas où vous devez ajouter l’environnement .NET, comme discuté à la page 274, il se peut que vous deviez activer plutôt un fichier Setup.exe qui s’occupera, après avoir installé les composantes nécessaires, de lancer automatiquement le .msi.

Si l’application a déjà été installée sur la station de travail et qu’il s’agit de la même version, l’utilisateur se fait tout d’abord demander s’il veut réparer ou supprimer l’application. Une réparation va réinstaller l’application, tandis qu’une suppression va simplement désinstaller l’application existante30.

30 C’est une alternative à la désinstallation traditionnelle par le panneau de configuration. C’est à peu près aussi absurde que le bouton [Démarrer] qu’il faut activer pour sortir de Windows. Vous devez lancer l’installation pour désinstaller. Il vous faudra par la suite relancer toute la méthode pour vraiment installer.


Autrement, l’installation standard est lancée avec tout d’abord un premier écran de présentation.

L’utilisateur se fait demander où il veut installer l’application et si elle doit être disponible pour tout le monde ou seulement « moi ». Cette question, qui n’est pas disponible dans tous les systèmes d’opération, ne touche que certaines composantes de l’installation, comme par exemple les raccourcis que vous avez peut-être définis à la page 270.

[Espace requis] donne des indications sur la grosseur des fichiers en permettant à l’utilisateur de voir s’il possède suffisamment d’espace disque pour pouvoir les installer. Notez que ces chiffres sont bien peu précis. Lors de l’installation illustrée ci-dessous, l’installateur n’a pas tenu compte, dans son évaluation des 33Mo requis, que .NET était déjà installé sur la partition H. et n’avait pas à être réinstallé. Ce qu’on nous indique ici, c’est qu’il faudra au maximum 33 Mo. En fait, l’installation dans l’environnement illustré ne demandait que 540 Ko (à peu près 60 fois moins, c’est naturellement négligeable ☺).


Deux petits [Suivant >] et l’installateur commence son vrai travail, en nous offrant, de patienter. Vous serez récompensée par une application toute prête à être lancée par le raccourci que l’installateur a créé selon nos instructions.

Un petit clic pour tester… et naturellement… ça ne fonctionnera pas.

Vérifier l’installation Même en installant sur la station de travail où l’application a été développée, où toutes les composantes et fichiers nécessaires à votre application sont présents, vous risquez d’avoir des problèmes. Les plus courants à ce niveau-ci sont souvent des références relatives à des dossiers contenant des fichiers.

Heureusement, vous aviez spécifié que vous vouliez incorporer les Debug Symbols dans notre application (n’est-ce pas? ☺), ce qui invoque un outil bien utile, étant donné qu’il permet de déboguer l’application compilée et installée dans son environnement.

Just-In-Time Debugging

Si vous avez indiqué, lors de la préparation de votre projet d’installation, que vous vouliez inclure les données de débogage dans votre installation, toute erreur non gérée dans l’application va invoquer le Just-In-Time Debugging, un mécanisme qui vous permet de tomber en environnement de débogage à partir de l’application compilée, même quand elle est exécutée à l’extérieur de Visual Studio. Il faut cependant que l’environnement de développement ait été déjà installé sur la station de travail au moment où l’application reçoit une exception. C’est un peu contradictoire, étant donné que vous voulez généralement tester vos installations sur une station la plus « sobre » possible, et ça sous-entend automatiquement que vous n’y avez pas installé Visual Studio.


Dans notre prise d’écran, trois options sont offertes. La dernière est due au fait qu’au moment où le mécanisme a été déclenché, nous avions déjà une copie de l’environnement de développement chargée en mémoire. Vous n’aurez donc souvent que les deux premières options.

New Instance of Microsoft CLR Debugger charge un débogueur qui est une version restreinte de l’environnement de développement31, tandis que la deuxième charge Visual Studio au complet. Comme l’idée est beaucoup plus d’identifier le problème que de le corriger – il faudra éventuellement retourner dans le code source original – la version restreinte est donc souvent plus appropriée parce qu’elle demande beaucoup moins de ressources (15 Mo vs 30 Mo) et risque donc moins de venir empirer un problème qui pourrait provenir d’un manque de mémoire.

Le module qui a reçu l’exception est décompilé (l’inclusion des Debug Symbols dans la compilation permet ça) et est affiché seul, sans les autres, avec les outils de débogage habituels, et arrêté sur la ligne ayant causé l’exception.

Si vous êtes entré en mode débogage avec l’environnement complet, vous pouvez même modifier le code et relancer l’application qui fonctionnera avec les changements.

Important Nous n’avons pas pu trouver de documentation sur ce qui suit, alors les remarques viennent seulement des nos observations et de nos tests.

Quand vous fermerez Visual Studio, .NET vous offrira d’enregistrer le projet contenant le code modifié. Vous constaterez qu’il enregistre le fichier .sln, mais pas le fichier .vb dans lequel vous avez peut-être fait des changements. D’après nous, le fichier .vb résultat de la compilation est simplement conservé en mémoire et est recompilé à partir de là quand vous relancez l’application.

Quand vous rouvrez la solution créée par le débogueur, il décompile à nouveau le module et vous affiche son code source.

Cette théorie semble corroborée par le fait que le fichier .sln fait référence au .exe comme source du projet au lieu de faire référence au .vbproj comme c’est habituellement le cas.

Nous aurions préféré avoir une copie du module modifié, pour pouvoir simplement l’incorporer au code source original, mais ce n’est pas le cas. Vous pouvez toujours enregistrer la « copie virtuelle » dans un vrai fichier .vb par un File►Save As.

31 Aucun outil pour la création des formulaires, aucune entrée pour faire des New de quelque sorte que ce soit, aucune possibilité de modifier le code, etc.


Ensuite… Ensuite, il faut idéalement tester dans plusieurs environnements différents32, idéalement sur des ordinateurs qui ont une installation toute fraîche de Windows33 avec aucun Service Pack et aucune application installée, sauf une version mise à jour de Windows Installer (page 260).

Besoins particuliers Dans des cas très particuliers, les fonctionnalités d’installation par défaut ne sont pas suffisantes. Dans un tel cas, l’infrastructure .NET fournit un namespace System.Configuration.Install qui possède toute une série de classes à partir desquelles vous pouvez définir une installation plus personnalisée.

Désinstaller l’application Comme toute bonne application Windows, l’utilisateur doit pouvoir la désinstaller.

Dans le cas des applications XCopy elles peuvent être éliminées aussi facilement qu’elles avaient été installées : vous détruisez le répertoire qui les contient.

Pour les autres, ce n’est pas tellement plus difficile. Dès qu’une application est installée par WI, ce dernier l’ajoute à sa base de données et elle se retrouve dans la liste d’applications à désinstaller dans le panneau de configuration de Windows.

32 Nous avons à maintes reprises entendu parler en bien de VMWare, un logiciel qui permet de rouler simultanément, dans une même session Windows, des versions différentes de Windows, chacune dans sa propre fenêtre. Ça facilite beaucoup les tests. Visitez leur site Web à www.wmware.com pour avoir des détails. 33 N’oubliez pas que .NET ne fonctionne pas sur Windows 95 ou sur NT3.