Fsharp: FSharp.Core nupkg and dll version number differences confusing.

[chillitom]

I'm working on a solution where a custom version of FSharp.Core.dll has been bundled in a package called FSharp.Core.4.3.1.0.nupkg. None of the projects that use this package can be upgraded to later packaged versions of FSharp.Core because of this. as dependency resolution fails. Latest nupkg version number is 4.2.1 and contains dll version 4.4.1.0.

We'll correct the issue by switching to the official packaged versions (official nupkg 3.1.2.5 for dll 4.3.1.0) but I doubt we're the first to have been confused by this. I believe this situation came about because of the confusion around the difference in version numbers. Likely somebody searched nuget for 4.3.1 and on not seeing it decided to roll there own.

Would it be possible to begin numbering the nupkgs to match the dll version? Failing that could the description field mention the version of the assembly that it contains?

[enricosada]

Yes 👍 please 💯 .
Starting from next FSharp.Core package minor version, if possibile
Use 4.3 or better just skip to 4.5 so version number is higher than 4.4.1.0..

[dsyme]

...or better just skip to 4.5 so version number is higher than 4.4.1.0..

Could we just use 4.3.0.0, 4.4.0.0, 4.4.1.0, 4.4.2.0?

[enricosada]

@dsyme 4.4.2.0 for package 4.2.0? leaving prefix 4 seems a lot complicated to understand for everyone but compiler developers.
We can continue to leave as is, until we reach 4.5. but after that, we should use normal versioning.

As an additional feedback, we really need to continue to increment AssemblyVersion now that is not in GAC? is not possibile to leave it fixed, and just increment AssemblyFileVersion? this avoid LOT of assemblybinding redirect hell.
pratically everyone just use a fixed assembly version, so noone need to binding redirct anything.

[abelbraaksma]

pratically everyone just use a fixed assembly version, so noone need to binding redirct anything.

Possibly true, but I've had many issues with third-party libraries using a fixed version, or downgrading whatever was in the project after a NuGet update. For instance, UnQuote uses a fixed 4.3.something version which causes the project to fail at runtime as it ends up loading an older version of F# prior to loading other versions of F#.

For exe-projects this can be fixed with binding redirects, but for dll-projects this is not possible (as you don't know whatever will be loaded in the host's application).

I ended up fixing this by writing a hack (essentially: creating a custom bindingredirect .config file and instructing Fusion to use the new file) that kicks in on module load and that fixes the binding redirects (because .NET does not call or abide by a custom AssemblyHandler if it already finds the assembly in the GAC or elsewhere, in fact, it only calls it if it fails, and finding an older assembly is not considered a fail).

Now that we have two valid versions with AssemblyVersion 4.4.1.0 (i.e., 4.1.17 and 4.2.1) this gets only trickier.

now that is not in GAC?

We may not install it in the GAC, but I don't think there's anything that prevents other applications or setups to install it in the GAC. My setup currently needs to check for wrong / old versions in the GAC and deal with it appropriately, but even if we don't install new versions in the GAC, that does not mean it doesn't end up in there.

In short, I would love to agree @enricosada, but in practice, esp. in large projects with a lot of dependencies, it is not that simple.

Back on topic: consistent versioning, and aligning more with the AssemblyVersion attribute would be very, very welcome.

[cartermp]

This is now complete - the major and minor versions of language, package, and binary align as of F# 4.5