A Cleaner Startup for .NET 6's Minimal Approach

After reading the .NET Migration Documentation in the past week, I have formulated an alternative to the suggested methods from Microsoft. To be honest, I created this approach last year and recently refined it, to make it ready to share with others.

The starting point was finding some posts about using the Startup.cs file in the new .NET 6 minimal hosting model. I know I'm not alone in finding Microsoft's format more annoying than anything. With Microsoft removing the Startup.cs file as the default, this lead me to assume they were proposing that Program.cs would be a heavy and long mess. In reading the posts and Microsoft's documentation I've come to realise that they have a suggested implementation. Problem is I think the implementation is a little messy.

---

Microsoft's Solution

As I read through their documentation I found that...

Apps migrating to 6.0 don't need to use the new minimal hosting model

This was a surprise because I thought they'd killed the Startup.csfile and it's a problem because I found that this eats away at their minimal model. The approach causes a few extra lines to be inserted into Program.cs to handle all the service and middleware configuration. It creates a new format Startup.cs file, that consists of two methods and an injected set of Configuration, easy enough and does the job.

	using Microsoft.AspNetCore.Builder;
	var builder = WebApplication.CreateBuilder(args);
	var startup = new Startup(builder.Configuration);
	startup.ConfigureServices(builder.Services);
	var app = builder.Build();
	startup.Configure(app, app.Environment);
	app.Run();

view raw Program.cs hosted with ❤ by GitHub

Combined with the following Startup.cs class

	public class Startup
	{
	public Startup(IConfiguration configuration)
	{
	Configuration = configuration;
	}
	public IConfiguration Configuration { get; }
	public void ConfigureServices(IServiceCollection services)
	{
	services.AddRazorPages();
	}
	public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
	{
	if (!env.IsDevelopment())
	{
	app.UseExceptionHandler("/Error");
	app.UseHsts();
	}
	app.UseHttpsRedirection();
	app.UseStaticFiles();
	app.UseRouting();
	app.UseEndpoints(endpoints =>
	{
	endpoints.MapRazorPages();
	});
	}
	}

view raw Startup.cs hosted with ❤ by GitHub

---

Alternative Solution

The above code works just fine, it's maybe a little clunky looking but it does the job. The alternative approach that I made is just a simple use of extension methods. Nothing world changing but I have found it to be a leaner and cleaner look. The extension methods pass in the WebApplicationBuilder and the WebApplication objects. WebApplication has access to the Environment configuration and both have access to the IConfiguraiton as well. This keeps the spirit of the old Startup.cs just like Microsoft's method but I've found it keeps the Program.cs clean and clear as well.

	using Microsoft.AspNetCore.Builder;
	var builder = WebApplication
	.CreateBuilder(args)
	.ConfigureBuilder();
	var app = builder
	.Build()
	.ConfigureApplication();
	app.Run();

view raw Program.cs hosted with ❤ by GitHub

Combined with the following ProgramExtensions.cs class

	using Microsoft.AspNetCore.Builder;
	using Microsoft.Extensions.DependencyInjection;
	public static class ProgramExtensions
	{
	public static WebApplicationBuilder ConfigureBuilder(this WebApplicationBuilder builder)
	{
	builder.Services.AddRazorPages();
	return builder;
	}
	public static WebApplication ConfigureApplication(this WebApplication app)
	{
	if (!app.Environment.IsDevelopment())
	{
	app.UseExceptionHandler("/Error");
	app.UseHsts();
	}
	app.UseHttpsRedirection();
	app.UseStaticFiles();
	app.UseRouting();
	app.UseEndpoints(endpoints =>
	{
	endpoints.MapRazorPages();
	});
	return app;
	}
	}

view raw ProgramExtensions.cs hosted with ❤ by GitHub

---

This method is not going to change your life but I have found value in it. A little pedantic, yeah probably but I enjoy the simplicity those extension methods offer. If they blow out in size, it's possible to break them into separate files for each method. If any configuration gets even larger and more important, it's possible to make ConfigureApplication and a ConfigureExceptionHandling methods. The possibilities are endless with that pattern.

---

Support

If you like this, or want to checkout my other work, please connect with me on LinkedIn, Twitter or GitHub, and consider supporting me at [Buy Me a Coffee]

Comments

[Vaclav Elias]

I like it! Helpful when you have got lots of services..

[Stephen Walsh]

Thanks!!! Yeah takes the emphasis off the Program.cs.

[Max Hamulyák]

it appears way more minimal imho good job!

[Stephen Walsh]

Thanks @kaylumah !!!! I like how it's a following the standards they set by introducing this new Program setup. The Setup file feels like they realised they made a mistake and had to clean it up. Extending those two object just feels like the right choice, at least to me

[JoCuevas]

I am thankful for this . kerala manthirigam contact number