OdeToCode IC Logo

.NET Core Opinion 12 – Use Your ASP.NET Core App as an Executable

Wednesday, March 27, 2019

There is a special moment of time in the life of every ASP.NET Core process when the application has all the services registered and all the configuration sources in place, but has not yet started to listen for HTTP messages. This is a moment in time you can seize and use to your advantage.

I tell people to think of their ASP.NET Core application as a console application that happens to listen for network connections, because there are many useful tasks the application can perform at development time and in production. Examples would be tasks like migrating database schemas, clearing a distributed cache, and creating storage containers.

public static void Main(string[] args)
{
    var host = CreateWebHostBuilder(args).Build();

    // the moment in time when magic can happen
    ProcessCommands(args, host);

    host.Run();
}

Let’s drill into database migrations. Many people will say we need to keep automatic migrations out of web applications because the results in a server farm are unpredictable. Good advice! I’m not suggesting you implicitly run migrations as a side-effect of the first HTTP request. I’m promoting the use of the application to explicitly run migrations when the app receives the right command line parameter. Think of the parameter as an automation point, and you can now migrate a database from a deployment script, or from a development shell.

Another objection is how executing utility tasks in the application feels like a violation of the single responsibility principle at the application level. Why not build a separate console application to execute utility tasks and leave the main app for processing web requests? This is possible, but you’ll find yourself needing to reuse or duplicate configuration code from the web application. Using database migrations as a concrete example again, there is a lot of work that goes into building the right services and configuration for a specific environment, including non-trivial steps like connection string decryption and network communication with key storage services. The app, assuming it works, is setup perfectly to have everything in place for a specific environment like production, staging, or development.

Here’s another example of something I’ve done in the past. On this project I could run the following command to drop the development database, recreate the database using migrations, seed the database with data, and then exit instead of entering into web server mode.

dotnet run  dropdb migratedb seeddb stop

The overall theme here is not about database specific tasks, but about automating common tasks to make development, testing, and deployments faster and more repeatable. The perfect tool for these jobs might just be the application you are already have!


Comments
Gravatar Wouter Thursday, March 28, 2019
Interesting! Would you also use this approach for a cloud deployment? E.g. a web app running in an App Service?
Gravatar scott Thursday, March 28, 2019
Yes - maybe not the deployment itself, but possibly as part of deployment.
Gravatar Lucas Vogel Wednesday, April 10, 2019
I've always wondered about the possibility of scenarios where you have a command-line tool that could move in and out of (self-hosted or even server-driven) web page mode, where you could do things like set configuration settings, or look at a database, as part of your command line workflow -- something optional that you could leverage if you were working in a GUI desktop environment, for example. For example, whenever setting up the Google Cloud SDK, whether on Windows or Linux (I run a KUbuntu instance on my Surface Pro 4) it will pop up a web site for user authentication, then save the outcome into a file for future authentication. But I wonder if that model could be used or even extended upon in an ASP.NET Core application...
Comments are closed.