Attempting to use EF Core with LinqPad getting unable to case to DbContext
Options
I am using EF Core 2.0.3 in an application. I can create a connection to the database using the DbContext DLL and the constructor that takes a connection string. The test button says everything is working. However, in the connection list I am getting the error: "Unable to cast object of type "...GorillaSyncDbContext" to type "Microsoft.EntityFrameworkCore.DbContext".
That type is definitely inherited from Microsoft.EntityFrameworkCore.DbContext. I have added the Nuget Package for Microsoft.EntityFrameworkCore v2.0.3 and Microsoft.EntityFrameworkCore.SqlServer v2.0.3 to LinqPad (or maybe just to the query). This caused no change.
What am I missing?
Thanks in advance for any advice.
That type is definitely inherited from Microsoft.EntityFrameworkCore.DbContext. I have added the Nuget Package for Microsoft.EntityFrameworkCore v2.0.3 and Microsoft.EntityFrameworkCore.SqlServer v2.0.3 to LinqPad (or maybe just to the query). This caused no change.
What am I missing?
Thanks in advance for any advice.
Comments
-
More information. Even though I am getting that error in the left connection list, if I do from x in TableName select x I get the same error about not being able to cast do DbContext.
However, if I do TableName.Dump() I do get results back. Most, but not all, of the fluent methods appear to work against the database. Strangely for some tables I get the cast error and not others. I haven't seen a clear pattern. -
Even more information. It turns out that the cast errors aren't persistent. If I get a cast error and then I query another table (that works) and come back to the call that returned a cast error it often works just fine. So, it's relatively random. Even the error on linq (versus fluent) queries has turned out to be temporary. Weird.
-
One possible cause is multiple conflicting copies of the Entity Framework assemblies. You can check for this by inserting the following query before the query which fails:
AppDomain.CurrentDomain.GetAssemblies() .OrderBy (a => a.GetName().Name) .Select (a => new { a.GetName().Name, a.Location }) .Dump();
-
I couldn't run that query directly because I got the error, "The invoked member is not supported in a dynamic assembly." by which it means GetName(). But, by changing the query to this:
var q1 = AppDomain.CurrentDomain.GetAssemblies(); var assemblyList = new List<string>(); foreach (var x in q1) { try { assemblyList.Add($"{x.GetName().Name} ({x.Location})"); } catch (Exception e) { assemblyList.Add(e.Message); } } assemblyList.OrderBy(a => a).Dump();
I was able to get the following list. I don't know if it's part of the problem, but the assembly that shall not be named only provides this in the debugger:
Anonymously Hosted DynamicMethods Assembly, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
The list was too long to paste here, so I put it in this Google Doc: https://docs.google.com/document/d/1vEmWhuRQm020p5OLwrH4olUX3QdXmh4BlWEpdzVOBqE/edit?usp=sharing
For reference, I have also listed the DLLs that I see in a new, unattached, LinqPad document. There is no anonymous assembly and your original code works fine there. -
I updated the list again. I had been playing with different things trying to resolve the problem and one of the things that was suggested in a forum was copying the EF DLLs to the LinqPad EXE location. I had done that before I ran the first list, but it hadn't had any effect. LinqPad was loading those DLLs though, so I cleared them out of the program files, ran LinqPad again. and pulled a new list of DLLs. Also, just so you can see it, here is a screenshot showing the error in the connection list:
Not sure why the image isn't showing up, here's the bare link:
https://drive.google.com/file/d/1lZM9NRwLRJRmDQapFudXRuHzYBlZejXh/view?usp=sharing