Skip to content

[BUG] PMLite 3.4.0 package installs binaries stamped 3.3.0 #2113

Description

@SalmanRajwani

Component

Lite

Performance Monitor Version

3.4.0 package; installed binaries report 3.3.0

SQL Server Version

N/A

Windows Version

Windows 11

Describe the Bug

After installing the Performance Monitor Lite 3.4.0 package, the package metadata reports 3.4.0 but the installed EXE/DLL binaries still report 3.3.0.

Steps to Reproduce

  1. Install PerformanceMonitorLite-3.4.0-full.nupkg / 3.4.0 Lite setup.
  2. Check package metadata / sq.version.
  3. Check file version metadata for PerformanceMonitorLite.exe and PerformanceMonitorLite.dll.

Expected Behavior

The 3.4.0 package should install binaries stamped as 3.4.0.

Actual Behavior

The package metadata reports 3.4.0, but the installed app binaries report 3.3.0 / 3.3.0.0.

Error Messages / Log Output

No application log output. This was verified from package metadata and file version metadata.

Additional Context

This does not appear to be an old shortcut target. The shortcut points to the current install folder.

Activity

  1. erikdarlingdata commented on Aug 7, 2026

    @erikdarlingdata
    Owner

    Confirmed, and thank you — this was verifiable straight from the tags: the 3.4.0 release bump updated <Version> (which names the package) in each app project but missed the three hand-pinned stamp properties (AssemblyVersion / FileVersion / InformationalVersion), which stayed at 3.3.0. Every earlier release had moved all four together; this one didn't, and the same skew exists in the Darling projects too.

    Two things worth knowing on your side:

    1. Your installed code is genuinely 3.4.0. The package contents are built from the 3.4.0 tag — only the version stamps on the binaries lie. Nothing to reinstall, no behavior difference.
    2. The fix (Version stamps derive from <Version> — 3.4.0 shipped binaries stamped 3.3.0.0 #2116) deletes the pinned properties so all stamps derive from the one <Version> line at build time — this class of skew structurally can't recur. Correctly-stamped binaries ship with the next release.
  2. erikdarlingdata commented on Aug 7, 2026

    @erikdarlingdata
    Owner

    Correction to my "no behavior difference" above — review turned up a real consequence: the in-app update check compares the entry assembly's version (the stale 3.3.0.0 stamp) against the latest release tag, so your install would keep offering the 3.4.0 update you already have. Harmless to accept (it reinstalls the same code), annoying until the next release ships the fixed stamps. Everything else stands.

  3. erikdarlingdata commented on Aug 7, 2026

    @erikdarlingdata
    Owner

    Fix merged to dev via #2116 — all version stamps now derive from the one <Version> line per project, so this skew structurally can't recur. Correctly-stamped binaries ship with the next release; until then the only symptom is the update-check nag described above. Thanks for the report — it also flushed out that the stale stamp was breaking the in-app update check, which nobody had connected.

  4. added a commit that references this issue on Aug 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions