Depuis que j’ai un Windows Vista à la maison, j’ai pu tester l’installeur de Bill2’s Process Manager, l’améliorer, et aussi découvrir des effets inattendus pour les utilisateurs non connectés en administrateur.

Windows, les répertoires spéciaux, et l’UAC
Avec les nouvelles versions de Windows, Microsoft a renforcé la sécurité des répertoires spéciaux comme Program Files, et introduit l’UAC.
Bill2’s Process Manager gère correctement tout ça depuis la version 3.3 : le fichier de config est enregistré dans le répertoire utilisateur dédié à ce genre de fichiers.
Résultat : chaque utilisateur du PC peut avoir sa propre configuration, et n’écrit plus dans le répertoire Program Files.

UAC et installeur
Sous Vista (et Windows 7), si on veut installer un programme dans Program Files, il faut le faire en tant qu’administrateur. C’est pourquoi mon installeur déclanche l’UAC.
Ainsi, le programme peut s’installer là où l’utilisateur le souhaite. Là où ça se complique, c’est qu’une fois installé, si l’utilisateur choisi de lancer directement le programme, il le démarre avec les même droits que l’installeur : en mode admin. Et donc la configuration est sauvegardée dans le répertoire Admin, et pas dans celui de l’utilisateur courant.
C’est pour ça que depuis la v1.2.1 de l’installeur, Bill2’s Process Manager n’est plus lancé automatiquement : ça force l’utilisateur à passer par son menu démarrer, et à lancer le programme avec ses droits utilisateur.
Mais il y a aussi un effet de bord que je n’avais pas prévu …

Mise à jour du fichier des « Exceptions »
Bill2’s Process Manager utilise différentes listes d’exceptions, pour la fonction de Priorité Automatique, pour l’assistant de création de règle, et depuis la v3.4, pour la fonction de « Règle par défaut ».
J’avais donc mis au point un système pour mettre à jour ces listes lors de l’installation d’un nouvelle version. Un fichier Updater.xml était copié sur l’ordi, et au chargement de Bill2’s Process Manager, les nouvelles infos étaient fusionnées avec les paramètres de l’utilisateur.

Sauf que … vu que l’installeur tournait en mode Admin, le fichier Updater.xml était copié dans le répertoire de l’admin, et non dans celui de l’utilisateur courant.
Résultat, vu qu’ensuite l’utilisateur lançait le programme « en son nom », la mise à jour n’était jamais intégrée, vu que le fichier Updater.xml n’était pas dans le répertoire de l’utilisateur.
Vous allez me dire : pourquoi copier se fichier dans le répertoire utilisateur, et pas dans le répertoire d’installation ? Et bien tout simplement parce que ce fichier est supprimé après intégration, et que par défaut, l’utilisateur courant n’a pas le droit de supprimer un fichier dans Program Files …

La solution que je vais mettre en oeuvre
L’installeur v1.3, sur lequel je suis en train de travailler, déposera le fichier Updater.xml dans le même répertoire que l’exécutable, vu qu’il n’a pas accès au répertoire de l’utilisateur courant.
Ensuite, lors de l’initialisation, Bill2’s Process Manager vérifiera un paramètre dans le fichier de config, et intègrera les nouvelles données si besoin est.
Ce nouveau paramètre, intégré avec la v3.4.1, sera tout simplement basé sur la version du programme.

Si j’ajoute cette vérification, c’est tout simplement pour que chaque utilisateur de l’ordinateur puisse avoir accès à la mise à jour.
En effet, les versions 3.3 et 3.4 supprimaient le fichier Updater.xml après intégration.
Si on supprime le fichier qui se trouve dans le répertoire de l’exécutable, alors seul le premier utilisateur qui lancera le programme bénificiera de la mise à jour …
Donc la v3.4.1 ne supprimera plus le fichier, mais conservera en mémoire le numéro de la dernière version ayant fait un update.