Proposé en détail dans la LST 64, je confirme le fonctionnement des installations silencieuses (bonheur).

Pour les lancer, il suffir d'exécuter :
INSTALL.EXE /SILENT=<CheminCompletDuPilote.INI>

Dans le fichier .ini on trouvera :
- une section PILOTE suivit de l'identifiant de l'installation (WDINST>Paramètres de l'installation>Fin d'installation>Identifiant de l'application dans la BDR).

[PILOTEMONAPPLI]

- Les mots clés et valeur qui fixent les paramètres de l'installation. Ces paramètres sont disponibles dans la procédure globale de WDSETUP : gbInitChoix.
On considèrera les valeurs suivantes :
REPINST = répertoire destination de votre installation
MODAUTO = modification automatique des données active ou pas (encore faut-il que l'installation comporte le ZIP correspondant)
...


Restriction : le .ini, s'il est généré par programmation, doit être localisé dans un espace accessible en écriture. Attention donc aux CD : on va alors utiliser le répertoire temporaire de Windows.

On peut aussi completement configurer la localisation finale de Etat et Requêtes ainsi que ses répertoire de travail.

Maintenant, sur mon CD, j'utilise un programme d'installation en amont des install.exe (comme le fait PCSoft !!!). Ce programme identifie s'il s'agit d'une installation ou d'une mise à jour et propose plusieurs paquetages (les mêmes projets mais configuré selon des types de clients).

Voici donc enfin la question :
Dans la foulée, on standardise le déploiement des framework (livré avec le CD). Chaque mise à jour du framework écrase-elle celui de la version précédente ?

En effet, les DLL WinDev sont postée dans le répertoire system du poste client. Un projet est validé pour un framework donné, je dois savoir si nos validations doivent toutes se produire sur une même génération de framework ou si la pluralité est possible. Chaque projet peut alors utiliser une version du framework.

Cette discussion sera etayée d'autres constats/questions sur le sujet.

OK on va résumer la problématique :

Comment, dans mon application qui pilote les installations, dépoyer le framework WinDev livré sur le support d'installation et s'assurer qu'il est bien déployé ?

En prime un petit truc pou connaitre la version winDev interne d'un programme, VersionWindev() devenant obsolète.
Pour une application incluant son propre framework :


Utile alors pour aller chercher le bon framework !

Quelques avancées sur ce sujet.
J'invite ceux qui se penchent sur le déploiement et le versionning de leurs projet à étudier l'aide de la fonction ExeInfo(). En effet, outre les constantes classiques qui permettent de retrouver la description complete de votre projet, voyez un peu l'utilisation des constantes issues de l'API (Comment, InternalVersion...). Un petit essais avec ces constantes a permis d'avoir par programmation exactement les mêmes informations que celles données par l'exploreur quand on cherche les propriétés d'un fichier, onglet version.

La dernière fois, on a vu comment récupérer la version interne utilisée par le projet en analysant la "VersionVI" de WDxxxVM.dll

Aujourd'hui : il est possible de localiser le framework installé sur le poste client.
Il faut s'avoir qu'il est installé dans le répertoire "C:\Program files\fichier communs\PC SOFT\<version WinDev>\Framework"
Ce qui donne pour un projet en Windev 10 :
C:\Program files\fichier communs\PC SOFT\10.0\Framework

La partie "C:\Program files\fichier communs" est disponible via le code suivant


On peut y lister les répertoire (boucle de fRep) pour aller chercher la plus grande version WinDev et y lire la version interne du framework installé.

La version produit (WinDev) est disponible via :



Ainsi, si vous utilisez un pilote d'installation, voici une stratégie pour assurer la mise à jour.

1- le pilote d'installation doit être compilé dans la même version WinDev que le projet à installer. Il doit utiliser sont propre framework.
2- le support d'installation doit contenir l'installtion du framework correspondant (si installation sans téléchargement possible)

Il est alors possible :
- de lire la version WinDev en analysant le WDxxxVM.dll du pilote d'installation (dans le répertoire courant)
- de chercher si un framework correspondant à cette version WinDev est présent sur le poste client et d'en comparer les version interne.
- si nécessaire, il est alors possible, sans poser de question, d'installer/mettre à jour sur le poste client le framework nécessaire à votre projet.


Ainsi, votre projet peut être découpé en plusieurs modules, tous utilisant le même framework dont la mise à jour ou l'installation est assuré par votre pilote d'installation.