--- source_files: - DataPRO/Modules/InstallerCustomActions/RegAddProductCode/Properties/AssemblyInfo.cs - DataPRO/Modules/InstallerCustomActions/RegAddProductCode/Properties/Settings.Designer.cs generated_at: "2026-04-16T04:44:25.291700+00:00" model: "Qwen/Qwen3-Coder-Next-FP8" schema_version: 1 sha256: "c5bd9c265d48c4b1" --- # Properties ## Documentation: `RegAddProductCode` Module ### 1. Purpose This module is a .NET-based Windows Installer custom action designed to register a product code in a specific Windows Registry location—primarily to support Windows Installer’s `SecureRepairPolicy` mechanism. It reads configuration settings (including registry key paths and a product code GUID) and writes the product code to the `SecureRepairWhitelist` registry subkey under the Windows Installer policies path. Its role is to ensure that a given product remains whitelisted for secure repair operations, a security feature introduced in Windows Installer to restrict which products may be repaired without elevated privileges. ### 2. Public Interface No public *executable* API (e.g., `CustomAction` entry points) is visible in the provided source files. However, the module exposes the following *configuration* types and members: - **`RegAddProductCode.Properties.Settings.Default`** - **Type**: `RegAddProductCode.Properties.Settings` (singleton instance) - **Behavior**: Provides application-scoped read-only access to configuration values defined in `Settings.settings`. This is the only public surface exposed via the generated settings class. - **`RegAddProductCode.Properties.Settings.InstallerKey`** - **Type**: `string` - **Default Value**: `"SOFTWARE\\Policies\\Microsoft\\Windows\\Installer"` - **Behavior**: Returns the base registry key path for Windows Installer policies. - **`RegAddProductCode.Properties.Settings.MissingKey`** - **Type**: `string` - **Default Value**: `"No key at {0}"` - **Behavior**: A format string template, likely intended for logging or error messages when a registry key is not found. - **`RegAddProductCode.Properties.Settings.ProductCode`** - **Type**: `string` - **Default Value**: `"{C4889149-0CAF-44C1-B226-8F6E73684DF4}"` - **Behavior**: Returns the product code GUID to be added to the whitelist. - **`RegAddProductCode.Properties.Settings.SecureRepairPolicy`** - **Type**: `string` - **Default Value**: `"SecureRepairPolicy"` - **Behavior**: The name of the registry value used to enable/disable secure repair policy. - **`RegAddProductCode.Properties.Settings.SecureRepairWhitelistKey`** - **Type**: `string` - **Default Value**: `"SOFTWARE\\Policies\\Microsoft\\Windows\\Installer\\SecureRepairWhitelist"` - **Behavior**: Returns the full registry path where whitelisted product codes are stored. > **Note**: The actual custom action logic (e.g., `Install`/`Commit`/`Rollback` methods or `[CustomAction]`-attributed functions) is *not present* in the provided files and must reside in other source files (e.g., `CustomAction.cs`). This documentation is limited to what is exposed in the provided `AssemblyInfo.cs` and `Settings.Designer.cs`. ### 3. Invariants - The `ProductCode` setting is expected to be a valid GUID string (format `{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}`), though no runtime validation is evident from the settings definition. - The registry paths (`InstallerKey`, `SecureRepairWhitelistKey`) are hardcoded and must be valid Windows Registry paths (double-escaped backslashes in source reflect single escaping in the runtime string). - Settings are *application-scoped* and read-only at runtime (no setters exposed); they are fixed at compile time. - The `Settings.Default` instance is thread-safe via `ApplicationSettingsBase.Synchronized()`. ### 4. Dependencies - **Runtime Dependencies**: - `System.Configuration.dll` (for `ApplicationSettingsBase`, `ApplicationScopedSettingAttribute`, etc.) - `System.dll` (for core types like `string`, `Attribute`, etc.) - **Build/Deployment Dependencies**: - This assembly is likely referenced by a Windows Installer (MSI) project or custom action project (e.g., WiX, InstallShield) as a custom action DLL. - It depends on the Windows Installer service being available at runtime (to interact with registry policy keys). - **Inferred Consumers**: - An external installer project (e.g., `.wixproj`, `.vdproj`) that invokes this assembly as a custom action during installation/repair. - The `RegAddProductCode` assembly itself is not referenced programmatically by other modules in the provided source. ### 5. Gotchas - **Missing Custom Action Entry Point**: The provided files contain *no* `CustomAction` method definitions (e.g., no `[CustomAction]` attributes or `Session`-based logic). The actual behavior (reading settings and writing to registry) is not observable here—this module’s *purpose* is inferred from naming and settings, but implementation details are absent. - **Hardcoded Product Code**: The `ProductCode` is fixed at compile time (`{C4889149-0CAF-44C1-B226-8F6E73684DF4}`), meaning this assembly is not reusable for other products without recompilation. - **Registry Path Escaping**: The `\\` in string literals (e.g., `"SOFTWARE\\\\Policies..."`) are *literal* backslashes in the compiled string (due to C# escaping), which is correct for registry paths, but could be confusing if misread. - **No Error Handling in Settings**: The settings class provides no mechanism to validate or handle missing registry keys—error handling (e.g., for `MissingKey`) must be implemented elsewhere (e.g., in the custom action logic not shown). - **No Versioning Strategy**: Assembly version is `1.0.0.0` for both `AssemblyVersion` and `AssemblyFileVersion`, suggesting minimal version discipline—could cause issues in side-by-side deployments. - **None identified from source alone.** (Additional gotchas would require inspecting the actual custom action implementation.)