System.Data.Entity.ModelConfiguration missing in EF core - entity-framework-core

Trying to load all the configurations dynamically on OnModelCreating for Entity framework core.
what is the other way around if ModelConfiguration is missing.

It's even easier in Core 2.0 now
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Metadata.Builders;
namespace MyApp.DAL.EntityConfigurations
{
public class StudentConfiguration : IEntityTypeConfiguration<Student>
{
public void Configure(EntityTypeBuilder<Student> modelBuilder)
{
modelBuilder.Property(f => f.Name).IsRequired();
}
}
}
Then in your db context:
public DbSet<Student> Students{ get; set; }
public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options) : base(options) { }
protected override void OnModelCreating(ModelBuilder builder)
{
base.OnModelCreating(builder);
// Customizations must go after base.OnModelCreating(builder)
builder.ApplyConfiguration(new StudentConfig());
builder.ApplyConfiguration(new SomeOtherConfig());
// etc.
// etc..
}

I've just stumbled across this question as I was searching for the answer myself. I found that it is not (yet?) implemented in EF Core but can be implemented yourself fairly easily.
You can create one of these:
using Microsoft.EntityFrameworkCore.Metadata.Builders;
namespace Microsoft.EntityFrameworkCore
{
public abstract class EntityTypeConfiguration<TEntity> where TEntity : class
{
public abstract void Map(EntityTypeBuilder<TEntity> modelBuilder);
}
public static class ModelBuilderExtensions
{
public static void AddConfiguration<TEntity>(this ModelBuilder modelBuilder, EntityTypeConfiguration<TEntity> configuration) where TEntity : class
{
configuration.Map(modelBuilder.Entity<TEntity>());
}
}
}
And then you can create a configuration for the entity itself: -
using Microsoft.EntityFrameworkCore;
using Project.Domain.Models;
using Microsoft.EntityFrameworkCore.Metadata.Builders;
namespace Project.Persistance.EntityConfigurations
{
public class MyEntityConfiguration : EntityTypeConfiguration<MyEntity>
{
public override void Map(EntityTypeBuilder<MyEntity> modelBuilder)
{
modelBuilder
.Property();//config etc
}
}
}
You can then load all your configurations somewhere (there's probably both a better way and a better place for doing it... but this is what I did): -
using Microsoft.EntityFrameworkCore;
using Project.Domain.Models;
using Project.Persistance.EntityConfigurations;
namespace Project.Persistance
{
public class MyDbContext : DbContext
{
// Normal DbContext stuff here
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.AddConfiguration(new MyEntityConfiguration());
}
}
}

Related

EntityFramework 6 Add-Migration with wrong placement of usings statement

We maintain an EF 6 project but I realized that Adding a new migration always generate the files like this which gives an error
namespace App.Data.Migrations
{
using System;
using System.Data.Entity.Migrations;
public partial class AddViews : DbMigration
{
public override void Up()
{
}
public override void Down()
{
}
}
}
instead of like this
using System;
using System.Data.Entity.Migrations;
namespace App.Data.Migrations
{
public partial class AddViews : DbMigration
{
public override void Up()
{
}
public override void Down()
{
}
}
}
I am using VS 2019 and I can't tell why I need to be moving it everytime

Cannot construct DbContext without using OnConfiguring(DbContextOptionsBuilder optionsBuilder)

I am developing a .NET CORE MVC 2.1 Web Application with a DbContext declared in a DLL (EF Core 2.1).
I would like to configure the context using IServiceCollection.AddContext<GladContext> but if I do not ALSO configures it DbContext.OnConfiguring(DbContextOptionsBuilder optionsBuilder) I am told that No database provider has been configured for this DbContext despite having a constructor taking a DbContextOptions<GladContext>
public GladContext(DbContextOptions<GladContext> options, IGladConnectionStringProvider connectionStringProvider) : base(options)
{
_connectionStringProvider = connectionStringProvider;
}
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
GladOptionsBuilderHelper.ConfigureDefaultOptionsBuilder(optionsBuilder, _connectionStringProvider.ConnectionString);
base.OnConfiguring(optionsBuilder);
}
The IGladConnectionStringProvider is my current workaround and that is acceptable if it wasn't because I now need to configure both DbContextOptionsBuilder and DbContextOptionsBuilder<GladContext>
public static class GladOptionsBuilderHelper
{
public const string GladMigrationsHistory = "__GladMigrationsHistory";
public static DbContextOptionsBuilder<GladContext> CreateDefaultTypedOptionsBuilder(string connectionString)
{
var optionsBuilder = new DbContextOptionsBuilder<GladContext>();
optionsBuilder
.UseSqlServer(connectionString, options =>
{
options.EnableRetryOnFailure();
options.MigrationsHistoryTable(GladMigrationsHistory, EntityBase.SchemaName);
})
.ConfigureWarnings(warnings => warnings.Throw(RelationalEventId.QueryClientEvaluationWarning));
return optionsBuilder;
}
public static void ConfigureDefaultOptionsBuilder(DbContextOptionsBuilder optionsBuilder, string connectionString)
{
optionsBuilder
.UseSqlServer(connectionString, options =>
{
options.EnableRetryOnFailure();
options.MigrationsHistoryTable(GladMigrationsHistory, EntityBase.SchemaName);
})
.ConfigureWarnings(warnings => warnings.Throw(RelationalEventId.QueryClientEvaluationWarning));
}
}
The DbContextOptionsBuilder<GladContext> is used in IDesignTimeDbContextFactory<GladContext>
Can you can tell me how to use AddContext to configure GladContext or how to construct a DbContextOptionsBuilder from a DbContextOptionsBuilder<GladContext> or the other way around?
The configuration part of it is an override of the IServiceCollection.AddDbContext().
So, when you call AddDbContext, just add your options into the parentheses like so:
var connectionString = "CONNECTION-STRING-HERE";
services.AddDbContext<MyContext>(o => o
.UseSqlServer(connectionString)
.UseQueryTrackingBehavior(true)
.EnableSensitiveDataLogging(true));
public class MyContext : DbContext
{
public DbSet<Blog> Blogs { get; set; }
public MyContext(DbContextOptions<MyContext> options) : base(options)
{
}
}

No extension Method ToList on a dbset - really though?

Background - I am using Entity framework code version 2.1.4-rtm-31024
check out the CODE LISTING 1 - the problem (according to Ms Build Engine 15.9) is that GetAllMakes calls .ToList, but no 'ToList' method exists for a DbSet of VehicleMake. (check out Code Listing 2) to see the implementation of _vehicleContext.VehicleMakes
Why do I get a compile error? this makes no sense to me since I can call VehicleMakes.ToList() elsewhere in the code (no compiler error) no problem at all - see listing 3 for an example.
CODE LISTING 1
using System.Collections.Generic;
namespace CarPriceComparison.Models
{
public class VehicleRepository : IVehicleRepository
{
private VehicleContext _vehicleContext;
public VehicleRepository(VehicleContext dbContext_)
{
_vehicleContext = dbContext_;
}
public IEnumerable<VehicleMake> GetAllMakes()
{
return _vehicleContext.VehicleMakes.ToList();
}
}
}
CODE LISTING 2
namespace CarPriceComparison.Models
{
public class VehicleContext : DbContext
{
private IConfigurationRoot _config;
public VehicleContext(IConfigurationRoot config_, DbContextOptions
options_) : base(options_)
{
_config = config_;
}
public DbSet<VehicleMake> VehicleMakes {get; set;}
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
base.OnConfiguring(optionsBuilder);
optionsBuilder.UseSqlServer(_config["ConnectionStrings:VehicleContextConnection"]);
}
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<VehicleModel>()
.HasOne(p => p.Make)
.WithMany(b => b.Models)
.HasForeignKey(p => p.VehicleMakeForeignKey)
.IsRequired()
.OnDelete(DeleteBehavior.Cascade);
}
}
}
CODE LISTING 3
private VehicleContext _vehicleContext;
private IMailService _mailService;
private IConfigurationRoot _config;
public HomeController(IMailService mailService_, IConfigurationRoot
config_, VehicleContext vehicleContext_)
{
_vehicleContext = vehicleContext_;
_mailService = mailService_;
_config = config_;
}
public IActionResult Index()
{
var vehicleData = _vehicleContext.VehicleMakes.ToList();
return View();
}
I think you missing an using statement.
using System.Linq;

How to Resolve multiple DBContext call using generic UnitOfWork<TContext> in Autofac

Hi I have created my UnitOfWork as generic and at runtime it should create new instance of DB context with DBContextOption Builder on the basis of TContext passing I have registered Mention DB Context in autofac but how to resolve this at DB Context Constructor Level
DB Context 1 Implemetation
public class DBContext1 : DbContext
{
public DBContext1(DbContextOptions<DBContext1> options1) : base(options1)
{
}
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
}
}
DB Context 2 Implemetation
public class DBContext2 : DbContext
{
public DBContext2(DbContextOptions<DBContext2> options2) : base(options2)
{
}
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
}
}
IUnitOfWork interface Implemetation
public interface IUnitOfWork<TContext> where TContext : DbContext, IDisposable
{
}
UnitOfWork class Implemetation
public class UnitOfWork<TContext> : IDisposable, IUnitOfWork<TContext> where TContext : DbContext, new()
{
private DbContext _context;
public UnitOfWork()
{
_context = new TContext();
}
}
StartUp Class Implemetation
public class Startup
{
protected IConfiguration _configuration { get; set; }
public Startup(IConfiguration configuration)
{
_configuration = configuration;
}
public IServiceProvider ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.AddEntityFrameworkSqlServer()
.AddDbContext<DBContext1>(options =>
options.UseSqlServer(_configuration.GetConnectionString("DBContext1")))
.AddDbContext<DBContext2>(options =>
options.UseSqlServer(_configuration.GetConnectionString("DBContext2")));
/* Autofac DI Configuration with registering DBContext/DataModule/ServiceModule to it */
var containerBuilder = new ContainerBuilder();
containerBuilder.RegisterInstance(_configuration).AsImplementedInterfaces().ExternallyOwned();
var autoFacOptions1 = new DbContextOptionsBuilder<DBContext1>().UseSqlServer(_configuration.GetConnectionString("DBContext1")).Options;
var autoFacOptions2 = new DbContextOptionsBuilder<DBContext2>().UseSqlServer(_configuration.GetConnectionString("DBContext2")).Options;
containerBuilder.Register(c => new DBContext1(autoFacOptions1)).As<DbContext>();
containerBuilder.Register(c => new DBContext2(autoFacOptions2)).As<DbContext>();
containerBuilder.RegisterModule<DataModule>();
containerBuilder.RegisterModule<ServiceModule>();
containerBuilder.Register<String>(c => Guid.NewGuid().ToString())
.Named<String>("correlationId")
.InstancePerLifetimeScope();
containerBuilder.Populate(services);
var container = containerBuilder.Build();
return new AutofacServiceProvider(container);
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
app.UseMvc(routes =>
{
routes.MapRoute(
name: "default",
template: "{controller=Account}/{action=Login}/{id?}");
});
app.Run(async (context) =>
{
await context.Response.WriteAsync("Hello World!");
});
}
}
I am able to achieve multiple DBContext Call as required but I have to create Default constructor & connection string in DB context like mention below
DB Context 1 Implemetation
public class DBContext1 : DbContext
{
public DBContext1()
{
}
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseSqlServer(#"Data Source=Server;Database=DB;User Id=UserID;Password=Password;Integrated Security=False;MultipleActiveResultSets=true;");
}
public DBContext1(DbContextOptions<DBContext1> options1) : base(options1)
{
}
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
}
}
DB Context 2 Implemetation
public class DBContext2 : DbContext
{
public DBContext2()
{
}
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseSqlServer(#"Data Source=Server;Database=DB;User Id=UserID;Password=Password;Integrated Security=False;MultipleActiveResultSets=true;");
}
public DBContext2(DbContextOptions<DBContext2> options2) : base(options2)
{
}
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
}
}
Please help me to call parameterised constructor of DBContext1 & DBContext2 using autofac dependency resolver
Well, if you're using autofac to resolve dependencies then why are you trying to do its job for it? :) That's the main problem with your code.
First of all, you don't need to register IConfiguration explicitly. It is already registered in the IServiceCollection that's passed to ConfigureServices() method and will be automatically picked up by autofac during containerBuilder.Populate(services) call. You can just remove this registration and nothing will change.
Further, you're registering both your DbContexts twice - in the service collection and in the autofac container builder. This is not necessary as the latter will effectively replace the former. Also, it creates confusion about what is registered where and how this whole this is going to work. It's better to pick one method of registration and stick with it.
Next problem: how are you going to unit test your unit of work? It has hard dependency on DbContext whose lifecycle you cannot control in tests. This is exactly what you need autofac for: manage component's dependencies for you allowing you to concentrate on the component's purpose and not on the secondary stuff.
Next confusion point is here:
containerBuilder.Register(c => new DBContext1(autoFacOptions1)).As<DbContext>();
containerBuilder.Register(c => new DBContext2(autoFacOptions2)).As<DbContext>();
By doing this you are effectively replacing first db context registration with the second. From this point there is no way to inject DBContext1 anywhere in your application. EDITED: You still can inject collection of DbContext derivative implementations and find DBContext1 among them... but that would look very weird.
All in all, this can be done in much more clean and straightforward way.
Startup
public class Startup
{
public Startup(IConfiguration configuration)
{
Configuration = configuration;
}
public IConfiguration Configuration { get; }
public IServiceProvider ConfigureServices(IServiceCollection services)
{
services.AddMvc();
var builder = new ContainerBuilder();
builder.Register(c => c.CreateDbContextOptionsFor<DBContext1>("DBContext1")).As<DbContextOptions<DBContext1>>().SingleInstance();
builder.Register(c => c.CreateDbContextOptionsFor<DBContext2>("DBContext2")).As<DbContextOptions<DBContext2>>().SingleInstance();
builder.RegisterType<DBContext1>().AsSelf().InstancePerLifetimeScope();
builder.RegisterType<DBContext2>().AsSelf().InstancePerLifetimeScope();
builder.RegisterType<SomeComponent>().As<ISomeComponent>().InstancePerLifetimeScope();
builder.RegisterGeneric(typeof(UnitOfWork<>)).As(typeof(IUnitOfWork<>)).InstancePerLifetimeScope();
builder.Populate(services);
var container = builder.Build();
return new AutofacServiceProvider(container);
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
....
}
}
CreateDbContextOptionsFor helper implementation. It is introduced in order to make Startup code concise and more readable. It can probably be improved even further by making use of autofac's parameterized factory instead of new DbContextOptionsBuilder<TContext>(), but I'm not sure if there's a point in it in this case.
public static class DBExtentions
{
public static DbContextOptions<TContext> CreateDbContextOptionsFor<TContext>(this IComponentContext ctx,
string connectionName) where TContext : DbContext
{
var connectionString = ctx.Resolve<IConfiguration>().GetConnectionString(connectionName);
return new DbContextOptionsBuilder<TContext>().UseSqlServer(connectionString).Options;
}
}
UnitOfWork
public class UnitOfWork<TContext> : IUnitOfWork<TContext> where TContext : DbContext
{
private TContext _context;
public UnitOfWork(TContext context)
{
_context = context;
}
}
Injecting and using unit of work
public class SomeComponent : ISomeComponent
{
private readonly IUnitOfWork<DBContext1> _uow;
public SomeComponent(IUnitOfWork<DBContext1> uow)
{
_uow = uow;
}
public void DoSomething()
{
_uow.DoWhatever();
}
....

How to dispose Entity Framework Core in-memory database

I want to create clean inmemory database in each unit test.
When I run multiple tests, data from previous tests remains in the database. How to dispose existing inmemory database?
I initialize each test with following code:
[TestInitialize]
public void TestInitialize()
{
Services = new ServiceCollection();
Services.AddScoped<DbContextOptions<MyDbContext>>(sp => new DbContextOptionsBuilder<TacsDbContext>()
.UseInMemoryDatabase("MyTestDbContext")
.Options);
Services.AddTransient<InMemoryMyDbContext>();
Services.AddTransient<MyDbContext>(sp => sp.GetService<InMemoryTacsDbContext>());
ServiceProvider = Services.BuildServiceProvider();
}
[TestMethod]
public void Test1()
{
using (var dbContext = ServiceProvider.GetService<MyDbContext>()) ...
}
[TestMethod]
public void Test2()
{
using (var dbContext = ServiceProvider.GetService<MyDbContext>()) ...
}
I use .NET Core 2.0, and Entity Framework Core 2.0
EDIT
I wasn't able to use the standard registration: Services.AddDbContext<InMemoryMyDbContext>(...), because
public class InMemoryMyDbContext : MyDbContext
{
public InMemoryMyDbContext(DbContextOptions<InMemoryMyDbContext> options)
: base(options) { } //compiler error
public InMemoryMyDbContext(DbContextOptions<MyDbContext> options)
: base(options) { } //runtime IoC error
}
public class MyDbContext : DbContext
{
public MyDbContext(DbContextOptions<MyDbContext> options)
: base(options) { }
}
Ok, the solution in my case was to call DbContextOptionsBuilder.UseApplicationServiceProvider()
Services.AddScoped<DbContextOptions<MyDbContext>>(sp => new DbContextOptionsBuilder<MyDbContext>()
.UseApplicationServiceProvider(sp)
.UseInMemoryDatabase("Test")
.Options);
This method is called automatically when you setup ServiceCollection the usuall way, so in following case the database is created from scratch each time
Services.AddDbContext<MyDbContext>(options => options.UseInMemoryDatabase("Test"));
At the end, I was able to modify MyDbContext so that I call the line above:
public class MyDbContext : DbContext
{
protected MyDbContext (DbContextOptions options) : base(options) { }
public MyDbContext (DbContextOptions<MyDbContext> options)
: this((DbContextOptions)options) { }
}
public class InMemoryMyDbContext : MyDbContext
{
public InMemoryMyDbContext (DbContextOptions<InMemoryTacsDbContext> options)
: base(options) { }
}
Services.AddDbContext<InMemoryMyDbContext>(options =>
options.UseInMemoryDatabase("Test"), ServiceLifetime.Transient);
Services.AddTransient<MyDbContext>(sp => sp.GetService<InMemoryMyDbContext>());
Consider using the Nuget package Effort
It is a simple and fast in-memory database ideal for unit-testing
You can start it with an empty database; if desired fill it using a database seeder, or fill it with values from a test CSV file.
See Tutorials Effort - Entity Framework Unit Testing Tool
Your DbContext probably will look similar to:
class MyDbContext : DbContext
{
public MyDbContext() : base() { } // constructor using config file
public BloggingContext(string nameOrConnectionString) :
base(nameOrConnectionString) { }
public DbSet<...> ...{ get; set; }
public DbSet<...> ...{ get; set; }
}
Just add one constructor and you can use your in-memory database as if it was your original database:
public MyDbContext(DbConnection connection) : base(connection, true) { }
You pass the DbConnection to the test database, this connection is passed to the DbContext class. The true parameter says that when the DbContext is disposed, that the DbConnection should also be Disposed.
Usage would be:
[TestMethod]
public void UnitTest_X()
{
var dbConnection = Effort.DbConnectionFactory.CreateTransient();
using (var dbContext = new MyDbContext(dbConnection)
{
// perform your test of MyDbContext as if it was connected to your
// original database
}
}
A simple copy-paste code example for a console program with an Effort database that uses a one-to-many relationship can be found here on StackOverFlow