How to apply existing migrations for ApplicationDbContext in Release build of ASP.NET Core web application using SQLite

Question

I am unable to apply existing migrations for ApplicationDbContext on the Release build of my ASP.NET Core web application using SQLite database. As a result, I have to copy over my sqlite .db file from Debug build (which I am able to apply migrations) to the Release build just so I can deploy it on my Ubuntu Server. Either that, or I have to call app.UseDatabaseErrorPage(); in the public void Configure() method inside Startup.cs for Production environment, which is not recommended.

To recreate the issue, create an ASP.NET Core Web Application (.NET Core) in Visual Studio with Individual User Accounts Authentication. I called my project Hevn .

Then, update project.json to use SQLite instead of SQL Server.

// Change from this
"Microsoft.EntityFrameworkCore.SqlServer": "1.0.1",
"Microsoft.EntityFrameworkCore.SqlServer.Design": {
  "version": "1.0.1",
  "type": "build"
},

// to this
"Microsoft.EntityFrameworkCore.Sqlite": "1.0.1",
"Microsoft.EntityFrameworkCore.Sqlite.Design": {
  "version": "1.0.1",
  "type": "build"
},

Then, update Startup.cs to use SQLite instead of SQL Server:

// Change from this
services.AddDbContext<ApplicationDbContext>(options =>
  options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));

// to this
services.AddDbContext<ApplicationDbContext>(options =>
  options.UseSqlite(Configuration.GetConnectionString("DefaultConnection")));

Then, open appsettings.json and change DefaultConnection to use SQLite database. (I named mine Hevn.db ):

// Change DefaultConnection to use SQLite database called Hevn.db
"ConnectionStrings": {
  "DefaultConnection": "Data Source=./Hevn.db"
},

Then open Command Prompt and apply migrations by navigating to the project and running dotnet ef database update

cd "%USERPROFILE%/Documents/Visual Studio 2015/Projects/Hevn/src/Hevn"
dotnet ef database update
dotnet run

This creates bin/Debug/netcoreapp1.0 folder and inside that folder resides Hevn.db sqlite database file. When I browse the sqlite file, I can see that the tables necessary for authentication have been created (ie AspNetUsers table).

However, I am unable to do this for the release build. I can run dotnet build -c Release to build a Release version of my app under bin/Release/netcoreapp1.0 . I can also run dotnet run -c Release to run the Release version of my app. Running the Release version will create Hevn.db sqlite file under bin/Release/netcoreapp1.0 , but browsing the sqlite file shows that no table has been created.

At this point, my only option is to copy the Hevn.db file from Debug into Release build.

I also tried dotnet ef database update -e Production , but that still creates Hevn.db under Debug build.

When I run my ASP.NET Core web app in Debug mode before applying migration, I get the following screen when I attempt to Register/Login. I can simply click Apply Migrations or run dotnet ef database update to apply migrations and Registration/Login works using SQLite.

But when I run my ASP.NET Core web app in Release mode, I get the following screen when I attempt to Register/Login. There is no way I can apply migrations to the Release build.

Is it possible to apply migrations on Release build of ASP.NET Core web app? Or do I have to resort to copying over database migrated sqlite file from Debug to Release?

Answer 1

dotnet ef database update is the correct command. However by default it runs under debug configuration. -e changes the Environment (ie affects code like env.IsDevelopment()) It won't make it run under Release. -c before database should do that. Please see https://docs.microsoft.com/en-us/ef/core/miscellaneous/cli/dotnet

Another alternative is having different connectionstrings based on the environment and then you could use -e to control which environment to use.

Answer 2

this command created my sqlite database in the release folder:

dotnet ef database update --configuration release

but then i'm using the new msbuild .csproj rather than project.json and latest SDK. Not sure if that might be affecting you?