inno setup ("downgrader" la version de MSVBVM60.DLL)

Bonjour,

J'ai un problème avec l'une de mes applications. Suite a quelques recherche, il semblerait que ce problème soit causé par la version de MSVBVM60.DLL présente sur les Windows 7 et + (info trouvé ici).

Bref je voudrais que mon installateur remplace la version présente sur le poste (version 6.0.98.15, notamment mon PC, Windows 7-64) par une version INFÉRIEUR (la 6.0.98.02).

J'ai donc cette DLL (la bonne version) dans un dossier, je dit à inno setup de la récupérer et d'ignorer la version présente dans le système pour installer celle qui vas bien.

Code:

---

Source: E:\Install\Commun\MSVBVM60.DLL; Components: COM; DestDir: {sys}; Flags: regserver uninsneveruninstall ignoreversion restartreplace 32bit

---

Sauf erreur de ma part, la balise "ignoreversion" devrait faire ça. Or quand j'exécute mon setup, c'est toujours cette saleté de version baugée qui est présent...
:arf:

J'ai bien compris que je pouvais remplacer "manuellement" ce fichier dans mon système. Sauf que cette application doit être livrée à des utilisateurs "de base" (et je ne me voie pas leur demandé de modifier à la mano des fichiers du système)

HELP ME SVP, je commence à avoir mal à la tête a force de la frapper contre mon bureau :mouarf:

Amicalement

Salut Polak77,

As-tu déjà testé ton application sur un Windows 7 avec l'ancienne version de msvbvm60.dll ?
Nan parce que si ça ne résoud pas le problème, pas la peine de se prendre la tête plus que ça !

Si tu as déjà fait ce test et que cela résoud vraiment ton probl'ème, alors les problèmes commencent. Déjà je ne suis pas sûr que remplacer la DLL officielle par une autre soit la bonne méthode. Maintenant si la version la plus récente ne propose rien de plus que des bugs, alors effectivement il est envisageable de la remplacer (mais comment être sûr de son coup??).


Sinon, pour en revenir a ton problème d'installation de fichier avec inno setup, tu dis que le PC où tu installes ton programme est un 64 bit.
Peux-tu vérifier que la DLL ne s'est pas installée dans C:\Windows\System32 au lieu de C:\Windows\SysWOW64 ? Ca ne devrait pas être le cas, mais on ne sait jamais (surtout que tu as bien précisé le flag 32bit)...

Bonjour,

Désolé de ne répondre que maintenant (le mail m'informant de la réponse c'était noyé dans des spams :oops:)

Je confirme que downgrader cette DLL ne suffisait pas :cry: ...

Du coup je sait pas trop comment corriger/contourner le problème :calim2: . Je cherche, si je trouve une solution autre que "attendre une maj de Ms" j'essayerais de penser à la poster ici ;)...

Si non concernant l'installation de la DLL. Suite à de multiple tests, il semblerais* que si cette DLL est dans le dossier d’exécution de l'application (typiquement dans le même dossier que l'exe) alors c'est celle du dossier d’exécution qui est utilisée et non celle du dossier de Windows. Donc remplacer la DLL de Windows n'est pas obligatoire (ce qui est une bonne chose :ccool: )

* :
il semblerait : je n'ai pas poussé mes tests à leur terme car même en remplaçant manuellement la DLL dans le dossier système de Windows (+ enregistrement) le problème continu d'apparaitre. Moins souvent peut être, mais vue que l'apparition du plantage est inconstant c'est difficile d'en être certain :/

Citation:

---

Envoyé par Polack77

Si non concernant l'installation de la DLL. Suite à de multiple tests, il semblerais* que si cette DLL est dans le dossier d’exécution de l'application (typiquement dans le même dossier que l'exe) alors c'est celle du dossier d’exécution qui est utilisée et non celle du dossier de Windows. Donc remplacer la DLL de Windows n'est pas obligatoire (ce qui est une bonne chose :ccool: )

* :
il semblerait : je n'ai pas poussé mes tests à leur terme car même en remplaçant manuellement la DLL dans le dossier système de Windows (+ enregistrement) le problème continu d'apparaitre. Moins souvent peut être, mais vue que l'apparition du plantage est inconstant c'est difficile d'en être certain :/

---

Si MSVBVM60.DLL a besoin d'être enregistrée, alors le fait de placer une autre version de la DLL dans le même dossier qu'un executable ne devrait pas suffire à utiliser cette dernière. (Sinon, c'est un peu le principe même de l'enregistrement qui me paraîtrai douteux... :aie:)
Mais je peux me tromper...

Comme je l'ai dit, je n'ai pas poussé mes tests très loin en final vue que cela ne corrigerais rien à mon bug (mais je suis plutôt d'accord avec que tu dis Aniki)

il manque le flag allowunsafefiles pour autoriser l'installateur a remplacer un fichier système

Éventuellement aussi le flag promptifolder pour vérifier que l'installateur a bien détecté une version plus récente sur la machine

Cette réponse un peu tardive pour les ceusses qui tomberaient sur ce sujet ;)

OK !

Merci pour ces infos ça me sera utile un de ces jours :D
(bon j'ai pas testé :oops: mais vue que tu semble sur de toi, et que ça me parait très cohérent, je valide ^^)