[64Bit] Wow6432node : Comment gérer la base de registre

Bonjour à tous,

J'ai une application full .Net, je livre un setup MSI (targetplatform x86) créé avec l'assistant de visual studio.
Avec ce setup, lors de l'installe je stocke le path d'installation dans HK_LOCAL_MACHINE/SOFTWARE/XXX/YYY.

Sous 64 bit, il s'installe dans /Program files (x86)/.
Jusque là pas de probleme.

Mais dans regedit il set la clé dans:
HK_LOCAL_MACHINE/SOFTWARE/Wow6432node/XXX/YYY.

Aiie...

Depuis une DLL 'proxy', j'essaye de récupérer le path d'installe de la manière suivante:

Code:

---

1 2 3 4

RegistryKey key = Registry.LocalMachine.OpenSubKey(@"Software\XXX\YYY"); string s = Convert.ToString(key.GetValue(@"InstallPath", "")); key.Close(); return s;

---

Mais sous 64 bit key est null...
Car Software\XXX\YYY n'existe pas, en effet il se trouve dans Software\Wow6432node\XXX\YYY


Comment gérer ce cas de figure "proprement" ?

Je croyais que Windows géré ca tout seul, il faisait croire aux application 32 bit que Software se trouve dans wow6432node ? // à confirmer


Merci de votre aide

Bon la première solution c'est:
- si key est null, alors chercher dans "wow6432node" mais c'est un peu crade comme solution...

Si ton application est compilée en x86, c'est normal qu'elle atterrisse dans Wow64. Ce qui est plus surprenant c'est que ta DLL n'atterrisse pas dedans. C'est une DLL x64 ?

KooKiz
Merci,
La dll 'proxy' fait partie du même projet que le setup, je la 'livre' aux autres developpeurs afin qu'il puisse démarrer mon application.

Le projet est compilé en mixed platform (j'ai essayé de compiler la dll proxy en Any Cpu, .Net... mais même résultat).
Je livre le setup en X86
Je livre ma DLL 'proxy faisant partie du même projet, afin que les dev l'integre dans leur propre projet (aussi x86)

Peut tu me confirmer une chose:
Si depuis ma DLL .Net (mixed platform), j'essaye d'accéder à HLM/SOFTWARE sur un OS x64... il va chercher de facon transparente dans Wow6432node ? Ou suis je obliger de specifier "Wow6432node" dans le path de regedit ?

j'ai un peu triché pour mon test sur X64, j'ai installé mon setup, par contre j'utilise une Application de test qui utilise ma dll 'proxy', que je copie / colle sur le bureau...
Je ne vois pas pourquoi ma dll / app test seraient considérées comme une étant x64....

Mais je suis novice dans cette problématique

Un schéma sera plus parlant:


'Application quelquonc.exe' -> Appel à ma DLL 'proxy' -> cette DLL se charge de récupérer dans regedit l'InstallPath de mon application -> Shellexecute de 'MonApplication.exe'

Ah je viens de voir que dans clique droit propriété sur le projet, dans l'onglet généré on peut choisir:
Any CPU
X86
X64

Donc si je force ma DLL 'proxy' a être X86... ca devrait aller ?

Bon Ok c'etait bien les variables de compilation du projet à mettre en X86 et non en Any CPU

Le probleme vient du fait que le MSI fournit par VS gérere spécifiquement une install par architecture (en l'occurence pour moi juste X86), donc le setup enregistre dans le registre 32 alors que le code par contre est exécuté en Any CPU (donc s'exécute en 64bit je suppose sous un OS 64).

La solution c'est donc de forcer la DLL a être en X86 ! (je pense que c'est la solution la plus élégante...)

Any CPU --> ton appli s'executera en tant que 32bits sur un Windows 32 bits et en tant que 64 bits sur un Windows 64bits
X86 --> tu forces le 32 bits.L'appli tourne en mode émulation sur une plateforme 64 bits.
X64 --> tu forces le 64 bits. Tu auras une erreur si tu executes l'appli sur une plateforme 32 bits.

Ton problème vient du fait que la clef de registre se place dans HK_LOCAL_MACHINE/SOFTWARE/Wow6432node.
Sur une plateforme 64 bits tu devrais la mettre à l'emplacement normal des clefs d'un Windows 64 bits. Et sur une plateforme 32 bits tu devrais la mettre à l'emplacement normal des clefs d'un Windows 32 bits. Compilé avec Any CPU, ta dll irait chercher automatiquement au bon endroit.

Sinon il faut mettre dans ta dll un bout de code qui detecte la plateforme (32 ou 64) et va chercher la clef au bon endroit.

Citation:

---

Envoyé par alavoler

La solution c'est donc de forcer la DLL a être en X86 ! (je pense que c'est la solution la plus élégante...)

---

Le problème c'est qu'un process en 64 bits (par exemple, une appli compilée avec Any CPU) ne pourra pas utiliser ta dll.

The_badger_man
Tu es sur de ton coup ?

Une appli .Net 64bit ne peux pas exécuter du .Net 32bit de façon transparente ? hum... (je te fais confiance, vu que je n'y connais rien)

Peux tu répondre à ca :
Pour une App de test .Net et une DLL 'proxy' .Net, avec mon code d'origine (je récupère simplement '/Software/XXX/YYY') sous OS 64
- App .Net 64 qui appel la DLL 32.Net : ca s'exécute ? qu'elle clé regedit récupère la dll 32: le registre 32, ou par 'héritage du 64' la valeur standard du registre 64 ?

même question pour:
- App 32 bit, dll 64



Pour les deux autres cas je pense pouvoir y répondre:
- App32, dll32: ca s'exécute, et il va dans le registre 32
- app64, dll64, ca s'exécute, et il va dans le registre 64

Bon de toute façon il faudra que je test un de ces 4, et je posterai le résultat ici

Citation:

---

Envoyé par alavoler

The_badger_man
Tu es sur de ton coup ?

---

Oui, The_badger_man a raison.