Salut,
 
Je viens de faire un MSI avec Wise Package Studio (Winrar 3.80 + licence + config perso).
 
Le MSI est déployé par GPO en mode Ordinateur, sur un OU qui contient ma machine de test.
 
Le MSI s'installe au reboot.
 
Le raccourci (de test pour visu de la bonne installation du soft) n'est pas sur le bureau.
Mais, dès que je fais un clic droit sur un dossier/fichier, le MSI s'installe !
 
Même chose si je me logue avec un autre utilisateur, une fenêtre termine l'installe pour cete session, et etc.
 
Pour j'ai fait un déploiement par machine, et ce comportement correspond à un dep. par utilisateur/"à la demande".
 
 
Quelqu'un a une idée ?

c'est normal, il s'agit d'un 'self repair' lancé par msiexec lors de la première exécution du programme sur un profil utilisateur.  
 
cela génère alors tout ce qui doit être installé pour un profil utilisateur (cle de registre utilisateur, raccourcis pour le profil, raccourcis quicklaunch, données dans Application Data, etc). cela finalise l'installation - côté utilisateur

pourquoi le self-repair :
http://en.wikipedia.org/wiki/Windo [...] #Key_paths
 
c'est à cause d'un keypath manquant que msiexec lance ce processus et finalise ce qui doit etre ajouter au profil utilisateur

Tutoriel :
http://forum.hardware.fr/hfr/syste [...] et_9_1.htm

Je vais lire de suite ! Merci.
 
 
Donc, on peut éviter ce comportement, en corrigeant/faisant ce qu'il faut ?

Je ne comprends pas si ce chemin manquant l'est dans le MSI. Si oui,une propriété manque pour un des fichiers contenus dans le MSI ?
 
Où est-ce un chemin sur le PC de destination qui n'existe pas ? Si c'est ce cas, pourquoi n'a t'il pas été installé lors de déploiement du MSI quand le PC a booté, avant login ?
 
Je nage..

attention un key path est comme le dit l'article un fichier ou une cle de registre et non pas un chemin
 
en gros dans tes tables msi tu marques une cle ou un fichier comme etant keypath.  
Quand le msi s'install il se met en place et check si le keypath existe (cad si le fichier est present ou si la cle de registre existe).
 
Si non a l'ouverture de session il execute un selfrepair du component concerné.
 
Désolé pour mes anglisismes mais j'ai lu plus de doc anglaise sur msi que francaise.
 
Pour information il y a des livres blans la dessus
 
dans package studio tu as des tests pour valider ton msi car parfois des keypath sont mis involontairement lors de snapshot.
 
par contre ce selfrepair est super interessant pour claquer du hkcu quand tu maitrise l'outil (exemple office lors d'un deploiement au premier lancement vient renseigner le hkcu)

au fait j'en remets une couche avec appdeploy mais c'est toujours utile
http://www.appdeploy.com/
y a meme des video ;-)

et puis toujours http://nexus.realtimepublishers.com/DGWITSA.htm

J'ai refait mon MSI cette fois ci sous un XP Pro (et plus W2K).
 
J'ai toujours la même chose.
 
Est-il possible de lister ces cles ou fichiers marqués comme keypath ?
Je désire savoir ce qui manque.
 
Car même avec un compte utilisateur que je n'ai jamais utilisé sur cette machine (virtuel, j'utilise les snapshots pour revenir sur une machine vierge en 1 clic), et donc qui charge HK_USERS/.DEFAULT (et qui contient les clefs), ça le fait aussi.

 
Je me bats pour ajouter une clef de registre dans HKCU, sans succès.
J'ai trouvé une explication sur le net mais qui ne fonctionne pas chez moi.
 
As-tu une piste ? Un tuto réellement détaille et fonctionnel ?
 

Ca fait maintenant plus de deux ans que j'ai pas fait joujou avec il me faudrait remettre les mains sur un wyse et prendre le temps d'en refaire un simple.
 
Faut que je regarde si j'ai pas un exemple qui traine sur mon poste a la maison.
http://www.appdeploy.com/faq/detail.asp?id=52
http://en.wikipedia.org/wiki/Windows_Installer
 
wise ne te fait pas deja ca ?
il me semblait que dans les dernières versions il était assez intelligent pour le proposer dans sa création de msi.
 
Sinon l'idée etait de faire une sous feature HKCU avec un component CurrentUser.
ce component a pour key path une cle de registre hkcu. Il contient toutes les clés HKCU.
De mémoire pour que le controle s'opère et me répare cette feature j'ajoutais à cette feature HKCU le component avec l'exe du programme et le shortcut.
 
L'idée était que lorsqu'il lancait l'application l'executable etait check ainsi que sa feature (et donc mes clé HKCU).
Comme les cle HKCU manquait il reparait ma feature HKCU en entier (et pas tout le programme pour pas réparer 300Mo par exemple.