Sunday, July 19, 2009

Pos .Net Series, Post #1 – Introduction & The Good Stuff

Microsoft Pos .Net is (almost certainly) the best way to control point of sale peripherals from your .NET retail application. It allows you to easily control receipt and slip printers, barcode scanners, cash drawers, MICR (magnetic ink character recognition), MSR (magnetic swipe reader), line display devices, and more.

Some time ago my boss and I decided we wanted to build Pos .Net drivers for the point of sale application I work on, Ontempo Store. Unfortunately we had trouble finding suitable service objects at the time, and as we only needed to drive a receipt printer and cash drawer so we implemented an alternate solution. Recently we got some new hardware on short-term loan, and it came with OPOS drivers (which are compatible with Pos .Net). We’ve also had better success in finding Pos .Net service objects for our existing hardware, recently and so I spent some time building a new set of drivers while we still had the loan hardware to test with.

This is a first in a series of posts on my experiences with Pos .Net. On the whole, it’s pretty good, but there are a few pitfalls to be aware of (a lot of these aren’t really Pos .Net’s fault, but you have to live with them anyway so I’m blogging about them).

Pos .Net has three really great features;

  • It allows you to control many different brands and model of devices in a device independent way… you don’t have to build a separate driver or write different code for each specific peripheral. While OPOS also does this, OPOS implementations are often built using COM components, which are an old technology and not ideal for use for .Net languages if you can help it.
  • It has a neat plug and play system that allows automatic detection of (connecting and disconnecting) USB devices, with no additional configuration of the device required to use it.
  • If your application is running on a terminal server but your devices are plugged into each local client, Pos .Net can access the devices back across the Remote Desktop connection, allowing your system to operate like a client application with regards to devices.

Pos .Net is the Microsoft implementation of the UPOS (Unified Point Of Service) standard, which is the follow up to the original OPOS standard, but features like the plug and play support have been added specifically by Microsoft as added extras.

In order for Pos .Net to work with a given device you must have either a native .net ‘Service Object’, or a legacy OPOS service object. Service objects are the ‘middleware’ that contain the brand/model specific code for a particular peripheral.

Once you have an appropriate service object (and you can write your own if need be) controlling a device with Pos .Net is very easy. Performance is generally great (although some what dependent on the service object).

If you’re new to Pos .Net and looking to get started I recommend downloading the Pos .Net SDK and looking at it’s samples. It has some good samples for dealing with barcode scanners and building your own service objects. If you want some samples for printers and cash drawers then I recommend downloading the Epson OPOS ADK for .Net. To get that, you’ll need to register at, and once logged in go to Application Development –> OPOS then scroll to the bottom of the page to find the download links. Even if you’re not using Epson hardware, the Epson samples will work (because Pos .Net is device independent) and they cover most aspects of using the Pos .Net PosPrinter class. There’s also this Microsoft hands on lab which is quite good too.

For Pos .Net resources and links see my earlier post.

If you’re wondering why you should use Pos .Net over other methods (such as using the Win32 print API) for driving printers and cash drawers, here are a few good reasons;

  • Universal escape codes… even Epson’s escape codes don’t necessarily work the same on all models, and across different brands there’s even more variation.
  • Better status handling and error detection. Detect conditions cover open, paper low, paper out, offline etc.
  • Capability reporting, know whether your device can report it’s status, print bitmaps, handle rotation etc.
  • Easy and elegant ways to detect/get notified of changes to the cash drawer (so you can close/clear your change window when it’s closed, or provide a warning or alarm if it is open too long).
  • Easily and efficiently print to two stations at once (i.e receipt and journal).


  1. This is very helpful. Thanks for the effort to blog.

  2. This is very helpful. Thanks for taking the time to post.


  3. Thanks Neil, its always nice to hear when one of my posts is useful.

  4. good post. can you indicate how long it takes to write a service object for a device? did you actually do this?

  5. Hi there,

    No, I haven't written my own service object but there are some people doign so posting questions in the Pos .Net forum Microsoft host, you might want to check out their threads.

    How long would it take ? That depends on the type of device and the features it supports... a cash drawer, or possibly even barcode scanner or MSR should be possible in a day or two, but a device like a PosPrinter or CheckScanner could take months as these devices are complex and often have a lot of features.

    Sean Liming ( has written some service objects for cash drawers and scales, you may be able to download the source or request it from him if you want a sample, but again those are simple devices.

  6. I'm interest on the redirect the WEPOS device to client machine through Remote Desktop connection.
    Is it i must use SQL 2008 Terminal Service and load my Application into TS Web Access in order to use this feature?

  7. Hi TuanFoo,

    I'm afraid I don't actually know the answer, but I don't *think* it requires Windows 2008 (it certainly doesn't require any particular version of Sql Server, the device access is not related to your database in anyway).

    I would guess it would work with Windows Server 2003.

    I'm not sure what you mean by TS Web Access, but again, I don't *think* it requires a browser or any web specific components.

    I suggest you look on MSDN for help, or post in the Pos .Net forum;

    to see if someone else can you.

    Good luck !

  8. Another benefit of native POS for .NET so over Win32 API and marshalling is 64 bit support.

  9. In My case MSR is connected to Computer1 and Application is running on Computer2.
    Please explain how to implement using POS .NET and C#

  10. Hi,

    Unfortunately there is no built in support for sharing POS .Net devices across machines/networks. You will need to run an application or (Windows) service on the PC the device is connected to that exposes some kind of network service (SOAP or REST - SOAP services are pretty easy to create in .Net and seem more appropriate than REST since you really want an RPC style service). The network service will have to expose methods to make the device do things, and then your app running on computer2 will have to make the network calls to your service to interact with the device. Basically, you have to do it all yourself.

  11. Thank you very much for your post. epos software Its pretty interesting. I appreciate your blogs and look forward for your next blog.