The dark side of Asp.Net Core: Deployment – Part 2, Databases

In the last episode of asp.net core deployment, we saw the author struggle and nearly give up with a basic asp.net core deployment to IIS; then he magically slays the evil giant, the app works and all is well again.  Now, days later, we return to find the author, with much less hair (its all been pulled out), struggling with a new foe: asp.net core WITH  SQL Server database deployment.

In this episode, I will spare you the gory details of hair loss, and just highlight the steps.  Before getting started, I will channel Andy Rooney to complain about the Start Icon on Windows Server 12.  The one in the bottom left corner that only appears on highlight.  Why is that?  Why not show the icon without hovering (or at least give the option to show it).  Alright, enough distraction; move along.

Deploying an asp.net core sql server database:

Step 1. Create a basic asp.net core mvc app with identity (individual user accounts).

Step 2. Create a database on the server in sql server.  FYI:  sql server express can be used on the server for small databases (<10 GB).  Setup permissions for the asp.net core “IIS AppPool\[poolName]” or Network Services or both.   The process is described well here.

Step 3: Formulate a sql connection string for the server instance (example here).

Step 4:  In the top directory of the asp.net core app, duplicate the appsettings.json file, and name the copy, “appsettings.production.json”.  In the project.json file, add this filename to the “publishOptions.include” array.  In the “appsettings.production.json” file, change the default connection to the one created in Step 3.  The basics about this are described here.  As a side note, data in the appsettings file can be accessed either with objects, or given json {Identity:{Authority:’MyAuthority.com’}} with:

Configuration.GetSection("Identity:Authority").Value

 

Step 5: Change the startup.cs file to  get an injected instance of the DB Context. Then use this to call the migrate function on the database (described here).  If no migration exists or is outdated, it will be updated; if it is already uptodate, nothing will change.

public  void Configure( ... ApplicationDbContext dbContext)
        {
            ..

            dbContext.Database.Migrate();

            app.UseIdentity();

Step 6: Publish the app in Visual Studio.

Step 7: Navigate your browser to the URL of the deployed app.

It fails (at least it did for me), with a 500 internal server error.  It is not fixed by changing the web.config to allow for full error messages in the browser,nor by changing the Startup.cs Configure method to call app.UseDeveloperExceptionPage() and  app.UseDatabaseErrorPage().  My error, at least,  was too early, occurring during the startup.cs config method; it would therefore not show up in the browser with any level of coercion.

Instead, on the server, open a command window (or powershell window) in the asp.net core application’s root directory and type “dotnet yourapp.dll”.  Now all the diagnostic info is there with a full call stack.  Fix the errors.

Done. Deployed app with database works.  Another giant slayed, another notch in the armor.  Glue your hair back in place, ready for the next frustration.

 

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.