My problem is that the below code does not register a data store during startup. This is the specific "error" statement I get in the response from the application:
An unhandled exception occurred while processing the request.
InvalidOperationException: No data stores are configured. Configure a data store by overriding OnConfiguring in your DbContext class or in the AddDbContext method when setting up services.
Microsoft.Data.Entity.Storage.DataStoreSelector.SelectDataStore(ServiceProviderSource providerSource)
In ConfigureServices(IServiceCollection services) I am trying to specify DbContextOptions for my DbContext in a lambda. Code:
services.AddEntityFramework(Configuration)
.AddSqlServer()
.AddDbContext<MyDbContext>(
options =>
options.UseSqlServer(Configuration.Get("Data:DefaultConnection:ConnectionString"))
);
In my DbContext, I have a constructor which sends the option to base, code:
public MyContext(DbContextOptions options) : base(options) { }
My configuration file config.json, which is read at startup, contains this connectionstring:
"Data": {
"DefaultConnection": {
"ConnectionString": "Server=(localdb)\\MSSQLLocalDB;Database=MyDbName;Trusted_Connection=True;MultipleActiveResultSets=True;"
}
}
I have previously used
protected override void OnConfiguring(DbContextOptions options)
{
options.UseSqlServer(Startup.Configuration.Get("Data:DefaultConnection:ConnectionString"));
}
in my DbContext successfully. It registers the data store and it works properly, but I'd rather use the lambda way.
If there is any more information needed, I'll provide it.
Are you injecting your context into your controller or wherever you are using it? I discovered that if you try to new up the context instead of injecting it, it does not use the configuration specified in Startup.cs
I (still) have the same problem with EF7 and beta 4. This is my workaround in my data context:
public class AspNetDataContext : IdentityDbContext, IDataContext
{
private readonly string _connectionString;
public DbSet<Player> Players { get; set; }
public AspNetDataContext(DbContextOptions options)
{
_connectionString = ((SqlServerOptionsExtension)options.Extensions.First()).ConnectionString;
}
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseSqlServer(_connectionString);
}
}
I extract the connectionstring from the options and use this in the OnConfiguring method. This is still not the solution we want, but I don't have to change something in the Startup.cs (everything there is like you described). And as soon this is fixed, you just have to remove the stuff from the data context class.
And maybe someone has another (and even better) solution to this problem.
public class MyContext : DbContext
{
private string _connectionString { get; set; }
public MyContext(string connectionString) //Inject external connectionstring.
{
_connectionString = connectionString;
}
public MyContext(DbContextOptionsBuilder options) : base(options.Options) //Default binding from web.config.
{
}
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
if (!optionsBuilder.IsConfigured && false == string.IsNullOrEmpty(_connectionString)) // if no default binding
{
optionsBuilder.UseSqlServer(_connectionString); //Use provider as SQL server and make connection through connection string.
optionsBuilder.UseLoggerFactory(_factory);//optional, Use Logger factory
}
base.OnConfiguring(optionsBuilder); //configure connection
}
}
EF7 has new sytax from DBContextOptionsBuilder to EntityOptionsBuilder. Following is ready to use for also command line scaffolding.
public class ContentContext : DbContext
{
public DbSet<Content> Contents { get; set; }
public DbSet<ContentCategory> ContentCategories { get; set; }
protected override void OnConfiguring(EntityOptionsBuilder optionsBuilder)
{
optionsBuilder.UseSqlServer("Data:DefaultConnection:ConnectionString");
}
}
