Refactor Program.cs to eliminate Startup.cs in .NET 6+ Web API project
Introduction
Get ready to wave goodbye to Startup.cs because with the release of .NET v6, it’s being consolidated into Program.cs! If you’re upgrading your Asp.Net WebAPI to version 6 or higher, and you’re planning on tidying up Startup.cs, this blog post has some valuable lessons for you. Just don’t trip and fall on your way to the trash bin with that old Startup.cs file, okay?
Background
Prior to .NET version 6, ASP.NET CORE WebAPI projects typically included both Program.cs and Startup.cs in the root folder. However, with the release of .NET 6, Startup.cs is no longer needed and has been consolidated into Program.cs. This means that any configuration or setup is previously done in Startup.cs will now be done in Program.cs.
Yes, many .NET Web API developers are accustomed to using Startup.cs to configure services and middleware, and the naming convention Startup.cs certainly makes perfect sense in this context. Why did Microsoft make this change? Could Startup.cs make a triumphant return in a future version of .NET? Whether Startup.cs makes a comeback or not, it’s important to remain adaptable and open to new ways of doing things.
Approach for Refactoring Code
For this blog post, I went ahead and created a working sample ASP.NET CORE Web API project. And if you’re feeling extra adventurous, you can check out the BEFORE and AFTER refactor using the handy-dandy links below.
- Before (BEFORE-REFACTORING branch): https://github.com/workcontrolgit/RefactorAspNetWebAPI/tree/BEFORE-REFACTORING
- After (master branch): https://github.com/workcontrolgit/RefactorAspNetWebAPI
This sample WebAPI project was generated using the Visual Studio template OnionAPI that I recently upgraded to .NET 7. So if you want to speed up your development with a Clean Architecture approach, give this template a try.
Source code of Startup.cs and Program.cs BEFORE refactoring
Figure 1 has a listing of the source code in the Program.cs and Figure 2 has a listing of the source code of Startup.cs BEFORE refactoring. The source code listing in Figure 1 and 2 contain the coding structure in the .NET 5 or older. Notice that the two functions Main (line 9) and CreateHostBuilder (line 37) in Figure 1 are deprecated in the .NET 6 + and the Startup.cs are no longer needed.
Source code of Program.cs AFTER refactoring
Figure 3 has the source code of the Program.cs AFTER refactoring.
Lessons learned
I learned a few things when refactoring Program.cs to eliminate Startup.cs
1. How to migrate code from Startup.cs to Program.cs
The structure of the program.cs in .NET 6+ has two main sections, Registering Services and Running HTTP Pipeline (aka Middleware). See Figure 3, lines 16–42 for an example section of Registering Services. See Figure 3, lines 44–75 for example section of Running HTTP Pipeline (aka Middleware).
What is going in Program.cs? Okay, bear with me here. Picture this: you’re about to embark on a thrilling road trip (in the metaphorical sense, of course). You need to get your car running before you can hit the open road, right? That’s where ‘registering services’ comes in — it’s like starting up the engine and getting everything ready to go. But once you’ve got the car running, you still need to actually drive it, right? That’s where ‘running HTTP Pipeline (aka Middleware)’ comes in — it’s like hitting the gas and taking off on your journey. Confusing? Maybe a little. But just think of it as a really extended car metaphor and you’ll be all set!
2. Are there less or more code after refactoring?
Before starting this whole refactoring thing, the Program.cs and Startup.cs files had a whopping 123 lines of code combined. But now, after some careful tinkering and pruning, I’ve managed to get it down to a lean, mean 87 lines of code in just Program.cs. That’s a whopping 35 fewer lines of code — if my math skills haven’t completely abandoned me, that is good.
2. How to access DbContext in/from Program class?
In Figure 2, line 58 of our legacy Startup.cs file, it calls the dbContext in the Configure section to ensure EF DB initialization. But now that we’re moving on to the brave new world of Program.cs, how am I supposed to do that? The all-knowing deity of the programming StackOverflow has the answer. Check out the code on lines 55–60 of Figure 3.
3. How to reference the services and http pipeline (middleware) from 3rd party or your custom project in the Program.cs?
Just add the necessary namespaces to the top of your Program.cs file. Take a look at the example lines 55–60 in Figure 3 to see how it’s done. And if I am really feeling fancy, I can even take advantage of the Global Usings feature to keep things nice and organized.
References
Okay, let’s be real here — explaining the whole Startup.cs to Program.cs transition is way beyond the scope of this little blog post. But fear not, my curious friends, because there’s always YouTube to the rescue! Just head on over to IAmTimCorey and check out his video on Cleaning Up The Program.cs File In .NET 6 Now That Startup.cs is Gone. It’ll give you all the juicy details you need to make sense of this whole mess.
Summary
It’s possible that Startup.cs could make a comeback in future versions of .NET, just as the Start button did when it was removed in Windows 8 and came back in Windows 10. However, it’s also important to keep in mind that software development is an ever-evolving field, and sometimes changes are made to streamline processes or improve efficiency. It’s possible that Microsoft has determined that consolidate Startup.cs into Program.cs will ultimately provide a better user experience for .NET developers.
Thanks for reading! Hope you found it useful. Want more? Hit the “Follow” button below my profile. With your support, I’ll keep creating awesome content for you. Have a great day ahead! — Fuji Nguyen
