Discussion :

[Arkazh]

Mon application terminée et validée (accdr dans l'environnement de déploiement), j'ai attaqué la partie package de déploiement, après bien entendu avoir parcouru ce forum et les précieux tutos qu'on peut y trouver.

Je dois déployer sur des postes en 32 bits et d'autres en 64 bits. j'ai donc créé deux packages, chacun sur son poste équipé en 32 bits pour l'un et 64 bits pour l'autre.

Mes packages : Pack_x32 et Pack_x64 (MSIs modifiés par ORCA pour approbation). je précise que j'ai prévu l'installation par défaut avec l'option "Program Files (Tous les utilisateurs, en lecture seule sous Windows Vista et version ultérieure)" d'ailleurs pourquoi lecture seule seulement ?

Coté déploiement Maintenant :

sur poste 32 bits, tout se passe comme prévu, aucun soucis

Sur poste 64 bits, aïe, aïe, aïe......

Joli message à l'ouverture de l'appli :
"Vous ne pouvez pas ouvrir la base de données, car le projet VBA y figurant ne peut pas être lu. Vous pouvez ouvrir la base de données uniquement si le projet VBA est d'abord supprimé.
La suppression du projet VBA supprime tous les codes des modules, des formulaires et des états. Vous devez sauvegarder votre base de données avant d'essayer d'ouvrir la base de données et de supprimer le projet VBA."

Après vérifications :

l'application a été installée dans \Program Files (x86)\Nom_Appli au lieu de \Program Files\Nom_Appli! ! ! ! !

Lorsque je place le fichier accdr dans "Mes Documents", je n'ai plus le soucis !
Si je le place dans \ProgramFiles\Nom-Appli je retrouve le message d'erreur ! !

Je peux bien entendu (j'ai testé), prevoir l'installation du package dans \Mes documents mais l'utilisateur peux choisir une installation dans un autre répertoire et donc le problème n'est pas résolu.

QUESTIONS :

1 - C'est quoi ce binz du program files (x86) ? ? ? ai-je fais une erreur ? Comment résoudre le soucis ?

2 - Comment interdire le choix du répertoire d'installation au niveau du package ?

[Arkazh]

Bon, correction.......

Je faisais erreur car sur mon PC 64 bits j'avais toujours MS Office 2010 installé, avec en plus le runtime Access 2010.
Mais lorsque j'ai désinstallé mon MSOffice 2010 j'ai retrouvé mon message d'erreur ou que soit situé le fichier accdr.

Donc, seul le accdb fonctionne, si je le renomme en accdr, lui aussi fonctionne.

Seul le fichier accdr produit par l'assistant pose soucis avec le runtime ! !

[argyronet]

Bonjour,

Program Files dans l'assistant est l'équivalent de « Program Files (X86) » pour X64 et « Program Files » pour X32.

Le fichier accdr généré par l'Assistant Microsoft Access 2010 est buggé. Je n'ai pas cherché à savoir pourquoi et j'ai plutôt pris la liberté de concevoir un nouvel Assistant 2010 téléchargeable ici et utilisable dans les mêmes conditions que 2013 ou 2016.

Pourriez-vous précisez (je pense que c'est 2010 d'après vos écrits) quel assistant utilisez-vous ?

Merci

Argy

[Arkazh]

Bonjour Argyronet

Je voudrai tout d'abord te dire un GRAND merci pour tes tutos et tes diverses informations sur ce forum, cela m'a été d'une aide précieuse.
J'avais, entre autres lu ton tuto "Comment déployer vos applications professionnelles développées avec Microsoft Access 2010 en incluant le Runtime".
J'avais bien vu sur ce tuto mais aussi sur le forum, que tu avais développé un assistant pour 2013 et 2016 puisque ce dernier n'est plus présent dans ces versions mais j'avais zappé cette version pour 2010, heureusement tu es toujours là pour nous donner les bonnes infos.

Bonjour,

Program Files dans l'assistant est l'équivalent de « Program Files (X86) » pour X64 et « Program Files » pour X32.

Ce qui veut dire qu'il est IMPOSSIBLE" d'installer une appli 64bits dans le répertoire destiné à cet effet ? Elle sera systématiquement installée dans Program Files (X86) ? En est-il de même dans ton assistant ?

Je vais effectuer quelques essais avec ton asssistant.

Pourriez-vous précisez (je pense que c'est 2010 d'après vos écrits) quel assistant utilisez-vous ?
Argy

En effet c'est ACCESS 2010 et son assistant que j'utilisais, mais bon.... c'est TERMINE, j'utiliserai le tiens dorénavant.
Incroyable quand même Microsoft, incapables de faire un assistant fonctionnel, ils l'ont carrément viré des versions ultérieures ! ! !

[Arkazh]

Alors, premier essais de l'assistant 2010 d'Argyronet.

* J'ai téléchargé et installé la version 64 bits SANS Runtime (je l'avais déjà). Installation sans soucis.

Utilisation de l'assistant :

1-

Je sélectionne mon fichier source ACCDB.

Lorsque je coche "générer un fichier ACCDE", j'obtiens un beau message me disant que ce n'est pas possible, de vérifier etc...etc....
Ca pourrait être mon appli, mais non car j'ai produit un ACCDE à partir d'office et il fonctionne très bien, j'avais fait auparavant un test dans l'environnement 64 bits sans office mais avec le runtime, puis avec les deux et tout était OK.
Bon j'ai donc choisi mon ACCDE comme source et là ça passe si je lui dit de ne pas régénérer de fichier ACCDE.

2 -

lorsque j'ai coché la case du Runtime, j'obtiens un message me disant que le runtime n'est pas disponible à l'endroit spécifié, normal puisque j'ai pris la version sans runtime. Je fais donc Parcourir, je sélectionne mon fichier AccessRuntime_x64.exe (téléchargé sur le site de Microsoft), et là l'assistant m'ouvre une fenêtre de téléchargement en me précisant un lien de téléchargement
Bon, malgré tout je suis là pour tester, je clique donc sur OK pour télécharger.
J'obtiens le même fichier que celui que j'avais déjà. Je recommence donc l'opération (parcourir etc...) et BING même message ! L'assistant ne prend pas le fichier spécifie

En relisant de plus près le message affiché, je m'aperçois que l'assistant attend un fichier nommé "AccessRuntime_x64_fr-fr.exe". Je fais donc un essai en renommant mon fichier runtime de AccessRuntime_x64.exe en AccessRuntime_x64_fr-fr.exe et là, ça fonctionne L'appui sur le bouton parcourir précisait pourtant *.exe

Bon, pas si grave, j'ai trouvé la soluce, mais un petit bug qui pourrait en dérouter plus d'un je pense.

3 -

Arrivé à la fin du processus, la génération du package est lancée (un peu plus long que l'assistant officiel quand même). J'obtiens bien les fichiers nécessaires et je m'empresse de lancer le setup de mon appli, mais là BING nouveau message d'erreur " Le fichier de paramètres d:\Packs\Package_0\FILES\Setup.INI manque ou n'est pas valide......."
J'ai vérifié, il est bien présent et accessible.

J'ai donc comparé avec un Setup.ini d'un package réalisé avec la version officielle d'office 2010 et j'ai trouvé une différence :
dans la section [Product] il manque deux lignes (ProductName et ProductVersion).

J'ai mofifié le fichier Setup.ini généré par l'assistant d' Argyronet en rajoutant ces deux ligne avec leur valeur adaptée à mon appli et refait un essai.

Je vous le donne en mille : CA MARCHE

Voilà, quelques pistes peut-être pour améliorer quelque peu ce bel outil.

[Arkazh]

1-

Je sélectionne mon fichier source ACCDB.

Lorsque je coche "générer un fichier ACCDE", j'obtiens un beau message me disant que ce n'est pas possible, de vérifier etc...etc....
Ca pourrait être mon appli, mais non car j'ai produit un ACCDE à partir d'office et il fonctionne très bien, j'avais fait auparavant un test dans l'environnement 64 bits sans office mais avec le runtime, puis avec les deux et tout était OK.
Bon j'ai donc choisi mon ACCDE comme source et là ça passe si je lui dit de ne pas régénérer de fichier ACCDE.

Une réponse à ce chapitre :

Suite à mes différents essais, j'ai constaté que mon fichier .accdb ne pouvait pas être compilé en .accde par l'assistant si il se trouvait sur mon disque D (D:\TestAccess\Test.accdb)
Par contre, sur ma clé USB en F:\TestAccess\Test.accdb le fichier .accde est bien généré (c'est le même fichier).

Au final, constatant que cette clé USB était formatée en FAT32, je me suis dit qu'il devait y avoir un problème de droits puisque mon disque D, lui est en NTFS.

J'ai donc lancé Access2010 en mode Administrateur et j'ai réussi à créer le fameux .accde sur le disque D.

Pffffff.... quelle misère....

Un point de réglé, enfin de bricolé ! ! !
Reste a voir le reste.

[Arkazh]

Et PAN !
retour au point de départ, j'explique :

après avoir déjoué avec l'aide du forum et d' Argyronet, toutes sortes de pièges, j'ai enfin pu générer avec l'assistant d' Argyronet, un package d'installation.

Retour dans un environnement 64 bits vierge de toute install d'office.
Le package s'installe sans soucis.

Mais.......

1 - le runtime n'a pas été installé et pour cause il n'a pas été intégré au package ! ! !

2 - j'installe le runtime manuellement puis je lance mon appli nouvellement installée : j'ai de nouveau le même message qu'avec l'appli empaquetée par l'outil Microsoft office officiel qui était buggé d'après Argyronet: "Vous ne pouvez pas ouvrir la base de données, car le projet VBA y figurant ne peut pas être lu. Vous pouvez ouvrir la base de données uniquement si le projet VBA est d'abord supprimé.
La suppression du projet VBA supprime tous les codes des modules, des formulaires et des états. Vous devez sauvegarder votre base de données avant d'essayer d'ouvrir la base de données et de supprimer le projet VBA."

J'en ai plein le c.. de ces c........ je perds mon temps.....

Mais quelle idée j'ai eu de reprendre Access Grrrrrrrrr... @#!

[argyronet]

@Arkazh

J'avais bien vu sur ce tuto mais aussi sur le forum, que tu avais développé un assistant pour 2013 et 2016 puisque ce dernier n'est plus présent

Oui... ce fut un grand chantier mais vu le succès si petit soit-il, je ne regrette pas de les avoir développés.

Ce qui veut dire qu'il est IMPOSSIBLE" d'installer une appli 64bits dans le répertoire destiné à cet effet ? Elle sera systématiquement installée dans Program Files (X86) ? En est-il de même dans ton assistant ?

En fait,

1. sur une plateforme win 64 bits, les applications 32 bits sont installées dans Program Files (x86).
2. sur une plateforme win 32 bits les applications sont installées dans dans Program Files ; les applications 64 le seraient aussi mais en général, un setup est bien fait les rejete faute de compatibilité.
3. sur une plateforme win 64 bits, les applications 64 bits sont installées dans Program Files (Alias Programmes).

L'emplacement physique de ce dossier est régit par la variable d'environnement %ProgramFiles%.
Cette variable est paramétrée dans la base de registre : valeur ProgramFilesDir dans HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion et toutes celles d'orthographes associées.

Donc concernant l'Assistant Package, le fait de choisir Program Files dans liste laissera supposer que le SETUP s'adaptera en fonction de la plateforme cible.
Mais quoi qu'il en soit et au vu des restrictions qui peuvent survenir des stratégies de sécurité dans les entreprises, je vous préconiserais volontiers de déconseiller ce choix de dossier à vos utilisateurs (clients).
Une application Access n'est pas un programme et donc, n'a pas à être installé dans ce dossier.

Incroyable quand même Microsoft, incapables de faire un assistant fonctionnel, ils l'ont carrément viré des versions ultérieures ! ! !

Tout le monde fait des erreurs ; moi le premier ; pour preuve, j'ai procédé à des releases des versions des assistants...

Mais effectivement, je te l'accorde, venant de Microsoft, ça fait tâche et c'est presque inacceptable.
Cela prouve que celui qui l'a développé n'a pas testé et fait recetter comme il faut dans un réèl contexte utilsiateur.
D'ailleurs, moi même, lorsque je m'en suis aperçu, je fus surpris que personne ne se manifesta hormis sur ce forum, ce qui évoque une possible faible utilisation de ces assistants au final ; et donc, l'implication de Microsoft à investir des moyens pour apporter un correctif tomba aux oubliettes... De plus, je suis presque sûr qu'au final ils ignorent cette faille et que le fait que ce soit 2010, c'est du passé à Y - 8.

Pour terminer, concernant les déboires que tu rencontres, il faut considérer que :

• l'assistant 64 bits est fait pour être utilisé sur Access 64 bits et donc Windows 64 bits
• l'assistant 32 bits est fait pour être utilisé sur Access 32 bits et donc Windows 32 ou 64 bits

Il n'est pas possible d'empaqueter une application développées sur Access 64 bits avec l'assistant 32 au même titre que je n'ai pas prévu de pouvoir utiliser les deux assistants 32 et 64 sur un même ordinateur.

Argy

[Arkazh]

Encore une fois, merci Argyronet pour toutes ces précisions.

Me confirmes tu qu'il FAUT lancer Access en mode Administrateur pour générer correctement le package ?
J'ai constaté qu'en mode utilisateur,et si la destination du package est un lecteur formaté en FAT (ou un disque sans sécurités) alors le fichier Setup.ini n'est pas bon, il manque la ligne ProductName dans la section [Product].

D'autres tests en cours.......

[argyronet]

Arkazh ,

Il faut lancer Access en mode administrateur pour installer le complément uniquement.
Une fois installé, on peut utiliser l'assistant en ouverture standard.

J'ai constaté qu'en mode utilisateur,et si la destination du package est un lecteur formaté en FAT (ou un disque sans sécurités) alors le fichier Setup.ini n'est pas bon, il manque la ligne ProductName dans la section [Product].

.

Là, je n'ai jamais testé cela ; je suis pointilleux mais pas à ce point.

Et surtout, je suis surpris car l'opération de création du setup.ini est opérée par un simple WritePrivateProfileString() et n'a rien à considérer sur un lecteur Fat ou NTFS.

Argy

[Arkazh]

Après de multiples tests effectués je confirme que :

- il me faut lancer Access en mode Administrateur pour pouvoir générer le package sur un disque NTFS, sur un disque sans sécurités (FAT) le package est généré mais le setup.ini n'est pas bon, il manque la fameuse ligne et le package ne peut être installé.

- Un fichier Access compilé (ACCDE) peut être généré et empaqueté (version Microsoft comme Argyronet) mais ce fichier compilé ne peut être utilisé qu'avec la version complète d'office, avec le runtime j'ai le fameux message :

"Vous ne pouvez pas ouvrir la base de données, car le projet VBA y figurant ne peut pas être lu. Vous pouvez ouvrir la base de données uniquement si le projet VBA est d'abord supprimé.
La suppression du projet VBA supprime tous les codes des modules, des formulaires et des états. Vous devez sauvegarder votre base de données avant d'essayer d'ouvrir la base de données et de supprimer le projet VBA."

Bien entendu, les essais ont été effectues en environnement 32 bits et 64 bits.

Seul un fichier accdb ou accdr NON COMPILE fonctionne avec le runtime.

Ca me gave sérieux.......

[argyronet]

Humm, le fichier ACCDE est généré avec quelle version d'Access ?

Il faut noter comme déjà dit que si vous voulez distribuer du 64 bits, il faut Access 64 bits.
Donc ouvrir l'appli et l'enregistrer en ACCDE à partir de cette version 64 bits.

Ensuite, depuis cette même appli ou une autre, lancer l'Assistant 64 bits et générer le package mais pas en administrateur.

Pour ce qui est de distribuer une version 32 bits, idem, sauf qu'il faut ouvrir l'appli et l'enregsitrer en ACCDE à partir d'une version 32bits d'Access.
Et donc, depuis cette même appli ou une autre, lancer l'Assistant 32 bits et générer le package mais là ejncore, pas en administrateur.

Il doit y avoir des restriction sur votre poste ; ce que vous confirmer reste illogique.
Où déployez-vous physiquement les packages avant distribution ?

Argy

[Arkazh]

Humm, le fichier ACCDE est généré avec quelle version d'Access ?

Il faut noter comme déjà dit que si vous voulez distribuer du 64 bits, il faut Access 64 bits.
Donc ouvrir l'appli et l'enregistrer en ACCDE à partir de cette version 64 bits.

Humm.... Hummmm....

Comme je l'ai déjà dit, me semble t'il, je travaille avec Office 2010 Pro Entreprise. Développement et essais de déploiement sur deux postes informatiques distincts ( un poste sous Windows 7 32 bits, un poste sous Windows 10 64 bits)

Donc, le fichier ACCDE généré est généré avec la version CORRESPONDANTE, Access 2010 32b sur le poste 32 bits et Access 2010 64b sur le poste 64 bits.
J'ai également essayé de générer, sur chaque poste, le fichier ACCDE à partir de ton Assistant --> MEME PROBLEME

Ensuite, depuis cette même appli ou une autre, lancer l'Assistant 64 bits et générer le package mais pas en administrateur.

Je le répète, et ceci est valable pour les deux postes, donc sous les deux environnements :
Je suis OBLIGE de lancer Access en mode ADMINISTRATEUR sinon le package généré est BUGGE, je l'ai expliqué plus haut, le bug se situe dans le fichier setup.ini ou il manque la ligne "Product Name" et au déploiement un message d'erreur apparait, mais tout ceci seulement en mode UTILISATEUR.

Pour ce qui est de distribuer une version 32 bits, idem, sauf qu'il faut ouvrir l'appli et l'enregsitrer en ACCDE à partir d'une version 32bits d'Access.
Et donc, depuis cette même appli ou une autre, lancer l'Assistant 32 bits et générer le package mais là ejncore, pas en administrateur.

Par pitié Argyronet, soit sympa, arrête de me prendre pour un NEUNEU..... je sais que tu cherches à aider, mais là ca commence à être lourd.

Il doit y avoir des restriction sur votre poste ;

Cela fait maintenant près de 20 ans que je travaille dans le milieu de l'informatique ( 15 ans en tant que responsable d'un gros service informatique puis près de 5 ans en bureau d'études), je pense maîtriser plutôt pas mal l'univers Windows et les réseaux et je peux t'assurer que les deux postes en questions n'ont pas de restrictions particulières si ce ne sont les sécurités de base d'un système NTFS.

ce que vous confirmer reste illogique.

Illogique ? Je n'en suis pas convaincu, pour moi il y a toujours une raison valable, le tout est de la découvrir et ne connaissant pas super bien Access ni ton Assistant je ne peux y arriver seul.

Où déployez-vous physiquement les packages avant distribution ?

Sur des PCs Autonomes.

Par exemple, j'ai développé une petite appli d'état civil toute simple au profit d'un généalogiste handicapé. Sur mes postes de développement et d'essais, les fichiers compilés provoquent le fameux message d'erreur. Le fichier ACCDB lui fonctionne parfaitement, y compris si je le renomme en ACCDR, que ça soit sur un poste équipé d'ACCESS ou sur un poste équipé uniquement du Runtime.
A NOTER : Les fichers ACCDE fonctionnent parfaitement si le poste est équipé d'une version complète d'ACCESS 2010 (pas le runtime).

Pour cette personne, j'ai finalement décidé de distribur le fichier ACCDB (avec quelques sécurités quand même), j'ai donc créé Deux packages 64 bits (cette personne travaille sous Windows 8.1 64 bits), l'un avec le fichier ACCDB, l'autre avec le fichier ACCDE.

Tu vas rire, le fichier ACCDB fonctionne parfaitement sur son poste mais PAS le fichier ACCDE, toujours le même message d'erreur.

Je reste donc persuadé que le soucis ne vient pas d'une "particularité" de mes postes de travail, mais le mystère reste entier.

Puisqu'on y est, j'ai également découvert un autre bug, avec ton assistant, en fin de procédure si je décide de ne pas sauvegarder le package (enfin la config du package plutôt), je ne fournit donc pas de nom de fichier (logique), lorsque je lance l'empaquetage j'ai un beau message qui me dit "utilisation incorrecte du paramètre NULL"

Merci en tous cas de te pencher sur ce problème, pas simple à résoudre à distance il faut l'avouer.

[argyronet]

Eh bien je vous invite a exécuter un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

WritePrivateProfileString ("MSI", "Product Name", "Mon application test", strIniFilename)

vers un fichier INI quelconque à l'endroit même où vous enregistrez vos packages (MSI) et ce en mode admin depuis Access (32 ou 64 bits) puis en mode utilisateur...
Si la valeur s'inscrit dans les 2 cas, c'est que le problème ne vient pas de là et j'en suis certain... Il n'y a aucune raison pour qu'une instruction appelant WritePrivateProfileString() pour une valeur A ne s'inscrive pas pour une valeur B sous prétexte qu'Access n'est pas démarré en mode Admin. Par ailleurs, je connais un peu le code qui régit cela, donc je sais de quoi je parle, si je puis dire.

Pour info, ce n'est pas Access en lui même qui créé le setup.ini mais l'API en question via une procédure intrinsèque à le routine de création du package.

2/ A la question :

Où déployez-vous physiquement les packages avant distribution ?

c'était où se trouvent les MSI avant déploiement ?

Argy

[rpconsultants]

Bonjour,
Et merci pour cet assistant.
Je rencontre le même problème avec le setup.ini qui ne comporte pas les lignes ProductName et ProductVersion.
J'utilise ACCESS 2016 en 32 bits.
Quand je rajoute ces deux lignes à la main, tout se déroule normalement.

[argyronet]

Bonjour,
Et merci pour cet assistant.
Je rencontre le même problème avec le setup.ini qui ne comporte pas les lignes ProductName et ProductVersion.
J'utilise ACCESS 2016 en 32 bits.
Quand je rajoute ces deux lignes à la main, tout se déroule normalement.

Bonjour,

Cela na va pas être facile à déboguer car je ne suis pas en mesure de reproduire ce cas.
Je vais me pencher de plus près sur cette création du .ini ; de fait, il semble que cela soit rencontré uniquement sur 2016 ce qui va rendre la tâche encore plus simple, tiens !!!

[argyronet]

Pour tous les utilisateurs Access 2016 64 bits

La version corrigée est déployée.
Vous pouvez la récupérer à partir de la page du tutoriel...

Argy

[Arkazh]

Bonjour Argy

La première ligne de ton message ci-dessus est : "Pour tous les utilisateurs Access 2016 64 bits"

J'étais le premier a faire remonter ces soucis, et comme je l'avais dit je travaille sous access 2010

As tu prévu de reprendre également cette version ?

Merci !

[argyronet]

Bonjour,

Il y avait une version 2010 de ce package fondée sur la même couche.


Mais elle n'a pas subi de correction particulière depuis sa sortie en août 2018
Je ne l'avais pas ébruité car 2010 a déjà 8 ans, bien qu'encore largement utilisé car c'est une bonne version et stable, contrairement à ses susccesseurs.

C'est ici :
https://argyronet.developpez.com/off...e/2010/#L9-4-3

Argy

[Arkazh]

Merci pour la réponse Argy mais tu ne répond pas à ma question !

Cette version office 2010 du package datant d'aout 2018, je l'ai mais comme tu le dis si bien "elle n'a pas subi de correction particulière depuis sa sortie en août 2018"

Ce que je te demande c'est si tu as prévu de corriger le bug du setup.ini qui ne comporte pas les lignes ProductName et ProductVersion pour cette version 2010, comme tu l'as a priori faite pour la version 2016.

Je contine d'utiliser cette version d'office 2010 et n'ai (pour l'instant) AUCUN intérêt à utiliser 2016 !