Products Shop Support Company |

Intro to Remoting SDK for .NET (6:03)

Download the Video | View on YouTube

This is a video about Remoting SDK.
Watch more Remoting SDK Videos. Read more about Remoting SDK.


This video is an introduction to using Remoting SDK for .NET.

Remoting SDK is a multi-platform library that allows you to create services you can expose over the network where client applications can call them. Let's start by creating a small server that exposes some sample functionality.

We'll be using C# and Visual Studio, but the same steps will work with any .NET language.

We'll start by clicking the "Create a New Project" button in Visual Studio and filtering for "Remoting SDK". Select the C# "Code First Server" template and click Next.

Let's call it "FizzBuzzServer".

Click the Create button, and the project will open in the IDE.

First, let's have a look at Program.cs. Note the application server class used here. It does all the dirty work for us so we can focus on our business logic. It is highly customizable, but for now the default code will suffice.

In LoginService.cs we can handle authentication of clients if we want our service to be private. For now we'll keep the dummy logic that just checks if user name and password are the same.

Finally, let's look at Service1.cs. This is the actual service we expose. Let's rename the class to "FizzBuzzService". we remove the dummy method and add a new one called "Calculate" that returns the fizzbuzz value for the given number.

Simply adding the service method attribute exposes this method to the world.

And that's — it press F5 to start the server.

You'll see that by default the server app starts in GUI mode this is usually the best option for testing and debugging but the same .exe could also be registered as a Windows service or deployed to Linux as a daemon.

If we point our browser to localhost, port 8099 we see our services responsive. Vlicking View RODL shows the metadata the server provides to describe its services.

Let's look behind the scenes a bit We've defined our service in its methods in code. This is what we call a "code first" server. When run, the server makes the coded functionality available to be called by default using HTTPS and using a highly optimized binary message format we call BinMessage.

Optionally you can also choose different transport protocols, which we call channels, or different message formats. For example, you might want to expose the same service using SOAP for third parties.

In addition to its functionality, the server also provides a description of the APIs it exposes in the form of the XML file we saw earlier. We call this the RODL, for remoting definition language. The RODL file describes what services and methods are available what parameters they take and so on. It's what makes it easy to auto-generate clean APIs that you can use in the client application we're about to create.

We'll keep using C# and Visual Studio for this example, but you can create clients in other languages and for other platforms.

For simplicity we'll create a small console app that will call the server.

Back in Visual Studio, click "Create a New Project" again. This time we pick the ".NET Core Console App" template, but really this could be any kind of project even one you might already have.

Set the name to "FizzBuzzClient" and create the project.

First, we'll connect our app to the server. In the main menu, go to "Extensions|Remoting SDK and Data Abstract|Connect to Remoting SDK Server". Note that in Visual Studio 2017 or older, these menu items will be located under the "Tools" menu. instead.

Since the default address already matches what we need for the local server we can continue and click "Connect". This will load the RODL service definition we saw from the server and generate three new files in the project:

The .remoteRODL file is a link to the remote server. It contains its URL, so you can easily regenerate proxy files if the server API is changed, by right-clicking and choosing this menu option.

The _Intf code file contains auto-generated proxy classes that represent the service and its methods. We'll never touch this file ourselves. You can see our "FizzBuzzService" and the "Calculate" method are visible here.

Finally, the _ServerAccess file provides a rudimentary starting point for accessing the server. It's for you to update or remove as you see fit.

In this case, let's go back to the Program.cs file and add our code there.

First we get a LoginService and call the Login method. Temember our dummy login just needs user name and password to match in order to be happy. Now we have a FizzBuzzService, and in a for-loop we call Calculate for various numbers, printing the results of the console.

Let's run the app — and it works!

Now, this may seem like a trivial app but remember: under the hood it's talking over the network to the server for the actual logic without us having to worry about it.

Note that remoting SDK servers and clients are compatible across different platforms. We have other videos available to show you how to create clients in other languages that can talk to the same server.