This video covers the new environmental awareness in ASP.NET Core, and the updated configuration system.
- [Instructor] Environmental awareness is another new feature is ASP.NET Core. It uses the ASP.NET Core underscore environment variable to determine what environment the application is running in. There are built-in environment variables of development staging in production, and this value is used throughout ASP.NET Core. It helps determine which configuration files to load, you can run different code based on the environment using the IHostingEnvironment framework provider, and it's also used by the environment tag helper.
Now, this simplifies deployment in testing. If I have the environment set to development on my machine and the configuration for the development environment loads my local sequel server instance, then when I move it to staging, the staging configuration file can load the staging connection string, and production can load the production connection string, et cetera. This greatly simplifies the process that we used to do in NVC, where we would take to different web configs and have to use the publish process in MSBuild to change the values based on a certain environment.
So let's look at how this works in our project. In launchsettings.json, we have for the IISExpress profile here on line 15, the environment set to developent. And for kestrel, it is also set to development. When you run through visual studio or from the command line if a launchsettings.json file is present, it will pick up that environment. You can also set it from the command line through your environment variables on your particular system.
If we look in startup, we're going to talk about configuration next, but this is where we actually add the JSON files into the configuration and there's a special environment dot environment name variable here on line 33 that will then add appsettings.development.json or appsettings.production.json or whatever your environment name is. And, to be clear, you can use any string that you want, but there is certain built-in support for development staging and production so the recommendation is to stick with those.
Not only can you choose which JSON file to load based on the environment, you can also make code decisions based on the environment. If we go down here to the configure method, and we're going to cover these methods and configurations soon, but, again, using the Ihostsingenvironment right here on line 75 it's passed into the configure method. We can then say if the environment is development, as we do on line 80, then use a developer exception page, do some very specific things when we're in development.
Applications are configured using simple JSON files, command-line arguments, environment variables, in-memory .NET objects, an encrypted user store, or you can even add your own custom providers. Configuration values are set in the order received. So when we saw the example of the appsettings.environment.json file being loaded after the appsettings.json file, any values in the appsettings.environment, for example, .development.json would overwrite anything that was in the regular appsettings.json file.
You can also create custom classes that represent configuration values. You can bind either the entire configuration or what's better and what most people do is bind individual sections of a configuration with services.Configure. Now, that configures your custom class, populating it with the right values, and it adds it to the DI container. And then you can inject it in with Ioptions of T. This does require the Microsoft.Extnesions.Options.ConfigurationExtension., whoa, long name, package.
Fortunately, that is included in the Microsoft.ASP.NET Core metapackage that comes standard with the default template. There are some changes I want to call out in 1.1 and 2.0. ReloadOnChange is only supported in 1.1 and later, so even though the 1.0 template includes that parameter, it's not supported. And also, 1.1 we get Azure Key Vault configuration provider. And then 2.0 changes how the configuration is called.
And we'll certainly cover those in those chapters. So let's look at how configuration works in ASP.NET Core. So here's our appsettings.json file. You see it's just regular old JSON. Connection strings, default connection, we have a logging section starting here on line five. And then I have some custom settings here on line 11. I also have an appsettings.development. And what this does is add some additional log level information.
So when we're running in development, we will actually get more logging than if we're running in production. You saw where these were loaded when we're talking about environment awareness, but now let's talk a little bit more about it. Go ahead and hide Solution Explorer. So when we create our configuration with a configuration builder, so this is what we use in ASP.NET Core is a configuration builder, we set the base path so it knows where to find those files, and then we add the appsettings.json and we make it required by setting the optional flag to false.
We then look for an appsettings.environment.json file and we make this one optional. So if there is not an appsettings.production.json and the environment variable is set to production, it won't error. It just won't load any files. Let's look at our custom settings class. And this is a very simple example, but I've got a string in an ints just named Setting1 here on line 14, and Setting2 on line 15. We go back to our startup class.
Actually, let's go back into appsettings. Here's my Setting1 and my Setting2. Those names need to match. And then in my startup, down here on line 70, I see services.Configures. So that services, of course, is the DI services. Configure the CustomSettings class by getting the information from the CustomSettings section. So that would create an instance of CustomSettings based on that section of the config file, and then we can inject that in to Controllers or really any class using constructor injection.
And we can also use method injection and view injection as well. So here in the home controller, I'm injecting in the custom settings, and we use the IOptions interface to do this. And then it's just a class that we have access to. So very powerful stuff.
- Running and debugging ASP.NET Core applications
- Pros and cons of migrating existing applications to ASP.NET Core.
- Built-in dependency injection
- Environment awareness and app configuration
- Web host configuration and SSL
- View components invoked as tag helpers
- Configuration and logging
- Using Razor Pages