Using SignalR Core in a standalone .NET application

[jgauffin]

This is another perspective of #20768.

With the previous version of SignalR it was possible to create a host for SignalR without having to include the entire ASP.NET infrastructure. Is that possible with the new version? i.e. limiting the amount of required packages, instead of having to install Microsoft.AspNetCore.All?

My use case is that we have 40 different microservices in which we use RabbitMQ/NServiceBus for communication for commands and events. We are using WebSockets (the vanilla ones in .NET Core) for executing queries.All of our microservices are console based and currently running as window services (they are prepared for docker).

Let's do a comparison.

For legacy signalR, there is a succint documentation that shows step-by-step how to install SignalR as standalone. That would be easy to implement in our services. But why use that version when there is a newer one for .NET?

For SignalR Core, all documentation expects that you can use the WebSdk as SDK type in your csproj. That is not an option for us. From what I've discovered, the option is to install Microsoft.AspNetCore.All. However, when using .NET Core 3.0 or higher it's not possible to reference that meta-package in a console/sdk application. Instead, by googling you discover that you can use <FrameworkReference Include="Microsoft.AspNetCore.App" /> instead in your csproj. In other words, it's not as straight forward as it was before.

When comparing the output (i.e. publish self-contained), there is a minimal amount of ASP.NET dlls included for the old version of signalR while the entire ASP.NET stack (including MVC etc) is included for SignalR Core.

The issue:

Is it possible to create a minimal SignalR host with ASP.NET Core? Like just using just the Microsoft.AspNetCore.Hosting, Microsoft.AspNetCore.Routing and Microsoft.AspNetCore.SignalR packages? I tried, but didn't manage to get everything fully working.

[davidfowl]

You need the FrameworkReference then it'll just work.

[jgauffin]

Yes, but doesn't that pull in the entire ASP.NET Core stack? As opposed to just three owin DLLs in the previous version of SignalR?

[davidfowl]

Couple of things:

• OWIN is no longer a thing in ASP.NET Core land
• SignalR is built on ASP.NET Core
• Pull in the entire ASP.NET Core stack doesn't have an impact per se unless you're worried about self contained deployments (and there are ways to make it not deploy all of the unused dlls)

What exactly are you worried about?

[davidfowl]

I should add, the other thing that you might be trying to prevent is allowing references to other components in ASP.NET Core. That's one of the things that isn't currently solvable.

[jgauffin]

I know that owin is not part of ASP.NET Core. It was just a comparison about how large the difference is between SignalR in ASP.NET Core vs the previous version in terms of dependencies.

I'm worried about self contained deployments.

Based on your answer I think that we'll stick with vanilla websockets instead of including the whole ASP.NET Core stack which we will not use (apart from signalR).

Why do you have a lot of different nuget packages (including the abstraction packages) if everything always have to be distributed with every release?

[davidfowl]

I'm worried about self contained deployments.

Great! One option would be to use the assembly trimming. That will remove unused binaries from the output folder when deploying.

Based on your answer I think that we'll stick with vanilla websockets instead of including the whole ASP.NET Core stack which we will not use (apart from signalR).

That's fine, assuming you're not using the WebSocket support in ASP.NET Core. I assume you're using HttpListener?

Why do you have a lot of different nuget packages (including the abstraction packages) if everything always have to be distributed with every release?

Most of those packages target pre 3.x ASP.NET Core #3756 and are likely to be broken on newer versions of ASP.NET Core.

Microsoft.Extensions.* will remain packages because they target ns2.0 and work on multiple frameworks.

[jgauffin]

Thank you for all your comments. They are helpful.