Déploiement et empaquetage d'applications professionnelles Access 2000 avec l'utilisation du Runtime

Jean-Philippe AMBROSINO

Ce document a pour but de simplifier la compréhension du déploiement des applications développées avec Microsoft Access 2000®.
Cela concerne Microsoft Office Professional® et Microsoft Office Premium® associés à Microsoft Office Developer® et les applications Visual Basic for Application® version 6.0a
Une partie de ce document traite de l'utilisation du Runtime.

Commentez ♪

- Titre : Déploiement et empaquetage d'applications professionnelles Access 2000 avec l'utilisation du Runtime

- Auteur : Jean-Philippe AMBROSINO

- Parution : 17 février 2005

- Mise à jour : 28 juin 2007

- Licence : Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur. La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur.

Sommaire

- I. Avant-propos

- I-A. Remerciements

- I-B. Contact

- II. Le développement de votre application

- II-A. Les tests à effectuer avant de générer un fichier MDE

- II-B. Test de l'application comme si elle était installée sur un poste client

- II-B-1. …comme s'il était doté de la version complète Microsoft Access

- II-B-2. …comme s'il était doté du Runtime Access seul sans version de Microsoft Access

- II-B-3. …doté du Runtime Access 2003 conjointement avec une version antérieure de Microsoft Access

- II-C. Comment et pourquoi convertir en MDE ?

- II-C-1. Caractéristique d'un MDE

- II-C-1-a. Précisions supplémentaires

- II-C-2. Création du MDE

- II-C-3. Impossibilité de générer un fichier MDE

- II-D. Sécurisation de votre Projet

- II-D-1. Sécurisation de votre application

- II-D-1-a. Les propriétés de protection d'une application

- II-D-2. Sécurisation de votre package

- III. Déploiement et empaquetage de votre application

- III-A. Préparation en vue d'exploiter l'application avec le Runtime Microsoft Access

- III-A-1. Préparation en vue d'exploiter l'application avec la licence Microsoft Access

- III-B. Installation de Microsoft Office Developer

- III-B-1. L'ensemble comprend les outils ci-dessous

- III-B-1-a. Les outils nécessaires au déploiement des applications et le Runtime

- III-B-1-b. Les outils de création de fichiers d'aide

- III-B-1-c. Les outils complémentaires au développement VBA

- III-B-1-d. Les outils complémentaires d'administrationde vos bases de données

- III-B-1-e. Les autres outils

- IV. Présentation de l'Assistant Empaquetage et Déploiement

- IV-A. Les options de l'Assistant Empaquetage et Déploiement

- IV-B. Empaquetage des applications

- IV-C. Processus d'empaquetage

- IV-C-1. Identification des fichiers à distribuer

- IV-C-2. Identification des fichiers de dépendance pour les composants de votre application

- IV-C-3. Choix de l'emplacement d'installation des fichiers sur la machine de l'utilisateur

- IV-C-4. Génération de l'empaquetage

- IV-C-4-a. Déploiement sur disquettes, répertoires et CD-ROM

- IV-C-4-b. Déploiement sur le Web

- V. Préparation de l'empaquetage

- V-A. Pour empaqueter votre application

- V-A-1. Définition des options complémentaires du Gestionnaire

- V-B. Démarrage de l'empaquetage

- V-C. Recherche des dépendances

- V-C-1. Information sur les dépendances manquantes

- V-C-2. Recherche manuelle des informations de dépendance

- V-C-3. Mise à niveau d'un fichier de dépendance

- V-C-3-a. Supprimer l'alerte du manque d'information relatif aux dépendances périmées

- V-C-3-b. Mise à niveau d'un fichier.dep

- V-D. Ajout de fichiers complémentaires

- V-D-1. Ajout de fichiers externes

- V-D-2. Petite interruption due aux dépendances

- V-D-3. Suppression d'un élément inséré par erreur

- V-E. Inclusion du Runtime dans le package

- V-E-1. Modification du Titre de la fenêtre d'installation

- V-F. Définition du groupe du menu Démarrer/Programmes

- V-G. Définition manuelle des dossiers de destination

- V-G-1. Partage des fichiers de l'application

- V-G-2. Enregistrement du Script d'empaquetage

- V-G-3. Mise en œuvre du package

- V-G-4. Fin de génération du package

- VI. Évolution de votre package

- VI-A. Gestion des scripts de l'Assistant

- VI-A-1. Avec cette option, vous pouvez effectuer diverses opérations

- VI-B. Modification ou évolution de votre projet

- VI-B-1. Modification de votre projet

- VI-B-2. Réempaquetage de votre projet modifié

- VI-B-2-a. Pour régénérer votre jeu de fichiers CAB accompagné du setup.exe correspondant

- VI-B-3. Régénération du package à l'aide d'un fichier Batch

- VI-C. Stockage de votre package sur une source d'installation

- VI-C-1. Création d'un fichier AutoRun pour votre CD- ROM

- VI-C-1-a. Pour concevoir un fichier Autorun

- VII. Tester son programme d'installation

- VII-A. Pour tester votre programme d'installation sur disquettes ou CD-ROM

- VIII. Exemple d'installation sur un poste client

- VIII-A. Cas de figure où l'on souhaite installer le Runtime sur le poste

- VIII-A-1. Étape 1 : Exécution du Setup

- VIII-A-2. Étape 2 : Premier redémarrage (Composants périmés)

- VIII-A-3. Étape 3 : Installation de l'application

- VIII-A-4. Étape 4 : Progression de l'installation

- VIII-A-5. Étape 5 : Fin de l'installation

- VIII-A-6. Étape 5 : Attribution d'une icône au raccourci

- VIII-B. Cas de figure où le Runtime ou Microsoft Access sont déjà présents sur le poste

- VIII-C. Modification du Setup.exe

- IX. Les tests à effectuer sur un poste de test

- IX-A. Test de l'application installée sur un poste…

- IX-A-1. …doté de Microsoft Access

- IX-A-2. …doté du Runtime Access seul sans aucune version de Microsoft Access

- IX-A-3. …doté du Runtime Access conjointement avec une version différente de Microsoft Access

- X. Erreur d'exécution au cours des tests

- X-A. Quelques exemples

- XI. Création d'un formulaire de démarrage

- XI-A. Spécification d'un formulaire de démarrage et des options de démarrage

- XI-B. Exemple de formulaire de démarrage

- XI-B-1. Génération d'un formulaire de démarrage temporisé

- XII. Installation du Runtime Microsoft Access sur le poste client

- XII-A. Installation manuelle

- XII-A-1. Lancement de l'installation manuelle sur un poste

- XII-B. Installation automatique du Runtime

- XII-C. Une fois le Runtime installé…

- XIII. Différences entre Microsoft Access et l'environnement Runtime

- XIII-A. Microsoft Access et la clé de licence Runtime

- XIV. Les erreurs liées à l'installation

- XIV-A. Erreur d'exécution 429 lors de l'exécution d'un programme Access

- XIV-B. Message d'erreur : Impossible du fichier C:\Windows\Temp\Msftqws.pdw\$(DllSelfRegisterEx) ne peut pas être inscrit parce qu'il n'a pas été trouvé.

- XIV-C. Erreur dans le chemin d'accès en installation du Runtime (Office XP)

- XIV-D. Problème de cohabitation des projets Access avec un Runtime Access

- XV. Utilisation du Runtime dans Office XP Developer

- XV-A. Empaquetage de solution Microsoft Access XP

- XV-A-1. Prérequis pour l'exploitation du Runtime Access XP

- XV-A-2. Installation d'un empaquetage contenant le Runtime Access XP

- XV-B. Correctif de sécurité Access Runtime pour Office XP

I - Avant-propos

Ce document a pour objectif de satisfaire aux demandes des développeurs ayant besoin de déployer des applications Microsoft Access.
Bien que dédié à Microsoft Access 2000, vous pouvez prendre en compte certaines informations de ce document pour les mettre en application sur les versions 97 ou XP.

Ce document a pour objectif de satisfaire aux demandes des développeurs ayant besoin de déployer des applications Microsoft Access version 2003.
Quatre autres tutoriels sont disponibles pour les versions 2003, 2007, 2010, et 2013 sur le forum.

I-A - Remerciements

Je tiens à remercier tout particulièrement Messieurs Maxence Hubiche, Papy Turbo et Fred G. ainsi que toutes celles et tous ceux qui ont participé à la relecture de ce document en y incluant leurs remarques.

À l'aide de leur collaboration, j'ai pu construire ce support qui j'espère vous apportera une aide précieuse.

I-B - Contact

Pour tous renseignements complémentaires, veuillez me contacter directement (Argyronet) par MP.

II - Le développement de votre application

Lorsqu'il vous est demandé de développer une application Access, la difficulté ultérieure à laquelle vous risquez d'être confronté est la mise en place de cette application sur un ou plusieurs postes cibles. Au sein de l'entreprise dans ou pour laquelle vous travaillez, vous avez la responsabilité d'un ou plusieurs projets et par ce fait, vous participerez de près ou de loin à la mise en œuvre de tous les paramètres pour que vos applications soient opérationnelles.
Les informations contenues dans ce document considèrent le cas suivant :

1. Vous développez une application à partir de Microsoft Office ;

2. Vous êtes en possession de Microsoft Office Developer ;

3. Les postes clients possèdent ou ne possèdent pas une licence Access installée.

De nombreuses phases de test sont nécessaires avant d'envisager la mise en place sur les postes clients. Ainsi, vous devez être à même de considérer trois cas de figure en ce qui concerne les applications.

Les applications simples

C'est ce que j'appelle des petites applications de base de données où seul est prédominant le traitement des données. Les formulaires sont pratiques à utiliser, mais sans look particulier et sans grande convivialité (Les Comptoirs exemple fourni en standard), des états lisibles contenant les informations attendues et l'ensemble est géré de façon semi-automatique avec quelques macros ou quelques routines VBA.
L'utilisateur sera alors confronté à une interface pauvre et par le fait, aura pour la majorité, un grand nombre de données à saisir manuellement pour aboutir à ses fins. Le tout fonctionnera en partie avec l'utilisation des menus Access intégrés et l'interface Access en arrière-plan.

L'utilisateur pourra au gré de ses besoins, intervenir pour modifier ou créer des requêtes par exemple.

Les applications avancées

C'est ce que j'appelle des applications semi-professionnelles de base de données où est prédominant le côté convivial et « user friendly » de votre application. Le développeur aura conçu un projet propre, doté de fenêtres agréables, inclus des boutons pour automatiser les tâches et créé des menus personnalisés.
L'utilisateur bénéficiera d'un confort d'utilisation très agréable avec de nombreux automatismes, des vérifications systématiques des entrées, des contrôles autoactivés en fonction des types de données saisis.
Les états auront un rendu très soigné, les ruptures des regroupements auront été vérifiées, etc.
L'application ne contiendra pas ou peu de macros et aucune pour les traitements des données.

Les applications professionnelles

Ce sont mes préférées… C'est le nirvana de l'application avancée. Elles seront dotées des caractéristiques totalement similaires aux précédentes, mais seront développées avec une finition irréprochable.
C'est une approche délicate, car le développeur doit oublier Access et considérer que son application est totalement indépendante. Quand je dis oublier Access, j'entends pour n'en détailler que quelques-uns, les commandes du type DoMenuItem et l'exploitation des barres d'outils autant que celle des menus contextuels intégrés sont à proscrire, voire oublier. Dans l'absolu, cacher l'instance Access pour ne laisser apparaître que l'application elle-même est un must auquel je me prête systématiquement.

Donc, quel que soit le type d'application que vous développerez, il est envisageable que pour leur distribution, vous soyez tenu de fournir un programme d'installation automatisé.
Il est vrai que pour le cas des applications simples, la fourniture du fichier MDB par le biais d'un fichier d'installation automatisé peut paraître exagérée. En fait, si vous n'avez aucun composant (OCX, DLL…) et que tous les postes cibles (utilisateurs) sont équipés d'une version complète d'Access, il suffit de distribuer les fichiers (mdb ou mde).

Si votre application, quelle que soit la catégorie dans laquelle elle se range, utilise des composants spéciaux tels que des DLL ou des OCX externes, vous devez faire en sorte que ces derniers soient fournis avec votre projet et qu'ils puissent être inscrits dans la base de registre de Windows du poste client.

De plus, si vous envisagez de distribuer vos applications avec le Runtime Microsoft Access, vous devez prendre en considération un certain nombre de paramètres. C'est pour cela que l'usage de l'Assistant Empaquetage et Déploiement peut vous aider considérablement dans cette manœuvre même si vous pouvez envisager la distribution par un autre procédé.

II-A - Les tests à effectuer avant de générer un fichier MDE

Une fois le développement terminé, vous devez lancer une batterie de tests afin d'éliminer toutes les erreurs potentielles.

Le cas typique est souvent l'omission d'un formulaire de démarrage ou celle d'une macro AutoExec ou encore l'omission de certaines références à des objets externes.

II-B - Test de l'application comme si elle était installée sur un poste client

Le jeu de tests consiste à exécuter l'application dans une situation identique à celle dans laquelle elle se trouvera après déploiement avec un poste…

II-B-1 - …comme s'il était doté de la version complète Microsoft Access

Il ne devrait pas y avoir de grande différence avec le poste de développement depuis lequel vous avez créé l'application.

Le jeu de tests consistera alors à naviguer entre les différents formulaires, l'impression des états (attention notamment à l'orientation des états et aussi à la notion d'imprimante par défaut), à l'exécution de l'ensemble des tâches proposées par votre application.

II-B-2 - …comme s'il était doté du Runtime Access seul sans version de Microsoft Access

Du fait que certaines fonctions Microsoft Access standards sont masquées ou désactivées dans l'environnement Runtime, vous devez vous assurer que l'application fonctionne correctement dans cet environnement avant de la distribuer.

Pour simuler le Runtime, il suffit de créer un raccourci (sur le bureau de votre poste par exemple) avec la syntaxe suivante :

- créez un raccourci pour lancer Microsoft Access ;

- cliquez sur le raccourci avec le bouton droit de la souris, cliquez ensuite sur Propriétés, puis sur l'onglet Raccourci ;

- dans la zone Cible, à la suite du chemin du Fichier MSAccess.exe, tapez le chemin de la base de données à ouvrir puis inscrivez le paramètre /Runtime.

Si le chemin comprend des espaces, placez-le entre guillemets.

Exemple de syntaxe pour un poste utilisateur :

"C:\Program Files\Microsoft Office\Office\MSACCESS.EXE" _
"C:\Program Files\ChessCircle\ChessCircle.mdb" /runtime

Ici, je considère que le poste client ne dispose d'aucune version de Microsoft Access, mais seulement celle du Runtime correspondant à la version de votre application. Dans ce cas, il n'y a pas plus de procédures de test à effectuer que celles qui sont stipulées en section 9.1.1 ci-avant.

Remarque

Le symbole _ représente la continuité de la ligne de commande du raccourci.

II-B-3 - …doté du Runtime Access 2003 conjointement avec une version antérieure de Microsoft Access

Ici, je considère que le poste client dispose d'une version de Microsoft Access antérieure à celle du Runtime qui, lui, correspond à la version 2003 Microsoft Access. Dans ce cas, vous devez mettre en place une syntaxe particulière. Toutefois, l'Assistant Empaquetage et Déploiement 2003 s'en charge à votre place lors du processus d'empaquetage.

Donc, un jeu de tests complet en tentant par exemple d'utiliser un poste de test dédié en y installant par exemple manuellement le Runtime Access 2003 et en y posant votre application et la lancer.

Si vous ne disposez pas d'un poste de test, vous pouvez alors envisager d'installer sur votre propre poste un VMWare® qui vous permettra toutes les fantaisies en matière de simulations.

II-C - Comment et pourquoi convertir en MDE ?

À partir du moment où votre application Microsoft Access comporte du code Visual Basic, il est conseillé de l'enregistrer comme fichier MDE.
Cette opération permet de compiler tous les modules et d'empêcher quiconque d'intervenir sur votre code source, celui-ci étant masqué.
Parallèlement à cela, la base de données occupera moins de place sur le disque dur et le fait que le code soit compilé va augmenter les performances de l'ensemble.

II-C-1 - Caractéristique d'un MDE

- Modification, création de formulaires, d'états ou de modules désactivés.
- Modification, ajout ou suppression des références aux bibliothèques d'objets ou aux bases de données interdites avec bien entendu, l'impossibilité d'intervenir sur le code à l'aide des propriétés ou des méthodes de Microsoft Access.
- L'importation ou l'exportation d'objets tels que formulaires, états ou modules est impossible.
- Seules les tables ou les requêtes peuvent être exportées ou importées vers ou depuis les bases de données.

Attention, avant de créer un MDE, compilez toujours votre projet à partir du menu Débogage de VBE.

Dans tous les cas créez systématiquement une copie de sauvegarde de votre fichier MDB avant de procéder à la conversion en MDE et ce par sécurité. Notez qu'il est impossible d'inverser la compilation de mdb en mde, c'est-à-dire, de récupérer un fichier .mdb à partir d'un fichier .mde !

II-C-1-a - Précisions supplémentaires

Dans la plupart des cas, il est fortement recommandé de scinder votre application en deux bases distinctes à savoir une application frontale qui est le programme utilisateur et l'autre qui représente les données.
Que ce soit en utilisation locale ou en réseau, vous établirez une liaison entre l'application frontale et le fichier MDB contenant les tables. (Clic droit dans la fenêtre de l'onglet Tables et Lier les tables…)
Si l'utilisation est prévue pour être en réseau, vous poserez alors la base de données contenant les tables dans un dossier dédié sur le serveur et établirez la liaison avec l'application frontale depuis cette ressource réseau.

Liaison des tables Microsoft Access

Pour afficher ou modifier les liaisons de votre base de données, il vous suffit d'aller dans le menu Outils/Utilitaires de base de données puis de sélectionner Gestionnaire de tables liées.

Les liaisons sont inscrites en dur dans l'application frontale.

La distribution d'une application dont les données sont liées nécessite que vous preniez la précaution de travailler dans un contexte identique en mode développement. Personnellement, je sais que mon projet sera installé dans C:\Program Files\ChessCircle, donc, je pose ma base de données contenant les tables dans ce dossier et j'y fais référence par un rattachement dynamique ce qui fait que la liaison n'est jamais rompue.

II-C-2 - Création du MDE

Pour générer votre fichier MDE et après avoir vérifié votre code et compilé votre code, vous sélectionnerez dans le menu Outils l'option « Créer un fichier MDE… »

À cet instant, Microsoft Access vous demandera de confirmer le nom du fichier qui est systématiquement le nom du fichier MDB en cours avec une extension MDE.
Vous pouvez ici changer le dossier dans lequel vous souhaitez créer le MDE. Par défaut, ce dossier est celui où a été ouverte l'application.
Vous confirmez par le bouton Enregistrer et le fichier MDE est généré.

II-C-3 - Impossibilité de générer un fichier MDE

Il est possible que Microsoft Access ne soit pas en mesure de générer un MDE à partir de votre application, et ce pour plusieurs raisons :

1. Une erreur dans le code est présente (référence de bibliothèque invalide, erreur de syntaxe, etc.) ;

2. La base de données est protégée avec des autorisations au niveau utilisateur ;

3. Le projet est protégé par mot de passe au niveau de VBE et vous devez le connaître ;

4. La base de données est répliquée et vous êtes tenu de supprimer les propriétés et les tables système répliquées.

Dans tous les cas, un message circonstanciel apparaît, mais ne vous dit pas pourquoi.

Je recommande à tous les développeurs de mettre des gestionnaires d'erreurs dans la plupart des procédures, sauf dans les classes, sous-procédures et certaines bibliothèques et de poser un Option Explicit dans toutes les pages de code.

II-D - Sécurisation de votre Projet

ATTENTION

Ce petit chapitre sur la sécurité est loin d'être exhaustif. Un authentique article sur la sécurité irait beaucoup plus loin.
Cette section a pour seul but de vous montrer que la notion de sécurité doit être prise en compte de façon sérieuse.

II-D-1 - Sécurisation de votre application

Si vous distribuez votre application d'exécution à des utilisateurs qui disposent de la même version Microsoft Access sur leur machine, plusieurs précautions s'imposent pour protéger votre base de données, et ce dans le but d'empêcher les éventuelles modifications des objets et du code ou de perturber par inadvertance le fonctionnement de l'application.

- Sécurisez tous les objets de votre base de données à l'aide de l'Assistant Sécurité fourni avec Microsoft Access. Pour sécuriser parfaitement la base, n'utilisez pas le groupe de travail par défaut défini par le fichier mdw créé lors de l'installation de Microsoft Access.
- Créez votre propre fichier de groupe de travail et donnez-lui un identifiant unique.

- Utilisez des menus et barres d'outils personnalisés dans votre application. Veillez à ne pas inclure de boutons de barre d'outils ou de commandes de menu susceptibles de permettre aux utilisateurs d'accéder aux modes Création des objets ou aux fenêtres Macro ou Module.

- Configurez toutes les propriétés de démarrage de la base de données susceptibles de permettre aux utilisateurs d'accéder à la fenêtre base de données ou au mode Création.

- Donnez à la propriété AllowBypassKey la valeur False pour désactiver la touche Maj. Cette précaution interdit aux utilisateurs d'ignorer les propriétés de démarrage ou la macro AutoExec. Vous trouverez un exemple illustré pour paramétrer la propriété AllowBypassKey par le biais de Visual Basic en cliquant ici.

- Protégez le code Visual Basic par un mot de passe (environnement VBE, menu Outils, Propriétés de Votre projet, onglet Protection)…

Si vous choisissez de mettre en œuvre la protection de votre projet avec la propriété AllowBypassKey, prévoyez pour vous-même une possibilité de désactiver celle-ci sans quoi, vous ne pourrez plus accéder (facilement) à votre application. Par exemple, vous pouvez ajouter un bouton caché dans un formulaire qui permet de passer cette propriété à True.

II-D-1-a - Les propriétés de protection d'une application

Il existe plusieurs propriétés dont vous pouvez écrire par programme en VBA l'affectation. Parmi elles :

- utiliser les touches spéciales d'accès (AllowSpecialKeys) ;
- autoriser la vue du code sur erreur (AllowBreakIntoCode) ;
- afficher la fenêtre de base de données (ShowStartupDBWindow) ;
- autoriser les modifications des barres d'outils/menus (AllowToolbarChanges).

Pour configurer ces propriétés, cliquez sur Démarrage dans le menu Outils ou par programme en VBA.

Si votre base de données contient du code Visual Basic, distribuez-le sous forme de fichier MDE. En effet, le fait d'enregistrer la base de données sous forme de fichier MDE a pour effet de compiler tous les modules, de supprimer le code source modifiable et de compacter la base de données de destination, mais aussi le MDE protège aussi (et surtout) les formulaires, les états, etc.

Donc, dans certains cas, si vous souhaitez laisser aux utilisateurs la possibilité de créer leurs propres formulaires ou leurs états, ne distribuez pas votre application au format MDE et ne verrouillez pas les options de démarrage…

Pour plus d'information à propos de la sécurité de l'accès à la base de données elle-même, veuillez vous rendre sur le forum où toutes ces spécifications sont détaillées par Maxence Hubiche par exemple ici : Les clauses de sécurité Access.

II-D-2 - Sécurisation de votre package

Lorsque vous fournissez un package d'installation contenant ou non le Runtime, vous ne devez en aucun cas fournir le répertoire Support avec ce dernier.

En effet, ce répertoire est réservé à la maintenance de votre empaquetage.

III - Déploiement et empaquetage de votre application

Vous pouvez envisager deux cas de figure pour le déploiement de vos applications. La section déploiement expliquée dans ce document concerne les deux cas avec ou sans Runtime puisque finalement, le principe reste le même.

III-A - Préparation en vue d'exploiter l'application avec le Runtime Microsoft Access

Si vous souhaitez déployer votre application en vue d'une utilisation avec le Runtime Microsoft Access, quelques précautions sont à prendre :

1. Que vous ayez, avant de compiler votre application en .mde, testé votre application en mode Runtime (vue plus loin dans ce document) ;

2. Que vous fassiez en sorte que le Runtime soit installé sur le poste utilisateur.

III-A-1 - Préparation en vue d'exploiter l'application avec la licence Microsoft Access

Si vous souhaitez déployer votre application en vue d'une utilisation avec une licence Microsoft Access, vous devez vérifier que la version de Microsoft Access du poste utilisateur est identique à la vôtre.

III-B - Installation de Microsoft Office Developer

Vous devez installer Microsoft Office Developer sur le poste du développeur pour bénéficier de tous les outils nécessaires à la mise en œuvre de son projet et du déploiement de celui-ci.
Microsoft Office Developer est conçu tout particulièrement pour les développeurs professionnels qui créent et déploient des solutions avec Microsoft Office. Il leur fournit des outils de productivité pour créer rapidement des solutions, des outils d'intégration qui permettent à ces solutions de fonctionner de façon transparente à partir de données et du Web et enfin, des outils de gestion qui simplifient le déploiement et la gestion des solutions créées avec Microsoft Office.

III-B-1 - L'ensemble comprend les outils ci-dessous

Tout le contenu du CD-ROM de Microsoft Office Developer n'est pas à installer sur votre poste de développement. Seuls le Runtime et les outils d'empaquetage et déploiement sont nécessaires. Vous pouvez par la suite installer le générateur de fichier d'aide et d'autres outils comme MSDE, etc.

III-B-1-a - Les outils nécessaires au déploiement des applications et le Runtime

Une version exécutable de Microsoft Access (Runtime)

Distribuez gratuitement les applications Access avec le système de stockage de données Jet ou MSDE (c'est-à-dire sans avoir à faire payer des licences supplémentaires Microsoft Access au destinataire) sur des postes qui ne sont pas équipés d'Access.
La version exécutable de Microsoft Access n'est pas installée sur votre ordinateur au cours de l'installation de Microsoft Office 2000 Developer. Elle se trouve sur le CD-ROM 2 de Microsoft Office 2000 Developer, dans le répertoire Runtime d'Access. Pour éviter d'utiliser le CD-ROM à chaque démarrage de cette version exécutable, copiez les fichiers nécessaires sur votre ordinateur.
Cette version requiert un espace disque de 150 Mo contrairement à la version « MIN » qui requiert 70 Mo.
Pour copier la version exécutable de Access sur votre ordinateur, ouvrez le répertoire Access Runtime depuis le second CD-ROM de Microsoft Office 2000 Developer et copiez son contenu sur votre ordinateur dans le répertoire de destination suivant :

..\Program Files\Microsoft Office\ODETools\V9\Runtime

Les licences pour la redistribution gratuite de MSDE (Microsoft Data Engine) avec la version exécutable de Microsoft Access sont situées quant à elles dans le dossier du second CD-ROM :

.\MSDE

On peut par exemple envisager d'ajouter un Runtime Access 2000 sur un poste équipé d'Access 97 et inversement.

Une autre version exécutable de Microsoft Access (Runtime)

Cette version requiert un espace disque de 70 Mo, contrairement à la version courante qui requiert 150 Mo.

Microsoft Office 2000 Developer propose cette licence qui permet de distribuer la version exécutable de Microsoft Access 2000 aux utilisateurs finals. Afin d'en faciliter la distribution, Microsoft a mis à votre disposition cette autre version exécutable d'Access dont la taille n'est plus de 150 Mo, mais de 70 Mo.

Il est nécessaire que le poste destinataire possède la version 3.01 ou ultérieure de Internet Explorer.

De façon identique, pour éviter d'utiliser le CD-ROM à chaque démarrage de cette version exécutable, copiez les fichiers nécessaires sur votre ordinateur. Pour copier la version exécutable d'Access sur votre ordinateur, ouvrez le répertoire Access Runtime depuis le second CD-ROM de Microsoft Office 2000 Developer et copiez son contenu sur votre ordinateur dans le répertoire de destination suivant :

..\Program Files\Microsoft Office\ODETools\V9\Runtime

III-B-1-b - Les outils de création de fichiers d'aide

Atelier d'aide HTML

Il s'agit d'un environnement complet de création d'aide HTML doté notamment d'un utilitaire de capture d'écran.

L'Aide HTML de Microsoft® contient une visionneuse en ligne, des composants d'aide associés et des outils Microsoft pour la création de l'aide. La visionneuse utilise les composants sous-jacents de Microsoft Internet Explorer pour afficher le contenu de l'aide. Elle prend en charge les langages de script HTML, ActiveX® et Java (JScript® et Microsoft Visual Basic® Scripting Edition), ainsi que les formats d'images HTML (fichiers .jpeg, .gif et .png). L'atelier d'aide HTML (HTML Help Workshop) est un système simple à utiliser, destiné à la création et à la gestion des projets d'aide et de leurs fichiers.

Pour installer HTML Help Workshop, à partir du second CD-ROM de Microsoft Office 2000 Developer, vous sélectionnez Installer Access Workflow Designer et d'autres applications de développement puis choisissez dans la liste Options des composants la mention HTML Help Workshop 1.2. Suivez alors les instructions d'installation.

III-B-1-c - Les outils complémentaires au développement VBA

Outils de productivité VBA

Pour vous faciliter la tâche en ce qui concerne l'écriture du code VBA, vous pouvez installer les Outils de productivité pour VBA 6.0 qui incluent la gestion automatique d'erreurs, le commentaire de code et le transfert de code.
Ces derniers accélèrent le développement en fournissant un ensemble étendu d'outils de productivité qui exploitent la puissance de VBA et vous aident tout au long du processus de création de solutions personnalisées avec Microsoft Office.

Ils permettent notamment d'optimiser la réutilisation du code et de gérer le développement en groupe et fournissent tout pour créer rapidement des solutions basées sur un code fiable. En parallèle, vous disposez d'exemples préécrits pour accélérer le processus de développement.
Il existe toute une liste de ces outils, et vous pouvez n'en installer que certains :

Bibliothèque de code

Application autonome qui facilite le partage de votre code source ainsi que la recherche du code développé par d'autres personnes. Vous pouvez sélectionner des fonctions, modifier le nom, la description et spécifier des critères de recherche. Vous avez également la possibilité de créer des nouveaux extraits de code et d'en supprimer des existants.

COM Add Designer

Dans le passé, vous pouviez déjà utiliser des compléments COM dans VBA, mais des outils tels que Microsoft® Visual C++® ou Microsoft® Visual Basic® étaient nécessaires pour créer ces compléments. Vous pouvez désormais créer vos propres compléments COM dans VBA avec Office 2000 Developer sans autre outil de développement.

Utilisez les concepteurs de compléments pour créer des compléments COM à utiliser dans VBA ou dans toute application Office.

Vous avez par exemple la possibilité de créer un outil pour formater et imprimer du code à partager entre développeurs ou bien créer un complément pour Microsoft® Excel qui permet de calculer des taux de taxe à partager avec les utilisateurs d'Office.

Éditeur de chaînes

Le complément éditeur de chaînes, intégré dans Office 2000 Developer, simplifie grandement le processus de formatage des chaînes complexes telles que les instructions SQL ou les scripts. L'utilisation de ce complément vous permet de saisir simplement les chaînes comme du texte et de marquer les variables incluses dans la chaîne. En fin de saisie, l'éditeur de chaînes formate automatiquement la chaîne à votre place en insérant tous les guillemets et autres caractères de formatage nécessaires.

Commentaire de code Visual Basic pour Applications

Ce complément vous aide à ajouter des commentaires cohérents dans votre code, y compris le nom de l'auteur, la date et l'heure de création ainsi que d'autres informations pertinentes. Il permet d'insérer un modèle d'en-tête au début d'une procédure ; il vous suffit de compléter les zones vides. Vous pouvez choisir d'ajouter des commentaires à une seule procédure, à toutes les procédures d'un module ou à l'ensemble des procédures du projet en même temps.

Gestionnaire d'erreurs Visual Basic pour Applications

Ce complément facilite l'ajout de balises d'erreur dans vos procédures sans avoir à saisir un code répétitif. Il permet d'insérer des modèles de balises d'erreur standardisées dans votre code ; il vous suffit de compléter les codes spécifiques aux procédures. Vous pouvez choisir d'ajouter des balises d'erreur à une procédure unique, à toutes les procédures d'un module ou à l'ensemble des procédures du projet en même temps.

Complément d'Importation/Exportation multicode VBA

Au cours du développement de votre application Office, vous pouvez être amené à créer des objets VBA utiles que d'autres développeurs pourraient utiliser.

Par ailleurs, vous pouvez avoir connaissance d'objets VBA créés par d'autres développeurs que vous souhaiteriez utiliser et modifier dans votre projet en cours. Le Complément d'Importation/Exportation multicode VBA permet d'importer et d'exporter ces objets facilement.

Assistant Empaquetage et déploiement Visual Basic pour Applications

Cet Assistant facilite la création et le déploiement de programmes d'installation pour vos solutions Office 2000 qui est expliqué tout au long de ce document.

Complément Contrôle de code source VBA

Ce nouveau complément, inclus avec Microsoft Office 2000 Developer, simplifie l'utilisation de la fonctionnalité Visual SourceSafe (VSS) dans l'environnement de développement Office.

C'est une base de données qui sert à stocker vos projets de développements professionnels pour gérer le code source dans un environnement de développement individuel ou en groupe.

Grâce à VSS, vous historisez les versions de vos applications et pouvez à tout moment remonter à une version antérieure, partager ou fusionner un module entre plusieurs applications. VSS propose des outils d'archivage et de recherche et permet de sécuriser vos développements. Les modifications apportées à vos fichiers sont enregistrées et vous pouvez rétablir une version précédente à tout moment. Les membres de votre groupe peuvent voir la dernière version de tous les fichiers, apporter des modifications et enregistrer une nouvelle version dans la base de données.

VSS vous aide à gérer vos projets, quel que soit le type des fichiers concernés (fichiers texte, graphiques, binaires, audio ou vidéo) en les enregistrant dans une base de données. Lorsque vous devez partager des fichiers entre deux projets ou plus, la procédure à suivre est rapide et efficace. Lorsque vous ajoutez un fichier dans le système VSS, le fichier est sauvegardé dans la base de données et mis à la disposition d'autres utilisateurs.
VSS facilite le partage et la protection des différentes versions des fichiers.

Visionneuse WinAPI

Les procédures externes les plus communément utilisées sont celles qui constituent Microsoft Windows lui-même. L'API Windows contient des milliers de fonctions, procédures, types et constantes que vous pouvez déclarer et utiliser dans vos projets. Toutefois, ces procédures sont écrites en C et vous devez donc les déclarer avant de pouvoir les utiliser avec VBA.
Les déclarations pour les procédures DLL peuvent devenir particulièrement complexes. Vous pouvez les traduire vous-même, mais le moyen le plus simple d'accéder à l'API Windows consiste à utiliser les déclarations prédéfinies incluses dans la visionneuse WinAPI de Office 2000 Developer.

III-B-1-d - Les outils complémentaires d'administrationde vos bases de données

Gestionnaire de réplicas Microsoft

Permet de visualiser et de gérer des bases de données Microsoft Jet répliquées via un réseau ou Internet.

Le Gestionnaire de réplicas fournit une interface visuelle pour la conversion des bases de données, la création de réplicas supplémentaires, la visualisation des relations entre les réplicas et la définition de propriétés pour les réplicas. De plus, le Gestionnaire de réplicas peut répliquer des données entre les bases Microsoft Access et les bases Microsoft SQL Server.

Cet outil n'étant pas nécessaire aux sujets traités ici, je vous conseille de lire le ReplMan40.hlp situé dans le dossier d'installation :

.\ODETools\V9\Replman

III-B-1-e - Les autres outils

Answer Wizard Builder

Outil qui permet de créer une interface de recherche en langage naturel pour consulter les rubriques d'aide affichées au format HTML. Cet outil permet de créer les fichiers d'index de l'Aide intuitive (*.AW) correspondant au contenu de l'aide personnalisée. L'ajout d'un fichier AW personnalisé à l'ensemble des fichiers AW déjà utilisés par l'aide d'Office 2000 permet aux entreprises d'inclure une aide étendue dans le système d'aide d'une application Office, offrant ainsi un accès direct à cette aide à partir du système d'aide Office.

Il est possible de générer un index AW pour un fichier d'aide HTML personnalisé ou pour un site Web. Office 2000 peut être configuré pour fournir un accès à ce fichier AW dans l'une ou l'ensemble des applications.

Les index de l'Aide intuitive conviennent davantage aux contenus qui ne changent pas souvent. Un fichier AW généré pour un site Web devra peut-être être mis à jour fréquemment au fur et à mesure des modifications apportées au site Web.

Le générateur de l'Aide intuitive doit être exécuté sur les ordinateurs déjà équipés d'Office 2000. Si Office n'est pas installé, cet outil ne fonctionnera pas.

Exchange Server Developer Edition

La version réservée aux développeurs Microsoft Exchange Server constitue la plate-forme idéale pour les systèmes de messagerie essentiels aux entreprises. Elle vous permet de développer et de tester votre solution de workflow avec Workflow Designer pour Exchange Server. La version réservée aux développeurs Microsoft Exchange Server qui est une plate-forme dédiée à la gestion des messages d'une entreprise, vous permet de développer et de tester votre solution Workflow Designer pour Exchange 2000 Server.

Agent SDK

Agent SDK est un éditeur de caractères destiné à être utilisé avec Microsoft Agent et les fichiers d'en-tête qui définissent les interfaces COM pour Agent Server. Microsoft® Agent est un ensemble de services logiciels qui prend en charge la présentation des agents logiciels en tant qu'éléments interactifs de l'interface Microsoft Windows®. L'approche de l'interface conversationnelle de Microsoft Agent est une évolution et une amélioration des modalités interactives existantes de l'interface Windows.

Pour installer cet outil, accédez au répertoire suivant du second CD-ROM :

.\ODETools\V9\MSAgent

et exécutez MSAGENT.EXE pour enfin suivre les instructions d'installation.

SQL Server 7.0 Developer Edition et compléments

La version 7.0 de Microsoft SQL Server est également fournie dans Microsoft Office Developer 2000. Sont disponibles également les outils complémentaires Workflow Designer pour Exchange Server avec qui vous pouvez créer des définitions de traitements de workflow pour les dossiers Microsoft® Exchange Server et Workflow Designer pour SQL Server qui permettent de créer des applications de suivi puissantes.

IV - Présentation de l'Assistant Empaquetage et Déploiement

L'Assistant Empaquetage et Déploiement est conçu pour vous aider à déployer des programmes d'installation de vos projets et applications Office par la génération de fichiers cab et d'un programme d'installation (nommé Setup.exe) en vue de les remettre aux utilisateurs finals. Cet assistant peut inclure le Runtime Microsoft Access si vous savez que les postes client ne disposent pas de la version complète de Microsoft Access.

L'assistant regroupe tous les composants dont votre application a besoin pour fonctionner et automatise la plupart des tâches de création et de déploiement des fichiers tout en vous laissant la possibilité d'apporter les modifications nécessaires aux machines des utilisateurs finals. En ce qui concerne le programme d'installation lui-même, les possibilités de mise en œuvre restent relativement pauvres, mais dans la plupart des cas, suffisantes pour créer un Setup convenable et quasi professionnel.

Il n'est toutefois pas obligatoire d'utiliser l'Assistant Empaquetage et Déploiement pour déployer vos applications. Par exemple, InstallShield, Wise et d'autres installateurs gratuits ou payants font cela très bien, voire mieux.

IV-A - Les options de l'Assistant Empaquetage et Déploiement

Pour lancer l'Assistant Empaquetage et Déploiement, cliquez sur le menu Compléments puis sélectionnez Assistant Empaquetage et Déploiement.

Elles sont au nombre de trois et sont représentées par les trois boutons de la fenêtre d'accueil de ce dernier.

L'option Empaquetage

Elle est conçue pour vous aider à créer un empaquetage regroupant les fichiers d'une application dans un ou plusieurs fichiers cab associés à un programme d'installation automatique. Il repère et regroupe les fichiers en vous assistant pour établir les choix voulus pour votre projet.

L'option Déploiement

Elle est conçue pour vous montrer comment distribuer des applications empaquetées vers les supports de distribution appropriés (disquettes, CD-ROM, partages de réseau ou sites Web).

L'option Gestion des scripts

Elle est conçue pour vous permettre d'afficher et gérer les scripts que vous avez enregistrés dans l'Assistant au cours des précédentes sessions d'empaquetage et de déploiement. En effet, pour chaque utilisation, vous pouvez enregistrer un script contenant les choix que vous avez retenus, ce qui fait que vous pouvez réutiliser ces scripts pour les sessions suivantes et appliquer des choix ou paramètres déjà employés.

IV-B - Empaquetage des applications

Cette opération consiste à créer un empaquetage permettant d'installer votre application sur l'ordinateur de l'utilisateur. Un empaquetage est un ensemble de fichiers cab contenant vos fichiers projet compressés, ainsi que les autres fichiers à installer (composants OCX, ActiveX® et DLL, images, etc.) pour que votre application fonctionne correctement.

Pour chacun des composants additionnels à votre projet, il est recommandé de consulter l'accord de licence de l'éditeur pour savoir si vous êtes autorisé à le faire.

IV-C - Processus d'empaquetage

IV-C-1 - Identification des fichiers à distribuer

Avant de créer un empaquetage, l'assistant identifie les fichiers de votre projet (notamment les fichiers nécessaires à l'application).

Cette opération étant automatisée, vous ne pouvez pas intervenir.

IV-C-2 - Identification des fichiers de dépendance pour les composants de votre application

Une analyse des fichiers de dépendance est effectuée par L'Assistant Empaquetage et Déploiement et si tout ou partie de ces derniers en sont dépourvus, il peut les créer. Cela vous permet de les inclure dans votre empaquetage et de pouvoir les réutiliser ultérieurement.

Un fichier de dépendance (.dep) contient des informations sur la configuration d'exécution requise d'une application ou d'un composant, sa version, son mode d'enregistrement et l'emplacement où il doit être installé sur la machine de l'utilisateur.

IV-C-3 - Choix de l'emplacement d'installation des fichiers sur la machine de l'utilisateur

Par défaut, les fichiers de l'application et d'installation sont installés dans un sous-répertoire du répertoire Program Files tandis que les fichiers système et les fichiers dépendants sont installés dans le répertoire où est installé le répertoire System ou System32 de Windows selon la version.
Par exemple :

\Windows\System ou \Winnt\System32

En cas d'installation individuelle ou multiple en entreprise où l'architecture des postes de travail est soumise à des droits spécifiques, vous devez en tenir compte. Il est évident que vous ne rencontrerez pas les mêmes problèmes d'installation sur un poste Windows NT que sur un poste équipé en Windows 2000 ou XP.

Vous devrez alors vous rapprocher des administrateurs réseau pour disposer d'un jeu de droits multiples en fonction des différents profils et différents droits répartis parmi les clients devant recevoir votre application. Vous pourrez alors simuler plusieurs installations successives pour vérifier que vous ne serez pas confrontés à tel ou tel problème en mode réel. Pour un plus grand confort à ce niveau-là, je vous préconise d'utiliser des logiciels de machine virtuelle par exemple VMWare®, qui vous autorise à créer plusieurs versions de Windows sur un même poste de travail et de procéder aux tests circonstanciels.

IV-C-4 - Génération de l'empaquetage

L'Assistant crée l'empaquetage et le programme d'installation (setup.exe) correspondant, en référençant tous les fichiers requis. À l'issue de cette étape, un ou plusieurs fichiers cab ont été créés (selon votre préférence) ainsi que les fichiers d'installation nécessaires.
Le déploiement d'une application consiste à transférer une application empaquetée vers le support de distribution choisi ou vers un site Web depuis lequel elle pourra être téléchargée. Pour déployer votre application, vous avez deux possibilités :

- déployer l'application sur des disquettes, un CD-ROM, un lecteur local ou réseau ou encore un site Web, en utilisant l'option de déploiement de l'Assistant Empaquetage et déploiement ;

- vous pouvez copier manuellement les fichiers sur des disquettes ou un CD-ROM ou partages réseau ou bien les publier manuellement sur l'emplacement Web approprié.

L'Assistant Empaquetage et déploiement propose des raccourcis et exécute automatiquement certaines des tâches qui vous incombent dans la procédure manuelle de déploiement.

IV-C-4-a - Déploiement sur disquettes, répertoires et CD-ROM

Vous pouvez procéder à un déploiement sur disquettes uniquement si vous avez créé l'empaquetage via l'option Plusieurs cabs. En effet, cette dernière fait en sorte que l'empaquetage soit composé de fichiers .cab d'une taille inférieure à la capacité d'une disquette.

Le système propose de formater chaque disquette avant d'y copier les fichiers cab.

Le formatage n'est pas impératif, mais fortement recommandé et qui plus est complet, car le formatage complet vérifie chaque secteur de la disquette. En effet, il n'est pas rare que l'installation plante parce qu'une des disquettes est défectueuse. Dans tous les cas, les disquettes utilisées pour cette opération doivent être vides, sinon, leur contenu sera effacé.

Si vous optez pour un déploiement dans un répertoire, le système vous demande de choisir un répertoire local ou réseau dans lequel copier les fichiers pour qu'ensuite les utilisateurs puissent accéder au programme d'installation.

IV-C-4-b - Déploiement sur le Web

Vous pouvez déployer n'importe quel empaquetage sur le Web via FTP.

Lorsque vous choisissez la méthode Publication Web, le système considère le dossier du projet comme le dossier de base local pour le déploiement. Ce dossier de base local détermine de quelle manière les fichiers et répertoires sont copiés sur le site Web choisi.

Les fichiers et répertoires situés dans le répertoire de base local sont déployés sur le serveur Web avec la même arborescence que ce répertoire de base (en respectant la casse des noms de fichier).

Lors de la création du package, plusieurs phénomènes vont être générés…

On considère par exemple que votre projet est situé ici :

C:\Mes Développements\Access\Mon Projet

La création du répertoire Package (nommé ainsi par défaut) lors du déroulement et situé (par défaut) à la racine de votre projet.

C:\Mes Développements\Access\Mon Projet\Package

La création du répertoire Support lors du déroulement et situé (par défaut) à la racine Package de votre projet qui contient tous les fichiers servant à régénérer les fichiers cab.

C:\Mes Développements\Access\Mon Projet\Package\Support

Seul le contenu du dossier \Package doit être publié et celui de \Package\Support doit rester sur votre poste de développeur seulement.

V - Préparation de l'empaquetage

V-A - Pour empaqueter votre application

Passez dans Visual Basic Editor (Alt+F11) depuis votre base de données Access ou tout autre produit de la suite Office dans lequel vous avez créé votre application. Avant d'empaqueter votre application, vous devez avoir compilé votre projet et l'avoir enregistré sans quoi un message vous en informera :

Lancez l'Assistant Empaquetage et déploiement depuis le menu Compléments.

Si toutefois il n'est pas disponible, il y a deux possibilités :

Soit vous ne l'avez pas installé

Pour installer L'Assistant Empaquetage et Déploiement, il vous faut vous munir de Microsoft Office Developer 1.5 ou ultérieur.
Reportez-vous alors à la section Installation de Microsoft Office Developer un peu plus haut dans ce document.

Soit vous l'utilisez pour la première fois

Il ne figure donc pas dans le menu Compléments et il vous faut alors lancer le Gestionnaire de compléments et sélectionner l'Assistant Empaquetage déploiement, puis sélectionnez l'option Chargé/Déchargé.

Bien que non recommandé, car cela consomme de la mémoire inutilement et que vous ne déployez pas tous les jours des applications, vous pouvez faire en sorte qu'il soit chargé de façon permanente en cochant la case Charger au démarrage au bas de la fenêtre.

V-A-1 - Définition des options complémentaires du Gestionnaire

Sélectionnez le complément dans la liste puis cochez la ou les cases appropriées ou bien effectuez un double-clic sur l'élément de la liste Assistant Empaquetage et Déploiement.

V-B - Démarrage de l'empaquetage

Il vous propose le chemin spécifié du projet actif (*.mdb ou *.mde selon le cas) situé au-dessus des boutons. Le chemin spécifié est toujours celui du projet en cours.
Dans l'écran principal de l'Assistant, cliquez sur Empaquetage.

Lorsque vous cliquez sur le bouton Empaquetage, l'Assistant Empaquetage et Déploiement recherche les fichiers de dépendance attachés à votre projet.

V-C - Recherche des dépendances

Les fichiers de dépendance sont les fichiers inclus dans l'application proprement dite par le développeur.

Par exemple, les composants d'exécution (ActiveX®), les Bibliothèques de Liaisons Dynamiques (DLL), etc., nécessaires au fonctionnement de l'application sont inclus par référencement et possèdent parfois des fichiers de dépendance.

Ces informations relatives aux dépendances sont stockées dans des fichiers de type *.dep.

À l'étape suivante, L'Assistant Empaquetage et Déploiement vous propose deux choix d'empaquetage :

1. Soit la génération d'un Setup.exe de votre application par la création d'un package d'installation ;

2. Soit la génération d'un jeu d'informations de la liste des fichiers sur les composants d'exécution requis par votre application.

Laissez la sélection sur Logiciel d'installation standard puis cliquez le bouton Suivant.

L'Assistant Empaquetage et Déploiement vous propose ensuite de confirmer le répertoire de destination pour la génération du package d'installation.

Par défaut le répertoire nommé Package se loge comme sous-répertoire de votre application.

Il s'incrémente de 1 pour chaque package généré.

Vous pouvez conserver le dossier tel qu'il vous est proposé. Cependant, si vous le voulez, vous pouvez changer d'unité disque ou réseau, et même créer un nouveau dossier, etc.

Sélectionnez alors le bouton Suivant.

Un message peut apparaître selon le cas…

Si le dossier n'existe pas, ce qui est généralement le cas, il vous propose de le créer.

V-C-1 - Information sur les dépendances manquantes

Il n'est pas rare que les informations de dépendance des composants que vous auriez intégrés à votre projet soient introuvables. Cela n'a pas d'incidence directe sur le bon déroulement de la génération de votre package, mais il est tout de même recommandé de créer les dépendances lorsque celles-ci manquent.

Vous pouvez facilement créer des fichiers .dep pour votre projet. Souvent, les dépendances requises par l'Assistant Empaquetage et Déploiement sont issues des bibliothèques DLL ou de composants OCX.

Par exemple, il se peut que votre application exploite la désactivation de la molette de la souris lors de la consultation des données dans un formulaire. En effet, lorsque vous êtes dans un formulaire en mode « Entrée de données » où l'Ajout est autorisé, la manipulation de la molette entraîne la sauvegarde de l'enregistrement en cours ce qui peut être un inconvénient majeur. Pour pallier cette avarie, il a été mis à disposition gratuitement une DLL nommée MouseWheel.dll et qui permet de désactiver l'effet de la molette dans les formulaires. (À ce propos, vous trouverez des informations la concernant sur le forum ou sur le site de Microsoft.)

Bien que tout à fait opérationnelle, cette DLL est livrée sans fichier de dépendance et l'Assistant Empaquetage et Déploiement vous le précise expressément.

Pour tous les fichiers qui en sont dépourvus et dont vous êtes susceptible de connaître les dépendances, vous pouvez lancer une Analyse…

Figure 1

Figure 2

Seuls les fichiers mentionnés en gras peuvent être analysés afin de leur affecter un fichier de dépendance.

Tous les fichiers n'ont pas nécessairement besoin de dépendances.

Dans la liste de l'image ci-avant, vous pouvez remarquer que seul le fichier ChessCircleData.mdb est en gras. L'autre ne l'est pas et ne peut pas être analysé afin que l'Assistant Empaquetage et Déploiement cherche ses dépendances.

Cette liste confirme que le projet utilise un fichier de base de données et la DLL MouseWheel.dll expliquée ci-avant, mais que ces derniers sont dépourvus de dépendances.

Pour ce qui concerne le fichier de données ChessCircleData.mdb, il n'est pas nécessaire de lui attribuer de dépendance puisqu'il s'agit d'un fichier Microsoft Access. D'ailleurs, si vous cliquez sur Analyser, vous le verrez disparaître de la liste quelque seconde après (Figure 2).

Je précise ici qu'il s'agit ici d'une base de données contenant uniquement des tables et des requêtes, mais aucun code VBA et donc, pas de références externes… Dans le cas où cette base serait un « fichier Microsoft Access » contenant la partie applicative indépendante sous-entend qu'elle possède peut-être, des références à des OCX, DLL…

En finalité, le but est de vérifier que vous redistribuez bien la même version que celle utilisée par le projet.

C'est pour cela que les composants ActiveX® en sont pourvus. Ils devraient en pratique l'être, mais, hélas, seuls quelques-uns sortent du rang et en possèdent. Pour les autres, soit ils n'en ont pas besoin, soit ils en auraient besoin, mais n'en ont pas…

Dans cette liste de fichiers, si vous n'êtes pas en mesure de fournir les dépendances de vos fichiers et que vous ne serez jamais en mesure de le faire, alors, cochez la case pour les marquer définitivement comme tels.

De toute façon, vous pouvez ignorer cette étape en cliquant directement sur OK. Auquel cas, la question vous sera reposée lors d'un prochain empaquetage, car, s'il n'y a pas de dépendance, c'est parce qu'il n'y en a aucune ou qu'il n'y en a jamais eu…

V-C-2 - Recherche manuelle des informations de dépendance

Pour rechercher manuellement des informations de dépendance, sélectionnez le ou les fichiers en gras puis cliquez sur Analyser et suivez les instructions. Si l'Assistant les détecte, il supprimera tout bonnement le fichier de la liste (Figure 2). Sinon, il vous avertira qu'il n'y a pas d'informations de dépendance pour ce type de fichier auquel cas vous pouvez cocher la case pour le marquer définitivement comme tel.

Tout composant ActiveX® redistribuable devrait fournir un fichier de dépendance (.dep) qui est en général situé dans le même répertoire que l'ActiveX® lui-même.

Pour tout fichier concerné, tel que mabibliotheque.dll, le fichier de dépendance se nommera mabibliotheque.dep.

S'il s'agit d'un composant tiers, vous pouvez sans doute vous procurer le nouveau fichier de dépendance auprès de son éditeur ou sur un site Web approprié. Quand vous générez un fichier .dep pour les composants, ses informations de dépendances sont combinées et se répercutent en conséquence pour un usage ultérieur dans un autre projet.

V-C-3 - Mise à niveau d'un fichier de dépendance

V-C-3-a - Supprimer l'alerte du manque d'information relatif aux dépendances périmées

De façon identique aux dépendances manquantes, vous pouvez être confronté à la question des dépendances périmées. Cela revient à peu près au même sauf qu'ici, l'Assistant Empaquetage et Déploiement vous spécifie que ces dernières ne sont plus valides.

Ce qui provoque ce phénomène vient souvent d'une mise à jour tierce d'un composant donné à la suite d'une installation logicielle faite par vous-même ou par un processus quelconque d'installation et où ledit composant a été remplacé par une version plus récente sans que son fichier de dépendance ne soit mis à jour.

V-C-3-b - Mise à niveau d'un fichier.dep

Vous pouvez modifier un fichier .dep dans le but de faire coordonner ses informations de dépendance avec la réalité relative à sa version (comme stipulé ci-après).

Pour modifier un fichier de dépendance, ouvrez le fichier .dep à partir de Notepad et modifiez les informations en conséquence de la version du fichier.

C:\Program Files\Microsoft Office\ART\Office

; Dependency file for setup wizards.
; Dependencies for MsCal.OCX
; Default Dependencies
------------------------------------------------------
[MSCAL.OCX]
Dest=$(WinSysPath)
Register=$(DLLSelfRegister)
Version=9.0.0.3620
Uses1=
; Localized Dependencies
----------------------------------------------------

C:\Program Files\Microsoft Office\Office

; Dependency file for setup wizards.
; Dependencies for MsCal.OCX
; Default Dependencies
------------------------------------------------------
[MSCAL.OCX]
Dest=$(WinSysPath)
Register=$(DLLSelfRegister)
Version=9.0.0.2403
Uses1=
; Localized Dependencies
----------------------------------------------------

Vous devez alors effectuer la mise à niveau du fichier de dépendance à partir de Notepad et modifiez les informations conséquentes à la version du fichier.

Dans notre projet ChessCircle, c'est le composant mscomctl.ocx qui est concerné…

Sélectionnez alors le bouton OK.

À ce stade, l'étape suivante va consister à ajouter d'autres fichiers que l'Assistant Empaquetage et Déploiement ne peut pas référencer de lui-même et en l'occurrence, les images, les fichiers d'aide […] et tout autre fichier complémentaire de votre projet.

V-D - Ajout de fichiers complémentaires

L'Assistant Empaquetage et Déploiement insère dans l'empaquetage tous les fichiers et composants nécessaires au bon fonctionnement de votre application. Il est donc tout à fait probable que vous ayez à inclure d'autres fichiers comme un guide d'utilisateur, des icônes, des images…

V-D-1 - Ajout de fichiers externes

Cliquez sur le bouton Ajouter pour ajouter manuellement des fichiers.

Sélectionnez les fichiers concernés manuellement depuis la boîte de dialogue et maintenez la touche Ctrl appuyée pour en sélectionner plusieurs à la fois…

V-D-2 - Petite interruption due aux dépendances

Comme nous l'avons vu plus haut, les dépendances sont nécessaires à certains fichiers. Au moment de l'ajout de ces fichiers, vous pouvez être à nouveau sollicité par l'Assistant Empaquetage et Déploiement à ce sujet.

Ici, l'alerte concerne un des documents Word que j'ai ajoutés au projet. Il m'a alors suffi de l'analyser pour que ses dépendances soient identifiées comme quoi ils dépendent de Microsoft Word.

L'Assistant Empaquetage et Déploiement crée alors les fichiers de dépendance pour les deux fichiers Word que j'ai ajoutés au projet.

Dont le contenu est, somme toute, assez insignifiant si ce n'est la date de création du document.

[Version]
Version=0.0.0.0
[Attestation d'inscription club.doc <000C>]
Dest=$(AppPath)
Date=15/10/2004
Time=16:15
Version=0.0.0.0
CABFileName=
CABDefaultURL=
CABINFFile=

Une fois l'ajout terminé, la liste des fichiers ajoutés est complétée.

Vous pouvez décocher un fichier si vous vous apercevez qu'il ne fallait pas l'inclure au projet. Ici, j'ai décoché ChessCircle.mdb, ce dernier étant le projet lui-même, puisque j'y ai inclus le MDE.

Si vous lancez l'empaquetage depuis le fichier MDE, vous n'avez pas à décocher le projet MDB comme ci-avant. J'ai opéré de la sorte exprès pour considérer un cas de figure auquel vous auriez vous-même pu être confronté.

V-D-3 - Suppression d'un élément inséré par erreur

Lorsque vous décochez un fichier pour ne finalement pas l'inclure, il ne disparaît pas de la liste.

En revanche, si vous régénérez un nouveau package à partir du même Script d'empaquetage que celui en cours de génération, les fichiers décochés n'y seront plus. J'aborderai un peu plus loin les Scripts d'empaquetage.

V-E - Inclusion du Runtime dans le package

Vous pouvez inclure le Runtime de Microsoft Access dans votre application à l'aide de l'Assistant Empaquetage et déploiement. Cela permet de procéder à une installation complète de votre application, pour les utilisateurs qui n'ont pas Access (version complète) installé sur leur poste.

Si vous souhaitez l'inclure, n'oubliez pas de cocher Insérez Access Runtime avant de cliquer sur le bouton Suivant.

Nous verrons comment installer le Runtine manuellement, ce processus, lui, l'installe automatiquement.

Vous verrez un peu plus bas une simulation d'installation d'une application pour rendre compte des aléas qui sont provoqués lors d'une installation avec le Runtime Access.

Si un message d'erreur indiquant que le Runtime est introuvable au moment où vous cochez la case, c'est que vous ne l'avez pas installé, voire mal installé.

Reportez-vous alors à la rubrique Installation du Runtime Access.

À ce stade, vous pouvez aller le chercher sur le CD-ROM ou localement sur votre disque dur si vous ne l'avez pas placé dans le répertoire recommandé par défaut. Il vous faut alors pointer le fichier Data1.msi dans le dossier du CD-ROM depuis le CD N° 2 de Microsoft Office Developer.

En cliquant sur OK, la boîte de dialogue pour le localiser apparaît…

Insérer le CD-ROM ou copiez le contenu du Runtime sur votre disque puis pointez la cible, enfin, validez par Ouvrir puis sélectionnez alors le bouton Suivant pour arriver à l'étape du titre de l'installation.

V-E-1 - Modification du Titre de la fenêtre d'installation

Vous pouvez donner un titre à votre Setup.

Dans le processus de l'installation sur le poste client, le titre sera précédé de Installation de et suivi par défaut du nom de l'application, par exemple pour CE CAS :

Vous pouvez également ordonner au Setup d'exécuter une commande une fois que l'installation est terminée.

Par exemple, lancer un exécutable qui ouvre l'application justement installée.

Sélectionnez alors le bouton Suivant.

V-F - Définition du groupe du menu Démarrer/Programmes

À l'étape suivante, il vous sera demandé de confirmer le groupe du Menu Démarrer - Programmes de votre application…

Si votre projet est constitué d'un fichier MDE et que vous avez généré votre package à partir du fichier MDB, cela n'est pas pris en compte par l'Assistant Empaquetage et Déploiement. Ce dernier prend pour fichier de démarrage le nom du projet actif initial. Dans notre cas, je suis parti du fichier ChessCircle.mdb pour générer mon package et j'ai inclus par la suite ChessCircle.mde dans la liste des fichiers à ajouter. Cela n'aurait pas été nécessaire si j'avais empaqueté directement depuis le MDE.

De ce fait, vous devez le spécifier à la main.

Vous pouvez également remarquer que le répertoire spécifié Démarrer dans indique par défaut que l'application doit démarrer dans le répertoire d'installation sous forme d'alias $AppPath.

V-G - Définition manuelle des dossiers de destination

Il peut s'avérer utile de définir manuellement les dossiers respectifs d'installation des fichiers de l'application.

C'est un cas exceptionnel, car de manière générale, il n'est pas recommandé de les modifier.
Le cas typique serait par exemple de regrouper un jeu de polices TrueType dans le dossier Fonts de Windows afin de les partager avec les autres applications, si toutefois votre application utilise des polices particulières de façon exclusive.

Pour cette catégorie de fichiers spécifiques (Composants OCX, DLL…), vous devez être à même de considérer le déploiement sur le poste client en tant qu'administrateur de votre projet.
Cela implique que vous êtes tenu de connaître la structure de votre entreprise ou de l'entreprise devant recevoir le package à installer.

En effet, selon la version de Windows sur laquelle sera déployée votre application, vous serez peut-être confronté à des droits spécifiques, et notamment être administrateur des machines ciblées.

Dans le cas où vous ne seriez pas en mesure de le déterminer, je vous conseille de laisser les options telles que définies par l'Assistant Empaquetage et Déploiement.

Si dès lors l'installation devait échouer sur un poste cible à cause des droits d'administration, il vous faudra faire en sorte de vous rapprocher des administrateurs de l'entreprise.
Sélectionnez ensuite le bouton Suivant.

V-G-1 - Partage des fichiers de l'application

Certains de vos fichiers peuvent être installés en tant que fichiers partagés. L'avantage est qu'ils bénéficient alors d'une sécurité lors de la désinstallation d'une application autre que celle-ci qui utilise les mêmes composants.

Cela peut s'avérer utile si vous avez plusieurs projets sur la même machine qui partagent une même Bibliothèque de Liaison Dynamique (DLL) par exemple ou une bibliothèque de code VBA.

Dans notre cas, j'aurais pu cocher la case pour la DLL MouseWheel.dll considérant que celle-ci pourrait être exploitée par une autre application Microsoft Access.

Sélectionnez ensuite le bouton Suivant.

V-G-2 - Enregistrement du Script d'empaquetage

La dernière étape consiste à enregistrer le Script d'installation pour un usage ultérieur tel que je l'ai défini ci-avant dans ce document. Il servira à régénérer votre package sans que vous ayez à définir des options manuellement.

Vous donnez alors un nom EXPLICITE à votre script de manière à pouvoir le cibler rapidement dans la liste des scripts. En règle générale, vous nommez vos scripts par le nom de l'application elle-même (ici Installation de ChessCircle), car par défaut, il est mentionné Logiciel d'installation standard suivi d'un numéro incrémenté, (ici Logiciel d'installation standard 1) ce qui n'est pas du tout parlant.

Sélectionnez alors le bouton Terminer et la mise en œuvre démarre…

V-G-3 - Mise en œuvre du package

L'Assistant Empaquetage et Déploiement commence alors l'empaquetage…

Il insère le Runtime Microsoft Access…

Puis construit le fichier .cab

V-G-4 - Fin de génération du package

Puis, pour terminer, l'Assistant Empaquetage et Déploiement vous propose d'enregistrer le descriptif de la mise à niveau de votre package.

En cas de modification de votre MDE, il est intéressant de considérer que vous pouvez régénérer le fichier .cab en utilisant un fichier batch. Pour des informations complémentaires à ce sujet, reportez-vous à la section Évolution de votre package ci-après.

Enregistrer l'état vous permet de reporter le contenu du descriptif non exhaustif du package. Il porte le nom du Titre de l'application suivi de l'extension TXT, mais vous pouvez ignorer et fermer cette fenêtre (après l'avoir lue).

Les informations qui y figurent sont celles qui seront enregistrées dans l'état.

VI - Évolution de votre package

VI-A - Gestion des scripts de l'Assistant

Lorsque vous travaillez dans l'Assistant Empaquetage et déploiement, vous pouvez créer et stocker des Scripts. Un script est un enregistrement contenant les sélections que vous avez effectuées au cours d'une session d'empaquetage ou de déploiement (ce que l'on a vu juste avant).

En créant un script, vous conservez ces sélections et vous pouvez les réutiliser lors de sessions ultérieures de l'Assistant pour le même projet.

L'utilisation de scripts assure des gains de temps considérables.

Chaque fois que vous créez un empaquetage ou que vous déployez un projet, l'Assistant conserve les informations relatives à cette session sous forme de Script. À l'aide de l'option Gestion des scripts de l'assistant Empaquetage et déploiement, vous pouvez afficher la liste complète des scripts du projet en cours.

VI-A-1 - Avec cette option, vous pouvez effectuer diverses opérations

- Visualiser la liste de tous les scripts d'empaquetage et de déploiement.
- Renommer un script.
- Créer une copie d'un script sous un nouveau nom.
- Supprimer un script dont vous n'avez plus besoin.

Lorsque vous supprimez un script d'empaquetage, l'option de déploiement de l'Assistant Empaquetage et déploiement ne reconnaît plus l'empaquetage créé à partir de ce script.

Pour pouvoir le déployer, vous devez empaqueter de nouveau ce fichier. Veillez donc à ne supprimer que les scripts dont vous êtes sûr de ne plus avoir besoin.

VI-B - Modification ou évolution de votre projet

Il est très probable que vous ayez à faire évoluer certaines fonctionnalités de votre projet. Auquel cas il faudra le redéployer sur le poste client si vous avez ajouté un composant ou référencé une DLL qui n'y figurait pas dans la version initiale. Ceci peut être un inconvénient, car il sera alors nécessaire de désinstaller l'application initiale sur ledit poste.

En effet, si on travaille « proprement », on ne réinstalle jamais une application sans l'avoir entièrement désinstallée d'abord, car on ne peut généralement plus désinstaller (proprement) une application si plusieurs installations hétérogènes se sont succédé sans qu'elles aient été désinstallées d'abord.

Il est à noter alors que si votre client ou les postes concernés fonctionnaient avec le Runtime Microsoft Access, la désinstallation de l'application ne supprime pas le Runtime.

Sinon, il est vrai que dans 90š% des cas, la simple fourniture du fichier MDE (ou MDB si vous n'avez pas créé de MDE, ce qui n'est pas forcément conseillé) à copier dans le répertoire de destination est suffisante. Là, vous pouvez donc procéder à la mise à niveau de votre application sur le poste client par la distribution à travers un petit VBScript ou un simple fichier .bat que vous rédigerez et testerez auparavant.
Cela reste la méthode de loin la plus rapide, surtout en réseau sur de nombreux postes tous identiques.

VI-B-1 - Modification de votre projet

Si vous êtes amené à modifier votre programme MDE, il vous faut d'abord modifier le programme MDB qui en est le générateur.

Vous ouvrez donc votre base MDB, apportez les corrections ou suppléments nécessaires, protégez ensuite votre projet au niveau du code VBA même si le projet doit être compilé dans un MDE et qu'il n'y a aucun accès au code VBA.

De là, vous enregistrez le tout pour enfin générer un nouveau fichier MDE.
Le nouveau fichier MDE que vous venez de générer, ainsi que tous les fichiers que vous avez modifiés (fichiers d'aide, images…), seront alors à glisser dans le répertoire Support en lieu et place des existants.

Tous les fichiers que vous glissez dans ce répertoire doivent porter le même nom que les fichiers existants.
En aucun cas, vous ne devez glisser des fichiers qui n'étaient à l'origine pas prévus dans le package. De toute façon, ils ne seraient pas pris en compte lors de la génération du package.

VI-B-2 - Réempaquetage de votre projet modifié

L'Assistant Empaquetage et Déploiement permet de régénérer rapidement votre jeu de fichiers CAB à partir d'un simple fichier Batch situé dans le répertoire Support (sous-répertoire du répertoire Package ou du répertoire dans lequel vous avez déployé l'empaquetage).

Si vous avez modifié votre MDE et que vous pensez qu'il est préférable de fournir un SETUP.EXE plutôt que de fournir seulement la copie du MDE mis à jour, ce paragraphe vous concerne.

En effet, cela fait plus professionnel de fournir un Setup, mais si vos clients ou vos utilisateurs possèdent déjà une version 1 de votre projet et que vous n'avez pas ajouté d'autres composants ou d'autres DLL c'est inutile comme je viens de vous le préciser.

VI-B-2-a - Pour régénérer votre jeu de fichiers CAB accompagné du setup.exe correspondant

- Compilez votre projet puis générer un nouveau MDE.
- Copiez ce MDE dans le dossier Support (sous-répertoire du répertoire Package ou du répertoire dans lequel vous avez déployé l'empaquetage).
- Puis, depuis l'Explorateur, pointez le fichier qui porte le nom de votre application suivi d'une extension bat. Pour l'exemple de ce document, il s'agit de ChessCircle.bat.

Ce fichier batch porte le nom de votre projet ou plutôt celui que vous avez stipulé en tant que Titre durant les étapes de génération de votre empaquetage.

VI-B-3 - Régénération du package à l'aide d'un fichier Batch

Sélectionnez alors ce fichier puis appuyez sur la touche Entrée ou bien effectuez un double-clic dessus.

Vous lancerez alors le batch…

L'information du traitement est écrite en toutes lettres dans la fenêtre de commande DOS ouverte.

Le processus reconstruit le fichier cab et se ferme aussitôt après.

Vous disposez alors d'un nouveau fichier cab prêt à être distribué avec votre package.

VI-C - Stockage de votre package sur une source d'installation

Lorsque votre package est prêt, vous devez le stocker sur une source réseau, un CD-ROM ou un jeu de disquettes afin de faire en sorte qu'il puisse être installé sur un poste client. Vous pourrez également inclure d'autres applications par exemple Acrobat Reader au cas où vous fourniriez un guide d'utilisation au format PDF.

En tout état de cause, votre package doit contenir au minimum, les éléments suivants : (Exemple avec un seul fichier .cab) :
- SETUP.LST
- Setup.exe
- VotreApplication.cab
Et si vous avez prévu de proposer l'installation du Runtime, le dossier complet :
- \Runtime
doit y être également.

VI-C-1 - Création d'un fichier AutoRun pour votre CD- ROM

Vous pouvez générer un fichier AutoRun pour votre package si toutefois vous proposez un CD-ROM d'installation.

Le fichier AutoRun.inf permet au programme d'installation d'être lancé automatiquement à condition que le Service de Notification d'Insertion de CD sur le poste client soit activé.

Ce fichier est à poser sur la racine du CD-ROM gravé avec votre projet.

VI-C-1-a - Pour concevoir un fichier Autorun

Prenez un éditeur de texte comme Notepad ou autre et inscrivez les lignes de code correspondant à vos paramètres comme dans l'exemple suivant :

[autorun]
open = setup.exe
icon = ChessCircle.ico

Il est bien entendu que le programme setup.exe tout comme l'icône ChessCircle.ico se situent eux aussi sur la racine du CD-ROM si vous stipulez le contenu comme ci-dessus.

Vous enregistrez ensuite ce fichier sous le nom Autorun.inf et l'incorporez dans la liste des fichiers de votre programme de gravure de CD-ROM.

VII - Tester son programme d'installation

Une fois que vous avez terminé le processus d'empaquetage et produit des supports de distribution pour votre application, vous devez tester votre programme d'installation.

Pour ce test, choisissez une machine qui ne dispose pas déjà des fichiers de votre application ni des contrôles ActiveX requis par celle-ci. De plus, il est conseillé de tester l'installation sur tous les systèmes d'exploitation concernés.

Vous pouvez pour ce genre d'opérations envisager d'utiliser des logiciels de Machines Virtuelles comme VMWare® qui s'avèrent être d'un grand secours pour des simulations multiples et ce, sur plusieurs systèmes d'exploitation.

VII-A - Pour tester votre programme d'installation sur disquettes ou CD-ROM

Insérez la première disquette ou le CD-ROM dans le lecteur approprié.

Dans Windows 9x et Windows NT version 4.0 ou ultérieure, sélectionnez le menu Démarrer, choisissez Exécuter, puis tapez
D:\setup.exe où D:\ est le lecteur source…

ou

cliquez deux fois sur Setup.exe depuis l'Explorateur de fichier.

VIII - Exemple d'installation sur un poste client

Si vous installez depuis un CD-ROM et que la notification d'insertion automatique est activée, la procédure d'installation automatique est lancée.

Sinon, vous devrez accéder manuellement et à partir de l'Explorateur de fichiers sur le CD-ROM ou la source d'installation du disque dur ou du réseau et localiser le fichier setup.exe.

N.B. L'exemple que vous allez lire ici est le reflet de l'installation d'un projet tel que vous le subirez lors de vos tests.

VIII-A - Cas de figure où l'on souhaite installer le Runtime sur le poste

Pour le cas de figure qui suit, je suppose bien évidemment que vous avez embarqué le Runtime dans le package d'installation. L'objectif étant de considérer que le client ne possède pas de licence Microsoft Access.

Vous double-cliquerez alors sur le fichier Setup.exe et la procédure se lance aussitôt.

VIII-A-1 - Étape 1 : Exécution du Setup

L'installer va donc installer le Runtime, mais cette procédure nécessite très fréquemment un redémarrage à cause de la version des composants qui peut être périmée. De ce fait un message vous en informe…

VIII-A-2 - Étape 2 : Premier redémarrage (Composants périmés)

Du fait que l'ordinateur cible ne possède pas les fichiers système à jour, l'installation doit redémarrer son système pour y parer. Cette opération est sans effet pour l'ordinateur, mais reste indispensable pour le fonctionnement des projets nécessitant l'installation du Runtime Microsoft Access pour la première fois.

Une fois votre ordinateur relancé, revenir à l'étape 1 ci-dessus pour arriver à l'étape 5 décrite ci-après.

Ce message n'apparaît qu'une seule fois si le poste client ne subit pas de réinstallation de son système.

Pour les fois suivantes, le lancement du Setup.exe détecte la présence du Runtime et installe directement les fichiers mis à jour comme dans l'étape 3.

Je rappelle encore une fois ici que vous n'êtes pas tenu de proposer un setup pour chaque mise à jour de votre application. En effet, si vous modifiez une partie du code de votre base et que vous voulez fournir la version MDE de celle-ci à vos clients, la seule copie du fichier MDE dans le répertoire d'installation cible suffit…

Le fait de proposer un setup fait plus professionnel si je puis dire et permet par exemple en cas de réemploi d'un nouveau contrôle ActiveX® dans votre projet qui n'y était pas auparavant, de l'enregistrer correctement sur le poste Client, mais comme nous l'avons vu auparavant, cela nécessite une désinstallation préalable.

Mais il faut noter qu'il est généralement beaucoup plus simple et efficace d'utiliser un fichier .bat avec l'écriture d'une commande exploitant regsvr32.exe pour enregistrer les composants que n'importe quel Setup… À vous d'envisager la solution la mieux appropriée.

Ce dernier point est très important. Vous ne devez en aucun cas ajouter une référence ou un composant à votre projet si vous ne fournissez pas un nouveau package avec les fichiers correspondants au sein du fichier .cab ou si vous n'êtes pas en mesure d'automatiser leur inscription respective dans le registre Windows du poste cible. Sinon, votre projet ne pourrait tourner et serait assujetti à des erreurs de type 429.

VIII-A-3 - Étape 3 : Installation de l'application

Après avoir redémarré, vous êtes tenu de relancer le setup. Malheureusement, c'est un pas obligé auquel vous ne pouvez pas échapper et il représente à mon sens un inconvénient mineur, mais peu convivial.
Le début de l'installation se présente de façon classique où vous suivrez au pas à pas et cliquez sur les messages de dialogues affichés…

C'est cet écran qui apparaîtra directement si le Runtime ou bien la version complète de Microsoft Access de version identique à la vôtre sont déjà installés sur le poste.

VIII-A-4 - Étape 4 : Progression de l'installation

Vous visualisez les fichiers en cours d'installation

VIII-A-5 - Étape 5 : Fin de l'installation

Le message de fin d'installation apparaît :

Une fois l'installation terminée, vous pourrez lancer votre projet depuis le menu Démarrer de Windows…

VIII-A-6 - Étape 5 : Attribution d'une icône au raccourci

Vous pourrez ultérieurement même, créer un raccourci sur le bureau avec l'icône de l'application s'il est présent dans le dossier de l'application qui est par défaut :

C:\Program Files\Nom de l'application\icône.ico

VIII-B - Cas de figure où le Runtime ou Microsoft Access sont déjà présents sur le poste

Pour ce cas de figure, je suppose que le Runtime ou bien une version complète de Microsoft Access sont déjà installés sur le poste client. Il sera alors inutile d'inclure le Runtime dans votre package d'installation généré par l'Assistant Empaquetage et Déploiement. Bien entendu, vous devrez vous assurer que la version de Microsoft Access ou celle du Runtime correspondent bien à la vôtre. Si vous l'ignorez, alors vous pouvez cocher la case en question, l'Assistant Empaquetage et Déploiement se chargera de déterminer s'il faut ou non installer le Runtime.
La procédure d'installation sera alors plus rapide et démarrera directement ici.

VIII-C - Modification du Setup.exe

Le setup d'installation est un programme écrit en Visual Basic 6.0. Lorsque vous disposez du Kit Microsoft Office Developer, il vous est fourni l'ensemble du code du SETUP. Celui-ci est situé dans le répertoire :

\Program Files\Microsoft Office\ODETools\V9\Samples\Unsupported

Comme son nom l'indique, vous ne trouverez aucune documentation sur celui-ci et aucun support auprès de Microsoft. Pour les adeptes que ça intéresse, cela permet de modifier le code de manière à forcer certaines options comme le répertoire par défaut d'installation, voire le masquage de certaines fenêtres.

Vous devrez alors régénérer un setup1.exe et faire en sorte que votre nouveau setup remplace le précédent.

Faites une copie préalable de Unsupported avant de le modifier. Je n'aborderai pas le sujet en détail ici.

C'est une information que je souligne pour que tous ceux qui, comme moi, sont amenés à personnaliser les installations soient au courant que cette possibilité existe.

________________________________________________________________________________________________
Regsvr32.exe
Le processus REGSVR32.EXE est utilisé pour enregistrer une bibliothèque dynamique (DLL) ou un composant ActiveX dans la base de registre.
Ce processus est nécessaire au bon fonctionnement de votre système.

IX - Les tests à effectuer sur un poste de test

Une fois l'installation terminée, exécutez le programme installé pour vous assurer de son bon fonctionnement.

En général, vous n'êtes pas à l'abri de surprises inattendues et c'est le meilleur moyen de s'en rendre compte avant de délivrer le package à votre client ou à l'équipe d'utilisateurs de votre entreprise.

Veuillez alors revenir à la section 2 relatant des tests préalables.

IX-A - Test de l'application installée sur un poste…

Le jeu de tests consiste à exécuter votre application depuis le poste sur lequel vous l'avez installée…

IX-A-1 - …doté de Microsoft Access

Il ne devrait pas y avoir de grande différence avec le poste de développement depuis lequel vous avez créé l'application.

Le jeu de tests consistera alors à naviguer entre les différents formulaires, l'impression des états (attention notamment à l'orientation des états et aussi à la notion d'imprimante par défaut), à l'exécution de l'ensemble des tâches proposées par votre application.

Je précise que votre application doit comporter un formulaire de démarrage qui donne accès à l'ensemble des objets que vous voulez rendre disponibles dans l'application (formulaire de menu général par exemple).

IX-A-2 - …doté du Runtime Access seul sans aucune version de Microsoft Access

Si le poste client ne dispose pas d'une version complète de Microsoft Access, il semble évident que vous avez embarqué le Runtime dans le package d'installation SETUP.EXE. Le Runtime est alors résidant sur le poste client et se comporte comme si une version d'Access était installée sauf que celle-ci est dépourvue des fonctionnalités de conception.

Dans ce cas, il n'y a pas plus de procédures de test à effectuer que celles qui sont stipulées en section 9.1.1 ci-avant.

IX-A-3 - …doté du Runtime Access conjointement avec une version différente de Microsoft Access

Ici, je considère que le poste client dispose d'une version de Microsoft Access antérieure à celle du Runtime qui, lui, correspond à la version de votre application.

Dans ce cas, vous devez mettre en place une syntaxe particulière, car l'Assistant Empaquetage et Déploiement 2000 ne génère pas de raccourci approprié pour ce cas de figure.

Pour ce faire, soit vous le créez manuellement, soit vous vous faites aider par l'Assistant Installation de Microsoft Office Developer qui génèrera les options de ligne de commande nécessaires pour démarrer Microsoft Access en mode Runtime avec la possibilité d'exploiter un fichier de groupe de travail ou un profil spécifique, le cas échéant.

Cas particulier pour un environnement réseau

Je vous déconseille en cas d'utilisation en réseau de mettre votre application frontale sur un serveur.

Outre le fait que dans ce cas, plusieurs personnes peuvent partager les mêmes formulaires et autres objets, les temps de chargement et d'exécution seraient horrifiques !

Vous devrez alors déplacer la base de données ne contenant que les tables sur le serveur dédié, car le setup ne saura pas le faire nativement… L'application frontale qui est liée à cette base sur chaque poste utilisateur sera installée dans le dossier Program Files.

Au début du document, je vous ai recommandé de travailler dans le contexte réel lors du développement de votre application, à savoir développer votre projet sur votre poste tout en ayant déposé la base de données décentralisée dans un dossier dédié sur le serveur s'il s'agit d'une application multiutilisateur ou dans le dossier Program Files\Nom de l'Appli s'il s'agit d'une appli monoutilisateur…

Toutefois, pour un confort de développement, il peut être préférable de travailler totalement en local et envisager de scinder la base de données plus tard lorsque le projet tire à sa fin dans sa phase de développement.

En cas de développement multiutilisateur, cela permet de se rendre compte notamment des temps de réponse de l'ouverture de certains formulaires exécutant des requêtes lourdes, auquel cas, il faut envisager d'optimiser…

X - Erreur d'exécution au cours des tests

Vous n'êtes pas à l'abri de surprises en matière de bogues et d'erreurs concernant votre application nouvellement installée sur le poste de test. Si vous n'en rencontrez pas, tant mieux.

Les plus courantes sont, en général, liées à une omission de la part du développeur vis-à-vis de l'application et son environnement.

X-A - Quelques exemples

Vous pouvez très bien voir une erreur qui spécifie qu'il est impossible de masquer une barre d'outils. Vous devez alors modifier les options de démarrage plutôt que d'éventuelles routines dans votre code qui s'en chargent.

Une autre sera liée à l'exploitation d'un composant qui n'a pas été enregistré sur le poste de test. (Erreurs de type 429.)
Ce cas de figure peut se rencontrer quand vous avez greffé un nouvel ActiveX® dans votre projet, que vous avez créé le MDE (ou le MDB) et fourni ou copié vous-même le MDE (ou le MDB) sur le poste de test sans avoir pris la précaution d'embarquer le composant et de l'enregistrer dans le registre de Windows…

XI - Création d'un formulaire de démarrage

Il existe deux cas de figure qui concernent l'obligation de créer un formulaire de démarrage :

- si aucun formulaire de démarrage n'est stipulé et que votre application est un fichier MDE rien ne se passera sinon l'ouverture d'une fenêtre grise, absente de toutes possibilités sinon celle de quitter Microsoft Access. - Si une macro AUTOEXEC est présente, elle se doit de spécifier l'ouverture d'un formulaire sinon, même phénomène que précédemment.

Il est donc conseillé de créer un ou plus exactement de stipuler celui qui doit être chargé au démarrage, par exemple, le menu principal. Vous pouvez aussi créer un formulaire de démarrage spécifique sous forme de «Splash Screen» qui est un formulaire qui s'affichera de façon temporisée comme dans toutes les applications Microsoft au démarrage (§ Word, Excel…).

Ce dernier pourra par exemple vérifier un certain nombre de paramètres avant d'ouvrir le Menu Principal.

Ceci dit, vous n'êtes pas tenu d'opter pour le choix Formulaire de démarrage. En effet, la mise en place d'une Macro AutoExec peut très bien faire l'affaire, mais dans tous les cas, un formulaire doit être affiché si votre projet tourne avec le Runtime.

Tout dépend des cas et des besoins.

XI-A - Spécification d'un formulaire de démarrage et des options de démarrage

La boîte de dialogue ci-dessous vous permet de définir le formulaire à ouvrir au lancement de l'application que vous avez développée.

Pour y accéder, ouvrez le menu Outils/Démarrage et spécifiez les options comme par exemple, ci-dessous où vous spécifierez le nom du formulaire à démarrer (ici frmAbout)

Pour une sécurité totale, vous pouvez décocher toutes ou partie des cases, mais cela reste risqué si vous n'avez pas prévu le code pour les rétablir ou bien pour accéder à votre application, par exemple avec un bouton caché…

Sinon, nombreuses pourraient être les personnes qui posteraient sur le forum en écrivant qu'elles ont suivi ces conseils et que depuis, elles ne peuvent plus rien faire avec leur application…

XI-B - Exemple de formulaire de démarrage

Ceci est un formulaire de démarrage pour l'application qui est citée en exemple dans ce document.

XI-B-1 - Génération d'un formulaire de démarrage temporisé

Pour concevoir un formulaire de ce type, en dehors de son contenu graphique, j'ai exploité l'événement Timer fixé à 5 secondes et parallèlement à cela, une routine se charge de faire quelques opérations de contrôle pour enfin afficher le formulaire de Connexion ou le Menu Principal selon le type d'application distribuée.

Le Timer permet de temporiser une action. Dans ce cas précis, il permet d'afficher ce formulaire (présentant rapidement l'application chargée, histoire de faire patienter l'utilisateur) pendant 5 secondes avant de l'éliminer de l'écran et afficher ensuite le Menu Principal.

XII - Installation du Runtime Microsoft Access sur le poste client

Vous avez deux manières d'installer le Runtime Access.

XII-A - Installation manuelle

Elle consiste à repérer le dossier Runtime qui est situé sur le CD-ROM de Microsoft Office Developer et à lancer le setup.exe.

Vous installez le Runtime Microsoft Access comme vous installez l'application Access en lançant le programme approprié (setup.exe).

N'installez pas le Runtime sur le poste développeur.

Si vous devez installer manuellement le Runtime sur plusieurs postes en réseau, je vous conseille de copier le dossier complet sur un serveur dédié et installer le Runtime depuis celui-ci. Sinon, trouvez tout autre moyen de le faire (CD-ROM, Clé USB, etc.) et lancez le SETUP.EXE depuis le Répertoire en question.

Pour copier le Runtime de Microsoft Access sur un serveur - sur le CD-ROM Microsoft Office Developer, localisez le dossier Access Runtime.
- Copiez le contenu du dossier du Runtime de Microsoft Access sur le serveur dans un dossier ciblé :

..\ODETools\V9\AccessRT

L'installation manuelle du Runtime 2000 (c'est-à-dire avec un Setup.exe) ne détecte pas si Microsoft Access 2000 est déjà installé sur le poste de destination. Elle installera donc le Runtime tout à fait normalement et ne refusera pas de le faire, mais ce dernier restera totalement inexploitable.

Le Runtime installe en fait un MSACCESS.EXE comme la version licenciée, mais dans le dossier :

C:\Program Files\Microsoft Office\ART\Office

Il n'y a à priori aucun danger à écraser la version existante de Microsoft Access, mais cette opération reste inutile, car vous ne serez pas en mesure de tester en mode Runtime vos applications développées.

Détail des fichiers installés par le Runtime

XII-A-1 - Lancement de l'installation manuelle sur un poste

L'installation manuelle du Runtime s'effectue comme n'importe quel programme Microsoft à installer…

Cliquez alors sur Installer

Si vous choisissez une installation personnalisée, vous pourrez définir un emplacement spécifique différent de celui utilisé par défaut. La procédure analyse votre système puis vérifie la présence de certaines applications pouvant nuire à une installation correcte.

Fermez alors toutes les applications listées après avoir enregistré vos éventuels travaux en cours puis cliquez sur Réessayez.

Je ne vous conseille pas de choisir Ignorer, car même si le Runtime s'installe correctement, il est possible que des dysfonctionnements ultérieurs surviennent inopinément et vous ne serez pas en mesure de faire un rapprochement entre ces derniers et la décision que vous auriez prise (celle d'ignorer la présence des applications encore actives) au moment de l'installation dudit Runtime. Donc fermez bien les applications concernées avant de continuer.

La procédure alors installe le programme…

L'installation poursuit son cours puis se termine

XII-B - Installation automatique du Runtime

L'installation automatique est quant à elle exécutée par le SETUP.EXE d'installation que vous empaquetez lorsque vous générez un package si vous avez coché l'option Insérez Access Runtime.
Voyez le chapitre consacré à la génération d'un package à l'aide de l'Assistant Empaquetage et déploiement, plus haut dans ce document.

L'installation automatique (avec un Setup) détecte si une version d'Access est déjà installée sur le poste de destination. Elle n'installera donc pas le Runtime si Access (version complète et de même version que le Runtime) est déjà là.

Par ailleurs, le programme issu du Runtime Microsoft Access s'appelle aussi MSAccess.exe et se situe dans le répertoire C:\Program Files\Microsoft Office\ART\Office.

XII-C - Une fois le Runtime installé…

Une fois que les opérations d'installation manuelle ou automatique sont achevées, vous pouvez lancer une ou plusieurs applications Microsoft Access depuis un raccourci (créé automatiquement par le SETUP en cas d'installation par un package généré par l'Assistant Empaquetage et Déploiement) ou depuis l'Explorateur de fichiers.

XIII - Différences entre Microsoft Access et l'environnement Runtime

Un poste client équipé du Runtime Microsoft Access seul ne peut pas accéder directement aux données dans la base de données autrement que par l'application elle-même. Il ne peut ni voir la structure des formulaires ni voir le code ou tout autre objet issu de l'application. Même si la base de données est située sur un serveur, l'utilisateur sera dans la même situation.

Si les applications qui fonctionnent avec le Runtime de Microsoft Access se comportent, à bien des égards, de la même manière que des applications qui fonctionnent avec la version complète de Microsoft Access (Microsoft Access Runtime est une version du logiciel Access amputée des objets permettant la conception), il existe certaines différences qui peuvent avoir une incidence sur les approches de conception et de développement :

- les fenêtres Base de données et Visual Basic Environment sont masquées de même que tous les modes Création y compris les fenêtres Filtre ;

- les barres d'outils intégrées ne sont pas gérées, mais vous pouvez néanmoins ajouter à votre application des barres d'outils personnalisées ;

- certains menus (y compris les menus contextuels), fenêtres et commandes sont masqués ou désactivés ;

- la gestion d'erreurs de Visual Basic est nécessaire. Les erreurs qui ne sont pas gérées par le code arrêtent l'application sans aucun avertissement préalable. Pour cette raison, l'emploi des macros est plutôt déconseillé ;

- certaines séquences et combinaisons de touches sont désactivées :

Raccourcis clavier

Correspondance

Ctrl+Pause

Interrompt l'exécution du code ou de la macro.

Maj

Empêche l'exécution d'une macro AutoExec et ignore les propriétés de démarrage des bases de données lorsque vous ouvrez une base de données.

Alt+F1 ou F11

Affiche la fenêtre base de données.

Alt+F2 ou F12

Affiche la boîte de dialogue Enregistrer sous.

Maj+F12 ou Alt+Maj+F2

Enregistre un objet de base de données.

Ctrl+G

Affiche la fenêtre Débogage.

Ctrl+N

Ouvre une nouvelle base de données.

Ctrl+Entrée ou Alt+D

Ouvre un objet en mode Création.

Ctrl+F11

Bascule entre les barres de menu personnalisées et intégrées.

XIII-A - Microsoft Access et la clé de licence Runtime

Toute application Microsoft installée sur un poste de travail est soumise à une licence. Bien que le Runtime Microsoft Access permette la distribution gratuite et l'exploitation de vos applications développées à travers le mode de fonctionnement équivalent à celui de la version complète de Microsoft Access, il n'en est pas moins doté d'une licence qui se traduit par l'inscription dans le registre de Windows.

Seules l'installation manuelle du Runtime par le SETUP.EXE ou l'installation de votre application à partir du programme d'installation créé avec l'Assistant Empaquetage Déploiement incluant le Runtime permettent d'apporter automatiquement les modifications voulues.

S'il n'y a aucune clé de licence dans la base de registres Windows, l'application d'exécution ne peut pas être lancée. D'ailleurs, il est fort probable que les icônes spécifiant les fichiers de type MDB ou MDE, caractéristiques des fichiers Microsoft Access soient dépourvus des illustrations respectives qu'ils reçoivent dès que le Runtime est correctement installé.

XIV - Les erreurs liées à l'installation

XIV-A - Erreur d'exécution 429 lors de l'exécution d'un programme Access

Symptômes

Vous installez une application d'exécution Microsoft Access Runtime ou bien vous exécutez une application Access et le message d'erreur suivant apparaît :

Erreur d'exécution '429' : Le composant ActiveX ne peut pas créer l'objet

Cause

Vous avez installé l'application d'exécution sur un ordinateur où Microsoft Access n'a jamais été préalablement installé. Cette erreur peut se produire lorsqu'un composant n'a pas été enregistré dans le Registre du système. En effet, lorsque vous introduisez dans votre application un certain nombre de références externes et que votre programme contient des instructions exploitant ces dernières via VBA, ce message apparaîtra et votre application ne pourra fonctionner.

Par exemple, lorsque vous effectuez des appels DAO dans votre application, Microsoft Access utilise la référence de la DLL correspondante à savoir pour DAO 3.6 le fichier dao360.dll situé généralement dans le dossier

C:\Program Files\Fichiers communs\Microsoft Shared\DAO

Ici, le code ci-dessous suppose que vous avez fait une référence à DAO sans en préciser la version.

Set RS = CurrentDB.OpenRecordset ("SELECT * FROM CLIENTS", DBOpenDynaset)

Résolution

Vous devez enregistrer correctement le ou les composants incriminés. Pour ce faire, vous devez localiser l'implantation physique de ce composant dans votre système et également dans le registre de Windows.

Vous devez alors faire en sorte d'avoir une seule et unique version et que cette version soit celle qui corresponde à la version exploitée dans votre projet.

Dans le menu Outils/Références de Visual Basic Editor, vérifiez si les références sont correctes (pas de terme Manquant) et que les références cochées correspondent bien à des bibliothèques correctement enregistrées.

Exemple
- Par défaut, les appels DAO se font à partir de ces composants
- Microsoft Access 97 => DAO350.DLL
- Microsoft Access 2000 => DAO360.DLL

Pour plus d'informations…

Pour plus d'informations, vous pouvez aussi jeter un œil ici à la page Résolution de l'erreur 429 lors de l'automatisation des applications Office.

XIV-B - Message d'erreur : Impossible du fichier C:\Windows\Temp\Msftqws.pdw\$(DllSelfRegisterEx) ne peut pas être inscrit parce qu'il n'a pas été trouvé.

Symptômes

Lorsque vous installez le package contenant votre application Access à partir du Setup.exe, tout se passe bien jusqu'à la définition du groupe de démarrage, mais ensuite, il est possible que vous receviez un message de confirmation du type :

à partir du moment où vous avez employé le contrôle calendrier au sein de votre application, mais ce n'est pas obligatoire.

En fait, ce message apparaît uniquement si une autre application ou un autre programme exploite aussi ce contrôle qui a donc déjà été inscrit dans le registre de Windows. Toutefois, celui que vous tentez d'installer, enfin pas, vous, mais le Setup est de version différente.
Il est évident que vous pouvez choisir Oui si vous estimez que la version proposée est plus récente.

Le problème n'est pas là en fait…
Il s'en suit généralement un message plus grave qui arrête tout bonnement votre installation :

Le fichier C:\Windows\Temp\Msftqws.pdw\$(DllSelfRegisterEx) ne peut pas être inscrit parce qu'il est introuvable.

Ce message s'affiche dans une boîte de dialogue comme ci-dessous, ne permet pas d'avoir davantage d'informations…

Il décrit avec peu de détails le fait qu'il manque un fichier, mais il ne dit pas lequel.

Selon votre version de Windows (98SE, NT4, 2000, XP), il est précisé le chemin conséquent à votre dossier Temp qui est généralement défini comme suit (ici XP) :

« C:\DOCUME~1\VOTRE NOM D'UTILISATEUR\LOCALS~1\Temp\msftqws.pdw\$(DLLSelfRegisterEx) »

Vous pouvez remarquer que mon message d'erreur est différent ; tout simplement parce j'ai défini D:\Temp comme dossier temporaire.

Explications

En fait, cette erreur s'explique du fait que le fichier de dépendance de votre contrôle calendrier ne correspond pas à la version que vous tentez d'inscrire et que la méthode employée pour l'inscrire est rédigée avec une mauvaise syntaxe.
Souvent, la version du contrôle MSCal.ocx est 8.0.0.5007 alors que celle spécifiée dans le fichier MSCAL.DEP est 8.0.32.29.

Résolution

Cas N° 1

Pour y remédier, il suffit de confirmer l'arrêt par la succession de messages circonstanciels pour quitter le SETUP et de revenir à la conception du package.

Vous détruisez alors le fichier *.cab du dossier ..\..\Package sans appréhension puis vous ouvrez le fichier MSCAL.DEP comme expliqué à cette section, le but étant de mettre à niveau la version du contrôle que vous installez avec la version spécifiée dans le fichier MSCAL.DEP.

Vous utilisez donc un éditeur de texte pour mettre à jour cette version sans omettre de corriger $(DLLSelfRegisterEx) et de le remplacer par $(DLLSelfRegister).

; Dependency file for setup wizards.
; Dependencies for MsCal.OCX
; Default Dependencies
------------------------------------------------------
[MSCAL.OCX]
Dest=$(WinSysPath)
Register=$(DLLSelfRegister)
Version=9.0.0.2607
Uses1=
; Localized Dependencies
----------------------------------------------------

Cas N° 2

J'ai effectué ce qui est dit en Cas N° 1, mais l'erreur persiste…
Eh oui, effectivement, l'erreur peut persister puisqu'il faut également corriger le fichier SETUP.LST comme suit :

[Setup1 Files]
File1=..........
File2=..........
File3=..........
File4=..........
File5=..........
File6=..........
File7=..........
File8=@MSCAL.OCX,$(WinSysPath),$(DLLSelfRegister),$(Shared),4/7/99 1:06:14 AM,106496,9.0.0.2607
File9=..........

en remplaçant $(DLLSelfRegisterEx) par $(DLLSelfRegister)…

Les clés File1 à File9 sont les fichiers que vous insérez dans votre package : il peut y en avoir plus ou moins 9.

Une fois cela terminé, relancer la génération du fichier *.cab comme expliqué ici.

Chaque fois que vous régénérerez un package, prenez la précaution de le corriger en conséquence et surtout de le tester sur un poste typique client…

Pour éditer votre fichier SETUP.LST, ouvrez-le à partir du dossier ..\..\Package, une fois que vous l'avez régénéré…

État

Microsoft a confirmé que ce comportement fait partie intégrante de Microsoft Office 2000 Developer.
Il semblerait toutefois que ce problème ait été résolu dans le Service Release-1/1a pour Microsoft Office 2000.

XIV-C - Erreur dans le chemin d'accès en installation du Runtime (Office XP)

(Path/File Access Error - Installing a Runtime Application)

Symptômes

Quand vous essayez d'installer le Runtime depuis le CD de Microsoft Office XP Developer sur un poste équipé de Microsoft Windows 98 ou de Microsoft Windows Millénium Edition (Me) il est probable que vous receviez le message d'erreur suivant :

Path/File access error OU An unexpected Setup error has occurred!

Le message d'erreur est une boîte de dialogue dotée des boutons Réessayer/Annuler. Si vous cliquez sur Réessayer vous perpétuez l'apparition du même message. Si vous cliquez sur Annuler vous obtiendrez un message comme quoi l'installation a échoué.

Résolution

Procurez-vous le Service Pack 1 (SP-1) de Microsoft XP Developer et régénérez le package puis réinstallez-le sur les postes concernés.

313166 OFFXPDEV : Comment obtenir le Service Pack 1 (SP-1) Office XP Developer ?
Quand vous êtes en mesure de l'installer, exécutez les étapes suivantes :
- créez un dossier sur le poste cible ;
- copiez l'ensemble du contenu du CD ;
- depuis l'explorateur de fichiers, changez les propriétés des fichiers cab en décochant l'attribut lecture seule ;
- exécutez le Setup depuis ce répertoire.

État

Microsoft a confirmé que ce problème fait partie intégrante de Microsoft Office XP Developer.
Ce problème n'existe plus dans le service pack Office XP Developer SP-1.

XIV-D - Problème de cohabitation des projets Access avec un Runtime Access

Vous pouvez rencontrer un léger problème lorsque vous installez un Runtime Access de version antérieure à une version complète de Microsoft Access sur le poste de votre utilisateur. En effet, de façon systématique dans l'installation des applications Microsoft, les affectations des types de fichiers et leurs associations respectives sont réaffectées au programme venant d'être installé.

Par exemple, si sur un poste doté de Microsoft Access 97 vous installez le Runtime Microsoft Access 2000, toutes les applications réalisées sur ce poste s'ouvriront depuis l'Explorateur de fichier avec la version 2000 du Runtime et qui plus est pour ce cas, elles seront impossibles à modifier.

Du fait que l'application tourne avec une version particulière de Microsoft Access ou avec un Runtime Access de cette même version, il se peut que celle-ci refuse de se charger. Un message d'incompatibilité de version apparaîtra alors…

Le phénomène se traduit par un conflit d'association de fichier de type mdb ou mde pour ce cas. Les associations de fichiers de ce type n'ont pas été mises à jour sur le poste… En effet, Windows n'est pas capable d'associer un type de fichier en fonction de sa version, mais seulement en fonction du nom de l'extension du fichier lui-même.

Pour y remédier, il vous suffit de modifier le chemin du Raccourci comme suit :

Ancien chemin :

"Lecteur:\Chemin du Projet\Base2000.mde"

Exemple

"C:\Program Files\ChessCircle\ChessCircle.mde"

Nouveau raccourci à modifier (Runtime 2000) :

"Lecteur:\Program Files\Microsoft Office\ART\Office\MSACCESS.EXE" _
"Lecteur:\Chemin du Projet\Base2000.mde"

Exemple avec Runtime 2000 :

"C:\Program Files\Microsoft Office\Office\ART\Office\MSACCESS.EXE" _
"C:\Program Files\ChessCircle\ChessCircle.mde"

Exemple Microsoft Access 97 (où le Runtime 2000 est résident) :

"C:\Program Files\Microsoft Office\Office\MSACCESS.EXE" _
"C:\Applications97\Clients\GestionFactures97.mde"

Veuillez prendre en compte qu'un espace entre le chemin du Programme et celui du projet est présent et que le caractère de soulignement ( _ ) est symbolique pour représenter la continuité de la ligne et ne doit pas être stipulé dans le chemin d'accès.

XV - Utilisation du Runtime dans Office XP Developer

Tout comme pour Microsoft Office 2000 Developer, Microsoft Office XP Developer contient également tous les outils nécessaires pour la mise en place de solutions et le déploiement de ces dernières avec le Runtime.

Nous avons élaboré quels étaient les avantages qu'apporte le Runtime, ils restent identiques pour la version XP et pour ce qui est de l'empaquetage, la procédure est quasi identique.

XV-A - Empaquetage de solution Microsoft Access XP

Le principe de création d'un empaquetage pour Office XP Developer reste inchangé par rapport à la version 2000. Seule la façon de l'intégrer est différente.

Un package contient donc la version exécutable Microsoft Access XP (limitée à l'ouverture des applications) et les différents fichiers nécessaires à son fonctionnement et votre application (MDB ou MDE, ADP ou ADE).

XV-A-1 - Prérequis pour l'exploitation du Runtime Access XP

Le poste devant recevoir une version du Runtime issue du package doit remplir un certain nombre de conditions :

si le poste cible tourne sous Windows NT 4.0 vous devez préalablement installer le Service Pack 6.0a ;

pour le poste du développeur, la version 5.1 ou supérieure de Microsoft Internet Explorer doit avoir été installée.

XV-A-2 - Installation d'un empaquetage contenant le Runtime Access XP

Pour lancer l'Assistant Empaquetage, il vous faut repérer le groupe de programme où se situent les raccourcis de Microsoft Office XP Developer. En général, vous devez localiser ce groupe depuis le menu Démarrer de Windows et sélectionner Assistant Empaquetage.

Le fait de lancer la création d'un Empaquetage contenant le Runtime Access sur votre poste exige que vous mettiez à disposition les fichiers exécutables du dit Runtime. Il vous faudra alors insérer le CD-ROM de Microsoft Office XP Professionnel avec FrontPage qui fait partie du lot de CD de la suite Microsoft Office XP Developer.

Pour inclure le Runtime Access à votre package, cliquez sur le bouton Empaquetage et sélectionnez Standard Package puis au moment où vous visualisez l'écran où vous pouvez inclure vos propres fichiers, sélectionnez l'option Oui, inclure Access Runtime. Le principe reste très proche de la version 2000 où vous pouvez avoir plus de détails à cette section.

Par ailleurs, vous pouvez inclure les composants système requis pour exécuter une application Access Runtime dans votre application et cela est fortement recommandé si vous n'êtes pas certain que les postes cibles n'en disposent pas. Du même et du fait que Microsoft Internet Explorer 5.1 est requis sélectionnez l'option Installer Internet Explorer 5.1.

XV-B - Correctif de sécurité Access Runtime pour Office XP

Microsoft a découvert une faille dans Microsoft Access 2002 Runtime. Une mise à jour corrective est disponible ici. Pour plus d'informations concernant ce correctif, veuillez vous rendre sur le site de Microsoft à cette page.