In this section I discuss the application configuration and set the connection string for the application. Next we discuss the runtime environments, how they are set, and the effect on application configuration.
- [Instructor] Now that we have the data access layer completely migrated and tested, let's migrate the Web API 2.2 site over to ASP.NET Core. A couple of important concepts to understand are application settings and runtime environments as these have drastically changed since Web API 2.2. In prior versions of ASP.NET, application configuration was done through a Web.config file by adding in different settings.
Configuration settings in ASP.NET Core is now, by default, handled in json files and the project template starts you off with an appsettings.json file. You can use other providers but the default is json. You can also set different configurations for different environments. So for example, if you have appsettings.development.json then that will be used if your application runtime environment is set to development and we'll talk about those shortly.
So the only migration that we need to do is to move the connection string from the Web.config into the appsettings file. Let's do that now. So in our project we see an appsettings.json file and underneath of it an appsettings.development.json. If we look at the settings file, we just have one setting for logging and then in the development version, we have additional settings for the logging node.
We'll see how we pull these settings into our project shortly but for now we need to add in the connection string. So I'm going to copy from the finished solution, again to save a whole bunch of typing, and paste in the connections string that we've used in the data access layer test file. You can see the database is SpyStoreShortCore. So you'll need to update that if you change the name as well as update the server if you're not using local DB.
Now let's add in production and staging setting files as well. So let's copy the development. We'll change the name to appsettings.staging and you'll see it automatically comes underneath the appsettings file, and we'll do that once more. Copy and paste. And we'll call this one production.
Typically the use for this is to have different settings for different environments. You could do this is ASP.NET with the Web.config, although there was a little bit of magic and trickery involved. Once you got it figured out it was pretty simple but this is much more straightforward. So let's add in the production connection string and we will just call this Foo because we're not actually going to change the environment to production and we'll add in a staging connection string and we'll call this one Bar.
So within the file itself, based on the application's runtime environment, it will pull in different settings. Let's see how that's done. If we go into the startup class, which we'll talk more about shortly, right here in the constructor we have a configuration builder and then sending the base path to the content root, that just means that it's going to be the root of the project, and we add a json file called appsettings.json.
So this pulls in all of our settings across all environments. It is not optional, as we see here on line 19. We have to have a settings file. And, do we want to reload it on change? And the answer is usually yes. The next file loaded on line 20 is the appsettings environmentname.json and it is optional. Last one in wins, so if we have a connections string set in appsettings.json, for example maybe a default, then the appsettings.development.json would overwrite that.
So now that we have the configurations set, let's talk about the different runtime environments. So the environment is set with the ASPNETCORE_ENVIRONMENT variable. The default options are development, staging and production and there's some helpful methods to use those specific names, but it can be any string value. This environment is configured several different ways. In the VS project debug properties in the lauchsettings.json which we will look at shortly, through the command line by setting the environment or through the control panel.
So the advantage here over prior versions, is as you move your code from an environment to environment nothing has to change. With the Web.config file in prior versions that only worked using MSBuild and, as I said earlier, there was a little bit of friction getting that to work correctly. This is super simple and as you move through your environments it'll automatically pick up the changes needed. So let's look in Visual Studio and our project to see where that is configured.
If we go under properties, there's a launchsettings.json file and this sets up two different profiles: one for IIS Express and another one for Kestrel. And we'll talk about running the application in the next section. The items of note that we want to look at here are the URLs, so under IIS here on line six it will run on port 6-0-9-1-0 and under Kestrel it'll run under 6-0-9-1-1.
For both of these profiles we can see an environment variables entry and we see that at the ASP.NET Core environment setting is development for both IIS Express and Kestrel. The other place where you can see this set is if you go into the properties for the project and you can hit alt enter or right click and select properties. Under debug, here in the environment variables section we can see that the ASPNETCORE_ENVIRONMENT is set to development.
This page here mirrors the launchsettings.json file with the IIS Express settings.
- Creating the .NET Core project
- Adding Entity Framework
- Migrating the data access layer (DAL)
- Configuring services and the HTTP pipeline
- Adding remaining services to the dependency injection container
- Migrating controllers and actions
- Testing the services