Running EF Core Migrations From Your Own Code

Running EF Core Migrations From Your Own Code
Running EF Core Migrations From Your Own Code

So absolutely everyone who makes use of Entity Framework/EF Core is aware of that you can run migrations from powershell/package supervisor console like so :


And you in all likelihood additionally be aware of that with EF Core, you can additionally use the dotnet ef command like so :

dotnet ef database update

But in uncommon cases, you may also have a want to run migrations on demand from your C#/.NET Core code, maybe with the aid of calling an API endpoint or from an admin screen. This used to be typically extra of an trouble in older variations of Entity Framework that had actual troubles with the “version” of the database versus the “version” that the EF Code concept it have to be. Infact, put simply, it would bomb out.

In EF Core, this is much less of an trouble as your code won’t die till it clearly tries to do some thing that it can’t whole (e.g. Select a column that doesn’t exist yet). But there are nevertheless some instances the place you favor to set up code, take a look at it works in a staging surroundings towards the stay database, then run database migrations on demand.

Migrating EF Core Database From C#

It’s actually very simple.

var migrator = _context.Database.GetService<IMigrator>();
await migrator.MigrateAsync();

Where _context is clearly your database context. That’s it! Crazy loopy simple!

Checking Pending Migrations

It can additionally be extraordinarily reachable checking which migrations want to be run earlier than trying to run them. Even then, it can be beneficial to comprehend which kingdom the database is in from an admin panel or comparable simply to diagnose manufacturing issues. For example, if you roll a guide manner of updating the manufacturing database, it can be beneficial to see if it’s honestly up to date.

await _context.Database.GetPendingMigrationsAsync()

Migrating EF Core On App Startup

In some cases, you virtually don’t care when migrations are run, you simply favor them to migrate the database when the app starts. This is properly for initiatives that the timing of the database migration without a doubt doesn’t count number or is an exceptionally small rollout window. For example, a single computing device of a low use internet app in all likelihood doesn’t want all the bells and whistles for a separate database rollout, it simply wishes to be on the today’s model at any given time.

For that, .NET Core has this new paradigm of a “StartupFilter”. The code appears like so :

public class MigrationStartupFilter<TContext> : IStartupFilter where TContext : DbContext
    public Action<IApplicationBuilder> Configure(Action<IApplicationBuilder> next)
        return app =>
            using (var scope = app.ApplicationServices.CreateScope())
                foreach (var context in scope.ServiceProvider.GetServices<TContext>())

Startup Filters in .NET Core are essentially like Filters in MVC. They intercept the startup method and do “something” earlier than the utility starts, and solely on startup. I absolutely haven’t made an awful lot use of them in the previous however these days I’ve located them to be enormously handy. If you ever made use of the global.asax startup techniques in Full Framework .NET, then this is fairly similar.

We can then add our this filter to our startup pipeline via enhancing our startup.cs file like so :

services.AddTransient<IStartupFilter, MigrationStartupFilter<Context>>();

Where Context is our database context. Again, top notch easy stuff however some thing that you’ll likely quit up the use of in each new undertaking from now on!

Leave a Reply

Your email address will not be published. Required fields are marked *

14 + ten =

You May Also Like
Twelve-Factor Application of Microservices
Read More

The Twelve-Factor App

Introduction In the current era, software program is usually delivered as a service: referred to as net apps,…