Connecting to a Hub from a .NET application
In the context of the Adding a Hub to a self-hosting application recipe, we already mentioned that SignalR can be used in the context of a generic standalone process, and we detailed how this can be leveraged for the server-side portion of an application. Thanks to the .NET client library, we can apply the same reasoning on the client side, enabling traditional Windows applications to connect to any SignalR server. In this recipe, we'll learn how to use the .NET SignalR client inside a simple console application. For the server portion to connect to, we'll make use of what we did in the Adding a Hub to a self-hosting application recipe, so please make sure you have the code from that recipe ready and fully working before proceeding.
Getting ready
Let's create a console application using the following steps:
Navigate to File | New Project.
Navigate to Installed | Visual C# in the dialog box and select the Windows folder.
On the central panel of the dialog box, select Console Application, give it a name (
Recipe04
, in this case), and click on OK.
Visual Studio will add a Program.cs
file containing the startup code for our application. For this recipe, we will add all our code to this file, which contains the following lines:
namespace Recipe04 { class Program { static void Main(string[] args) { } } }
How to do it…
We're ready to actually start building our SignalR client. Visual Studio simplifies the process for web applications or websites, which are normally supposed to contain both server- and client-side portions; hence, the action of adding a Hub through the corresponding Visual Studio code template actually includes the JavaScript client portion too. When building a purely .NET client, we do not have a specific code template to use, and we have to resort to NuGet to import the appropriate package. This is done using the following steps:
Select the
Recipe04
project, and under the Project menu, click on the Manage NuGet Packages… entry.From the corresponding dialog box, perform a search for the online packages using
signalr client
as the filter expression. We should obtain a results list like the following:Select the Microsoft ASP.NET SignalR .NET Client package and then click on the Install button. This action will download and install all the packages that we need to proceed with our application.
We are ready to add some code. Let's open the
Program.cs
file and modify theMain()
method's body as follows:using System; using Microsoft.AspNet.SignalR.Client; namespace Recipe04 { class Program { static void Main(string[] args) { var url = "http://localhost:1968"; var connection = new HubConnection(url); var hub = connection.CreateHubProxy("echo"); connection.Start().Wait(); hub.Invoke("Say", "Hello SignalR!"); Console.ReadLine(); } } }
How it works…
Starting from the inside of the
Main()
method, the first line defines the address to which our client will try to connect to, and the second line actually instantiates aconnection
object pointing to that address; our client will expect to find a SignalR server listening at that position.Then we use the
connection
object to create a proxy for theEchoHub
Hub that we used so far when building our servers (the third line). In this recipe, we are using the one that we created in the Adding a Hub to a self-hosting application recipe, so we know from its code that it will be listening on port1968
, and it will expose ourEchoHub
Hub with the friendly nameecho
, which we supply as a parameter to theCreateHubProxy()
method that will provide us with a proxy pointing to it.We are now ready to perform the connection using the
Start()
method. Its return value is atask
-derived object, which means its execution will be asynchronous; indeed, we are not allowed to use a Hub until the connection process has properly completed. That's why in this example we use theWait()
method to block our code until the connection is effectively ready.When we are done with the
Wait()
call, we can safely address any method on our Hub proxy. We know thatEchoHub
exposes aSay()
method, so we call it usingInvoke
, to which we pass the name of the method to call (Say()
) and the list of the expected parameters (in this case, just one for the"Hello SignalR!"
message argument).The
Console.Readline()
method is there to prevent the process from exiting immediately.
That's it. If we now launch the Recipe 02
console application first and then the one we just built in this recipe (either from Visual Studio directly or from a console window), we should see the server application happily printing Hello SignalR!
on the screen because of the call from our client.
Note
Pay attention; you have to keep the application's Recipe02
project open while Recipe04 is running. If you just debug Recipe02
and then stop the debugger to launch Recipe04
, Recipe02
will be killed. There are several ways to achieve the right workflow. One of the simplest is to make Recipe02
the active project, start it without debugging (Ctrl + F5), and then make Recipe04
active and launch it, with or without debugging.
This recipe has completed our first showcase of SignalR features, and it allowed us to understand the basics of how it works and the general structure of any SignalR-based application. We also learned about the different types of hosting we can use and about the two client libraries available out of the box.