[kuhsaft]

You shouldn't have to change the SDK.

You can create a class library ASP.NET Core Server by using a FrameworkReference [1]. I can't remember the library, but there was one that had its own `IHostedService` with its own embedded ASP.NET Core Server startup within it.

If your `WebApplication` requires services, of course you're going to have to register its dependencies on its `IServiceCollection`. Though, you can use factory methods for service registration to use an external `IServiceProvider`.

For console applications, I would recommend using `Host.CreateEmptyApplicationBuilder` [2]. Makes it a lot easier to configure services for Console applications. It also handles `IHostApplicationLifetime`s.

[1] https://learn.microsoft.com/en-us/aspnet/core/fundamentals/t...

[2] https://gist.github.com/pethin/7e5edd7614ff2f51c06c086e1bc7c...

[oakstendheim]

Wow I did not know that, I was always under the assumption that I needed to have a project using the Microsoft.NET.Sdk.Web for anything Web as its base. Thanks for the info!

[andix]

It used to be much more modular back in dotnet core 2.x. It was just too complex for most people to wire up everything themselves. You needed to install a lot of nuget packages, add a lot of middlewares. In the end 95% of the projects added everything anyway, but always with some little mistakes and weird errors.

Starting with 3.0 (or 5.0?) they ditched the Startup class and just added in everything by default. Much easier for the regular web application. The modular approach is still everywhere though. You can just pick the components you need, most of them also run without DI, it's just a bit of a hassle to manage all those dependencies manually.

[electroly]

FrameworkReference enables other cursed combinations, too. You can use WinForms/WPF in an ASP.NET project with a FrameworkReference to Microsoft.WindowsDesktop.App. Finding a use case for this is left as an exercise for the reader.