WPF Remoting vs. Silverlight

DAN SHAPPIR on July 29, 2014 | 1573

It is an interesting coincidence that Microsoft released Silverlight 1.0 Beta, a browser plug-in that utilizes WPF to provide a rich user experience, shortly after releasing Longhorn Beta 3, which does not include WPF Remoting for Terminal Services. Given this, I think that it is worthwhile to discuss the similarities and differences between these two technologies (other than the fact that one exists and the other, at least currently, doesn’t),.

The similarity between the two is that both are Microsoft proprietary technologies enabling server-driven applications to provide a high-grade user experience using WPF. In both cases XAML is generated or stored on the server, then transmitted to and rendered on the client. In addition, while some event handling and validation can be performed on the client, the brunt of the business logic is performed on the server.

The are also numerous differences between the two technologies:

  1. Silverlight contains a custom implementation of WPF and the CLR. It utilizes this implementation regardless of the capabilities of the client device. TS WPF Remoting, on the other hand, is dependant on WPF support being built into the client. This means that Silverlight can work on devices that do not have .NET (it can even work on devices that don’t run Windows) but WPF Remoting is better integrated into the local desktop.
  2. Silverlight transmits XAML over HTTP or HTTPS while WPF Remoting transmits the XAML through an RDP virtual channel (which can be tunneled through HTPS if TS Gateway is used),. While both RDP and HTTP are built on TCP/IP, they are very different in nature. HTTP is a stateless protocol where a client sends a request for particular data and the server sends a response specifically for that request. RDP, on the other hand, is a more symmetric stateful protocol.
  3. Silverlight can handle events and perform computations using JavaScript embedded in the containing HTML page. When officially released Silverlight will also be able to download and execute .NET assemblies utilizing its built-in Core CLR and a special Sandbox environment. WPF Remoting, as I understand, is limited to .NET event handlers embedded within the XAML.
  4. Silverlight has powerful built-in video streaming capabilities. Streaming video has always been a weak spot for RDP and I do not know if WPF Remoting address this weakness in any way.

Based these differences, in particular #2 and #3, it appears that despite relying on the same WPF/CLR technology WPF Remoting and Silverlight espouse very different usage patterns. Silverlight naturally follows the Web 2.0 pattern of handling as much user interaction as possible in the client, and requesting more data from the server only when it is required. Session context is also based on the client state. WPF Remoting is an extension of RDP, and as such it is the server that does almost all of the heavy lifting with the client primarily just doing the rendering.

While the approach used by Silverlight has the benefit of generally being more scalable, it is also more complicated to use than WPF Remoting. Creating Web 2.0 Ajax applications, with or without Silverlight, is certainly more difficult than developing a standalone WPF application. Given this I believe both approaches have merit, and I remain hopeful that Microsoft will eventually give WPF Remoting a chance.

Author | 180 Blog Posts

Dan Shappir

Dan Shappir is responsible for all aspects of product design, software development and maintenance of the Ericom's product lines. | Ericom Software

Recommended Articles