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>

It's only now occurred to me that the Core means the "core" of identity. I thought there were now new ways to set things up in the latest ASP.NET Core, so these Core extensions were added leaving the old ones not breaking existing code. Crazy as it sounds, I thought Core was just on-brand. I mean, Core is the framework name afterall.

I'd counter that forcing people to write more code isn't a design failure, just as twisting more knobs, pressing more buttons, gesturing more or clicking more hyperlinks isn't a failure of interaction design.

Anyway, maybe a design where those extensions were reached via an intermediate extension would be better. I'd also favour something like services.ConfigureEssentials().AddIdentityEssentials() perhaps.

On the second point, we agree.

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!