1

Mon patron vient de Windows 7 et il a essayé d'exécuter un de nos installateurs qui fonctionne parfaitement sous XP. Sous Windows 7, le programme d'installation s'exécute sans donner d'erreur. Cependant, il ne crée pas de clés de registre sous HKEY_LOCAL_MACHINE \ SOFTWARE {Company} {product}. Ces clés sont créées correctement sous XP.Comment puis-je lire le registre dans l'application C# 32 bits de sorte que la redirection du registre fonctionne sur Windows 7 bits

Est-ce que quelqu'un a rencontré ce problème? Je soupçonne que c'est un problème de droits/sécurité, mais je ne suis pas sûr et je n'ai pas Windows 7 à expérimenter.

EDIT

L'ordinateur en question est une machine 64 bits en cours d'exécution 64 bits de Windows. Il s'avère que Windows 7 redirige les applications 32 bits vers HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node {Company} {product}. Le problème est mon code d'application tente d'accéder au registre en utilisant une valeur hardcoded comme ceci:

var t = Registry.GetValue("HKEY_LOCAL_MACHINE\\SOFTWARE\\..., "ValueName", DefaultValue); 

Alors, ma nouvelle question est de savoir comment puis-je accéder au registre de telle sorte que la redirection de registre Windows 9 sera tout simplement travailler?

Répondre

2

Après plus de creuser je suis tombé sur ce link qui décrit les règles d'accès au registre pour les applications .NET. Mon programme avait initialement été ciblé pour "AnyCpu" qui provoque l'application pour cibler le registre 64 bits même si Windows l'a installé sous le Wow6432Node. En définissant la cible sur "x86", mon programme "magiquement" a commencé à accéder au registre sous le Wow6432Node. Allez comprendre!

0
+0

J'ai trouvé la référence ci-dessus avant de la publier, mais elle n'est pas dans .NET. Y a-t-il un moyen d'accomplir en utilisant du code managé? – ejwipp

1

Dans l'API C de Windows cela se fait en définissant le paramètre samDesired dans l'appel RegOpenKeyEx-KEY_WOW64_64KEY. Cela signifie que la recherche de la valeur de Registre sera mappée sur l'entrée 64 bits normale, plutôt que sur celle WOW32Node. Je ne vois pas comment vous obtiendriez cela dans .Net, car la classe Registry ne semble pas supporter ces opérations, mais peut-être est-elle fournie par une classe plus récente?

3

Si vous utilisez .NET 4, vous pouvez également demander que votre accès processus 32 bits (ou 64 bits) la vue 64 bits du registre en utilisant la méthode RegistryKey.OpenBaseKey.

Cf. http://msdn.microsoft.com/en-us/library/microsoft.win32.registrykey.openbasekey.aspx

Voici un exemple qui lit une valeur de la vue 64 bits du registre, même si elle fonctionne dans le cadre d'un processus 32 bits:

var hklm64 = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64); 
var key = hklm.OpenSubKey(@"SOFTWARE\AcmeSoft\AnvilMaker 1.0"); 
var value = (string) key.GetValue("Blacksmith Name"); 

La méthode RegistryKey.OpenBaseKey vous permet également de façon explicite ouvrir une vue 32 bits du registre. C'est utile si vous essayez de faire le contraire et accédez à la vue 32 bits du registre à partir d'un processus 64 bits et vous ne voulez pas ajouter explicitement "Wow6432Node" au chemin du registre. Par exemple, aujourd'hui, j'avais besoin de supprimer un arbre de sous-clé dans les deux les vues 32 bits et 64 bits du Registre. Faire cela dans.NET 4 avec un seul chemin de registre était facile:

foreach(var view in new[] {RegistryView.Registry32, RegistryView.Registry64}) 
{ 
    var hklm = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, view); 
    hklm.DeleteSubKeyTree(@"SOFTWARE\AcmeSoft\SomeKeyWeNoLongerWant", throwOnMissingSubKey: false); 
} 

Sur une version 64 bits de Windows, le code ci-dessus effacera les arbres sous-clés suivants du Registre:

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\AcmeSoft\SomeKeyWeNoLongerWant 
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\AcmeSoft\SomeKeyWeNoLongerWant 

-Adam

Questions connexes