Windows: entire.exe reports version 0.0.0.0 in PE metadata

Problem

On Windows, Get-Command entire and File Explorer Properties show version 0.0.0.0:

PS> Get-Command entire

CommandType     Name         Version    Source
-----------     ----         -------    ------
Application     entire.exe   0.0.0.0    C:\Users\Victor\.local\bin\entire.exe

entire version reports correctly — the issue is that the Windows PE (Portable Executable) VERSIONINFO resource is not embedded in the binary. Windows reads version from this resource, not from Go's ldflags. Since Go doesn't embed it by default and the GoReleaser config doesn't generate one, Windows falls back to 0.0.0.0.

Root cause

The version is stamped via ldflags into versioninfo.Version (line 25 of .goreleaser.yaml), which works for entire version at runtime. But Windows reads the VS_FIXEDFILEINFO / StringFileInfo structures from the PE resource section — a completely separate mechanism that requires a compiled .syso or .rc resource linked into the binary at build time.

Possible fixes

Option A: goversioninfo (proven in production)

github.com/josephspurrier/goversioninfo — used by NetBird in production. Their approach (from .github/workflows/release.yml):

- name: Install goversioninfo
  run: go install github.com/josephspurrier/goversioninfo/cmd/goversioninfo@b66839b

- name: Generate windows syso amd64
  run: goversioninfo -product-name "Entire CLI"
       -copyright "Copyright (c) Entire, Inc."
       -ver-major ${{ steps.semver_parser.outputs.major }}
       -ver-minor ${{ steps.semver_parser.outputs.minor }}
       -ver-patch ${{ steps.semver_parser.outputs.patch }}
       -ver-build 0
       -file-version ${{ steps.semver_parser.outputs.fullversion }}.0
       -product-version ${{ steps.semver_parser.outputs.fullversion }}.0
       -o cmd/entire/resources_windows_amd64.syso

- name: Generate windows syso arm64
  run: goversioninfo -arm -product-name "Entire CLI" ...
       -o cmd/entire/resources_windows_arm64.syso

For GoReleaser, this can go in before.hooks or a CI step before goreleaser release. One invocation per arch.

Pros: proven at scale (NetBird ships it), supports icon embedding, manifest embedding, CLI flags for version override.
Cons: one invocation per arch (not a real cost — two extra lines).

Option B: go-winres

github.com/tc-hib/go-winres — newer tool, convention-based. Place winres/winres.json next to main.go, run go-winres make --product-version=X.Y.Z, and it generates both arch .syso files in one pass.

Can be integrated as a GoReleaser before.hooks entry:

before:
  hooks:
    - go install github.com/tc-hib/go-winres@latest
    - go-winres make --dir cmd/entire --product-version={{.Version}} --file-version={{.Version}}
    - go-winres make --dir cmd/git-remote-entire --product-version={{.Version}} --file-version={{.Version}}

Pros: generates both amd64+arm64 .syso in one call, cleaner JSON config.
Cons: less widely adopted than goversioninfo.

Option C: GoReleaser Pro native support

Worth checking if GoReleaser Pro has built-in resource_compiler or similar. The project already uses GoReleaser Pro.

Additional benefit

Both tools can also embed an RT_MANIFEST (DPI awareness, UAC asInvoker execution level), which is best practice for CLI tools on Windows.

Affected binaries

• entire.exe
• git-remote-entire.exe

Start with .goreleaser.yaml, especially the ldflags around line 25, and trace how the Windows builds for entire.exe and git-remote-entire.exe are produced. Compare the resource-generation options described in the issue, then verify that released Windows binaries expose the intended VERSIONINFO metadata instead of 0.0.0.0 in File Explorer or Get-Command.