ASP.NET Core apps are actually straightforward console applications. In fact most of the application types you’ll run on .net core are configured in a main method in program.cs. The answer to your specific questions about mixing different services in one app will be some combination of the following links.
That is exactly the thing. I *do not* want to have the Sdk=...Web/Worker.
Imagine this scenario, you started a new project with the Sdk targeting Worker. Then you need that binary to also target web.
What do you do?
- If you switch the project to Sdk=...Web, you won't have the dependencies to build the worker services.
- If you keep it as Sdk=...Worker, you won't have the dependencies to build asp.net
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.
> 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].
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.
The original poster is going slightly off the beaten path and therefore has to manually compose three or four different concepts together to come to the right solution vs relying on the out of the box experience.
I, and a lot of other devs, would be able to solve this particular problem without looking up the docs but I can’t assume any knowledge on the poster’s behalf so I posted the links to the docs about the building blocks and an article showing one possible way of composing them.
The same exact problem as posed by the poster was thought of by the dotnet/aspnet teams and the pieces (apis/docs/samples) are all there, just not the default.
> I, and a lot of other devs, would be able to solve this particular problem without looking up the docs
Look through the rest of this comment thread and see how many failed attempts at solving this problem there were before two high profile members of the ASP.NET team came in (JamesNK and davidfowl).
It's not about looking up or not looking up. The criticism here is that the way the framework is laid out is not intuitive enough. It's very "different" from the rest of the industry (in this case, there are 3 potential ways of pulling in dependencies for ASP.NET). This requires a lot of time investment for its users to solve these slight one-off issues.
My question to them below was why isn't what they shared here the default. If they had done that, it would be intuitive to know that one can add other "FrameworkReferences" in a project, or know what to search for. Instead, the default is "each project can only target one SDK".
JamesNK also answered this. We started off with just nuget packages, it was beautiful for about 5 minutes until we ended up with ~300 in the default project. Then physics kicked in, slower build times, slower compilation times, slower intellisense. All of those old O(N/N^2) algorithms started to show up on profiles and we had to do something about it. That was just the practical performance side of things, then there was the customer confusion around which packages had which APIs. We offered a .NET buffet that customers hated. On top of that, the versioning got nuts. Each of those packages could in theory version independently, who is going to test all of those combinations of things? What happens when you need tot publish ~300 + packages to your server deployment because you didn't want to "install the framework"? You'd be complaining that they were too many assemblies (which people did). Amplify that by deploying these binaries to the same physical machine when running multiple .NET Core applications there (very popular for IIS setups). We pre-JIT (ready to run) the core libraries and ASP.NET to improve startup time, that makes the assemblies bigger (as they contain both native code and IL), this makes your applications bigger by default.
We got LOTS of feedback that this was all really terrible and we listened.
We did this from .NET Core's inception to .NET Core 3.0 when we pulled the plug. We set things up so that the base install/platform/framework was not composed of packages but framework references. We merged several assemblies together to get rid of some of the unnecessary layering. We invented shared frameworks so that people could install the framework once and run lots of applications using shared libraries so that:
- Customers have faster publish times as you only need to deploy your application bits, the framework can be pre-installed
- Loading the same dll on disk into multiple processes allows for more virtual memory sharing (a handy performance optimization)
- We could version the set (.NET, ASP.NET Core) as a coherent unit
- We could pre-JIT (R2R) the built in stuff so it's installed on the machine once and usable by many apps.
As for being intuitive, the default experience is to use the Web SDK. I didn't even get into SDKs but it does more than default the framework reference. It also exposes capabilities that tooling use to light up behaviors in the build and in the IDE.
PS: This stuff is harder than it looks on the surface and we spend lots of time and take lots of care designing it (making the typical tradeoffs you make when doing software engineering).
@David, thanks, and completely aligned on why we don't use nuget packages anymore.
> As for being intuitive, the default experience is to use the Web SDK. I didn't even get into SDKs but it does more than default the framework reference. It also exposes capabilities that tooling use to light up behaviors in the build and in the IDE.
It is these "does more than default framework reference" are precisely the things in discussion here. All of these hidden functionalities and dependencies are like a black box. What's the difference between what James shared here and the default Sdk=...Web, then? It's the lack of uniformity, where "ASP.NET is a first class citizen" rather than just another piece of the ecosystem that is a turn off.
Compared to other ecosystems, for example: Go, Rust, even Java for example, where everything is just code that one can pull in, and the customization is in the code, not the runtime/JVM.
It's not about if you should or should not search. It's about how often you have to do that, and how easy it is to search for what you want. It boils down to how much anti pattern a framework/ecosystem has. In this case, their default template caused me to search "dotnet core project multiple SDK", which yielded nothing, and is actually a completely wrong track.
The answer the asp.net team shared below, was instead of using the SDK attribute, use a completely different thing called FrameworkReference. Which can completely replace this SDK attribute, it seems.
Hence my question to them below was, why is framework reference not the default? Especially since it does lead to better searchability, and the template shows that one could have multiple of these per project, intuitively.
- If you switch the project to Sdk=...Web, you won't have the dependencies to build the worker services.
- If you keep it as Sdk=...Worker, you won't have the dependencies to build asp.net