Recently I've been working on updating an old, old piece of infrastructure. Over the last year I had managed to move some common libraries shared between projects to NuGet packages, nothing new there.

But they could only target the lowest version of the .NET Framework in use. At the time it was .NET 4.0 which meant that data access was dependent on Entity Framework 4.4.

But, enough time living in the dark ages, it's consolidate all the projects and it was agreed to do so on .NET 4.6.1
This meant we could also update NuGet packages and our data access could use EF 5, an update to the latest (6.2.0 at the time of writing) can wait for another day.

So after updating one of the projects to 4.6.1 and using the newly-built NuGet packages I got the following runtime error and a System.Reflection.TargetInvocationException to go along with it

error CS1705:
    Assembly 'Redacted' with identity 'Redacted, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' uses
    'EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' which has a higher version than referenced assembly
    'EntityFramework' with identity 'EntityFramework, Version=4.4.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'

Wait a minute! We just updated everythign to EF 5, what gives?

Let's check our app.config files, sure enough, that's all as it should be

<section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />

So we have no references to EF 4.4
The HintPath in the csproj isn't pointing at the net40 folder in the NuGet package

The package reference in the csproj

Let's take a look at where it's loading the DLL from. When we hit a breakpoint we can inspect the loaded modules in Visual Studio

How to find the modules window...

And here's our modules with "entity" in the name

The loaded modules

Ah-ha! There's the culprit!
Windows, in an attempt to be a little too helpful is loading the DLL from a cache in AppData.

Since it's a simple enough cache all we have to do is delete the contents of %TEMP%\Temporary ASP.NET Files

Now, when we next go to debug the application it loads EntityFramework from the NuGet package and all is well.

TL:DR;
Windows will cache DLLs for IIS Express
Try deleting the contents of the following folders

  • %TEMP%\Temporary ASP.NET Files
  • %SystemRoot%\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
  • %SystemRoot%\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files