Reported by: @mvandere on #31 (during testing of #37 against the 1.3.0 release ZIP)
the CLI included with the 1.3.0 build, says it's 1.2.0
Root cause
`PrintVersion` in `src/CLI/DX.Comply.CLI.Options.pas` emits a hardcoded literal:
```pascal
procedure TCliOptions.PrintVersion;
begin
Writeln('DX.Comply v1.3.0');
end;
```
The DPROJ's `VerInfo_Keys` are at `1.3.0.0` (and were updated for the release), but the hardcoded string in the source was not bumped at the same time. The 1.3.0 release ZIP therefore shipped with a CLI that self-reports as 1.2.0. On `main` the string is now `v1.3.0`, but the same kind of drift will reappear on the next release unless the source of truth is consolidated.
Fix
Read the version from the executable's own VersionInfo so the string can never drift from `VerInfo_Keys`:
```pascal
function GetExeFileVersion: string;
var
LSize, LDummy: DWORD;
LBuffer: TBytes;
LInfo: PVSFixedFileInfo;
LExe: string;
begin
Result := '';
LExe := ParamStr(0);
LSize := GetFileVersionInfoSize(PChar(LExe), LDummy);
if LSize = 0 then Exit;
SetLength(LBuffer, LSize);
if not GetFileVersionInfo(PChar(LExe), 0, LSize, LBuffer) then Exit;
if not VerQueryValue(LBuffer, '', Pointer(LInfo), LDummy) then Exit;
Result := Format('%d.%d.%d.%d',
[HiWord(LInfo^.dwFileVersionMS), LoWord(LInfo^.dwFileVersionMS),
HiWord(LInfo^.dwFileVersionLS), LoWord(LInfo^.dwFileVersionLS)]);
end;
procedure TCliOptions.PrintVersion;
begin
Writeln('DX.Comply v' + GetExeFileVersion);
end;
```
(`Winapi.Windows` is already in scope via the executable; add a `uses System.Win.VersionInfo` only on platforms where the helper isn't in `Winapi.Windows` directly.)
Acceptance criteria
- `dxcomply --version` prints the same x.y.z value that `FileVersion` reports for the .exe.
- Bumping `VerInfo_Keys` automatically also bumps what the CLI prints — the literal in `PrintVersion` is gone.
- Manual test: build, then `dxcomply --version` matches what Windows shows under right-click → Properties → Details → File version.
Related
Reported by: @mvandere on #31 (during testing of #37 against the 1.3.0 release ZIP)
Root cause
`PrintVersion` in `src/CLI/DX.Comply.CLI.Options.pas` emits a hardcoded literal:
```pascal
procedure TCliOptions.PrintVersion;
begin
Writeln('DX.Comply v1.3.0');
end;
```
The DPROJ's `VerInfo_Keys` are at `1.3.0.0` (and were updated for the release), but the hardcoded string in the source was not bumped at the same time. The 1.3.0 release ZIP therefore shipped with a CLI that self-reports as 1.2.0. On `main` the string is now `v1.3.0`, but the same kind of drift will reappear on the next release unless the source of truth is consolidated.
Fix
Read the version from the executable's own VersionInfo so the string can never drift from `VerInfo_Keys`:
```pascal
function GetExeFileVersion: string;
var
LSize, LDummy: DWORD;
LBuffer: TBytes;
LInfo: PVSFixedFileInfo;
LExe: string;
begin
Result := '';
LExe := ParamStr(0);
LSize := GetFileVersionInfoSize(PChar(LExe), LDummy);
if LSize = 0 then Exit;
SetLength(LBuffer, LSize);
if not GetFileVersionInfo(PChar(LExe), 0, LSize, LBuffer) then Exit;
if not VerQueryValue(LBuffer, '', Pointer(LInfo), LDummy) then Exit;
Result := Format('%d.%d.%d.%d',
[HiWord(LInfo^.dwFileVersionMS), LoWord(LInfo^.dwFileVersionMS),
HiWord(LInfo^.dwFileVersionLS), LoWord(LInfo^.dwFileVersionLS)]);
end;
procedure TCliOptions.PrintVersion;
begin
Writeln('DX.Comply v' + GetExeFileVersion);
end;
```
(`Winapi.Windows` is already in scope via the executable; add a `uses System.Win.VersionInfo` only on platforms where the helper isn't in `Winapi.Windows` directly.)
Acceptance criteria
Related