Hey there! Let's walk through where to store your installer's configuration properties—starting with the registry paths you asked about, then diving into cleaner alternatives that might fit your workflow better.

一、注册表的标准存储位置 #

For Windows installers, there are two standardized registry paths recommended by Microsoft (and fully supported by InstallShield):

• Machine-wide configuration (applies to all users)：HKEY_LOCAL_MACHINE\SOFTWARE\[YourCompanyName]\[YourAppName]\[AppVersion]
  • Heads up: On 64-bit systems, 32-bit apps will have their registry entries redirected to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\[YourCompanyName]\[YourAppName]\[AppVersion]. InstallShield usually handles this automatically, but it's worth verifying if you're building for mixed architectures.
• Per-user configuration (only applies to the current user)：HKEY_CURRENT_USER\SOFTWARE\[YourCompanyName]\[YourAppName]\[AppVersion]
  • This is ideal if your app supports per-user installs, since it doesn't require admin privileges to write to.

Sticking to these paths ensures consistency with Windows conventions, making it easy for future updates to locate and reference existing settings.

二、Simpler, Modern Alternatives to the Registry #

If you want to avoid the registry entirely, here are some cleaner options:

• JSON/XML configuration files：Store settings in a plain-text file like config.json or settings.xml. You can place it either in your app's installation directory (for machine-wide settings) or in the user's %APPDATA%\Roaming\[YourCompanyName]\[YourAppName] folder (for per-user settings). This approach is far more human-readable, avoids registry permission headaches, and makes cross-platform porting easier if you ever need it.
• MSI Property Storage (if using InstallShield's MSI projects)：If you're building an MSI package, you can store configuration values directly in the MSI's Property table. Subsequent updates can leverage MSI's built-in upgrade logic to read these properties seamlessly. Just note this is tied tightly to the MSI framework, so it's less flexible than file-based storage.
• .NET Configuration Files (for .NET apps)：If your software is built with .NET, use the built-in app.config (which becomes [YourApp].exe.config at runtime) or web.config. The .NET framework handles reading/writing these files automatically, and you get bonus features like configuration transformations for different environments.

三、Which Should You Choose? #

• Go with the registry if your app needs deep Windows system integration (e.g., file associations, context menu entries) or if you're following traditional desktop app conventions.
• Opt for JSON/XML files if you want simplicity, portability, or to avoid registry-related complexity—this is the go-to for most modern apps these days.
• Use MSI properties only if your configuration is tightly linked to the installation process itself (e.g., installation directory, feature selection) and you're committed to MSI as your installer format.

内容的提问来源于stack exchange，提问作者Kannon Sama