Microsoft.AspNet.WebApi.Core 5.2.8 has System.Web.Http.dll with file version lower than the one in 5.2.7 nuget release

[samarunraj]

The file version of System.Web.Http.dll in https://www.nuget.org/packages/Microsoft.AspNet.WebApi.Core/ nuget has actually decrement with the 5.2.8 nuget release.

The 5.2.8 version of Microsoft.AspNet.WebApi.Core nuget package has System.Web.Http.dll

File Version: 5.2.34876.0
Product Version: 5.2.8-34876 (005f94e)

The 5.2.7 version of Microsoft.AspNet.WebApi.Core nuget package has System.Web.Http.dll

File Version: 5.2.61128.0
Product Version: 5.2.7-61128 (39d3064)

This causes installer issue when performing upgrades as the version decremented instead of incrementing.

[dougbu]

This causes installer issue when performing upgrades as the version decremented instead of incrementing.

Could you elaborate on this please❔ What errors occur exactly❔

/cc @TanayParikh @mkArtakMSFT

[samarunraj]

when you perform a major upgrade, windows installer will remove the older version with the larger file version and won't install the supposedly newer file with an older file version.

Just to simplify the ask here, the file version number needs to increment upwards to indicate this is a newer assembly.

[dougbu]

Hmm, it looks like the build version was close to uint16.MaxValue in the previous release and has now wrapped around. That took the assembly file version backwards. I'm pretty sure this has happened before, but I don't remember how we handled it. Looking…

[dougbu]

@joeloff I introduced the % uint16.MaxValue operation in changeset 1756613 but I don't remember why. We haven't changed the start year since 2013 which makes sense given that's when history started😸 I suspect we thought we'd change the major or minor version in less than 6 years but it's been more than 3 years since 5.2.7. 5.2.0 shipped in 2014. Any suggestions❔ (I'm assuming a build version like 100411 would cause problems somewhere.)

@mkArtakMSFT what are your thoughts on perhaps moving straight to v5.3.0 ASAP❔

[dougbu]

Another workaround would be to change <AssemblyFileVersion>$(VersionMajor).$(VersionMinor).$(VersionBuild).$(VersionRevision)</AssemblyFileVersion> to <AssemblyFileVersion>$(VersionMajor).$(VersionMinor).$(VersionRevision).$(VersionBuild)</AssemblyFileVersion>, bump $(VersionRevision) from 0 to 61129, and reset $(VersionStartYear) to 2022. That might require changes other places we use $(VersionRevision) or $(VersionBuild) but would avoid bumping the major or minor versions. Assembly versions should be close to 5.2.61129.00419 if we built again tomorrow.

[joeloff]

@dougbu yes, file versions must be unsigned 16-bit numbers. This is true for the MSI version as well, though I don't think we're shipping those at this point, unless there was need to push out a security fix. For the MSIs, we have to 8-bits for major/minor and 16 bits for the build number. The 4th part of the version is ignored.

I wonder, given the servicing model whether we shouldn't have reset the year on patch number. For file versions 5.2.8.x is bigger than 5.2.0.y and 5.2.7.z, NuGet only cares about the major.minor.patch part since semver doesn't support build/revision except if you have prerelease labels with build metadata.

but for the file versions, I do see the issue. Recycling those would be bad when versioning rules were applied to the files and you could end up with an older version looking newer, unless you inspect other attributes of the DLLs.

[dougbu]

@samarunraj I remain unsure exactly what scenarios are broken due to the lower assembly file version in this release. You mentioned "windows installer" but the assembly file version is less important than other metadata such as the assembly version. Only one value has wrapped.

[assembly: AssemblyFileVersion("5.2.34876.0")]
[assembly: AssemblyInformationalVersion("5.2.8-34876 (005f94e123afdf3111f23f0b982880f8db9b10a7)")]
[assembly: SatelliteContractVersion("5.2.8.0")]
[assembly: AssemblyVersion("5.2.8.0")]

That said, we should do something different in our next release.

[dougbu]

@joeloff you're correct that we didn't ship any installers and don't have plans for new ones anytime soon. But wouldn't resetting the patch number also have wrapped the [AssemblyFileVersion] value❔ I'm not sure why that would be any better or worse for @samarunraj's scenario.

we should do something different in our next release.

Should have said "probably" in there because I thought we had options like using the fourth portion of the [AssemblyFileVersion] for uniqueness.

[samarunraj]

The file version is the one MSI is concerned about and that is the one that has wrapped, the other versions don't matter from the installer perspective.

For better understand my use case, I have System.Web.Http.dll installed using our own installer MSI and when I update the nuget to 5.2.8 and do a major product upgrade using the new MSI, System.Web.Http.dll is missing after the upgrade since the version requirements to do the upgrade was not met (The version needs to be newer for this)

[dougbu]

I'm missing something still @samarunraj. An MSI shouldn't ignore the [AssemblyVersion] value. Could you please describe your MSI and the error(s) you see❔

[samarunraj]

It doesn't and there are no installer error, just missing files after the install. The only way to get around it by setting https://docs.microsoft.com/en-us/windows/win32/msi/reinstallmode property to force reinstall of all files regardless of version.

The default behavior is it won't install a file if you do (MajorUpgrade - wix snippet below) and the file version of the file in MSI being used to upgrade is lower than what was already installed on the machine.

<MajorUpgrade AllowDowngrades="no" AllowSameVersionUpgrades="no" DowngradeErrorMessage="[NEWER_VERSION_FOUND_MESSAGE]" Schedule="afterInstallValidate"/>

[joeloff]

@samarunraj you can also change the scheduling of RemoveExistingProducts (schedule it for after InstallExecute). If the new MSI is installed first, the reference count for the component will be bumped and not removed when the older copy of the MSI is removed. If you remove the old MSI first (after InstallValidate) you can end up with files being removed. Of course changing the scheduling is not always possible as that determines what you can/cannot do during upgrades.

[dougbu]

@joeloff could you clarify what you said about the fourth part of the [AssemblyFileVersion] value being ignored❔ I liked my idea above until you said that.

Separately, what do you feel is the urgency of a fix here❔ Other installers may be making similar assumptions…

[joeloff]

Oh, I was talking about MSI versions - they have restrictions around versioning.

[dougbu]

I was talking about MSI versions

So, the assembly attribute has no similar restrictions❔ If that's the case, we could use my earlier idea and be done with it for 6.5 years or so.

This issue is specific to going from

[assembly: AssemblyFileVersion("5.2.61128.0")]

to

[assembly: AssemblyFileVersion("5.2.34876.0")]

because our $(VersionBuild) wrapped.