Configure Your ASP.NET Core 1.0 Application
Though it's not terribly hard once you know what you're doing, ASP.NET Core doesn't really make it easy to get started. Learn how to configure your ASP.NET Core app.
Join the DZone community and get the full member experience.
Join For FreeConfiguring
Unfortunately, a newly started ASP.NET Core Application doesn't include a complete configuration as a sample. This makes the jump-start a little difficult. The new Configuration is quite better than the old one and it would make sense to add some settings by default. Anyway, let's start by creating a new Project.
Open the Startup.cs
and take a look at the controller. There's already something like a configuration setup. This is exactly what the newly created application needs to run.
public Startup(IHostingEnvironment env)
{
// Set up configuration sources.
var builder = new ConfigurationBuilder()
.AddJsonFile("appsettings.json")
.AddEnvironmentVariables();
if (env.IsDevelopment())
{
// This will push telemetry data through Application Insights
// pipeline faster, allowing you to view results immediately.
builder.AddApplicationInsightsSettings(developerMode: true);
}
Configuration = builder.Build();
}
But in the most cases you need much more configuration. This code creates a ConfigurationBuilder
and adds an appsettigns.json
and environment variables to the ConfigurationBuilder
. In development mode, it also adds ApplicationInsights settings.
If you take a look into the appsettings.json, you'll only find a ApplicationInsights key and some logging specific settings (if you choose an individual authentication, you'll also see a connection string):
{
"ApplicationInsights": {
"InstrumentationKey": ""
},
"Logging": {
"IncludeScopes": false,
"LogLevel": {
"Default": "Verbose",
"System": "Information",
"Microsoft": "Information"
}
}
}
Where do we need to store our custom application settings?
We can use this appsettings.json
or any other JSON file to store our settings. Let's use the existing one to add a new section called AppSettings
:
{
...
"AppSettings" : {
"ApplicationTitle" : "My Application Title",
"TopItemsOnStart" : 10,
"ShowEditLink" : true
}
}
This looks nice, but how do we read these settings?
In the Startup.cs
, the configuration is already built and we could use it like this:
var configurationSection = Configuration.GetSection("AppSettings");
var title = configurationSection.Get<string>("ApplicationTitle");
var topItmes = configurationSection.Get<int>("TopItemsOnStart");
var showLink = configurationSection.Get<bool>("ShowEditLink");
We can also provide a default value in case that item doesn't exist or in case it is null:
var topItmes = configurationSection.Get<int>("TopItemsOnStart", 15);
To use it everywhere we need to register the IConfigurationRoot
to the dependency injection container:
services.AddInstance<IConfigurationRoot>(Configuration);
But this doesn't seem like a really useful way to provide the application settings to our application. And it looks almost like what we would have done in the previous verisions of ASP.NET. But the new configuration is much better. In previous versions, we created a settings facade to encapsulate the settings, to not access the configuration directly, and to get typed settings.
Now, we just need to create a simple POCO to provide access to the settings globally inside the application:
public class AppSettings
{
public string ApplicationTitle { get; set; }
public int TopItemsOnStart { get; set; }
public bool ShowEditLink { get; set; }
}
The properties of this class should match the keys in the configuration section. When this is done, we are able to map the section to that AppSettings
class:
services.Configure<AppSettings>(Configuration.GetSection("AppSettings"));
This fills our AppSettings
class with the values from the configuration section. This code also adds the settings to the IoC container and we are now able to use it everywhere in the application by requesting the IOptions<AppSettings>
:
public class HomeController : Controller
{
private readonly AppSettings _settings;
public HomeController(IOptions<AppSettings> settings)
{
_settings = settings.Value;
}
public IActionResult Index()
{
ViewData["Message"] = _settings.ApplicationTitle;
return View();
}
We can even do this directly in the view:
@inject IOptions<AppSettings> AppSettings
@{
ViewData["Title"] = AppSettings.Value.ApplicationTitle;
}
<h2>@ViewData["Title"].</h2>
<ul>
@for (var i = 0; i < AppSettings.Value.TopItemsOnStart; i++)
{
<li>
<span>Item no. @i</span><br/>
@if (AppSettings.Value.ShowEditLink) {
<a asp-action="Edit" asp-controller="Home"
asp-route-id="@i">Edit</a>
}
</li>
}
</ul>
With this approach, you are able to create as many configuration sections as you need and you are able to provide as many settings objects as you need to your application.
What do you think about it? Please let me know and drop a comment.
Environment Specific Configuration
Now we need to have differnt configurations per deployment environment. Let's assume we have a production, a staging, and a development environment where we run our application. All these environments need another configuration, another connection string, mail settings, Azure access keys, whatever...
Let's go back to the Startup.cs
to have a look at the constructor. We can use the IHostingEnvironment
to load different appsettings.json
files per environment. But we can do this in a pretty elegant way:
.AddJsonFile("appsettings.json")
.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
We can just load another JSON file with an environment specific name and with optional
set to true. Let's say the appsettings.json contain the production and the default settings and the appsettings.Staging.json
contains the staging sepcific settings. If we are running in Staging mode, the second settings file will be loaded and the existing settings will be overridden by the new one. We just need to specify the settings we want to override.
Setting the flag optional
to true means that the settings file doesn't need to exist. With this approach, you can commit some default setings to the source code repository and the top secret access keys and connections string could be stored in an appsettings.Development.json
, an appsettings.staging.json
, and an appsettings.Production.json
on the buildserver or on the webserver directly.
Conclusion
As you can see, configuration in ASP.NET Core is pretty easy. You just need to know how to do it. Because it is not directly visible in a new project, it is a bit difficult to find out how to start.
Published at DZone with permission of Juergen Gutsch, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments