如何实现32位与64位应用共享HKLM注册表设置？

The core issue here is Windows' WOW64 registry redirection—32-bit apps get routed to HKLM\SOFTWARE\WOW6432Node, while 64-bit apps use the standard HKLM\SOFTWARE path. To avoid duplicating your license key, here are clean, maintainable solutions:

Option 1: Explicitly Target a Single Registry View #

Pick one registry location (either 64-bit or 32-bit) and modify both applications to access that specific view, regardless of their own bitness. This ensures both read/write to the exact same key.

Example: Use the 64-bit HKLM Path #

• 32-bit Office Add-In: Bypass WOW64 redirection by specifying RegistryView.Registry64 when opening the registry key. This lets your 32-bit add-in access the 64-bit registry directly:

  using (var baseKey = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64))
  using (var productKey = baseKey.OpenSubKey(@"SOFTWARE\YourCompany\YourProduct", true))
  {
      // Write license key
      productKey.SetValue("LicenseKey", yourLicenseString);
      // Or read it
      var license = productKey.GetValue("LicenseKey") as string;
  }
  

• 64-bit Standalone App: While it naturally accesses the 64-bit registry, explicitly specifying RegistryView.Registry64 makes your code future-proof (in case you ever compile it as 32-bit):

  using (var baseKey = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64))
  using (var productKey = baseKey.OpenSubKey(@"SOFTWARE\YourCompany\YourProduct", true))
  {
      // Same read/write logic as the add-in
  }
  

If you prefer the 32-bit WOW6432Node path instead, just replace RegistryView.Registry64 with RegistryView.Registry32 in both snippets.

Option 2: Switch to HKCU (Per-User Licensing) #

If your license model allows per-user activation (instead of machine-wide), storing the key in HKEY_CURRENT_USER\SOFTWARE\YourCompany\YourProduct eliminates redirection issues entirely. HKCU doesn’t apply WOW64 redirection for software keys—both 32-bit and 64-bit apps will use the exact same path.

This is often the simplest approach because it avoids needing admin rights (writing to HKLM requires elevated privileges). Here’s the code for both apps:

using (var productKey = Registry.CurrentUser.OpenSubKey(@"SOFTWARE\YourCompany\YourProduct", true))
{
    // Read/write license key here
}

Option 3: Synchronize Registry Paths (Last Resort) #

If you absolutely must use HKLM and can’t modify the registry view logic, you can sync the license key between the two paths. For example:

• When either app writes the key, it writes to both the 64-bit and 32-bit locations.
• When reading, check both paths and use the most recent value (or prioritize one over the other).

This is less ideal because it introduces duplication and potential consistency bugs, so only use this if Options 1 or 2 aren’t feasible.

Critical Notes #

• Permissions: Writing to HKLM requires admin rights. If your apps don’t run elevated, go with HKCU.
• Testing: Validate your solution on both scenarios: 32-bit Office on 64-bit Windows, and 64-bit Office on 64-bit Windows.
• Consistency: Stick to one approach to keep your codebase maintainable and avoid unexpected behavior.

内容的提问来源于stack exchange，提问作者David Thielen