Question
I am trying to figure out if there is something I am missing or some way to hack around the lack of support (yet) for Entity Framework Core DbContexts in LinqPad. I've compiled my code targeting 4.6.1 (as suggested on the LinqPad forum) and tried the "Entity Framework V7" driver, but as its name suggests, I don't believe it's up-to-date. It still asks for an app.config file or a connection string for the constructor.
Since EF Core contexts use DbContextOptions for construction rather than connection strings, I was thinking I could possibly create a constructor overload that takes a connection string, but that doesn't handle the underlying database driver. Is there a way to specify a factory for constructing the context? Any other possibilities? I'm feeling lost without LinqPad.
Popular Answer
Latest EFCore 1.1 LINQPad driver (v1.1.1.1) can correctly use constructor that accepts string (when this option is selected in LINQPad).
So it's possible to add the following constructor:
public ApplicationDbContext(string connectionString)
: this(new DbContextOptionsBuilder<ApplicationDbContext>()
.UseSqlServer(connectionString).Options)
{ }
This will hard link this context instance to sql server provider, but at least not to connection string. And in addition your app not likely will ever try to use this constructor, EF Core never expects/promotes a ctor. that accepts string.
For additional safety you could wrap this constructor in #if DEBUG ... #endif so that it never gets to production.
Related Questions
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow