---
source_files:
  - DataPRO/Modules/InstallerCustomActions/LocalSQLDB/Properties/AssemblyInfo.cs
  - DataPRO/Modules/InstallerCustomActions/LocalSQLDB/Properties/Settings.Designer.cs
generated_at: "2026-04-16T04:45:12.575157+00:00"
model: "Qwen/Qwen3-Coder-Next-FP8"
schema_version: 1
sha256: "02e9f5ae4a239fa1"
---

# Properties

## Documentation: LocalSQLDB Module

### 1. Purpose  
This module provides configuration and metadata for a local SQL Server database component used during Windows Installer custom actions in the DataPRO system. It does not contain executable installation logic itself but defines assembly identity and application-scoped settings that support database deployment operations—specifically, naming conventions and paths for database files (`.mdf`, `.ldf`) and registry keys. Its role is to centralize configuration constants used by other installer custom actions that interact with SQL Server Express or LocalDB instances.

### 2. Public Interface  
This module exposes **no public types or methods**. It defines only internal configuration and assembly metadata:

- **`LocalSQLDB.Properties.Settings`** (internal, sealed class)  
  Auto-generated settings class (via `Settings.Designer.cs`) providing read-only, application-scoped configuration values. Accessible via `Settings.Default`.  
  Properties:
  - `string RegistryDataPROExe` → `"DataPRO.exe"`  
    Registry key path or executable name used to locate the DataPRO application.
  - `string ApplicationSettings` → `"applicationSettings"`  
    Subkey or section name under which application settings are stored.
  - `string LocalDbFolder` → `"db"`  
    Relative folder name where database files are stored.
  - `string Mdf` → `".mdf"`  
    File extension for primary database files.
  - `string LogLdf` → `"_log.ldf"`  
    Suffix used for transaction log files (note: full filename is constructed externally as `<basename><LogLdf>`).
  - `string DataPRO` → `"DataPRO"`  
    Base name for database files (e.g., `DataPRO.mdf`, `DataPRO_log.ldf`).

> **Note**: The `Settings` class is `internal` and not part of the public API surface. Its properties are only consumed by other modules in the same assembly or via reflection.

### 3. Invariants  
- All settings are **application-scoped** and **read-only at runtime** (no user-scoped or mutable settings defined).  
- File naming convention: Database files follow the pattern `<DataPRO><Mdf>` and log files follow `<DataPRO><LogLdf>` (e.g., `DataPRO.mdf`, `DataPRO_log.ldf`).  
- `LocalDbFolder` is a relative subdirectory path; absolute paths are not used.  
- The assembly is **not COM-visible** (`ComVisible(false)`), indicating it is intended for .NET-only consumption.  
- Version is fixed at `1.0.0.0` (both `AssemblyVersion` and `AssemblyFileVersion`).

### 4. Dependencies  
- **Depends on**:  
  - `System.Configuration` (for `ApplicationSettingsBase`, attributes like `ApplicationScopedSettingAttribute`)  
  - `System.Runtime.CompilerServices`, `System.CodeDom.Compiler`, `System.Diagnostics` (for code generation attributes)  
- **Used by**:  
  - Other modules in the `InstallerCustomActions` solution folder (e.g., custom action DLLs that perform database installation/uninstallation).  
  - Likely consumed by installer projects (e.g., WiX, MSI) that reference this assembly for database file path resolution.  
- **No external runtime dependencies** beyond .NET Framework 4.0+ (inferred from runtime version in `Settings.Designer.cs`).

### 5. Gotchas  
- The `LogLdf` setting is a **suffix**, not a full filename—consumers must prepend the database name (e.g., `DataPRO` + `"_log.ldf"` = `"DataPRO_log.ldf"`). Confusing this with a full extension (e.g., assuming `".ldf"`) is a common mistake.  
- `RegistryDataPROExe` is named misleadingly: it holds `"DataPRO.exe"` (a filename), not a registry path. Actual registry key construction is handled elsewhere.  
- The `Settings` class is auto-generated and **should not be manually edited**—changes will be overwritten on regeneration.  
- No validation logic is present in this module; invalid file paths or naming conflicts are not caught here.  
- The assembly has no public entry points (e.g., no `CustomAction` classes defined here)—it is purely a configuration container.