Windows 2003 Server x64 et le registre

Bonjour tout le monde,

ce thread est à mi-chemin avec d’autres forums, donc j’espère qu’il déborde pas trop…

Je découvre Windows Server 2003 x64 depuis quelques jours. J’y fais des tests pour y passer bientôt définitivement (de l’appli Web sous IIS 6, et du SQL Server 2005). J’ai rencontré des soucis avec le registre, géré différemment entre les versions 32 et 64 bits de Windows.

Dans l’une des applications à déployer en x64, j’ai une DLL .NET exposée en COM, afin d’être consommable par quelques vieilles applis ASP 3.0 VBScript. Mon MSI qui déploie cette DLL crée quelques clés de registre à des endroits très précis, clés qui seront lues et utilisées par ma DLL lors de son exécution.

Maintenant arrive mon problème: mon MSI crée une clé au chemin suivant:
HKLM\SOFTWARE\MyCompany\MyNode

En réalité la gestion spécifique des applis 32 et 64 bits (explications) a redirigé cette clé ici :
HKLM\SOFTWARE\Wow6432Node\MyCompany\MyNode

Hors ma DLL .NET étant nativement exécutée en x64, lorsque mon appli va lire cette clé, elle n’est pas redirigée vers la seconde, mais vers la première, inexistante…

J’ai cru que c’était à cause de MSIEXEC.EXE exécuté par défaut en 32 bits, donc en ligne de commande j’ai à nouveau réinstallé mon MSI en passant par le MSIEXEC.EXE 64 bits, mais ça ne change rien.

Je suis un peu dans l’impasse, ne sachant pas si mes clés de registre sont correctement crées, ou correctement lues…

Bon, x64 et .net, c’est un peu mon domaine, je vais tenter de t’aider.

Ton appli ASP, je présumes qu’elle tourne en 32bits, non ? Si c’est le cas, normalement, ta dll devrais être executée aussi en 32bits (si elle est chargée dans le même process). Tu ne peux avoir de process “hybrides” sous x64. Soit c’est full 32, soit c’est full 64. Si tu n’est pas sur, lance process explorer, il te dira quel est l’état (64/32) du process.

Est-tu le developpeur de la dll .net ? de l’appli ASP ?

Sache que tu as des moyens de forcer l’execution d’un code en 32 bits s’il appelle des libs natives qui sont pas dispos en 64 (auquel cas, l’appli crash en 64bits), avec une option de compil ( /platform:x86 ), ou si tu récupères l’executable déja compilé, avec l’outil corflags.

Merci de ta réponse Tzim, mais j’ai, à priori, trouvé d’où pouvais venir le problème.

Mon projet de déploiement précise « x86 » en plateforme, et malgré le fait qu’il soit exécuté par MSIEXEC x64 il doit aller écrire dans le node du registre x86… :stuck_out_tongue:
La bonne pratique étant de déployer un MSI x86 et un MSI x64, avec le bon flag « platform » dedans.
Peut-être existe-t-il le moyen de « merge » les 2 MSI ensuite, pour n’avoir qu’un seul fichier à déployer.

Bref j’ai trouvé réponse ici, mais j’ai pas encore pu tester ça :
http://www.64advantage.com/files/64-bit%20…20Issue%208.pdf

Sinon ma DLL exposée COM est bien exécutée en x64 puisque pour le moment, lors de mes tests, elle a directement été utilisée dans un appli ASP.NET qui tourne en x64. Le second morceau était de l’utiliser en COM via ASP VBScript, mais j’y suis pas encore…

[quote=« Tzim, post:2, topic: 29574 »]Est-tu le developpeur de la dll .net ? de l’appli ASP ?

Sache que tu as des moyens de forcer l’execution d’un code en 32 bits s’il appelle des libs natives qui sont pas dispos en 64 (auquel cas, l’appli crash en 64bits), avec une option de compil ( /platform:x86 ), ou si tu récupères l’executable déja compilé, avec l’outil corflags.[/quote]

Oui je suis le développeur de la .DLL et de l’appli ASP (VBScript).
Merci du tuyau pour l’option de compil :stuck_out_tongue:

Petit à petit je découvre quand même que le x64 est plus subtil qu’il n’y parait…