Hacker News new | ask | show | jobs
by dahauns 1554 days ago
But those are just sets of convenient defaults? You could just start with the default sdk and add the imports/targets yourself (or in practice: let the IDE do it for you.)

And

>- If you switch the project to Sdk=...Web, you won't have the dependencies to build the worker services.

Yes you will, since the worker sdk is simply a subset of the web sdk.

1 comments

> You could just start with the default sdk and add the imports/targets yourself (or in practice: let the IDE do it for you.)

That's what I have been calling out. I have not had much luck in pulling in the right dependencies needed. Could not find any documentation on it. Everything relies on that Sdk=...Web thing on the official documentation.

If you’re just looking to be unblocked, use the Web SDK because you’re building and running combined web + hosted services [1]. The section linked shows the precise difference between the Web and Worker SDKs for hosted services.

If you’re looking for docs on what all the SDKs are/do, and their source code, start here [2].

If you’re looking to just add the asp net core packages/apis to your basic sdk/console project, here [3]. But note that your app build/publish probably won’t work 100% because msbuild won’t be configured to do so.

If you want to fix that manually (i.e do what the Web SDK does automatically), You can use the Web SDK props file as a starting point [4]. (Linked to in [2])

It seems well documented to me, but you’re welcome to propose new docs to the aspnet docs team. They’re very responsive [5].

[1] https://docs.microsoft.com/en-us/aspnet/core/fundamentals/ho...

[2] https://docs.microsoft.com/en-us/dotnet/core/project-sdk/ove...

[3] https://docs.microsoft.com/en-us/aspnet/core/fundamentals/ta...

[4] https://github.com/dotnet/sdk/blob/ee98c8c25188195fd4f8a145b...

[5] https://github.com/dotnet/AspNetCore.Docs

Well, not much to add to what jkulubya said, but: Just use Web, then - that's what it's for and it just worksTM.

We have almost your exact scenario in production - a (Quartz.NET-based) service for background/scheduled jobs, with a web dashboard and a healthcheck API, all from a single console executable without external dependencies. And it was super straightforward to implement.