Déploiement

Transcription

Déploiement

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
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
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.
236
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.
237
•
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.
238
•
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é.
239
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.
240
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
241
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.
242
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).
La documentation fait parfois mention d’un shared name, une « traînerie » des
premières versions bêta.
11
243
•
Ê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.
244
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.
245
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é.
246
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.
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.
13
247
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 ».
248
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 2005.
2002-2003
249
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.
250
•
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.
251
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.
252
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.
253
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.
254
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é.
Vous savez qu’un fichier suit le défaut quand son Publish Status est réglé à
Include (Auto).
18
255
[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.
256
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
⇒
Un click sur [Publish Now] fait tout le travail de publication.
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.
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.
257
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.
258
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.
259
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.
260
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.
L’équivalent du vieux Setup and Deployment Wizard de VB6, mais en mieux,… et
celui-là donne des résultats qui fonctionnent.
20
261
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.
262
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.
263
⇒
⇒
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.
Consultez l’aide en ligne à Resource Files si c’est quelque chose qui pourrait
éventuellement vous intéresser.
23
264
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.
Les curieux constateront que ce projet possède l’extension vdproj (probablement pour
Visual Deployment Project) plutôt que le vbproj habituel.
24
265
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.
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.
25
266
⇒
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.
267
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
Vous pouvez aussi simplement faire glisser des fichiers de Windows Explorer
(L'Explorateur Windows) à la fenêtre listant les composantes de l’application
27
268
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.
269
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.
270
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.
271
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
Comme par le fichier de trace qui est créé par PhotoCat lorsqu’une erreur imprévue
survient dans certaines compilations.
29
272
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.
273
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 luimê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 doublecliquant 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.
274
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=04DBAF2E61ED-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.
275
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.
276
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 ☺).
277
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-InTime 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.
278
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.
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.
31
279
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.
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.
32
33
N’oubliez pas que .NET ne fonctionne pas sur Windows 95 ou sur NT3.
280

Déploiement

Transcription

Documents pareils

Dial-a-fix pour corriger les mises à jour de Windows.

Mon CV - Site Web de Wizou

Diapositive 1

recrute - Neuilly

Lecture des joysticks sous Windows

experiences professionnelles

Karta przedmiotu

FDP Saitek X52 Flight Control System

CV en PDF

IcProg 1.05C/ Windows_XP Alain le 27.08.06 Je viens de faire une