Over a million developers have joined DZone.

NuGet Install Is Broken With F#

DZone's Guide to

NuGet Install Is Broken With F#

· Integration Zone ·
Free Resource

SnapLogic is the leading self-service enterprise-grade integration platform. Download the 2018 GartnerMagic Quadrant for Enterprise iPaaS or play around on the platform, risk free, for 30 days.

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:

D:\>gacutil -l | find "NuGet.Core"
  NuGet.Core, Version=1.0.11220.104, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL
  NuGet.Core, Version=1.6.30117.9648, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL

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:

PM> Install-Package NuGet.Core -Version 2.5.0
Installing 'Nuget.Core 2.5.0'.
Successfully installed 'Nuget.Core 2.5.0'.
Adding 'Nuget.Core 2.5.0' to Mike.NuGetExperiments.FsProject.
Successfully added 'Nuget.Core 2.5.0' to Mike.NuGetExperiments.FsProject.

It correctly creates a packages directory, downloads the NuGet.Core package and creates a packages.config file:

D:\Source\Mike.NuGetExperiments\src>tree /F
│   Mike.NuGetExperiments.sln
│   │   Mike.NuGetExperiments.FsProject.fsproj
│   │   packages.config
│   │   Spike.fs
│   │
│   ├───bin
│   │   └───Debug
│   │
│   └───obj
│       └───Debug
    │   repositories.config
        │   Nuget.Core.2.5.0.nupkg
        │   Nuget.Core.2.5.0.nuspec

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.

<Reference Include="NuGet.Core, Version=1.6.30117.9648, Culture=neutral, PublicKeyToken=31bf3856ad364e35">

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, and drop it into to the projects output directory (bin\Debug).

Next use NuGet to install an earlier version of the assembly:

Install-Package EasyNetQ -Version
Attempting to resolve dependency 'RabbitMQ.Client (='.
Attempting to resolve dependency 'Newtonsoft.Json (≥ 4.5)'.
Installing 'RabbitMQ.Client 3.0.2'.
Successfully installed 'RabbitMQ.Client 3.0.2'.
Installing 'Newtonsoft.Json 4.5.11'.
Successfully installed 'Newtonsoft.Json 4.5.11'.
Installing 'EasyNetQ'.
Successfully installed 'EasyNetQ'.
Adding 'RabbitMQ.Client 3.0.2' to Mike.NuGetExperiments.FsProject.
Successfully added 'RabbitMQ.Client 3.0.2' to Mike.NuGetExperiments.FsProject.
Adding 'Newtonsoft.Json 4.5.11' to Mike.NuGetExperiments.FsProject.
Successfully added 'Newtonsoft.Json 4.5.11' to Mike.NuGetExperiments.FsProject.
Adding 'EasyNetQ' to Mike.NuGetExperiments.FsProject.
Successfully added 'EasyNetQ' to Mike.NuGetExperiments.FsProject.

NuGet reports that everything went according to plan and that EasyNetQ 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, and again there’s no hint path:

<Reference Include="EasyNetQ, Version=, Culture=neutral, PublicKeyToken=null">

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:


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):

    public virtual void AddReference(string referencePath, Stream stream)
        string name = Path.GetFileNameWithoutExtension(referencePath);
            // Get the full path to the reference
            string fullPath = PathUtility.GetAbsolutePath(Root, referencePath);
            string assemblyPath = fullPath;
           // Add a reference to the project
           dynamic reference = Project.Object.References.Add(assemblyPath);
           // This happens if the assembly appears in any of the search
           // paths that VS uses to locate assembly references. Most commonly, 
           // it happens if this assembly is in the GAC or in the output path.
           if (!reference.Path.Equals(fullPath, StringComparison.OrdinalIgnoreCase))
               // Get the msbuild project for this project
               MsBuildProject buildProject = Project.AsMSBuildProject();
               if (buildProject != null)
                   // Get the assembly name of the reference we are trying to add
                   AssemblyName assemblyName = AssemblyName.GetAssemblyName(fullPath);
                   // Try to find the item for the assembly name
                   MsBuildProjectItem item = 
                       (from assemblyReferenceNode in buildProject.GetAssemblyReferences()
                       where AssemblyNamesMatch(assemblyName, assemblyReferenceNode.Item2)
                       select assemblyReferenceNode.Item1).FirstOrDefault();
                   if (item != null)
                       // Add the <HintPath> metadata item as a relative path
                       item.SetMetadataValue("HintPath", referencePath);
                       // Save the project after we've modified it.
       catch (Exception e)

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.

With SnapLogic’s integration platform you can save millions of dollars, increase integrator productivity by 5X, and reduce integration time to value by 90%. Sign up for our risk-free 30-day trial!


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}