Silverlight 3 for Kiosk Apps? Of Course!

Several of the customers I work with are looking to build kiosk or point-of-sale applications with Silverlight. The ease of deployment with browser-based Silverlight applications is definitely appealing. Sharing applications or components between customers’ kiosks and web sites is another appealing reasons to go with Silverlight. This post outlines the architecture decisions between Silverlight and WPF and presents architecture options for Silverlight based solutions. A follow up post will discuss the Silverlight implementation details.

However, POS systems or kiosks often need integration with local peripherals, such as credit card readers, barcode scanners, printers, etc. Since Silverlight browser applications run in a sandbox access to these devices isn’t immediately available. Therefore we need to find a way to insert a bridge between the peripherals and the Silverlight application to read data from the devices and forward the data to the Silverlight app.

To get started, let’s look at applications that can communicate with local peripherals. Desktop applications can communicate with local devices. Devices usually ship with C++ or .NET libraries to read data or sink events from devices. Therefore Desktop applications are usually preferred for POS systems. Microsoft has a POS for .NET framework to simplify development of applications that need access to a wide array of peripherals. WPF offers a very compelling option to build the application UI and building the UI in WPF is a great step to share assets between the kiosk and the Web. The following table summarizes the decision points to decide between a full desktop application or a Silverlight app.




Full POS Framework for peripheral integration

Requires high-touch deployment

Full access to local resources (files, registry, printers, peripherals)

Some re-development to share assets between desktop and web applications

Hardware accelerated graphics

Windows specific

Richest Graphics with WPF and XNA


Full .NET Framework (WCF, WPF, WF, SxS versioning, …)


If the cons weigh too high and you really need a browser-based app, for example when you’re running in shared kiosk environments or if ease of deployment is much more important than peripheral integration, then you have a couple of options with Silverlight.

First, you can simply load the Silverlight application with a control hosted in a desktop application via the COM hosting interfaces. The host application can load the Silverlight application from a web URL, i.e. once you install the host application, you can still download the Silverlight application from the web. The Silverlight hosting interfaces even allow managing the download process, customize caching of .xap files and other resources through the IXcpControlHost interface.

For communication between the Silverlight app and the device manager running in the host application, the Silverlight application can expose an interface via the scriptable object bridge. That bridge is intended for communicating with the javascript engine of a web browser but it works in other containers as well. The scriptable object is accessible to the Win32 host via COM IDispatch interfaces, which the host application can invoke to send data to the embedded Silverlight application as shown in the diagram below.


You may at this point decide that the custom host is all you need, but may also want to run the application in a browser, for example because the Silverlight application integrates with an existing web site or you need to comply with an industry standard like CUSS.



Single Process solution

Non-standard,  Windows-only container


Need to re-develop browser functionality, such as caching


Tight coupling of peripheral management and application UI

In the past, applications installed a local web server like Cassini which hosted a .NET component that would communicate with local resources as needed. The Silverlight application would make REST calls to the “web server” which would handle the communication with a peripheral device or other local resources.


However, this approach had a couple of drawbacks. First, running a local web server requires administrator privileges and is often frowned upon because of potential security risks. Second, communication always had to be initiated by the Silverlight application. The peripheral could not send notifications to the application running in the browser.



Potentially fully managed code implementation

Complexity running a local web server


Communication overhead with HTTP


One-way communication. Silverlight application has to poll/


Policy restrictions for local services and sockets


Perceived security risks of local web servers


Complex deployment of local services

With Silverlight 3 we have an alternative that doesn’t require a local “web server”. Silverlight 3 introduced the ability for Silverlight applications to communicate regardless what application container they are running in. One Silverlight application would send messages over a “named channel” with a LocalMessageSender object. Another Silverlight application can listen on that named channel with a LocalMessageReceiver object.

In our case the Win32 application could be an application without a visible UI that only acts as a bridge between the peripherals and the browser application.


In a scenario where the need for a local peripherals is limited to a single, well-known device, the effort to write a C++ host and communicate with the device in unmanaged code isn’t a daunting task. More sophisticated POS solutions may require more than one peripheral type. They may even require supporting different device configurations, i.e. bar code readers from different vendors. These types of POS applications typically require POS abstraction frameworks like POS for .NET. However, in that case the host application could be either a managed C++ application with C++ code to implement the COM host for the Silverlight “bridge” application and .NET code to manage peripheral interaction.



Loose coupling between peripheral management and UI

Local deployment of peripheral management application required

Shareable bridge

More complex architecture with two applications

To close with some food for thought, there may be a completely browser based alternative that I haven’t tested out yet. Instead of running a Silverlight bridge in a separate Win32 application you could try to build a C++ ActiveX control to host the Silverlight “bridge” and the native device interaction code. This approach presents some security challenges that can be mitigated, but you still have to deal with the perceptions of pushing down an ActiveX control.


You do have the benefits of clean separation between a cross-platform application that run on any platform that supports Silverlight and the platform specific extensions that need to manage interaction with local peripherals. You also have the benefit of a fully browser-based deployment model.



Fully browser-based deployment model

Native code development of ActiveX control


Policies for secure ActiveX execution required to avoid security risks


  • Kiran,

    Silverlight 4 introduces COM integration for Out-Of-Browser apps, but not for in-browser apps like I outline in my post.

    I'm hoping to follow up with a Silverlight 4 post soon. The next post will detail the code for the solution in this post. It should post later this week.

    I do know of several kiosk apps that are being developed or already running in Silverlight, but unfortunately I can't disclose the customers. Two of them are chains of specialty retailers, another is in the transportation industry.

    Hope this helps,

  • Thanks for your timely respone.

    Waiting for your Silverlight 4 post.

  • I look forward to reading what you find out about developing this type of application with Silverlight 4.

  • Silverlight will definately adds the usability of kiosk system. Interested to read more about Silver light apps.

  • ...just adding to the chorus of voices interested in the Silverlight 4 update of this article...

  • this web application allow you to build a kiosk application from server (you can also preview the result before deploy it to the kiosk).

  • Hello, I know this article was commented a lot of time ago, but i'm working on Kiosk software and i need some help to understand what could be the best solution. First I decided to try with WPF(Windows Presentation Foundation) for the ease of hardware devices implementation.

    Im trying to centralize kiosk administration, One server for about 20 Kiosks. what i want is to run the application from the server to the Kiosk. I thin if a got a very good connections between kiosk and server i could use remote desktop protocol from kiosk to the server with Windows Terminal Services, but im afraid about if kioks could be run animations implementing this architecture.


    Could yo please tell what the best way to do this, im just want to update the software at one time for all kiosk when its nedeed.

    Thanks and sorry for my bad english.

  • You are so awesome! I do not suppose I've read anything like this before. So good to discover someone with a few original thoughts on this issue. Really.. thanks for starting this up. This website is something that's
    needed on the internet, someone with a little originality!

  • I think that everything said was actually very
    reasonable. However, think about this, what if you
    were to create a awesome headline? I ain't suggesting your content isn't good., however
    suppose you added a post title to possibly get a person's
    attention? I mean Silverlight 3 for Kiosk Apps?
    Of Course! -

Comments have been disabled for this content.