Entity Framework Core Migrations in a desktop or mobile application - entity-framework-core

Question

I don't want to sound like a jerk here, but it feels like the desktop and mobile applications have been forgotten when migrations were documented.
Given:
It is unacceptable to ask an end user to run any commands to create or migrate a database.
Its not an Asp.Net Core web application so I don't have a startup.cs scaffolded.
When the software is updated on an user's device it must update its own database without user intervention the next time it runs.
This is a code first project.
I'm pretty sure its just a matter of getting the IOC container that the entity framework core code will use and putting the right things into it, but I'll be damned if I can figure out how. Despite my best google-jitsu and bing-fu, I've only been able to find docs or examples that show running using startup.cs in web projects or using the Entity Framework core CLI tools.
public void SomeDesktopAppStartupMethod()
{
var context = new DesktopAppContext();
// ??? - register some migration locator with the IOC container? ¯\(°_o)/¯
context.Database.Migrate();
// Profit!
}

Answer 1

Right cause there really isn't much to the migrations of your database within in a mobile. Since more than likely you are using SQLite (guessing) mobile/uwp apps don't get some of the same treatment that Web gets this is a function of MS not pushing mobile at present if you hadn't noticed. Unfortunate for most of us early adopters but early bird doesn't always get the worm.
More than likely those doing Desktop are going to be using EF not EFC and not usually target SQLite but SqlExpress or SqlLocalDb
Most of my changes for my apps are surface level changes to the database but due to limitations of the migration system you would have to write your own SQL into the UP/Down of a migration to drop columns in SQLite and the reverse to undo your changes. The is a SQLite only limitation at present, for EFC provider.
As for location in the application where I process any migrations since I am using template10 (which is in a refactoring at present) is done where the UIElement CreateRootElement(IActivatedEventArgs e) is being created. Another location to consider would be OnStartUp for the app. It would vary based the development you are doing of course XPlat might make sense where all flavors could take advantage.
Some apps when syncing data I don't bother with migrations and wipe and recreate cause its just easier from that standpoint since all data is server based on Azure.
That being said there are major changes coming from 2.0 with respect to SQLite and EFC, if read correctly there will be a heck of a lot more control over how things are "migrated" or modified from Version X.X of your app.

Answer 2

We're using EFCore and SQLite for our Desktop app! This is what we did for the InitialCreate migration, I can't speak to subsequent migrations, but they should be similar (solution left as exercise to the reader):
1.For the project that contains the DBContext implementation, change the csproj ItemGroup section to include
2.Right click on the project and select Open folder in File Explorer
3.Enter cmd in the command window
4.In the command window enter: dotnet ef migrations add "xxx"
where "xxx" is the name of your migration e.g. InitialCreate, or AddNewTable
5.This resulted in some error messages for me, but in the end it created a
migrations folder with 3 new classes. Date_xxx.cs Date_xxx.Designer.cs and a YourDBContextClassModelSnapshot.cs. Add the folder and classes to your project/source.
6.Ensure your DBContext implementation has an empty ctor.
7.Replace your call to context.DataBase.EnsureCreated() with
context.DataBase.Migrate()
8.Rebuild, sacrifice a few chickens, cross your fingers and hopefully the Migrate() now creates a db with version/migration info. You can edit the .DB file which is mostly binary but will have some text like the following, which does not exist when created via .EnsureCreate()
"MigrationId" TEXT NOT NULL CONSTRAINT "PK___EFMigrationsHistory" PRIMARY KEY,
"ProductVersion" TEXT NOT NULL
Notes: the first time I ran the dotnet command it failed because the EFCore designer/tools weren't loaded. I did some project rebuilds and it seemed to work after that. Also i had a lot of problems with the app during runtime getting "EFCore assembly failing to load" crashes due to different projects referencing different versions. Took many clean/rebuilds to get this working again once the .csprojs were tweaked to ref the same version. Also, out of curiosity i tried The "ef migrations remove" command, but it failed to execute (unable to load Sqlite3), fortunately we don't need to use that cmd yet.