SolutionPersistence product and product version numbers report wrong version

[mthalman]

Microsoft.VisualStudio.SolutionPersistence has multiple version fields that differ because the source-build project passes some but not all of the necessary version overrides:

• MSFT: FileVersion:1.0.52.6595, ProductVersion:1.0.52+19c3ca7dc9.RR, ProductVersionNumber:1.0.52.0
• SB: FileVersion:1.0.52, ProductVersion:1.0.0+0f576f0a..., ProductVersionNumber:1.0.0.0

The source-build project vs-solutionpersistence.proj passes /p:FileVersion=$(SolutionPersistenceVersion) and /p:PackageVersion=$(SolutionPersistenceVersion) (both 1.0.52), but does not pass /p:Version= or /p:VersionPrefix=. The upstream build relies on Nerdbank.GitVersioning (referenced in Directory.Packages.props) to compute versions from git commit history, which cannot work correctly in the VMR context. The SB project partially compensated with FileVersion and PackageVersion overrides but missed Version, causing two problems:

1. FileVersion revision is 0: The /p:FileVersion=1.0.52 override is only 3 components, so the revision defaults to 0. The MSFT build's NBGV computes the revision from git commit height (6595).

2. ProductVersion is 1.0.0 instead of 1.0.52: Without /p:Version=1.0.52, the project's version.json base of 1.0 is used, and NBGV cannot compute the correct commit height in the VMR context, so the version falls back to 1.0.0. This flows into InformationalVersion/ProductVersion and ProductVersionNumber.

Affected DLLs

• Microsoft.VisualStudio.SolutionPersistence.dll

[akoeplinger]

I think for this one we just missed bumping the submodule.

v1.0.52 used in the MB is microsoft/vs-solutionpersistence@19c3ca7 but in source-build-reference-packages the submodule is referencing v1.0.28 microsoft/vs-solutionpersistence@0b6f82a