There’s a very nasty bug when you try and use NuGet to add a package reference to an F# project. It manifests itself when either the assembly that is being installed also has a version in the GAC or a different version already exists in the output directory.
First let’s reproduce the problem when a version of the assembly already exists in the GAC.
Create a new solution with an F# project.
Choose an assembly that you want to install from NuGet that also exists in the GAC on your machine. For ironic purposes I’m going to choose NuGet.Core for this example.
It’s in my GAC:
You can see that the highest version in the GAC is version 1.6.30117.9648
Now let’s install NuGet.Core version 2.5.0 from the official NuGet source:
It correctly creates a packages directory, downloads the NuGet.Core package and creates a packages.config file:
But when when I look at my fsproj file I see that it has incorrectly referenced the NuGet.Core version (1.6.30117.9648) from the GAC and there is no hint path pointing to the downloaded package.
Next let’s reproduce the problem when a version of an assembly already exists in the output directory.
This time I’m going to EasyNetQ as my example DLL. First I’m going to take a recent version of EasyNetQ.dll, 0.10.1.92 and drop it into to the projects output directory (bin\Debug).
Next use NuGet to install an earlier version of the assembly:
NuGet reports that everything went according to plan and that EasyNetQ 0.9.2.76 has been successfully added to my project.
Once again the packages directory was successfully created and the correct version of EasyNetQ has been downloaded. The packages.config file also has the correct version of EasyNetQ. I won’t show you the output from ‘tree’ again, it’s much the same as before.
Again, when I look at my fsproj file the version of EasyNetQ is incorrect, it’s 0.10.1.92, and again there’s no hint path:
Yup, NuGet install is most definitely broken with F#.
This bug makes using NuGet and F# together an exercise in frustration. Our team has wasted days attempting to get to the bottom of this.
It seems that it’s a well know problem. Just take a look at this workitem, reported over a year ago:
http://nuget.codeplex.com/workitem/2149
After much cursing of NuGet, the problem actually appears to be with the F# project system rather than with NuGet itself:
“F# knows about this behavior and they will release the fix”
Hmm, it hasn’t been fixed yet.
We had a dig around the NuGet code. The interesting piece is this file snippet (from NuGet.VisualStudio.VsProjectSystem):
On line 13 NuGet calls out to the F# project system and asks it to add a reference to the assembly at the given path. We assume that the F# project system then does the wrong thing by searching for the assembly name anywhere in the GAC or the output directory rather than referencing the explicit assembly NuGet is asking it to reference.
Interestingly, it looks as if the NuGet team have attempted to code a work-around for this bug from line 22 onwards. Could this be why C# projects don’t exhibit this behaviour? Unfortunately the work around doesn’t work in the F# case. We think it’s because F# doesn’t respect assembly versions and will happily replace any requested assembly with another one so long as it’s got the same simple name. At line 33, no assemblies are found in the fsproj file because the ‘AssemblyNamesMatch’ function does an exact match using all four elements of the full assembly name (simple name, version, culture, and key) and of course the assembly that the F# project system has found and added has a different version.
So, come on F# team, pull your finger out and fix the Visual Studio F# project system. In the meantime, in my next post I’ll talk about some of things our team, and especially the excellent Michael Newton (@mavnn) has been doing to try and work around these problems.