4

In a C# project built with VS2013, I could put this in the AssemblyInfo.cs file:

[assembly: AssemblyInformationalVersion("7.1.0.0 Private (Debug build)")]

When I used the FileVersionInfo.GetVersionInfo .NET API against the executable from within another project, I found these values reported:

  • Product version: 7.1.0.0 Private (Debug build)
  • ProductMajorPart: 7
  • ProductMinorPart: 1

When I use the same attribute and string value in a C# project built with VS2015, the ProductMajorPart and ProductMinorPart properties are reported as zero!

Does anyone know if the behaviour change is intentional?

I have examined the binary file version information found within the executables, and whilst the string values within the version information are as expected in both files, the VS2015 executable has zero values within the VS_FIXEDFILEINFO.dwProductVersionMS and VS_FIXEDFILEINFO.dwProductVersionLS fields.

David Razzetti
  • 167
  • 2
  • 11
  • This used to be taken care of by the assembly linker, alink.dll. Not anymore, it is now done by Roslyn. Many, *many* bugs, click the "New Issue" button on [this web page](https://github.com/dotnet/roslyn/issues). – Hans Passant Dec 19 '15 at 02:14
  • Thanks for the reply. I guess we are going to decode the product components (major, minor) manually from now on. Oh well... – David Razzetti Dec 21 '15 at 08:11

1 Answers1

1

I can confirm the change in behavior for this case, with the observation that if the AssemblyInformationalVersion is in canonical format, for example "7.1.0.0" then it works as expected in all versions i.e. the Product version major/minor/build/revision fields are filled in.

For background, the docs for AssemblyInformationalVersion do in fact specify that:

The attribute defined by this class attaches additional version information to an assembly. If this attribute is applied to an assembly, the string it specifies can be obtained at run time by using the Application.ProductVersion property.

[...] Although you can specify any text, a warning message appears on compilation if the string is not in the format used by the assembly version number [...]

From the above:

  • there is no formal guarantee other than that the string itself can be retrieved;

  • there is a warning against using free-format strings.

You may, or even should, file a bug report on VS connect though my feeling is that MS sees free-format strings in AssemblyInformationalVersion as an unsupported "accidental" feature, and might not consider a change in undocumented behavior to be a "bug" proper.

Not directly related, but this VS 2010 bug report Localized build with free form AssemblyInformationalVersion causes ALINK warning AL1053 has been closed by MS as won't fix.

Also the accepted answer at Why is warning CS1607 “The version specified for the 'product version' is not in the normal 'major.minor.build.revision' format” generated? basically advises that once you deviate from the standard major.minor.build.revision format, you are pretty much on your own.

Community
  • 1
  • 1
dxiv
  • 16,984
  • 2
  • 27
  • 49