ASP.NET Core: Environment-based Configuring Methods

default configuring methods of start-up class

when we create a new asp.net core application, our startup class looks like this.

public class startup
{
    public startup(ihostingenvironment env)
    {
        var builder = new configurationbuilder()
            .setbasepath(env.contentrootpath)
            .addjsonfile("appsettings.json", optional: false, reloadonchange: true)
            .addjsonfile($"appsettings.{env.environmentname}.json", optional: true)
            .addenvironmentvariables();
        configuration = builder.build();
    }public iconfigurationroot configuration { get; }

    // this method gets called by the runtime. use this method to add services to the container.
    public void configureservices(iservicecollection services)
    {
        // add framework services.
        services.addmvc();
    }       // this method gets called by the runtime. use this method to configure the http request pipeline.
    public void configure(iapplicationbuilder app, ihostingenvironment env, iloggerfactory loggerfactory)
    {
        loggerfactory.addconsole(configuration.getsection("logging"));
        loggerfactory.adddebug();if (env.isdevelopment())
        {
            app.usedeveloperexceptionpage();
            app.usebrowserlink();
        }
        else
        {
            app.useexceptionhandler("/home/error");
        }           app.usestaticfiles();

        app.usemvc(routes =>
        {
            routes.maproute(
                name: "default",
                template: "{controller=home}/{action=index}/{id?}");
        });
    }
}

the configureservices() method adds services to the container, and the configure() method configures the request pipeline.

configuring multiple environments

it’s possible we need to configure our application based on the environment where the application is running. we may want to use some specific services and features in development mode and some others in release mode. one option is to use default configuring methods and #ifdef checks, but these make our code look ugly.

asp.net core allows us to define special versions of configuring methods:

• configure<environment>services()
• configure<environment>()

<environment> is the name of the environment where the application runs. for example, with debug builds, we can use development as the environment name. it gives us the following two methods:

• configuredevelopmentservices()
• configuredevelopment()

in the same way, we can use staging and production as environment names. we can try out these methods with some lines of additional code.

public void configuredevelopmentservices(iservicecollection services)
{
    debug.writeline("configuredevelopmentservices");
    configureservices(services);
}
public void configuredevelopment(iapplicationbuilder app, ihostingenvironment env, iloggerfactory loggerfactory)
{
    debug.writeline("configuredevelopment");
    configure(app, env, loggerfactory);
}

we can run the application and check the output in the debug window, or we can just use breakpoints to see if the application is stopping on these when we run it.

adding custom environments

it’s possible we need support for additional environments. behind the curtains, asp.net core uses the aspnetcore_environment environment variable to find out what type of environment it is currently running in. we can set a value to this variable on the debug settings page of project properties.

and methods for environment called “custom” are here:

public void configurecustomservices(iservicecollection services)
{
    debug.writeline("configurecustomservices");
    configureservices(services);
}

public void configurecustom(iapplicationbuilder app, ihostingenvironment env, iloggerfactory loggerfactory)
{
    debug.writeline("configurecustom");
    configure(app, env, loggerfactory);
}

this way we can add methods for as many environments as we want.

wrapping up

we can write configuration methods based on the environment name and use default ones as fallbacks for other environments. this way we can avoid ugly code that has to go through several environment name checks. the environment name is held in the aspnetcore_environment variable, and the value can be set on the project properties page. using environment based configuration methods we can keep our code cleaner.