NuGet - dependency installed but not found

Question

I have a problem with the NuGet package manager. I published my library (a type provider, but I don't think this matters) and then testet it, but it fails to find a dependency. The complete error message is (full namespace/name ommitted for brevity):

The type provider 'TypeProviderImplementation....' reported an error:
Could not load file or assembly 'dotNetRDF', Version=1.0.3.0, Culture=neutral, PublicKeyToken=...' or one of its dependencies.

The thing is that when installing the library, it looks like the dependencies are installed correctly. The correct libraries are downloaded and there is no error showing up. In an attempt to solve the problem, I specified the exact version in the .nuspec file, but this didn't change anything. ...

Installing dotNetRDF via NuGet and then manually referencing my precompiled DLL (without going through NuGet) seems to work fine.

So I'm basically out of ideas on how to solve or even debug the problem. I'm thankful for any pointers.

Addign more information about .NET version numbers as my comment below is quite hard to read:

I checked framework versions as suggested. I did this via looking at the FrameworkDisplayName in the object browser. Basically, my library was using 4.5 and dotNetRDF was using 4.0.

I switched to .NET 4.0, but nothing changed.

• My library = ".NET Framework 4"
• dotNetRDF = ".NET Framework 4"
• HtmlAgilityPack = ".NET Framework 4.5"
• Newtonsoft.Json = ".NET Framework 4.5"
• VDS.Common = ".NET Framework 4 Client Profile"

My dependency is dotNetRDF, the remaining ones are dependencies of dotNetRDF.

Latest NuSpec file can be found here. I create the package via the command nuget pack LITEQ.fsproj -Prop Configuration=Release.

The package id is LITEQ.RDF.

Some additional information: The library is a F# project. I just tested what happens if I create a console project and install the library via NuGet and then send the references to the F# Interactive Console. It actually works in this case.

So it feels like there is some problem with the project configuration after installing the library via NuGet.

To reproduce, the error, download the library, open up the UniKo.West.Liteq namespace and for example use the NpqlTypeProvider:

open Uniko.West.Liteq

type A = NpqlRdfProvider< @"">

Answer 1

Certainly for me I can't see any obvious problems, when I install your package into an empty console project I don't have any issues and I can write a trivial example that uses the dotNetRDF APIs just fine. If you can produce a minimal example project into which installing the packages creates an issue then that would be very helpful.

Your Issue

However the dependencies you state for your project look wrong, you have .Net 4.0 for your project and some dependencies but .Net 4.5 for others which will not work. Note that when you downgrade a projects target framework NuGet does not cope nicely with that, it is best to completely uninstall and reinstall NuGet packages any time you change the target framework version. It is perfectly fine for a newer version of the framework to rely on dependencies that target older versions, so your .Net 4.5 project can happily depend on the .Net 4.0 version of dotNetRDF. However the reverse is not true which may be the cause of your problems.

You can sometimes tell if this is the case because VS may highlight bad dependencies under References in the solution explorer with little warning icons (sadly it doesn't always do this). Even if this is not the case you should see output like the following in the Output Window when you try and build if you have incompatible dependencies and this may also yield compile errors about missing namespaces:

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3274: The primary reference "HtmlAgilityPack" could not be resolved because it was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.0".

So I would strongly suggest that you uninstall all packages via NuGet and reinstall them whenever you change the target .Net framework of your project.

Other Issues

In terms of other possible issues you are using dotNetRDF 1.0.3 which is not the latest version, versions prior to 1.0.5 have a known issue related to interactions with the versioning and framework profiles of Json.Net. If a project you are installing into also has dependencies on Json.Net you may run into version conflict issues. See CORE-405: Resolve Issues with Json.Net dependency for some discussion on this.

I would suggest that you also upgrade your dependency to the latest dotNetRDF release which is 1.0.6.3421 at the time of writing this answer and see if that resolves your problem.

Edit - NuGet Package Versions

NuGet packages versions do not have to correspond to the assembly version, as it happens 1.0.6.3421 does have an assembly version of 1.0.3.0. That was actually not our intention but a flaw in our build process but that isn't really relevant here.

What it looks like is that your library is compiled against a different version of dotNetRDF than the one NuGet is installing for you. However without seeing the source of your package it is impossible to debug further.

What if neither solution works?

If neither of these things resolves your problem then you are going to need to provide a minimal project that reproduces the problem.

Answer 2

A temporary solution (or more of a hack) is to not rely on dependencies, but to directly put the DLLs into the NuGet package. When I do this, the library works fine. The NuSpec file in this case looks like this (excerpt):

<package>
    <metadata>
        ...
    </metadata>
    <files>
        <file src="bin\Release\dotNetRDF.dll" target="lib/net40" />
        <file src="bin\Release\HtmlAgilityPack.dll" target="lib/net40" />
        <file src="bin\Release\HtmlAgilityPack.pdb" target="lib/net40" />
        <file src="bin\Release\HtmlAgilityPack.xml" target="lib/net40" />
        ...
    </files>
</package>

But obviously, this isn't a good solution.