Fsharp: `FSharp.Core.dll` 4.7 Version Downgrade blocks MSI upgrades

[matthid]

We try to upgrade to 4.7 but our installation routine fails because Windows Installer detects the version downgrade:

Versions go up not down.

This is at the moment a blocker issue for us (which was sadly detected a bit late because testing upgrade scenario is not something you do after each package update).

You can easily verify versions by downloading from NuGet.

Expected behavior

Upgrade-Installation succeeds

Actual behavior

Upgrade-Installation fails

Known workarounds

None yet, we are still investigating. Will try to add additional info as we have them.

Related information

We use a WIX Installer to distribute our software.

• Operating system: Win 10
• .NET Runtime kind: Doesn't matter
• Editing Tools: Doesn't matter

[0x53A]

Msi is just broken in such circumstances, my condolences.

[matthid]

@0x53A Problem is that doesn't really help, we will not get rid of Msi just because fsharp core is broken? Generally it works (and has worked) good enough for our use case.
I'm more interested in finding a way to solve this issue.

[abelbraaksma]

I'm struggling with understanding the scenario. You say you upgrade your project to use 4.7. But then MSI thinks it's a downgrade, although you go from 4.6 to 4.7? Or has the target machine a higher version and you want to install a lower version?

Just a hunch: may it have something to do with 'beta' in the version string?

[ringwaldK]

The problem is (as already described) in nuget package version 4.6.2 the DLL file version is 2019.2.13.3 and in version 4.7.0 it is 4.700.19.40208. Which is a downgrade.

The MSI detects that with:

Disallowing installation of component: {*} since the same component with higher versioned keyfile exists

[abelbraaksma]

Ah, got it, it's the file version, not the product version that breaks the procedure.

[abelbraaksma]

You use WIX. There are some ideas in this answer, using AllowDowngrades https://stackoverflow.com/a/35490322/111575. Maybe it helps.

[ringwaldK]

This does not fix our problem. Cause AllowDowngrades will be set in the installer and only affects the installer version itself not the files which are copied.

And we run in the problem which is described in the last comment in https://stackoverflow.com/a/35490322/111575

In this case there's no impact if doing a major or minor upgrade

[ringwaldK]

Finally we could work out a solution: https://stackoverflow.com/a/60527774/8495260

Hopefully it's helpful for anybody who uses WIX and this F# package

[cartermp]

@KevinRansom any thoughts here?

[cartermp]

I can't say for certain, but this feels like an unintended consequence of changing the build (which appears to generate a different FileVersion that's not VS-focused). How that change occurred I'm not sure. I'm not on a Windows machine at the moment - is it the same version for the FSharp.Core deployed by Visual Studio?

[KevinRansom]

Well ... that 4.6 FSharp.Core File version looks quite suspect, and the 4.7 file version looks how I would expect it to look. We haven't intentionally changed anything around this in eons. I guess I need to look at it, see what occured, and what we can do to fix it.

[KevinRansom]

@cartermp 's suspicion looks like the correct one. Previously FSharp.Core had an idio-syncratic file-version based on the date, and it now has a version number based on the actual version of the file, compatible with the remainder of dotnet tooling.
We need to figure out how to move forward on this. Because the vsix update scenario, is pretty important to us.

[cartermp]

Firstly - sorry @matthid and folks, this definitely is an unintended consequence of our build. It wasn't caught because we don't distribute an MSI and have no test for that kind of scenario.

@KevinRansom I'm not sure if this affects the VSIX update scenario; but it clearly does affect MSI installs as per @matthid's experience. Not applicable to VS updates, but it is applicable to third-party apps.

I'm hesitant to change things further unless it's clear that:

• Reverting back to the VS versioning scheme fixes the reported issue
• We won't ever have to revert the reversion and adopt an actual file version again

The second part is more important to me, since breaking people with MSI installs once is enough for everyone involved.

[matthid]

@cartermp Problem is that I can't really say how many people this hits. I also can't say how critical this scenario is (how many people still use msi and will hit this eventually, as I guess those people are slower to adapt in general?)
What I can say is that this hit every project of us which uses F#, but that might be not so surprising as all our installers look similar.
What I can say is that we found a solution but you need quite the expertise in order to:

• find the issue (you need good wix debugging skills)
• find the solution (now we have posted it but we didn't find anyone else using this solution)
• implement the solution (we had to change the automatic heat transformations in order to exclude FSharp.Core and then add it back manually, so you need to have xml transformation expertise as well)

We tested that future updates work. Therefore we don't really depend on a fast fix for this anymore (but not doing this again in the future might save us from running into this in the future with another installer).
Maybe we should look out in the wild for people who report missing FSharp.Core.dll files after update installations to see how critical this is?

So in general I'd say:

• I hope it doesn't hit a lot of people (you might have the numbers)
• But when it hits you it can be incredible painful
• Let's agree to at least don't do this again :)

Another question is: How important is the file versioning scheme? Where and why was it historically changed to include the year?

[cartermp]

Unfortunately, we don't have any numbers on F# apps getting deployed via MSI. Our best guess is that the scenario is uncommon, since FSharp.Core 4.7 was released 7 months ago and we probably would have heard about it sooner if it widely affected folks. A quick glance at StackOverflow suggests recent problems were about type providers, binding redirects, and ill-specified package references. But that could also just be lag time in adopting F# 4.7.

The previous file versioning scheme (date-based) was probably an artifact of our old build, which was quite VS-centric. I don't know why it didn't use the literal file version and was just some date + build number. Arcade (.NET build/CI system) uses the real version of the file plus a date-computed value, which required this file version change about a year ago. Deviating from that is a pain for official builds, and introduces yet another special case for FSharp.Core that we're sure to screw up in the future, so we're hesitant to move back to the old scheme unless we get enough reports about the MSI scenario.

I think we can chalk this one up to not anticipating this being a problem, especially since we've moved away from MSI installs quite a while ago (otherwise we would have noticed the break in dogfood builds). Really sorry that this hit you and caused such a time and money problem.

[cartermp]

Closing out old issue, I don't think there is a good resolution here other than the apology ;/