Develop Reference

Is it possible for EF Core to respect code in OnModelCreating/ConfigureConventions as part of migration code generation?

I don't know if I'm expecting too much, but there have been a few different things I've ran into where I attempted to configure EF Core 6 behavior in OnModelCreating and/or ConfigureConventions that simply don't seem to be respected when new migrations are created.
For example, I would like to force all string properties to be varchar (instead of nvarchar). There are dozens of examples of handling this via model property attributes that do seem to be respected at migration code generation time, but unfortunately they are all at the property level. I have also seen examples setting IsUnicode(false) via overriding ConfigureConventions like so:
protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder)
{
configurationBuilder
.DefaultTypeMapping<string>()
.HasColumnType("varchar")
.IsUnicode(false);
}
But this code doesn't seem to be respected at migration code generation time. It's simply ignored. I realize it will be respected at runtime when queries are being generated, but I'm specifically talking about during development when generating new migration code.
Should this code in ConfigureConventions be respected when new migration code is created such that if I add a new string property to the model and then add a new migration, that the generated code should show the new column type as varchar?
UPDATE per #David Brown's request for repro example:
I created a new .NET6 Core Console app with the following:
Program.cs
using ConsoleApp1;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
IHost host = Host.CreateDefaultBuilder(args)
.ConfigureServices((hostContext, services) =>
{
services.AddDbContext<MyDbContext>();
})
.Build();
host.Run();
MyDbContext.cs
using Microsoft.EntityFrameworkCore;
namespace ConsoleApp1
{
public class MyDbContext : DbContext
{
public MyDbContext(DbContextOptions<MyDbContext> options) : base(options)
{
}
public DbSet<WorkRequest> WorkRequests { get; set; }
protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder)
{
configurationBuilder
.DefaultTypeMapping<string>()
.HasColumnType("varchar")
.IsUnicode(false);
base.ConfigureConventions(configurationBuilder);
}
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
optionsBuilder.UseSqlServer(#"Server=(localdb)\mssqllocaldb;Database=MyDb;Trusted_Connection=True;");
}
}
}
WorkRequest.cs
namespace ConsoleApp1
{
public class WorkRequest
{
public Int64 Id { get; set; }
//[Unicode(false), MaxLength(256)]
public string SubmitterId { get; set; }
}
}
ConsoleApp1.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net6.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="6.0.8" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="6.0.8">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="6.0.8" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="6.0.8">
<PrivateAssets>all</PrivateAssets>
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>
<PackageReference Include="Microsoft.Extensions.Hosting" Version="6.0.1" />
<PackageReference Include="Microsoft.Extensions.Hosting.Abstractions" Version="6.0.0" />
</ItemGroup>
<ItemGroup>
<Folder Include="Migrations\" />
</ItemGroup>
</Project>
I then simply drop to the Package Manager Console and enter:
add-migration InitialCreate -verbose
The resulting migration code always shows SubmitterId as nvarchar(max) unless I use the commented property attribute instead of the ConfigureConventions code:
SubmitterId = table.Column<string>(type: "nvarchar(max)", nullable: false),

The code in OnModelCreating / ConfigureConventions is of course respected in migrations.
The problem you are hitting is the DefaultTypeMapping method, specifically the difference between expectations and what it really does.
Just looking at the method name, one would expect exactly what you did - that it specifies the default mapping for a CLR type. From the other side, there is another method called Properties which returns a builder with similar methods (just starting with Are / Have instead of Is / Has), so it's unclear what's the difference and which one you should use.
The documentation of DefaultTypeMapping does not help a lot:
Marks the given type as a scalar, even when used outside of entity types. This allows values of this type to be used in queries that are not referencing property of this type.
Unlike Properties(Type) this method should only be called on a non-nullable concrete type. Calling it on a base type will not apply the configuration to the derived types.
Calling this is rarely needed. If there are properties of the given type calling Properties(Type) should be enough in most cases.
It shows a small difference in the behavior and says that using the method is rarely needed, but does not say why.
Default type mapping section of the docs is a bit cleaner:
Generally, EF is able to translate queries with constants of a type that is not supported by the provider, as long as you have specified a value converter for a property of this type. However, in queries that don't involve any properties of this type, there is no way for EF to find the correct value converter. In this case, it's possible to call DefaultTypeMapping to add or override a provider type mapping
So, it turns out this method and the associated fluent configuration calls affect only query translation, and not the entity property mappings (thus migrations).
Shortly, inside ConfigureConventions use Properties method and fluent API for configuring the model defaults, and they will be respected everywhere, including migrations, e.g. in your example:
configurationBuilder
.Properties<string>()
//.HaveColumnType("varchar") // not needed, see below
.AreUnicode(false); // abstract way of specifying varchar vs nvarchar
As a side note, be also aware of the following little note in the docs
Data annotations do not override pre-convention configuration.
which means that if you use data annotations (attributes) for non default columns of the type configured via Properties, they won't be respected (you have to use fluent API and OnModelCreating). This is quite important difference from "default" EF Core conventions which have less priority than data annotations, and just another example of poorly documented poor design decision (they say, for me it is implementation bug) difference between logical expectation (we are only overriding default conventions, right?) and the actual behavior.

Entity Framework Core - Custom Migration stopped working

For a while now I've had a custom migration in my Entity Framework Core project that creates some SQL objects - stored procedures and functions.
It looks something like this:
using Microsoft.EntityFrameworkCore.Migrations;
namespace CaseFlow_API.Migrations
{
public partial class AdditionalSQLObjects : Migration
{
protected override void Up(MigrationBuilder migrationBuilder)
{
// Functions
var f_exampleFunction = #"CREATE OR REPLACE FUNCTION public.f_exampleFunction(
character varying,
character varying,
character varying,
integer)
/*
SOME SQL CODE
*/
";
migrationBuilder.Sql(f_exampleFunction);
}
protected override void Down(MigrationBuilder migrationBuilder)
{
}
}
}
However now it stopped working - functions and procedures are not created when updating the db. I don't think I changed anything in how migrations are created. What I would do usually is that I'd run
dotnet ef migrations add Initial
dotnet ef database update
I tried dropping all migrations, dropping the database, recreating the AdditionalSQLObjects.cs class. I have no idea how to debug/fix this.
Can you please point me to places where I can fix this?

Ok, so the custom migration finally works. Here's what I did (added class attributes):
[DbContext(typeof(CaseflowingContext))]
[Migration("CustomMigration_AdditionalSQLObjects")]
public partial class AdditionalSQLObjects : Migration
{
protected override void Up(MigrationBuilder migrationBuilder)
{
//miration code
}
}
I have no idea what happened, because this migration used to work without the attributes, but I'll take it.

ApplicationDbContext.OnModelCreating() in .Net Standard 2.0 has MissingMethodException

this is one of the problems that I issued in "Found conflicts between different versions" OR System.MissingMethodException when using aspnetcore.identity, but I wanted to explain it separately with a small example:
SetUp:
A .Net Standard 2.0 Library
A .Net Framework 4.7.2 WebForms application
The .Net standard Library has this Code:
public class Class1
{
public static void doStuff()
{
var optionsBuilder = new DbContextOptionsBuilder<ApplicationDbContext>();
optionsBuilder.UseSqlServer("MyConnectionString");
var userStore = new UserStore<ApplicationUser, MyRole, ApplicationDbContext, Guid>(
new ApplicationDbContext(optionsBuilder.Options)
); // the userStore.Users property shows already the exception in the debugger
AspNetUserManager<ApplicationUser> userManager = new AspNetUserManager<ApplicationUser>(
userStore,
null,
new PasswordHasher<ApplicationUser>(),
new List<UserValidator<ApplicationUser>>() { new UserValidator<ApplicationUser>() },
null,
null,
null,
null,
null
);
var x = userManager.Users; // exception throw (see next code snipped)
}
}
public class ApplicationDbContext : IdentityDbContext<ApplicationUser, MyRole, Guid>
{
public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}
protected override void OnModelCreating(ModelBuilder builder)
{
base.OnModelCreating(builder); // after userManager.Users is called the exception is thrown here
}
}
And in the WebForms-Project just:
public partial class _Default : Page
{
protected void Page_Load(object sender, EventArgs e)
{
Class1.doStuff();
}
}
Exception:
System.MissingMethodException: 'Methode nicht gefunden: "Microsoft.EntityFrameworkCore.Metadata.Builders.IndexBuilder Microsoft.EntityFrameworkCore.Metadata.Builders.EntityTypeBuilder1.HasIndex(System.Linq.Expressions.Expression1>)".'
Configuration of .Net Standard 2.0 Project:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.Identity" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.Identity.EntityFrameworkCore" Version="2.2.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="3.1.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="3.1.1" />
<PackageReference Include="Microsoft.Extensions.Identity.Stores" Version="3.1.1" />
</ItemGroup>
</Project>
References:
https://github.com/dotnet/aspnetcore/issues/8467 Here they say to update to "Microsoft.AspNetCore.Identity" 3.x, but I cannot do that because its not compatible with the .Net Standard 2.0 project and I need that for the WebForms Project.
So my question would be if someone knows a workaround to generate an Usermanager in a different way... I need to Get and Set Users (and validate) using aspnetcore-identity (database etc. is already migrated)

So, I have a solution for my problem:
use Microsoft.EntityFrameworkCore.SqlServer version 2.2.6 (NOT 3.1.1 even though its supposed to work with .net standard 2.0...)
And a sequence of
deleting nuget packages
clearing nuget cache
deleting nuget packages on the local computer (in the C:/../Users/.../.nuget folder)
changing the nuget management format to "PackageReference"
cry a lot
reinstalling everything and dealing with warnings helped
(I cant say what exactly the issue was regarding the version-conflicts)

EF-Core Single Deployment; Multiple Databases; Migrations

I currently have a .net core web api that has a SQL Server database per client. An api key is required to be passed in for every call and then is looked up in a master tenant database to get the correct connection string. The api will then set the connection string in the startup file and run the call.
Within the api, I have an endpoint that allows me to update all tenants to the latest migration and I also have a console app that will do the same. Something like this:
public async Task UpdateAllDatabases()
{
var qry = await GetAll(null, true);
foreach (var i in qry)
{
var optionsBuilder = new DbContextOptionsBuilder<MigrationContext>()
.UseSqlServer(i.DatabaseConnectionString);
using (var tenantContext = new MigrationContext(optionsBuilder.Options, _appSettings))
{
tenantContext.Database.Migrate();
}
}
}
The issue I am having is when I need to remove-migration. How can I remove a migration from all tenant databases?

You can use the same Migrate method but with the parameter ‘targetMigration’.
This will upgrade or rollback all databases to the specified target migration.
public void Migrate (string targetMigration = null);
(https://learn.microsoft.com/en-us/dotnet/api/microsoft.entityframeworkcore.migrations.imigrator.migrate)
Update: added example
MigrationContext.cs
public class MigrationContext : DbContext
{
}
Execute migrations
using (var tenantContext = new MigrationContext())
{
tenantContext.Database.GetService<IMigrator>().Migrate("targetMigration");
}
.csproj file
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.2</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.2.4" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.2.4" />
</ItemGroup>
</Project>

i'm resloved
EFCoreMigrateMultiDatabase
this is my demo,need replace service IMigrationsScaffolder and IMigrationsAssembly support different database with single dbcontext to migration

How to force a new empty EF Migration?

Ok, so I'm relying completely on my migrations and seed code to maintain all database structure and initial data. Because of that, I'm facing a situation where all the changes I'm doing at this version are made directly on the database (Stored Procs and Updates) and nothing has changed on the C# code itself.
The question is: Since I want to do those DataBase specific changes using a new migration (and an "add-migration" will do nothing - cause the code hasn't change), how can I force a new empty code first migration to put my changes manually on it?

In the package manager console issue the command
Add-Migration "My new empty migration"
This will generate this migration template
public partial class Mynewemptymigration : DbMigration
{
public override void Up()
{
}
public override void Down()
{
}
}
You can then create your own custom up and down migration steps. If you model is not up to date there will be migration code in the up and down. In that case you'll have to get your model up to date and then add a new empty migration.

You have to add an empty migration and add the code to the Up and Down method manually. I have found that people tend to think that the code for those methods have to be generated by the tool similar to ".designer" files and this is not the case. In fact more often than not i have found my self editing and adding code there.
For this purpose I place all the sql code that i have to execute in scripts files and the execute then in the Up methods like this:
public override void Up(){
var dirBase = AppDomain.CurrentDomain.BaseDirectory.Replace(#"\bin",string.Empty) + #"\Migrations\SqlScripts";
Sql(File.ReadAllText(dirBase + #"\CreateMyViews.sql"));
Sql(File.ReadAllText(dirBase + #"\CreateMySproc.sql"));
}
public override void Down(){
var dirBase = AppDomain.CurrentDomain.BaseDirectory.Replace(#"\bin",string.Empty) + #"\Migrations\SqlScripts";
Sql(File.ReadAllText(dirBase + #"\DropMySproc.sql"));
Sql(File.ReadAllText(dirBase + #"\DropMyViews.sql"));
}
I recomend you read this link:
http://elegantcode.com/2012/04/12/entity-framework-migrations-tips/

This is a more up-to-date answer...
In Package Manager Console in Visual Studio, add an empty migration targeting your Database context.
add-migration SeedingFacilityTable -context YourDbContextName
It'll create an empty migration provided you don't have any other DB changes to be applied.
Inside the Up method, write the following:
public partial class SeedingFacilityTable : Migration
{
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.Sql(#"Put as many SQL commands as you want here");
}
protected override void Down(MigrationBuilder migrationBuilder)
{
}
}
Then run the following command:
update-database -context YourDbContextName

Add-migration actually do exactly what's asked for.
You can just run dotnet ef migrations add or Add-Migration in the package manager console (as mentioned by David) to generate a class with empty Up and Down methods. Then just put your changes inside that class as usual.