A minimal fully asynchronous C# ASP.NET Core 3.0 application with routing (learn more about ASP.NET Core here https://docs.microsoft.com/en-us/aspnet/core/?view=aspnetcore-3.0)

Program.cs

using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Hosting;

public class Program
{
    public static void Main(string[] args) =>
        Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.Configure(app =>
            {
                app.UseRouting();
                app.UseEndpoints(route =>
                {
                    route.MapGet("/", context => context.Response.WriteAsync("Hello world"));
                });
            });
        })
        .Build().Run();
}

WebApp.csproj

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
  </PropertyGroup>
</Project>

Ah, I also now see that AddIdentity forces me to supply TRole which I don't want to supply, since I have no concept of roles in my app.

My final addition to this thread is to ask that work is done on an API design that makes it easy to "fall into the pit of success" regarding correct order of these extension methods.

See this.

https://stackoverflow.com/questions/56842367/controller-user-has-no-claims-even-though-identity-applicaton-cookie-is-sent

Sure, I don’t see how adding more undiscoverable methods helps that but your point is taken

Glad to see these improvements. Do you think we can bring it down to 3 lines? 😉

var app = Host.CreateDefault(args);
app.Get(“/“, context => context.Response.WriteAsync(“easy”));
app.Run();

@BuddySpike, not with the same types but a different API optimized for web scenarios could be that simple. What we have today is a generic host not tied to web that we use for background workers as well (so single shared type for different types of apps). Plus the web specific host wire up nested inside of it.

That’s the sort of competition ASP.Net Core has today. For example, http.HandleFunc in Go or express in node has a very similar API.

@BuddySpike Such a ridiculous comment. No disrespect, but I find it hard to not see the elegance in the code presented here. Sure, can C#/.NET claim it has as small a surface area as Go? Absolutely not. The language has been maturing for almost 20 years, .NET roughly the same. But, if you're programs are backed by .NET Core chances are you're writing fast, succinct and simple-to-reason-about software. If you want to stick around at the handler level, we call them RequestDelegate's, you absolutely can. The built in router, or mux if you want to be silly and fancy, is fantastically designed and has auto parameter mapping built-in (no slicing through the URL.path required).

@davidfowl Love this! Such an emphasis on bare bones these days, and I feel as though .NET is sometimes still viewed as cumbersome. Which I don't believe is the case at all.

Created a version without the default host builder, to make things a bit more explicit for potential newcomers. Seeing this as a potential acorn for new projects!