1

Is there a specific culture setting that governs how the ProductVersion string is delimited and that can be set through the CultureInfo class?

For example, using the following line on a Windows 10 PC, with the region set to English (South Africa), the ProductVersion string is returned as 1,2,3,4 instead of 1.2.3.4.

string version = FileVersionInfo.GetVersionInfo("myApp.exe").ProductVersion;

From my testing thus far, none of the NumberFormat decimal separator options applies to the ProductVersion.

RooiWillie
  • 2,198
  • 1
  • 30
  • 36
  • 3
    `FileVersionInfo.GetVersionInfo` is a wrapper around the Win32 `GetFileVersionInfo` function, and the `ProductVersion` is obtained through a call to `VerQueryValue`, which can offer the information in different code pages. The localization of this bypasses what .NET itself is doing. You could try getting a local-independent `Version` by using the separate fields (`new Version(v.ProductMajorPart, v.ProductMinorPart, v.ProductBuildPart, v.ProductPrivatePart)`); this is not guaranteed to match the arbitrary `ProductVersion` string exactly, though. – Jeroen Mostert Jan 24 '20 at 13:30
  • For example, `cmd.exe` reports a `ProductVersion` of `10.0.18362.1` on my machine, but the `ProductPrivatePart` is `449`. Even so, the version numbers are actually comparable, as opposed to the strings. – Jeroen Mostert Jan 24 '20 at 13:33
  • The native VERSIONINFO definition is quirky in many ways. This is one of the quirks, it defines *two* sources of product version. One is a string, returned as-is without any culture sensitive formatting. The one you obtained with ProductVersion. So you got what the original programmer used as a string. The other is an actual number, returned by the ProductMajor/Minor/Build/PrivatePart properties. They don't have to agree. Clearly you prefer the latter properties to get it formatted the way you want. – Hans Passant Jan 24 '20 at 13:58

0 Answers0