In this chapter, we will take a deeper look at the .NET client library on the Hubs API. From a functional perspective, this API does not differ from the JavaScript one; in fact, it basically offers the same features, the only difference being the platform it operates on. Hence, in this chapter, we'll keep the same outline that we used in Chapter 3, Using the JavaScript Hubs Client API, with recipes that are similar to the ones in that chapter.

This chapter will concentrate exclusively on the .NET client's code that we'll be writing; however, as usual, we will need a counterpart for the server Hub. In order to avoid repetition and complexity, we will use the same servers that we used in Chapter 3, Using the JavaScript Hubs Client API, and we'll connect the new clients to those servers to perform the operations. Clients will perform mostly the same actions as the corresponding ones from there. In this way, you will have a chance to easily compare the two APIs in action, discovering similarities and differences. We can say that for a full comprehension of the current chapter, the previous one is a prerequisite.

The first thing worth noticing here is the fact that the .NET client does not bring any dynamic proxy feature. Everything is based on what is exposed by a specific type called HubConnection. Whether we need to perform calls on a remote Hub or we want to supply some function to be called back on, we'll have to use a couple of generic methods on HubConnection to achieve our goal, and use a string to specify the method names. We'll cover this in detail later in this chapter.

Dynamic programming shows up again here with method arguments. As long as they are serializable, we can use any type of argument, no matter whether we're calling a Hub's method remotely or we're triggering a client-side callback. The receiving part has to just declare that it's expecting a dynamic value, and SignalR will do the rest to make the supplied values available, without any need of sharing common assemblies in order to distribute the type definitions to be shared between the server and client sides.

The other interesting aspect that we'll be digging into is how the asynchronous nature of SignalR is expressed by the .NET client API. The Task Parallel Library (TPL) is at the core of this client; in our samples, we'll be showing how that neatly integrates with the async/await support introduced in C# 5.0. That said, the goal of this book is not to teach how async/await works; that alone can be the topic for an entire book. For this reason, we'll be writing code that might look naïve and may not fully exploit the power of async/await, but it will be hopefully easy to follow and understand. At the same time, there will be enough details to proof the points that we will be making in our recipes.

For the following recipes, we will always start with console application projects and all our code will be contained in the default Program class. For each recipe, we will need to go to NuGet, and from there add the Microsoft ASP.NET SignalR .NET Client client library, which is the actual full name of the .NET client library we are dissecting here. This is shown in the following screenshot:

That's it; now we are ready to start.