Windows Image Acquisition (WIA) Library

Ages ago I created a simple Windows Image Acquisition library for a proof-of-concept I was working on.  I zipped it up and threw it in the old blog as a download and promptly forgot about it. Well the new blog engine seems to be resurrecting things, and it has a pretty simple way to see what people are looking for and when they get 404s.

I dug up the old source, and put it somewhere a bit more stable this time – over on Codeplex.

On Software Development: Moving from statics or instances to a DI container

I’ve recently started refactoring a customer’s code base for a working application.  They recognize the need to make their code more extensible and maintainable so I’m helping to massage the existing code into something that they will be able to continue shipping and upgrading for years to come without ending up backed into a corner.

One of my first suggestions was to start eliminating the abundance of static variables in the code base.  In this case, static classes and methods abound, and it looks like it was used as a quick-and-dirty mechanism to provide singleton behavior.  Now I’m not going to go into depth on why an actual singleton might have been better, or the pitfalls of all of these statics.  Write-ups on that kind of thing about in books and on line.

Instead, let’s look at what it means to migrate from a static, an instance or a singleton over to using a DI container, specifically OpenNETCF’s IoC framework.

First, let’s look at a “service” class that exposes a single integer and how we might consume it.

   1: class MyStaticService

   2: {

   3:     public static int MyValue = 1;

   4: }

And how we’d get a value from it:

   1: var staticValue = MyStaticService.MyValue;

Simple enough.  Some of the down sides here are:

  • There’s no way to protect the Field value from unwanted changes
  • To use the value, I have to have a reference to the assembly containing the class
  • It’s really hard to mock and cannot be moved into an interface

Now let’s move that from a static to an instance Field in a constructed class:

   1: class MyInstanceService

   2: {

   3:     public MyInstanceService()

   4:     {

   5:         MyValue = 1;

   6:     }


   8:     public int MyValue { get; set; }

   9: }

Now we have to create the class instance and later retrieve the value.

   1: var service = new MyInstanceService();


   3: // and at a later point....

   4: var instanceValue = service.MyValue;

We’ve got some benefit from doing this.  We can now control access to the underlying value, making the setter protected or private, and we’re able to do bounds checking, etc.  All good things.  Still, there are downsides:

  • I have to keep track of the instance I created, passing it between consumers or maintaining a reachable reference
  • I have no protection from multiple copies being created
  • The consumer must have a reference to the assembly containing the class (making run-time plug-ins very hard)

Well let’s see what a Singleton pattern buys us:

   1: class MySingletonService

   2: {

   3:     private static MySingletonService m_instance;


   5:     private MySingletonService()

   6:     {

   7:         MyValue = 1;

   8:     }


  10:     public static MySingletonService Instance

  11:     {

  12:         get

  13:         {

  14:             if (m_instance == null)

  15:             {

  16:                 m_instance = new MySingletonService();

  17:             }

  18:             return m_instance;

  19:         }

  20:     }


  22:     public int MyValue { get; set; }

  23: }

And now the consumer code:

   1: var singleTonValue = MySingletonService.Instance.MyValue;

That looks nice from a consumer perspective.  Very clean.  I’m not overly thrilled about having the Instance accessor property, but it’s not all that painful.  Still, there are drawbacks:

  • The consumer must have a reference to the assembly containing the class (making run-time plug-ins very hard)
  • If I want to mock this or swap implementations, I’ll got to go all over my code base replacing the calls to the new instance (or implement a factory).

How would all of this look with a DI container?

   1: interface IService

   2: {

   3:     int MyValue { get; }

   4: }


   6: class MyDIService : IService

   7: {

   8:     public MyDIService()

   9:     {

  10:         MyValue = 1;

  11:     }


  13:     public int MyValue { get; set; }

  14: }

Note that the class is interface-based and we register the instance with the DI container by *interface* type.  This allows us to pull it back out of the container later by that interface type.  The consumer doesn’t need to know anything about the actual implementation.

   1: // Note that the Services collection holds (conceptually) singletons.  Only one instance per registered type is allowed.

   2: // If you need multiple instances, use the Items collection, which requires a unique identifier string key for each instance

   3: RootWorkItem.Services.AddNew<MyDIService, IService>();


   5: // and at a later point....

   6: var diValue = RootWorkItem.Services.Get<IService>().MyValue;

Mocks, implementation changes based on environment (like different hardware) and testing become very easy.  Plug-in and run-time feature additions based on configuration or license level also are simplified.

ORM: Transactions are now supported

I’ve just checked in new code changes and rolled a full release for the OpenNETCF ORM.  The latest code changes add transaction support.  This new release adds a load of features since the last (the last was way back in February), most notably full support for SQLite on all of the following platforms: Windows Desktop, Windows CE, Windows Phone and Mono for Android.

OpenNETCF.IoC: New Release

We’ve been heavily dogfooding the IoC project (and others) lately and I finally took the time today to back-port the fixes and updates to the public code. This is being used for a solution that runs on both the desktop and the compact framework, so it’s been heavily tested under both of those environments. The new release (1.0.11235) is now available on Codeplex.

Another Open Source Project: OpenNETCF Extensions

Like most people, the more projects I work on the more I find myself reusing common bits and pieces of code. For the past year or so I’ve been collecting these pieces into a library I called OpenNETCF.Extensions.  The name was becasue they originally started as a set of extension methods that helped me to compile one code base for Windows Phone, the Compact Framework and the full framework, but it eventually started expanding in scope.  I added a fairly robust set of method for validation, a set of classes for helpiing make REST clients, a class for a circular buffer (FIFO) and generally anything I found myself using on multiple projects.

Since many of those projects are already open-source, it started becoming a pain maintaining a single, controlled source for these helpers.  So in an attempt to centralize it, I’ve created yet one more open source project.  My plan now is to have all of the consuming projects only use binary releases from this project.

So, with that said, go ahead and check out the new MIT-licensed OpenNETCF Extensions project over on Codeplex.

Major Update to MTConnect Managed SDK

I’ve published a major upgrade to the OpenNETCF MTConnect Managed SDK over on Codeplex.  Earlier releases only had Agent support, but this release adds Client support.  The SDK supports both the Compact Framework and the Full Framework (version 3.5 of each).

If you’re wondering exactly what MTConnect is, it is a standard for how data should be published from machine tools as XML over a simple Web interface.  More information on the standard can be found on the MTConnect Institute’s web site, including the full specification.  This SDK allows managed developers to publish and/or consume data according to the standard.

Padarn Host implementation for MTConnect Agent SDK

The MTConnect Agent SDK I published last week is really only useful if you implement a Host to actually serve up the data.  The IHost interface isn’t complex, but if you don’t have an example, it’s a bit difficult to understand my intent.  I’ve published a desktop implementation that uses Padarn as the web server.  In theory the same code should work under Windows CE as well, but I’ve not yet tested it to be certain.

MTConnect Agent SDK for .NET

I do quite a bit of my work in the area of industrial automation, and one of the more interesting initiatives to come along in a while is called MTConnect (“MT” presumably for “Machine Tool”).  MTConnect is an open standard for communicating with a machine tool to retrieve information about its current or past status – everything from executing controller line of code to tool head positions.  It’s interesting enough that I joined the Technical Advisory Group and am helping to review and improve the specification (version 1.1.0 was just ratified last week).

As frequently seems to be the case, there was a bit of interest from other members on exposing MTConnect data from tools running Windows OSes (both CE and XPe), but no one working on providing an actual SDK to allow a standardized way to actually do it.  Well implementing code from nothing but a spec is actually something I find pretty fun and interesting, so I took up the challenge.  My first attempt was, as is typical, more of a throw-away attempt at writing code to help me understand how the spec itself works.  I spent a couple weeks on it then tossed it all out.

I then took the knowledge I gained from that first effort and put together a more coherent SDK that I’m releasing a loose Beta of today over on Codeplex.  It’s not done – in fact I wanted to get a few more features in and get it to a releasable point before publishing it, but I’ve already gotten inquiries and volunteers to test out the beta work, so I’m publishing early to facilitate sharing the code between teams and to allow me to track bugs and discuss the SDK in a publicly searchable location.

I’m working on a specific project that is going to use this SDK, so I have a specific set of funtionality that I’m driving toward, but that doesn’t mean I’m not open to making it easier for everyone to use. If you’re working on machine tool controllers and are interested in exposing data meeting the MTConnect standard, I encourage you to take a look at the Agent SDK, post questions in the Discussions area and report bugs/desired features to help drive the effort forward.

Updates to OpenNETCF.IoC Framework

We recently ported a desktop SCSF/CAB application over to use the OpenNETCF.IoC framework.  The primary thinking here was that the SCSF has way, way more stuff than we really need, want or use and the SCSF wizards had done wacky things to a few Studio installations, so we wanted to get rid of all of that as well.

I’ve checked in the fruits of the labors into the Codeplex project, including new desktop project and solution files.

Now you can be even closer to one codebase for both desktop and device projects.  If nothing else, it allows you to not have to remember two different injection frameworks if, like me, you end up doing a lot of work on both platforms.

OpenNETCF.IO.Serial Library moved to Codeplex

As you may have guessed from some of my recent blog entries, we’re making a push to get a lot of our shared source code out to the Codeplex servers.  Our serial library is the latest one to make the move.  It’s now available at  As with all of these libraries, if you have the desire to contribute, fix, extend, or whatever just let us know and we’ll add you as a developer.