Search code examples
asp.net-corebackground-service

Is Microsoft.NET.Sdk.Worker compatible with an API project?


A Visual Studio API project created via

"new project",

"ASP.NET Core Web App",

"ASP.NET Core Web API"

results in a project file that starts with...

<Project Sdk="Microsoft.NET.Sdk.Web">

If this API needs a long running task it seems likely that a BackgroundService is needed. This document says that the following is a starting point for a long running service application.

<Project Sdk="Microsoft.NET.Sdk.Worker">

Is Microsoft.NET.Sdk.Worker compatible with an API project and if so how can this project information be added to an API project?


Solution

  • Both Microsoft.NET.Sdk.Web and Microsoft.NET.Sdk.Worker are extensions to the default project SDK Microsoft.NET.Sdk that add certain defaults that are useful in these project contexts.

    Originally, there was just the normal SDK and the web SDK which added a lot of default things that made sense with the default ASP.NET Core templates. Part of these things was obviously support for Razor and support for web-specific things (like the wwwroot folder). But there were also defaults that were brought in because of what the default WebHost set up with configuration files like appsettings.json but also support for user secrets or the file nesting in Visual Studio.

    When the generic host was invented with ASP.NET Core 3.0, this opened up the host and host builder patterns for non-web projects. But since all those host specific defaults were part of the web SDK, which also had a lot of really web-specific things, the team came up with a new SDK, the worker SDK, to be used for projects that would use the default host builder but were not web projects. This worker SDK now basically contains a subset of the web SDK to be used for projects that use the generic host and the default host builder.

    There isn’t anything that the worker SDK contains that is not also part of the web SDK (at least not as far as I know, and if it was, it is probably just minor things). This also means that everything you can do with the worker SDK should also work identically in the web SDK.

    As for BackgroundService or IHostedService in general: Those are things that came with the generic host in Microsoft.Extensions.Hosting. While it is recommended to use a worker (or web) SDK for these, the implementation doesn’t technically need it. In particular though, the web SDK fully supports this as well, and the web host from ASP.NET Core 3.0 or later is actually built on top of the hosted services.

    So if you are building an ASP.NET Core application, you are already using hosted services with the host builder. And if you need to add additional hosted or background services, you can just register those in addition to the web host and everything will just work fine.

    To summarize, in terms of SDK features, NET.SdkNET.Sdk.WorkerNET.Sdk.Web. So if you want to add hosted services to your ASP.NET Core web project, you can do so directly, but you shouldn’t “downgrade” your web SDK to the worker SDK because then you will be missing out of the web-specific features that you may need for your ASP.NET Core application.