I déploiement d’application Windows avec Visual Studio. Net








télécharger 89.94 Kb.
titreI déploiement d’application Windows avec Visual Studio. Net
date de publication13.07.2017
taille89.94 Kb.
typeDocumentos
ar.21-bal.com > loi > Documentos

d'application .NET


Colonne
Déploiement d'application Windows Forms avec Visual Studio .NET

I) Déploiement d’application Windows avec Visual Studio.NET 3

1) Généralités et méthodes de déploiement en .NET. 3

a) Déploiement à l’aide de fichiers Windows Installer (.msi) 3

b) Déploiement par simple copie 3

c) Utilisation du déploiement Internet 4

2) Les types de projets de déploiement proposés par VS.NET 4

3) Les atouts de Windows Installer 5

4) Comment redistribuer Windows Installer en cas d’absence sur le poste cible. 6

II) Comment redistribuer le Framework .NET en cas d’absence sur le poste cible ? 7

1) Prérequis à l’installation du Framework.NET 7

2) Mécanismes possibles pour le redéploiement du Framework 8

3) Quelques points à éclaircir 9

a) Installer une version localisée du Framework.NET 9

b) Comportement de Visual Studio.NET 9

III) Mise en pratique 10

1) Exemple de redistribution simple 10

2) Exemple de redistribution avec de l’ADO classique 16

Conclusion 19



I) Déploiement d’application Windows avec Visual Studio.NET

1) Généralités et méthodes de déploiement en .NET.



Le déploiement est le procédé qui consiste à distribuer une application ou un composant afin de l’installer sur une machine différente. Pour qu’une application fonctionne, il faut que tous les composants qu’elle utilise soient présents dans la version attendue sur le poste cible.
Visual Studio.NET utilise la technologie Windows Installer pour redistribuer les applications Windows. En VB6, nous avions l’habitude d’utiliser soit l’assistant d’empaquetage et de déploiement (Package and Deployment Wizard), soit Visual Studio Installer (VSI).
Attention : Bien que VSI utilise la technologie Windows Installer, les projets Windows Installer (.wip) créés avec VSI ne peuvent pas être ouverts avec Visual Studio .NET.
Voici une ressource sur Windows Installer :

http://www.microsoft.com/windows2000/techinfo/howitworks/management/installer.asp
Avec les nouvelles fonctionnalités apportées par .NET (assemblies auto descriptives, CLR commune à tous les langages managés, etc…), la manière de déployer des applications Windows est impactée. Il existe maintenant plusieurs méthodes pour installer son application .NET sur une machine cible.
Nous allons rapidement les présenter ci-dessous.

a) Déploiement à l’aide de fichiers Windows Installer (.msi)


Traditionnellement, les applications Windows ont été installées à l’aide de programmes exécutables et plus récemment à l’aide de fichiers Windows Installer (.msi).

Il ne faut pas perdre de vue que pour installer une application Windows avec Windows Installer, l’utilisateur doit avoir les privilèges suffisants. Ces derniers dépendent des actions effectuées par Windows Installer ainsi que de la plateforme cible. Par exemple, sous Windows 95/98/Me, aucun privilège n’est nécessaire alors que sous Windows 2000/XP, pour faire une action aussi simple que créer un dossier sous « Program Files », il faut appartenir à un groupe ayant des privilèges élevés comme « Utilisateurs avec pouvoir » ou « Administrateurs ».

Si un utilisateur, non membre du groupe Administrateur local, essaie d’installer un fichier .msi sur Windows 2000, il peut obtenir un message lui disant qu’il n’a pas les droits nécessaires pour effectuer l’installation. Il lui sera alors possible d’effectuer l’installation sous un autre profil utilisateur ayant les permissions nécessaires (administrateur par défaut). L’utilisateur devra alors fournir le mot de passe de ce compte.

On peut également utiliser des outils comme SMS pour installer une application avec les droits administrateurs sur tous les postes.

b) Déploiement par simple copie



La nouvelle architecture de .NET permet de déployer par simple copie des fichiers :

● Distribution à l’aide de XCOPY via la console

● Distribution à l’aide du copier/coller dans l’explorateur Windows

● Distribution à l’aide de commandes FTP

● Distribution aux utilisateurs via email.
Il faut quand même noter que certaines fonctionnalités attendues lors d’un déploiement ne sont pas présentes lors de ce type d’opérations (créer un raccourci, vérifier que tous les composants sont présents,…).
De plus, il faut noter que ce type de déploiement ne peut pas être utilisé si l'on fait de l'interopérabilité COM.

c) Utilisation du déploiement Internet


Une nouvelle fonctionnalité d’empaquetage d’application Windows Forms est née avec .NET. Cette approche est appelée « déploiement d’applications .NET par Internet ». Elle fonctionne de la manière suivante :

  1. Vous stockez vos fichiers (assemblies exe ou dlls) sur un serveur.

  2. Les utilisateurs se connectent à l’application à travers leur navigateur (via http) ce qui provoque l’apparition d’une boîte de dialogue « Exécuter ».

  3. Les fichiers initiaux et les assemblies immédiatement nécessaires sont téléchargées dans le répertoire « \assembly\download\ » et le répertoire « Temporary Internet Files ».

  4. Chaque ressource supplémentaire nécessaire est alors téléchargée dans ces mêmes répertoires au cours de l’utilisation de l’application.


Vous trouverez de plus amples informations sur cette nouvelle fonctionnalité aux adresses suivantes :

  • Death of the Browser? :

http://msdn.microsoft.com/library/en-us/dnadvnet/html/vbnet10142001.asp

  • Security for Downloaded Code :

http://msdn.microsoft.com/library/en-us/dnadvnet/html/vbnet12112001.asp
Dans ce document, nous nous concentrerons sur la technologie Windows Installer proposée par Visual Studio.NET.

2) Les types de projets de déploiement proposés par VS.NET


Nous avons la possibilité avec Visual Studio .NET de créer 4 types de projet d’installation :


Type de projet

Utilisation


Projet de configuration (Setup)


Construit un programme d’installation pour des applications Windows.


Projet de configuration Web (Web Setup)


Construit un programme d’installation pour des applications Web.


Projet de module de fusion (Merge Module)


Empaquette un composant qui doit être utilisé par plusieurs applications et qui peut ainsi être ajouté à un package msi.


Projet Cab


Crée un fichier Cabinet téléchargeable à travers un navigateur Internet.

Attention : le type de projet ne peut pas être changé après avoir été créé. Ainsi, si on a choisi de créer un projet de configuration pour une application Windows, on ne peut pas, par la suite, l’utiliser pour le déployer sur le Web. Il faudra recréer un projet de configuration Web.

La différence entre un projet « Setup » et un projet « Web Setup » réside dans le choix du répertoire destination de l’installation :

  • un projet « Setup » installera, par défaut, les fichiers de l’application Windows dans le dossier « Program Files » de l’ordinateur cible.

  • Un projet « Web Setup » installera les fichiers de l’application Web dans un répertoire virtuel racine sur le serveur Web.

Dans ce document, nous nous intéresserons uniquement aux projets « Setup » permettant de déployer des applications Windows.

3) Les atouts de Windows Installer



On utilise en général la technologie Windows Installer pour créer des programmes d’installation traditionnels.

Quand une application Windows nécessite des fonctionnalités d’installation traditionnelles, la technologie Windows Installer semble la plus indiquée pour l’empaquetage et le déploiement.

En effet, cela permet :

● D'obtenir un programme d’installation ayant une interface graphique facile à utiliser

● Une intégration dans le « Panneau de Configuration » pour :

● Installer

● Désinstaller

● Ajouter ou retirer des fonctionnalités de l’application

● Réparer une installation corrompue

● D'obtenir un programme d’installation qui :

● Restore le système dans son état initial en cas d’échec d’une partie du setup.

● Restore le système dans son état initial en cas d’arrêt du setup par l’utilisateur (cancel par exemple).
● De prendre en charge les fonctionnalités suivantes :

● Manipulation du Registre.

● Association de types de fichiers à l’application.

● Installation d’assemblies dans le Global Assembly Cache (GAC).

● Personnalisation de tâches à effectuer après le succès de l’installation

● Vérification des prérequis logiciels et matériels avant l’installation.
Du point de vue du développeur, cela permet également d’utiliser l’architecture de gestion des versions d’applications afin de mettre à jour ou patcher une application dans le bon ordre.
Pour plus d'information sur les mises à jour d'application avec Windows Installer, vous pourrez consulter le document suivant :

Small update et minor upgrade avec Windows Installer 2.0 :

http://www.microsoft.com/france/msdn/support/colones/default.asp
Du point de vue de l’administrateur système, les applications empaquetées au format .msi offrent les fonctionnalités suivantes :

  • L'intégration avec des outils de distribution électronique de logiciels, comme System Management Server (SMS) ou Microsoft Active Directory™ « Directory Service Group Policies for software distribution », permettant un déploiement simplifié sur tout un parc machine.

  • La possibilité d’installation en mode silencieux c’est-à-dire sans interaction avec l’utilisateur.


De plus, lorsque notre application fait de l’interopérabilité COM (par exemple, on utilise un .ocx COM depuis .NET), la seule solution pour installer l’application est un projet Windows Installer.

4) Comment redistribuer Windows Installer en cas d’absence sur le poste cible.



Les packages de Visual Studio Installer étant des packages msi, on sent bien qu’un premier problème va se poser : Quid si Windows Installer n’est pas présent sur la machine cible ?

Dans ce cas, il faudra l’installer ! On a la possibilité, dans les projets « Setup » de joindre le redistribuable Windows Installer à notre programme d’installation qui, dès lors, vérifiera la présence de Windows Installer sur la machine cible et l’installera en cas d’absence.
Pour ce faire, voici la démarche :

  1. clic droit sur notre projet « Setup » dans le Solution Explorer de VS.NET puis sélectionner « Propriétés ».

  2. dans la liste « Programme d’amorçage » sélectionner « Programme d’amorçage de Windows Installer »

  3. cliquer « OK ».


Ceci a pour conséquence, lors de la génération de la solution, de voir apparaître en plus de notre fichier .msi, 4 fichiers supplémentaires :

    • Setup.exe: le fichier qui va déterminer si Windows Installer est présent sur la machine cible

    • Setup.ini: le fichier qui indique à Setup.exe le nom de votre fichier msi à installer

    • Instmsiw.exe: Windows Installer pour les PC avec Windows NT.

    • Instmsia.exe: Windows Installer pour les PC avec Windows 95 ou Windows 98.


Ces fichiers permettront d’installer Windows installer en cas d’absence et ceci quel que soit le système d’exploitation Windows. Il faut noter que Windows Installer est déjà présent sur Windows 2000 et Windows XP.

II) Comment redistribuer le Framework .NET en cas d’absence sur le poste cible ?





Une application .NET nécessite que le Framework.NET soit installé sur la machine cible. Ce dernier ne s’installe pas sur toutes les plateformes. De plus, il ne s’installe que si une version 5.01 ou supérieure de Internet Explorer est présente sur le poste.

1) Prérequis à l’installation du Framework.NET


Voici la liste des plateformes où le framework.NET peut être installé :

  • Microsoft® Windows® 98

  • Microsoft Windows 98 Second Edition

  • Microsoft Windows Millennium Edition (Windows Me)

  • Microsoft Windows NT® 4 (Workstation or Server) si le service pack 6a est installé

  • Microsoft Windows 2000 (Professional, Server, ou Advanced Server) avec le dernier service pack ainsi que les dernières mises à jour critiques (téléchargeable sur "Microsoft Security Web site" : http://www.microsoft.com/security/)

  • Microsoft Windows XP (Home ou Professional)

  • Microsoft Windows .NET Server family


De plus, il est conseillé d’installer les composants suivants (en fonction des besoins de votre application) :



Voici un lien en anglais où toutes les précisions sur les prérequis à installer sont données :

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetdep/html/dotnetfxref.asp
Remarque : l'environnement de développement Visual Studio .NET a des prérequis différents en terme de plateforme :

http://msdn.microsoft.com/vstudio/productinfo/sysreqs/default.asp.
Il y a plusieurs méthodes pour redistribuer le Framework.NET. Le package de distribution du Framework.NET est disponible sous la forme d’un exécutable nommé Dotnetfx.exe. Nous allons voir dans la partie suivante comment redistribuer ce dernier sur les postes non munis du Framework.

2) Mécanismes possibles pour le redéploiement du Framework



Lorsque l’on déploie une application Visual Studio.NET, le Framework doit être installé sur la machine cible. Le Framework ne peut pas être inclus dans le package .msi sous forme de module de fusion (merge module). Il doit être installé séparément du fichier .msi à l’aide de Dotnetfx.exe.
Il y a trois possibilités lorsque l’on distribue une application dépendante du Framework :

  1. Demander à l’utilisateur de lancer Dotnetfx.exe sur sa machine (par un fichier readme.txt par exemple).

  2. Pour les administrateurs, dans les entreprises, utiliser un outil de distribution de logiciels type SMS. Ceci permet en effet de redistribuer le Framework.NET une fois pour toute sur tous les postes de l’entreprise.

  3. Utiliser un programme d’amorçage fourni par Microsoft (« setup.exe bootstrapper sample ») qui va lancer une installation silencieuse de Dotnetfx.exe puis lancer l’installation de votre package .msi.


La première possibilité est certainement la plus simple à mettre en œuvre. Sachant que si le Framework.NET n’est pas installé, l’application ne s’installera pas, le fichier readme.txt aura un poids plus fort.
La deuxième solution est certainement la meilleure pour les grandes entreprises bénéficiant des outils d’administration de parc machine adéquats.
La troisième possibilité ravira les personnes qui veulent retrouver un déploiement installant tous les fichiers (Framework, package etc,…) à l’aide d’un setup (même si dans la réalité, les divers constituants sont juste installés les uns après les autres).
Le programme d’amorçage effectue les opérations suivantes :

  1. Vérification de la présence du Framework.NET sur le poste cible.

  2. Lancement d’une installation silencieuse de Dotnetfx.exe si la version spécifiée du Framework n’est pas présente, et, si nécessaire, installation ou mise à jour de Windows Installer en version 2.0. Un redémarrage de la machine peut être nécessaire à ce moment là.

  3. Installation de votre application. Si un redémarrage est nécessaire, il est reporté après la fin de l’installation de votre application.


Vous pourrez télécharger ce programme d’amorçage « Framework setup.exe bootstrapper sample » à l’adresse suivante :
http://www.microsoft.com/downloads/details.aspx?FamilyId=BF253CFD-1EFC-4FC5-BA7E-6A6F21403495&displaylang=en
Pour l’utiliser, il suffit de télécharger les fichiers compilés et de suivre les instructions fournies. Un fois téléchargés, vous aurez :

  • un fichier settings.ini qui vous permettra de paramétrer votre installation,

  • un fichier setup.exe qui lancera l’installation et fera les actions décrites précédemment.

Si vous voulez en savoir plus, les sources de ce programme sont fournies.
Nous allons montrer un tel déploiement plus loin dans ce document (cf. Mise en pratique).

3) Quelques points à éclaircir

a) Installer une version localisée du Framework.NET


Dotnetfx.exe a été localisé en différentes langues. Le Framework.NET s’installe dans toutes les langues sur les systèmes d’exploitation Windows Me, Windows 2000, Windows NT 4.0, Windows XP (et les Windows .NET à venir). On peut très bien mettre un Framework français sur une machine US et inversement. D'ailleurs, on peut mettre plusieurs Framework dans des langues différentes sur les plateformes citées plus haut. Par contre, comme toute règle a ses exceptions, sur un système Windows 98, il vous faudra installer la version du Framework.NET correspondant à la langue du Windows 98 installé sur la machine. Par exemple, il vous faudra installer la version française de Dotnetfx.exe sur un Windows 98 français.
Cette limitation concerne seulement Windows 98.
Les versions localisées du Framework.NET sont téléchargeables à partir du site

http://msdn.microsoft.com/downloads

b) Comportement de Visual Studio.NET


Lorsque l’on ajoute un projet de configuration afin de déployer une application, Visual Studio.NET ajoute dans les dépendances du projet un module de fusion (merge module) appelé dotnetfxredist_x86_enu.msm.


Par défaut, ce module de fusion est exclu du fichier .msi. En effet, il ne peut pas être redistribué. Il existe pour un usage interne du projet, afin d’empêcher que chaque assembly du Framework.NET utilisée par l’application ne soit listée dans les dépendances du projet.
Si vous essayez d’inclure dotnetfxredist_x86_enu.msm à votre package msi, vous recevrez une erreur de compilation :
ERREUR : dotnetfxredist_x86_enu.msm ne doit pas être utilisé pour redistribuer le .NET Framework. Veuillez exclure ce module de fusion.
Il vous faudra donc toujours exclure ce module de fusion.
Par contre, s’il est exclu, vous obtiendrez quand même un Avertissement :

AVERTISSEMENT : Ce programme d'installation ne contient pas le .NET Framework qui doit être installé sur l'ordinateur cible en exécutant Dotnetfx.exe avant cette installation. Le fichier Dotnetfx.exe se trouve sur le média Visual Studio .NET 'Windows Components Update'. Dotnetfx.exe peut être redistribué avec votre programme d'installation.
Cet avertissement vous indique que le moyen approprié de redéployer le Framework.NET est d’utiliser Dotnetfx.exe.

III) Mise en pratique


Nous allons maintenant appliquer ce que nous avons vu à des cas simples et concrets :

  • Redistribution d’une application .NET pure

  • Redistribution d’une application d’accès aux données avec ADO classique.


Le premier exemple va nous permettre de regarder comment redéployer le Framework .NET avec notre application. Le deuxième montrera comment redéployer MDAC avec notre package msi.

1) Exemple de redistribution simple



Pour fixer les idées, rien de tel que de créer son premier package de déploiement.
Nous allons créer un projet de configuration pour une application écrite avec le SDK du Framework .NET.
Cette application se nomme « SimplePad » et vous la trouverez dans le dossier FrameworkSDK sous l’arborescence suivante :

Samples\QuickStart\winforms\samples\printing\simplepad\cs si vous avez installé les exemples du Framework SDK.
Ouvrez la solution SimplePad.sln. Cette application est un Bloc-notes permettant d’afficher, de créer, d'imprimer des fichiers texte.
La première chose à faire est d’ajouter un projet de configuration à cette solution.

Pour ceci, allez dans Menu « Fichier », « Ajouter un projet » puis « Nouveau projet ».

On a alors le choix entre les différents types de projet de déploiement discutés dans la première partie.
Nous choisissons un « projet de configuration » (Setup Project).

Une fois ce projet ajouté à notre solution, nous allons commencer à le configurer.
La première chose à faire est de sélectionner les « sorties du projet ». Pour cela, cliquez avec le bouton droit sur le projet «Setup1», sélectionnez « Ajouter » puis « sortie du projet ».


Sélectionnez SimplePad dans la zone de liste déroulante pour « sortie principale » et appuyez sur "OK".
On voit apparaître en dépendance du projet dotnetfxredist_x86_enu.msm


De plus, la sortie principale de l’application apparaît dans le dossier de l’application.

On peut alors créer un raccourci sur le bureau en cliquant sur la sortie principale avec le bouton droit et en sélectionnant « créer un raccourci ». On déplace ensuite ce raccourci dans le dossier Bureau de l’utilisateur

(cf. fiche technique : Q307358 HOW TO: Create Shortcuts for a .NET Deployment Project

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q307358)
Nous avons ainsi créé un projet de configuration minimal.
On peut alors générer le package msi (menu « générer » puis « générer setup1 »).
Le premier test que nous allons faire est d'installer ce package sur la machine de développement. Pour cela, cliquer avec le bouton droit sur le projet setup1 dans l’explorateur de solution et choisir « Installer ».

Il est évident qu’un package aussi simple va s’installer sans problème sur la machine de développement qui contient déjà tous les composants nécessaires au fonctionnement de l’application. Par contre, cela peut être utile si l’on veut vérifier que d’éventuels fichiers ajoutés au package sont bien redistribués au bon endroit (dans notre cas, que le raccourci est bien créé sur le bureau).
De même, après avoir installé et vérifié que l’on a bien un raccourci sur le bureau, on peut désinstaller l’application en faisant la même opération et en choisissant « désinstaller ».

Il est aussi possible de choisir de désinstaller à partir de l'icône "ajout et suppression de programmes" situé dans le panneau de configuration.
Maintenant que nous avons vérifié que notre package installe l’application, nous allons essayer de le déployer sur une machine de test.
Si on regarde dans le dossier de Setup1, on a notre package généré sous le dossier Debug.

On voit bien que le fichier msi ainsi que les fichiers d’installation de Windows Installer ont été générés. Ceci est activé, par défaut, dans Visual Studio.NET.
Ce package suffirait si nous voulions déployer sur une plateforme où le Framework .NET est déjà installé. Par contre, s’il est absent, l’application refusera de s’installer car, par défaut, il y a une condition de lancement pour les package msi généré par Visual Studio.NET qui vérifie la présence du Framework et annule l’installation en cas d’absence.
Si nous voulons que le Framework soit installé avant que l’installation du package msi commence, nous pouvons utiliser le projet d’amorçage (Microsoft .NET Framework setup.exe bootstrapper sample) fourni sur le site Microsoft à l’adresse suivante :

http://www.microsoft.com/downloads/details.aspx?FamilyId=BF253CFD-1EFC-4FC5-BA7E-6A6F21403495&displaylang=en
Cet utilitaire vient en complément du package msi que nous venons de créer.

Son rôle consiste à effectuer une vérification de la présence du Framework .NET. En cas d’absence, il cherchera à lancer le package de redistribution du Framework : Dotnetfx.exe.
Téléchargez la version compilée de ce projet d’amorçage. Elle consiste en deux fichiers :

  • Setup.exe : c’est ce fichier qui lancera la vérification de la présence du Framework .NET et qui l’installera en cas d’absence.

  • Settings.ini : ce fichier sert à configurer l’installation (proposer un partage réseau où trouver Dotnetfx.exe par exemple)


Pour modifier un projet de déploiement afin d’utiliser l’utilitaire d’amorçage, il faut :

    1. Sélectionner le projet de configuration dans l’explorateur de solution

    2. Cliquer avec le bouton droit afin d’obtenir les propriétés

    3. Dans la page de propriété, mettre la propriété « programme d’amorçage » sur « Aucun »


Après avoir regénéré le projet de configuration, on obtient un seul fichier en sortie : setup1.msi (les différents fichiers pour l’installation de Windows Installer ne sont plus présents).
Le plus simple est alors de copier ce fichier msi dans un dossier de déploiement avec les fichiers setup.exe, settings.ini et Dotnetfx.exe :

Il ne nous reste plus qu’à configurer le fichier settings.ini. Si on l’ouvre avec le bloc-notes, il apparaît sous la forme suivante :

Nous avons à notre disposition 6 paramètres dont 5 sont en commentaire.
Pour notre déploiement, la première chose à faire est de remplacer la ligne

Msi=FxCopSourceSetup.msi

par :

Msi=Setup1.msi
On a également la possibilité de spécifier un partage réseau, Msi=\\monpartage\mondossier\Setup1.msi, ou un sous répertoire, par exemple Msi=mondossier/Setup1.msi.
Il en est de même pour la localisation de Dotnetfx.exe que l’on peut personnaliser à l’aide du paramètre FxInstallerPath. Etant donné que notre Dotnetfx.exe se situe dans le même répertoire que setup.exe et settings.ini, il n’est pas nécessaire d’utiliser ce paramètre.
Sauvegardons donc les modifications apportées au fichier settings.ini.
Il est également possible de demander au projet d’amorçage de vérifier, en plus de la présence du Framework et de sa version, la langue du Framework installé. Ceci est fait grâce au paramètre LanguageDirectory du fichier settings.ini. Nous ne nous servirons pas ici de cette possibilité.
Les différentes entrées de ce fichier settings.ini sont décrites à l'adresse suivante :

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetdep/html/redistdeploy.asp

(dans la partie : " Creating the Settings.ini file")
Nous pouvons maintenant tester notre package de déploiement sur une machine n’ayant pas le Framework.
Il ne faut pas perdre de vue que pour s’installer, le Framework a besoin de certains composants (IE 5.01 minimum, etc…). Avant d’essayer d’installer l’application il est utile de s’assurer que la machine cible remplie bien les conditions requises :

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetdep/html/dotnetfxref.asp
Si ce n’est pas le cas, le programme Dotnetfx.exe remontera une erreur et l’installation ne pourra pas continuer.
Un fois notre application installée et fonctionnant, il est toujours possible de la désinstaller, ainsi que le Framework, à l’aide d’ajout et suppression de programmes dans le panneau de configuration.

2) Exemple de redistribution avec de l’ADO classique



Il est possible avec VB.NET d’utiliser notre bon vieil ADO par interopérabilité. Nous allons maintenant effectuer le déploiement d’une application VB.NET simple utilisant ADO classique.
Pour cela, nous allons utiliser un code très simple se connectant à la base exemple SQL server nommée « Pubs ».


  1. Ajouter une référence à Microsoft ActiveX Data Object Library 2.7 (clic avec le bouton droit sur Référence dans l’explorateur de projet => « ajouter une référence » => choisir Microsoft ActiveX Data Object Library 2.7 dans l’onglet COM

  2. Ajouter 2 contrôles textbox sur votre formulaire

  3. Coller les déclarations suivantes dans la section de déclaration générale de votre formulaire :


Dim cn As New ADODB.Connection()

Dim rs As New ADODB.Recordset()

Dim cnStr As String

Dim cmd As New ADODB.Command()


  1. Coller le code suivant dans l’évènement Form_Load :


cnStr = "Provider=SQLOLEDB;Initial Catalog=Pubs;Data Source=nomserveur;User ID=sa;Password=motdepasse;"

cn.Open(cnStr)

rs = cn.Execute("Select * from Authors")
TextBox1.Text = rs.Fields(0).Value.ToString

TextBox2.Text = rs.Fields(1).Value.ToString
rs.Close()

cn.Close()
rs = Nothing

cn = Nothing
Lorsque vous lancez l’application, les deux boîtes de texte sont remplies au chargement du formulaire
C’est cette application simpliste que nous allons redistribuer maintenant.
Ajoutons un projet de configuration à notre solution et configurons les sorties du projet.
On voit bien que la « Primary Interop Assembly » ADODB.dll est détectée comme dépendance de notre application :


Bien sûr, étant donné que l’on référence ADO, nous allons devoir redéployer MDAC sur les machines cibles si la version n’est pas au moins MDAC 2.7.
Pour cela, un White Paper est disponible. Il traite de la redistribution de MDAC dans un package Windows Installer. Vous le trouverez ici :

http://support.microsoft.com/default.aspx?scid=kb;FR;q320788

Après avoir téléchargé ce White Paper, vous trouverez un lien à l’intérieur permettant de télécharger le module de fusion permettant de redistribuer MDAC (mdac.msm). Ce module de fusion permet le redéploiement de mdac_typ.exe qui reste la seule manière supportée d’installer MDAC.

Après lecture du White Paper, vous verrez que ce module inclut mdac_typ.exe, ce qui permet de contourner la protection des fichiers systèmes de Windows sous les plateformes Windows 2000, Windows XP et suivantes.
Une fois ce module de fusion téléchargé, il suffit de l’ajouter à notre projet de configuration :

  1. Clic droit sur le projet de configuration dans l’explorateur de solution

  2. Selectionner Ajouter

  3. Choisir module de fusion

  4. Sélectionner mdac.msm


Le module de fusion est alors listé dans les dépendances du projet.


Il suffit alors de générer l’application et d’installer le package msi sur un poste cible.
Lors de l’installation, une fois l’application installée, le merge module est lancé et installe, en cas de besoin, MDAC à l’aide de mdac_typ.exe.
On peut noter que même si MDAC 2.7 est présent sur la machine, le module de fusion lance mdac_typ.exe. Ceci est sans conséquence car mdac_typ.exe saura gérer la mise à jour et ne fera pas de changements s’il détecte que MDAC est déjà présent dans une version égale ou supérieure.
Ceci nous permet d’utiliser, si on le désire, le programme d’amorçage, permettant de vérifier que le Framework est présent, avec le package msi contenant le module de fusion qui déploie MDAC 2.7.

Conclusion



Visual Studio.NET nous offre la possibilité de créer des projets de configuration permettant d’effectuer les tâches de bases de tout programme d’installation. Il utilise la technologie Windows Installer avec tous ses avantages.

Nous ne sommes plus maintenant dépendants des différentes runtimes de nos outils de développement (runtime VB, runtime C, MFC, etc…). La seule chose dont nos applications écrites en code .NET pur ont besoin c’est le Framework.NET. Nous avons vu différentes manières de le redistribuer. L’avantage de celui-ci c’est qu’une fois installé sur une machine, on n’aura plus à se soucier de lui. Pour l’instant, il nous faut encore vérifier sa présence. Ceci est fait, soit par l’utilisateur, soit par le programme d’amorçage dont nous avons parlé plus haut. Ce programme d’amorçage peut également être utilisé dans le cas d’une application d’accès aux données utilisant de l’ADO classique. Il faudra alors compléter notre package de déploiement avec le module de fusion permettant de redéployer MDAC 2.7.
Il ne faut pas oublier qu’à terme, le Framework devrait être présent dans les systèmes d’exploitation Microsoft ce qui facilitera le déploiement des applications .NET.
Références :
Walkthrough: Deploying a Windows Application :

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsintro7/html/vbtskCreatingInstallerForYourApplication.asp

Deployment Articles :

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vstchDeployment.asp

Deploying .NET Applications: Lifecycle Guide :

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/DALGRoadmap.asp

Microsoft .NET Framework Setup.exe Bootstrapper Sample :

http://www.microsoft.com/downloads/details.aspx?FamilyId=BF253CFD-1EFC-4FC5-BA7E-6A6F21403495&displaylang=en

Microsoft .NET Framework Redistributable :

http://www.microsoft.com/downloads/details.aspx?FamilyID=d7158dee-a83f-4e21-b05a-009d06457787&displaylang=en


Microsoft France

Auteur :

Date de révision : 12/02/2003

Version : 1.0

similaire:

I déploiement d’application Windows avec Visual Studio. Net iconIntroduction à ado. Net avec Visual Basic 2005

I déploiement d’application Windows avec Visual Studio. Net icon3 tiers d’architecture, 100% de Visual Basic Les composants
«bout code» qu’il faut rajouter dans le code d’une application principale. IL arrive, d’ailleurs, fréquemment qu’un composant soit...

I déploiement d’application Windows avec Visual Studio. Net iconRésumé : Cet article présente le processus de migration de Visual...

I déploiement d’application Windows avec Visual Studio. Net iconJava 2ee (Jsp Servlet Ejb jpa/Hibernate Spring Jsf “Seam : notions”...

I déploiement d’application Windows avec Visual Studio. Net iconSolution En partenariat avec Xavor et Analysis Team, Virgin a déployé...
«Grâce à Windows Server System et. Net, nous avons élaboré une solution globale en réponse à un problème commercial très préoccupant....

I déploiement d’application Windows avec Visual Studio. Net iconDéveloppement d’une application de gestion de contacts avec asp. Net mvc (C#)

I déploiement d’application Windows avec Visual Studio. Net icon4Conception d’une solution de développement Visual Studio pour des Feature Receivers: 23

I déploiement d’application Windows avec Visual Studio. Net iconDéploiement Windows Seven 64 bits

I déploiement d’application Windows avec Visual Studio. Net iconDéveloppement d’une application de gestion de contacts avec asp. Net mvc (C#)
«Mock Object Framework» puis fabriquer des tests unitaires pour nos contrôleurs et logiques de validation

I déploiement d’application Windows avec Visual Studio. Net iconProgramme accompagnateur suisse
«hate radio» reprend de vraies émissions de la rtlm et les restitue en direct, sur scène, dans un studio reconstruit d’après le studio...








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com