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

Transcription

1 Insérer à la page 231 du manuel «Visual Basic 2005 Introduction», version 3.0 Copyright 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 (jbfi@sympatico.ca)

2

3 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

4 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. 235 Visual Basic 2005 Déploiement d'une application

5 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 installations 1, 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émoire 2 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 multiplateforme 3, 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. Visual Basic 2005 Déploiement d'une application 236

6 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 classes 4. 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. 237 Visual Basic 2005 Déploiement d'une application

7 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. Visual Basic 2005 Déploiement d'une application 238

8 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 $ 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éricains 5 et les 12 provinces canadiennes 6, 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ès 7. 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 à 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é. 239 Visual Basic 2005 Déploiement d'une application

9 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 vitesse 8 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 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. Visual Basic 2005 Déploiement d'une application 240

10 C est tout nouveau, mais ça marche, et c est un des aspects les plus emballants de la version Ç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 ( 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 241 Visual Basic 2005 Déploiement d'une application

11 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 mois 9 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. Visual Basic 2005 Déploiement d'une application 242

12 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 4 e élément d identification, une signature électronique appelée un strong name 11. 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. 243 Visual Basic 2005 Déploiement d'une application

13 Ê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. Visual Basic 2005 Déploiement d'une application 244

14 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 passe 12. 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. 245 Visual Basic 2005 Déploiement d'une application

15 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 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é. Visual Basic 2005 Déploiement d'une application 246

16 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. 247 Visual Basic 2005 Déploiement d'une application

17 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 ( 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éploie 14. 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». Visual Basic 2005 Déploiement d'une application 248

18 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é cidessous, 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 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 Visual Basic 2005 Déploiement d'une application

19 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 cryptique 15 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. Visual Basic 2005 Déploiement d'une application 250

20 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çaise 16 ) 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. 251 Visual Basic 2005 Déploiement d'une application