Code-first migrations in Entity Framework 6 are a great tool to work with most of the time, but when they hit you with an error, they like to do so in inexplicable ways. One of those is a SerializationException during any of the EF-related commands. In this article, I will show you what helps fix this problem.

Problem

After using migrations successfully for quite a long time in our project, one day the tool just stopped cooperating. Any attempt to run EF commands from PowerShell or even directly from migrate.exe ended with the following exception:

System.Runtime.Serialization.SerializationException: Type is not resolved for member 'System.Data.Entity.Migrations.Design.ToolingFacade+GetContextTypeRunner,EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. at System.AppDomain.DoCallBack(CrossAppDomainDelegate callBackDelegate) at System.Data.Entity.Migrations.Design.ToolingFacade.Run(BaseRunner runner) at System.Data.Entity.Migrations.Design.ToolingFacade.GetContextType(String contextTypeName) at System.Data.Entity.Migrations.EnableMigrationsCommand.FindContextToEnable(String contextTypeName) at System.Data.Entity.Migrations.EnableMigrationsCommand.<>c__DisplayClass2.<.ctor>b__0() at System.Data.Entity.Migrations.MigrationsDomainCommand.Execute(Action command) Type is not resolved for member 'System.Data.Entity.Migrations.Design.ToolingFacade+GetContextTypeRunner,EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

It is quite clear this exception does not tell us much useful information that would lead us to a solution. So naturally the first place we looked was StackOverflow.

Solutions

Invalid path

Most answers on SO resolved this problem by checking the path to the project on the hard drive. The most usual cause was the & character somewhere in the path, which EF apparently cannot handle. Unfortunately, in our case, the path was simple and without any special characters or even spaces for that matter.

Binding redirect

After a solid day of trial and error which included reinstalling all NuGet packages, upgrading the library to .NET Standard and much more, I finally randomly stumbled upon the cause - invalid binding redirect. Our App.config file contained the following:

<dependentAssembly>
   <assemblyIdentity name="EntityFramework" publicKeyToken="b77a5c561934e089" culture="neutral" />
   <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.2.0.0" />
   <codeBase version="6.0.0.0" href="libs/EntityFramework.dll" />
</dependentAssembly>

This looked perfectly normal at first, but then I started digging. The NuGet package version we are using is indeed 6.2. But when I ran the following PowerShell command against the EntityFramework.dll:

([system.reflection.assembly]::LoadFile("C:\Users\Martin\.nuget\packages\entityframework\6.2.0\lib\net45\entityframework.dll")).FullName

I got a whole different story:

EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

It turns out, that the full name of the assembly is still simply 6.0.0.0 and only the FileVersion matches the NuGet version. I changed the newVersion attribute to 6.0.0.0 and voilá - EF commands are again up and running!

<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />

Summary

Dealing with non-descriptive errors from EF tooling can be daunting, but in the end usually leads us to discover something new. In this case it took a bit more effort, but the end result reminded me of the fact that the problem can sometimes be where you least expect it.