Using EF Core 2.0 i am trying to implement IDesignTimeDbContextFactory to read connection string from the appsettings.json file. I am getting following error on call to SetBasePath
ConfigurationBuilder does not contain a definition of SetBasePath( )
public class DbContextFactory : IDesignTimeDbContextFactory<TestDbContext>
{
public TestDbContext CreateDbContext(string[] args)
{
IConfigurationRoot configuration = new ConfigurationBuilder()
.SetBasePath(Directory.GetCurrentDirectory())
.AddJsonFile("appsettings.json")
.Build();
var builder = new DbContextOptionsBuilder<TestDbContext>();
var connectionString = configuration.GetConnectionString("DefaultConnection");
builder.UseSqlServer(connectionString);
return new TestDbContext(builder.Options);
}
}
Second Question : Using this approach is it necessary to use dotnet CLI, will this method be called if i am just running my migration commands using "Package Manager Console" ?
The SetBasePath() method is an extension method in FileExtensions.
You can get it by adding the Microsoft.Extensions.Configuration.FileExtensions package. I see you have AddJsonFile() also, so you might want to use Microsoft.Extensions.Configuration.Json instead since it depends on FileExtensions (i.e you'll get both).
On the 2nd question, you don't need the IDesignTimeDbContextFactory<>, but without if you'll need to set the connection string in another place that is accessible during design time. Another example is to set it in the constructor of your DbContext, but that has various design problems like if you want to run a test vs production instance.
If you don't have a factory the DbContext is created using a public parameterless constructor.
Related
I'm facing an error while trying to obtain information of the DbSets in a DbContext object by using Entity Framework core.I'm trying to instante the context by calling a method which receives a generic type T which might be childs of DbContext this way:
My DbContext object looks this way:
public class CatalogueContext : DbContext
{
public DbSet<ConnectorCatalogueItemConv> CatalogueItemConvs { get; set; }
public CatalogueContext(DbContextOptions<CatalogueContext> options)
: base(options)
{
}
public CatalogueContext()
{
}
}
public T GetContext<T>() where T: DbContext, new()
{
var optionsBuilder = new DbContextOptionsBuilder<T>();
var connectionString = Configuration.GetConnectionString(ExternalTablesKey);
optionsBuilder.UseSqlServer(connectionString);
return Activator.CreateInstance(typeof(T), optionsBuilder.Options) as T;
}
Your sqlServerOptions.AddTempTableSupport() appears to be a custom extension method created by your organization. This method calls a method in a Thinktecture assembly, but your application can't find that metho at runtime.
As always with a MissingMethodException this means you're running your application against another assembly than parts of it were compiled against.
Make sure that you use the same version everywhere.
Such errors usually are sign of some nuget version mismatch. Since you have not provided a full .csproj file it is hard to say which ones exactly, but there are several in question, like Microsoft.EntityFrameworkCore.SqlServer is definitely should be upgraded to 6.x. I would assume that you have some package Thinktecture.Something... installed also so you need to update those to version which support 6.x version of EF Core (if it is one from pawelgerr then latest 4.2.3 versions seems to be appropriate).
I have a project created from the ASP.NET Core Web Application template in VS. When run, the project creates a database to support the Identity package.
The Identity package is a Razor Class Library. I have scaffolded it and the models can be seen. The models are sub-classed from Microsoft.AspNetCore.Mvc.RazorPages.PageModel.
I am tracing the code to try and get a better understanding of how it all works. I am trying to find the path from the models to the physical database.
In the file appsettings.json, I see the connection string DefaultConnection pointing to the physical database.
In startup.cs, I see a reference to the connection string DefaultConnection:
services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
Configuration.GetConnectionString("DefaultConnection")));
After this, I lost the trail. I can't find the link from a model in code to a table in the database. What is the code needed to perform a query like select * from AspNetUsers?
As #Daniel Schmid suggested , you should firstly learn the Dependency injection in ASP.NET Core.
ASP.NET Core has an excellent Dependency Injection feature through which this framework provides you with an object of any class that you want. So you don’t have to manually create the class object in your code.
EF Core supports using DbContext with a dependency injection container. Your DbContext type can be added to the service container by using the AddDbContext<TContext> method.
Then you can use the instance like :
public class MyController
{
private readonly ApplicationDbContext _context;
public MyController(ApplicationDbContext context)
{
_context = context;
}
...
}
or using ServiceProvider directly, less common :
using (var context = serviceProvider.GetService<ApplicationDbContext>())
{
// do stuff
}
var options = serviceProvider.GetService<DbContextOptions<ApplicationDbContext>>();
And get users by directly querying the database :
var users = _context.Users.ToList();
Please also read this article .
I am building web APIs in ASP.NET Core 1.1.
I have a number different databases (for different systems) which have common base schemas for configuration items such as Configuration, Users and groups (about 25 tables in all). I am trying to avoid duplicating the quite extensive EF configuration for the shared part of the model by inheriting from a base class as shown in the diagram.
However, this does not work because of the Entity Framework (EF) requirement to pass DbContextOptions<DerivedRepository> as a parameter to the constructor, where DerivedRepository must match the type of the repository the constructor is called on. The parameter must then be passed down to the base DbContext by calling :base(param).
So when (for example) InvestContext is initialised with DbContextOptions<InvestContext>, it calls base(DbContextOptions<InvestContext>) and EF throws an error because the call to the ConfigurationContext constructor is receiving a parameter of type DbContextOptions<InvestContext> instead of the required type DbContextOptions<ConfigurationContext>. Since the options field on DbContext is defined as
private readonly DbContextOptions _options;
I can't see a way around this.
What is the best way to define the shared model once and use it multiple times? I guess I could create a helper function and call it from every derived context, but it's not nearly as clean or transparent as inheritance.
I would like to bring this post from the OP's GitHub issue to everyone's attention:
I was able to resolve this without a hack by providing a protected constructor that uses DbContextOptions without any type. Making the second constructor protected ensures that it will not get used by DI.
public class MainDbContext : DbContext {
public MainDbContext(DbContextOptions<MainDbContext> options)
: base(options) {
}
protected MainDbContext(DbContextOptions options)
: base(options) {
}
}
public class SubDbContext : MainDbContext {
public SubDbContext (DbContextOptions<SubDbContext> options)
: base(options) {
}
}
OK, I have got this working in a way which still uses the inheritance hierarchy, like this (using InvestContext from above as the example):
As stated, the InvestContext class receives a constructor parameter of type DbContextOptions<InvestContext>, but must pass DbContextOptions<ConfigurationContext> to it's base.
I have written a method which digs the connectionstring out of a DbContextOptions variable, and builds a DbContextOptions instance of the required type. InvestContext uses this method to convert its options parameter to the right type before calling base().
The conversion method looks like this:
protected static DbContextOptions<T> ChangeOptionsType<T>(DbContextOptions options) where T:DbContext
{
var sqlExt = options.Extensions.FirstOrDefault(e => e is SqlServerOptionsExtension);
if (sqlExt == null)
throw (new Exception("Failed to retrieve SQL connection string for base Context"));
return new DbContextOptionsBuilder<T>()
.UseSqlServer(((SqlServerOptionsExtension)sqlExt).ConnectionString)
.Options;
}
and the InvestContext constructor call changes from this:
public InvestContext(DbContextOptions<InvestContext> options):base(options)
to this:
public InvestContext(DbContextOptions<InvestContext> options):base(ChangeOptionsType<ConfigurationContext>(options))
So far both InvestContext and ConfigurationContext work for simple queries, but it seems like a bit of a hack and possibly not something the designers of EF7 had in mind.
I am still concerned that EF is going to get itself in a knot when I try complex queries, updates etc. It appears that this is not a problem, see below)
Edit: I've logged this problem as an issue with the EF7 team here, and a team member has suggested a change to the EF Core core as follows:
"We should update the check to allow TContext to be a type that is derived from the current context type"
This would solve the problem.
After further interaction with that team member (which you can see on the issue) and some digging through the EF Core code, the approach I've outlined above looks safe and the best approach until the suggested change is implemented.
Depending on your requirements you can simply use the non type specific version of DbContextOptions.
Change these:
public ConfigurationContext(DbContextOptions<ConfigurationContext> options):base(options)
public InvestContext(DbContextOptions<InvestContext> options):base(options)
to this:
public ConfigurationContext(DbContextOptions options):base(options)
public InvestContext(DbContextOptions options):base(options)
Then if you create your ConfigurationContext first, the classes that inherit it seem to get the same configuration. It may also depend on the order in which you initialize the different contexts.
Edit:
My working example:
public class QueryContext : DbContext
{
public QueryContext(DbContextOptions options): base(options)
{
}
}
public class CommandContext : QueryContext
{
public CommandContext(DbContextOptions options): base(options)
{
}
}
And in Startup.cs
services.AddDbContext<CommandContext>(options =>
options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
services.AddDbContext<QueryContext>(options =>
options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
alternatively, in a test class:
var connectionString = "Data Source=MyDatabase;Initial Catalog=MyData;Integrated Security=SSPI;";
var serviceProvider = new ServiceCollection()
.AddDbContext<QueryContext>(options => options.UseSqlServer(connectionString))
.BuildServiceProvider();
_db = serviceProvider.GetService<QueryContext>();
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.
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.
The driver seems to be buggy / not updates at all. I found a way to bypass it by modifying the DbContext.
In theory, this should have worked, but it does not:
private string _connectionString;
public ApplicationDbContext(string connectionString) : base()
{
_connectionString = connectionString;
}
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
if (_connectionString == null)
base.OnConfiguring(optionsBuilder); // Normal operation
// We have a connection string
var dbContextOptionsBuilder = new DbContextOptionsBuilder();
optionsBuilder.UseSqlServer(_connectionString);
base.OnConfiguring(dbContextOptionsBuilder);
}
LinqPad EF Core driver keeps looking for the parameterless constructor even if you specify "Via a constructor that accepts a string". That seems like a bug in the driver.
So then I gave it what it wanted, a parameterless contructor. I had to hardcode the connection string since IoC/appsettings.json config reader is not loaded and I don't feel like loading that separately in the DbContext. But it works and lets me test EF Core queries in LinqPad off my model.
This works fine for me:
private bool _isDebug = false;
public ApplicationDbContext() : base()
{
_isDebug = true;
}
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
if (!_isDebug)
base.OnConfiguring(optionsBuilder); // Normal operation
// We are in debug mode
var dbContextOptionsBuilder = new DbContextOptionsBuilder();
// Hardcoded connection string
optionsBuilder.UseSqlServer("data source=XXXX;initial catalog=XXXX;persist security info=True;user id=XXXX;password=XXXX;MultipleActiveResultSets=True;App=EntityFramework");
base.OnConfiguring(dbContextOptionsBuilder);
}
This is in addition to the existing public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : base(options) { } of course.
Edit: Be careful, it looks like this overrides default behavior, which may not be visible until you deploy to the server.
How can you make EF migrations work without hardcoding a nameorconnectionstring in the base of the required parameterless constructor?
EF migrations is forcing you to add a default constructor to the custom dbcontext. In the base of the dbcontext you have to provide a nameorconnectionstring.
public class CustomDbContext : DbContextBase
{
public CustomDbContext ()
: base("theconnectionstringwedontwanttoset") //hardcoded connection string
{
}
The fact that we need to hardcode the constructor is something we cant work with since in our client applications we work without a config file and we dynamically build up the connection since we are connecting to many different databases (server, local sql compact).
After exploring the DbMigrationsConfiguration class I found a DbConnectionsInfo property named TargetDatabase which can be set in the constructor. But even this solution did not work. This is what I did:
public sealed class Configuration : DbMigrationsConfiguration<CustomDbContext>
{
public Configuration()
{
AutomaticMigrationsEnabled = true;
//Setting the TargetDatabase in the hope it will use it in the migration
TargetDatabase = new DbConnectionInfo("Server=xxx;Database=xxx;Trusted_Connection=True", "System.Data.SqlClient");
}
public class MigrationInitializer : MigrateDatabaseToLatestVersion<CustomDbContext, Configuration>
{
}
I can see that eventually the Activator.CreateInstance is used within DbMigrator and I expected from this class to use the TargetDatabase.Create...or something.
Any help or feedback is welcome.
Thanks in advance,
Wilko
it is possible yes See answers here
I also included a test program in this question.