Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Web Host Builder in ASP.NET Core 2.0

DZone's Guide to

Web Host Builder in ASP.NET Core 2.0

What's the biggest difference between the web host building in ASP.NET Core 2.0 and 1.0? Well, the newest version is much simpler and less verbose.

· Web Dev Zone ·
Free Resource

Jumpstart your Angular applications with Indigo.Design, a unified platform for visual design, UX prototyping, code generation, and app development.

I want to share something from the first chapter of my upcoming book Front-end Development with ASP.NET Core, Angular, and Bootstrap.

While reviewing and updating the code from ASP.NET Core 1.0 to version 2.0 I was faced with the challenge of how to explain what's going on in the initialization of the WebHostwhich was made much more simple and logical in ASP.NET Core 2.0 but at the cost of being more "magical."

Initialization in ASP.NET Core 2.x

But let's get back to basics a bit. The initialization happens inside two files:

  • Program.cs, where the WebHost is built.
  • Startup.cs, where the execution pipeline and dependencies are set up.

The ASP.NET Core 2.x the initialization of the WebHost in the Program.cs file is just a few lines of code:

public class Program
{
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();
}

And the code in the Startup.cs file is exactly just about configuring the request execution pipeline.

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
    }

    public void Configure(IApplicationBuilder app, IHostingEnvironment env)
    {
        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }

        app.Run(async (context) =>
        {
            await context.Response.WriteAsync("Hello World!");
        });
    }
}

But now you don't really understand what has happened. Especially if you have worked with ASP.NET Core 1.x where everything was much more verbose and explicit.

I bet you would be surprised to know that after this 3 lines of code you have:

  • Configured the app to use Kestrel as a web server.
  • Configured integration with IIS.
  • Specified to use the current project directory as root for the application.
  • Set up the configuration sub-system which reads settings from:
    • appsettings.json in the root of the project.
    • appsettings.{env}.json which specifies environment specific configuration.
    • Local user secrets storage for things like password and auth tokens (but only in development).
    • Environmental variables to allow for server-specific settings.
    • Command line arguments.
  • Configured to a logging sub-system to read its filters and rules from the Loggingsection of the appsettings.json file and log to the:
    • Console
    • Debug window

In ASP.NET Core 1.x, you had to specify everything explicitly, even adding references to a few additional Nuget packages.

All these configurations are hidden inside the CreateDefaultBuilder method. To understand better what's going on I recommend you go on the ASPNET/MetaPackages git repo and read its implementation.

How do you like this new approach? I personally like it as it declutters the code and removes all plumbing code from what is supposed to be just the creation of the execution pipeline of your application. But I admit it made my job of explaining what happens behind the scenes more difficult.

Take a look at an Indigo.Design sample application to learn more about how apps are created with design to code software.

Topics:
web dev ,asp.net core 2.0 ,web hosting

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}