A new customer came to me late last week with an interesting problem.  They have hundreds of Motorola/Symbol MC70 barcode scanners in the field and occasionally the flash memory on the devices gets corrupted. 

The current “solution” these guys are using involves removing the flash chips from the board, reprogramming it in a separate device, re-balling the BGA pins, and re-soldering it to the board. That explains why they desperately want an application that can do it.

They know the range where the corruption occurs and wanted an application that would allow a user to read, update and rewrite the corrupted bytes in flash.  They had talked with five separate developers before they found me, and all 5 had agreed that it was impossible, so naturally I took that as a challenge.

First, there are lots of things to know about how flash access works.  Most importantly, it’s not like RAM.  You can’t just map to it, then go about your merry way doing 32-bit reads and writes.  You can read it that way, sure, but writing is a whole new game.  Flash is broken up into “blocks” (which aren’t even always the same size - in the case of the MC70, the first 4 blocks are 64k long, and the rest are 256k long.) and writes must be done following this general procedure:

1. Read the *entire* block that contains the byte you want to change into RAM
2. Change to flash to Lock mode (a flash register write)
3. Unlock the block of flash (another register write)
4. Change the flash to erase mode (register write)
5. Erase the *entire* block of flash (which writes all FF’s to it)
6. Change the flash to write mode (register write)
7. Update the RAM buffer with your changes
8. Write in the *entire* block block to flash
9. Tell the flash to commit (register write)
10. Wait for the flash to finish (register read)
11. Put the flash back into read mode (register write)

Oh, and if you get any of this wrong, you’ve made yourself an expensive brick.  The only solution at that point is the de-soldering and reprogramming route, and I don’t have that kind of hardware in my office.

So I started writing the app Monday morning, using C# since I had to create a UI for the editor, and on Wednesday morning this is what I delivered:

So, in just 2 days I did what was “impossible”. I not only wrote all of the flash access code, I also wrote a hex editor control and an app UI to make use of the flash library.

A customer recently contacted me with a Padarn Web Server problem.  They wanted users to be able to download data files from their device to a client browser, but they were running out of device memory when the file got large (38MB in their case, but the size would be completely hardware and environment dependent).

What you have to understand is that Padarn caches your Page’s response in memory until such time as you either tell it to Flush explicitly, or until the Page has full rendered (in Padarn’s view) at which point it will call Flush for you.

For a large file, it’s going to be bad to try to hold the entire thing in memory before pushing it across the wire, so the strategy would be to read the local file in packets, then send those packets across to the client using Response.BinaryWrite.

Now BinaryWrite simply puts the data into the memory cache, so you have to actually tell Padarn to send it across the wire by calling Flush.  The issue there, though, is that on the first Flush, Padarn has to assemble and send the payload header to the client, and part of that header is the total length of the content.  If you haven’t explicitly set the content length, Padarn has no idea how big it might be, so it defaults to the length what it has in the buffer, and sends the header.  The browser then decodes that header and expects a length of only that first packet.

The solution is to set the Response.ContentLength property before you send any data.  Padarn will use your override value when it sends it to the client, and all will be well.

Here’s a quick example of a page that I used to send a 1.1GB media file from a page request with no problem.  You might want to tune the packet size based on device memory and speed, but 64k worked pretty well for my test.

               1:
              class LargeFileDownload
: Page

               2: {

               3:
              protected
              override
              void Render(HtmlTextWriter
writer)

               4: {

               5: var
largeFilePath = @"D:\Media\Movies\short_circuit.mp4";

               6:  

               7: var
packetSize = 0x10000; // 64k packets

               8:  

               9:
              using(var
stream = new FileStream(

               10: largeFilePath, 

               11: FileMode.Open, 

               12: FileAccess.Read))

               13: {

               14: var
toSend = stream.Length;

               15: var
packet = newbyte[packetSize];

               16:  

               17:
              //
set the response content length
            

               18: Response.ContentLength
= toSend;

               19:
              //
set the content type as a binary stream
            

               20: Response.ContentType
= "application/octet-stream";

               21:
              //
set the filename so the browser doesn't try to render it
            

               22: Response.AppendHeader("Content-Disposition", 

               23:
              string.Format("attachment;
filename={0}", 

               24: Path.GetFileName(largeFilePath)));

               25:  

               26:
              //
send the content in packets
            

               27:
              while (toSend
> 0)

               28: {

               29: var
actual = stream.Read(packet, 0, packetSize);

               30:  

               31:
              if (!Response.IsClientConnected)

               32: {

               33: Debug.WriteLine(

               34:
              "Client
disconnected. Aborting file send.");

               35:
              return;

               36: }

               37:
              else
            

               38: {

               39: Debug.WriteLine(

               40:
              string.Format("Sending
{0} bytes. {1} to go.", 

               41: actual,
toSend));

               42: }

               43:  

               44:
              if (actual
== packetSize)

               45: {

               46: Response.BinaryWrite(packet);

               47: }

               48:
              else
            

               49: {

               50:
              //
partial packet, so crop
            

               51: var
last = newbyte[actual];

               52: Array.Copy(packet,
last, actual);

               53: Response.BinaryWrite(packet);

               54: }

               55:  

               56:
              //
send the packet acrtoss the wire
            

               57: Response.Flush();

               58:  

               59: toSend
-= actual;

               60: }

               61: }

               62: }

               63: }

There’s no doubt in my mind that code libraries and frameworks are fantastic for saving time and work, after all I want to spend time solving my business problem, not writing infrastructure.  Nowhere is this more true than it is with Object-Relational Mapping, or ORM, libraries. 

Broadly speaking, if you’re still writing application code that requires that you also write SQL, you’re wasting your time.  Wasting time thinking about SQL syntax.  Wasting time writing it.  Wasting time testing, debugging and maintaining it.

I believe this so much, but was so dissatisfied with any existing ORM offering, that I wrote my own ORM. It wasn’t a trivial task, but I have something that does exactly what I need, on the platforms I need, and does it at a speed that I consider more than acceptable.  Occasionally I hit a data storage requirement that ORMs, even my own, aren’t so good at. 

ORM usage is usually viewed as one of two approaches: code first or data first.  With the code-first approach, a developer defines the storage entity classes and the ORM generates a backing database from them.  With data first, the developer feeds a database into the ORM or an ORM tool, and it then generates the entity classes for you. 

But this doesn’t cover all scenarios – which is something no ORM that I’m aware of seems to acknowledge.  Consider the following use-case (and this is a real-world use case that I had to design for, not some mental exercise).

I have an application that allows users to define storage for data at run time in a completely ad-hoc manner.  They get to choose what data items they want to save, but even those data items are dynamically available so they are available only at run time.

So we need to store effectively a flat table of data with an unknown set of columns.  The column names and data types are unknown until after the application is running on the user’s machine.

So the entities are neither data first nor code first.  I’ve not thought of a catchy term for these types of scenarios, so for now I’ll just call it “user first” since the user has the idea of what they want to store and we have to accommodate that.  This is why I created support in the OpenNETCF ORM for the DynamicEntity.

Let’s assume that the user decides they wanted to store a FirstName and LastName for a person.  For convenience, we also want to to store a generated ID for the Person entities that get stored.

At run time, we generate some FieldAttributes that define the Person:

               1: var
fieldList = new List<FieldAttribute>();

               2: fieldList.Add(new FieldAttribute()

               3: {

               4: FieldName
= "ID",

               5: IsPrimaryKey
= true,

               6: DataType
= System.Data.DbType.Int32

               7: });

               8:  

               9: fieldList.Add(new FieldAttribute()

               10: {

               11: FieldName
= "FirstName",

               12: DataType
= System.Data.DbType.String

               13: });

               14:  

               15: fieldList.Add(new FieldAttribute()

               16: {

               17: FieldName
= "LastName",

               18: DataType
= System.Data.DbType.String,

               19: AllowsNulls
= false

               20: });

And then we create and register a DynamicEntityDefinition with the DataStore:

               1: var
definition = new DynamicEntityDefinition(

               2:
              "Person", 

               3: fieldList, 

               4: KeyScheme.Identity);

               5:  

               6: store.RegisterDynamicEntity(definition);

Now, any time we want to store an entity instance, we simply create a DynamicEntity and pass that to the Insert method, just like any other Entity instance, and the ORM handles storage for us.

               1: var
entity = new DynamicEntity("Person");

               2: entity.Fields["FirstName"]
= "John";

               3: entity.Fields["LastName"]
= "Doe";

               4: store.Insert(entity);

               5:  

               6: entity
= new DynamicEntity("Person");

               7: entity.Fields["FirstName"]
= "Jim";

               8: entity.Fields["LastName"]
= "Smith";

               9: store.Insert(entity);

The rest of the CRUD operations are similar, we simply have to name the definition type where appropriate.  FOr example, retrieving looks like this:

               1: var
people = store.Select("Person")

Updating like this:

               1: var
person = people.First();

               2: person.Fields["FirstName"]
= "Joe";

               3: person.Fields["LastName"]
= "Satriani";

               4: store.Update(person);

And Deleting like this

               1: store.Delete("Person",
people.First().Fields["ID"]);

We’re no longer bound by the either-or box of traditional ORM thinking, and it leads to offering users some really interesting and powerful capabilities that before were relegated to only those who wanted to abandon an ORM and hand-roll the logic.

You don’t have to be a developer to create useful, customized applications for maintenance workers.  See what’s happening on the vehicle in real time, see it how you want and get it done in seconds.  Take a look at the new Transit and Telematics hands-on lab for Solution Family.

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: }

               7:  

               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();

               2:  

               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;

               4:  

               5:
              private MySingletonService()

               6: {

               7: MyValue
= 1;

               8: }

               9:  

               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: }

               21:  

               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: }

               5:  

               6:
              class MyDIService
: IService

               7: {

               8:
              public MyDIService()

               9: {

               10: MyValue
= 1;

               11: }

               12:  

               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>();

               4:  

               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.

Yes, VS 2012 will support CE development, including Compact Framework 3.9.  Support is scheduled to be released in Q1 of next year.  See this video for more details.

I’m (finally) trying to publish some better, more formal documentation for the ORM.  I just posted a simple example of how you can create a one-to-many relationship between Entities and how you can get the ORM to fill in the references when you do a Select call.  Take a look at the ORM documentation for more details.

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.

If you needed another excuse to try out IoC, here it is.  It’s now even easier to create intuitive UIs. I just checked in a new feature to the OpenNETCF.IoC.UI assembly.  Workspaces now have basic gesture support, so you get an even on a swipe in the four primary directions (up/down/left/right). 

The OpenNETCF ORM has supported SQLite for a while now – ever since I needed an ORM for Android – but somehow I’d overlooked addeing SQLite support for the Compact Framework.  That oversight has been addressed and support is now in the latest change set (99274).  I’ve not yet rolled it into the Release as it doesn’t support Dynamic Entities yet, but that’s on the way.

One limitation with using the SmartClientApplication as a basic for your IoC application is that it locks you in to the type of Form that’s going to be displayed when your app starts up.  In most cases that’s really not an issue, but sometimes you’d like to decide at runtime what UI to display.  You might even want that UI to come from a dynamically loaded DLL.

Well I just added a new capability to the SmartClientApplication.  During the startup process, the framework now looks in the Services collection to see if you’ve already registered a Form deriving from the new ShellReplacement base class.  If it finds one, that form will be shown instead of the type passed into the SmartClientApplication.  The effectively gives you a “default” main shell form, with the ability to dynamically load a different one based on whatever criteria you want.  We’re using it to support vertical-specific UIs for the Solution Engine, meaning that if you have the HVAC module installed you’ll get one UI but if you have the Telematics module installed you’ll get another.

The implementation details are as trivial as I could think of making them.  First, create your new shell Form like this:

               1:
              public
              partial
              class HVACMainView
: ShellReplacement

               2: {

               3:
              public HVACMainView()

               4: {

               5: InitializeComponent();

               6: }

               7: }

Then register it as the replacement when your Module loads:

               1:
              public
              class Module
: ModuleInit

               2: {

               3:
              public
              override
              void AddServices()

               4: {

               5: RootWorkItem.Services.AddNew<HVACMainView,
ShellReplacement>();

               6: }

               7: }

That’s all there is to it.  You can disable the feature by using the EnableShellReplacement property (defaults to true) of the SmartClientApplication.  Get the latest change set (69942 or later) to try out the new feature.

I’ve released version 1.0.12221 of the OpenNETCF IoC framework.  Not a whole lot new going on – it was primarily bug fixes – but binaries for all supported Platforms (Full framework, Compact Framework, Windows Phone and Mono for Android) are included.  If you’re using it, how about showing me some love and rating it (other than “Have not used it yet” – what kind of review is that?).

http://ioc.codeplex.com/releases/view/82674#ReviewsAnchor

The Data Collector feature in our Solution Family product line is one of the oldest (if not the oldest) sections of code, and as such it's in need of a refactor to improve how it works.  We've updated just about everything else that uses data storage to use the OpenNETCF ORM framework, but Data Collectors have languished, largely because they are complex.  The Data Collector lets a user create an ad-hoc data collection definition that translates into a SQL Compact Table at run time.  The problem with migrating to ORM is that the ORM requires compile-time definitions of all Entities.  At least that was the problem until today.

I just checked in a new change set that supports the concept of a DynamicEntity (along with all of the old goodness that is ORM).  Now you can create and register a DynamicEntityDefinition with your IDataStore at run time and it will generate a table for you in the back end.  New overloads for all of the typical CRUD commands (Select, Update, Insert, Delete) allow you to just ask for the DynamicEntity by name and it returns an array of DynamicEntity instances that hold the field names and data values.

It's in a "beta" state right now, but there's a test method in the change set that shows general usage of all CRUD operations.  Give it a spin, and if you find any bad behavior, report it on Codeplex.

It was easy to miss, but Microsoft publicly announced that Smart Device development projects will, in fact, be released in Visual Studio 2012 in Q1 of 2013.  It’s not news to me, but it is to most, and it’s way, way past due.

We recently needed the ability to do most-recently-updated data caching in our Solution Family products.  Since the products use the OpenNETCF ORM Framework, it only made sense to update the framework itself to include events that fire whenever an Insert, Update or Delete occurs.  In fact I added Before and After versions for each. While I was at it, I also added a full complement of virtual On[Before|After][Insert|Update|Delete] methods to the DataStore base, allowing DataStore implementers to hook into the process as well.  I’m thinking I’ll use those at some point in the future to add some form of Trigger capabilities.

I'm trying my hand at making using some of our stuff a bit easier.  Today I burned some time trying to understand the project template infrastructure and the result was the creation of a couple VSIX files for installing IoC templates into Visual Studio. 

Right now it only supports desktop projects (IoC supports Windows Phone, Mono for Android, Monotouch and Compact Framework). I've also not figured out how to actually deploy the IoC and Extensions binaries with the templates, so when you create your project, the References section will contain IoC references, but they'll be broken.  Still, as a first cut it greatly simplifies setting up a new IoC UI (SmartClientApplication) or IoC Module project.

You can install the templates in one of three ways:

• Use the Extension Manager in Visual Studio (Tools -> Extension Manager ; Online Gallery ; search for 'OpenNetCF')
• Download them via the Web from the online Visual Studio Gallery
• Pull them from Source Controll over at the IoC Project on Codeplex

Ages ago I created an SDK that allows you to extract device CAB files and create a replacement for wceload if you wanted (we used this on a couple customer applications).  We also tried to sell it as an experiment in "value-based pricing".  Well the experiment showed, largely, that people would pay the minimum and very, very rarely come back and pay anything more so either it was of low value, or people are just cheap.

At any rate, I don't feel like maintaining it internally any longer so it has become yet another project that I've open sourced for the community at large.  The full download is now available over on Codeplex.

I just got an email in the Support inbox over at OpenNETCF asking about the libraries support (or really lack thereof) for Wireless Networking in Windows Embedded Compact 7 (rolls off the tongue, doesn’t it?).  While this is a question about a specific feature of the SDF, it really opens up the broader question of what our plans are for the future of the whole product.  In fact you could say it really opens up the question on what our general company plans and philosophy are.

First, let’s address this specific issue, as it deserves answering and has a little bit of a back story leading to a minor rant which is always fun. 

The SDF supports an object model for wireless networks that is based around the Wireless Zero Config (WZC) API.  Microsoft introduced WZC in CE 5.0 (IIRC) in an attempt to “standardize” the way the platform and apps would communicate with the wireless drivers, since NDIS doesn’t really have any specification for a lot of the wireless properties.  While I applaud the spirit, WZC is convoluted at best, and was definitely not designed to make the life of someone who has to use P/Invoke to communicate with it any easier.  Still, it was some sort of standardization so we rolled up our sleeves and created a managed interface for it. 

I’ll readily admit that what we ended with isn’t ideal, but I’m a fierce self critic and I rarely think what we do is as good as it could be.  Still it provided a programmatic interface for something that a *lot* of people wanted and that Microsoft had not implemented in managed code.

Well with Compact 7 (I’ll just call it CE7) Microsoft decided that WZC wasn’t the way to go, but instead Native WiFi was.  Painfully they didn’t follow a sensible “deprecated but supported” track for WZC and support side-by-side, they just dropped WZC support altogether.  That meant that we could not interface with a wireless adapter under CE7 using our existing code base at all – it was a flat-out break.

To make things worse, Microsoft went radio-silent for about 2 years (and still counting – yes I’m looking at you Redmond!) on what, if any, future the Compact Framework, or CE for that matter, might have.  The original WZC work was probably 4-6 weeks of development and it required that we buy several devices for testing.  Believe me, it was a real pain in the ass.  Do we (more specifically do *I*) really feel like doing that all again for the Native WiFi interfaces?  If I do, where do I get a CE7 device with WiFi support?  If I do all of that work, what’s the ROI if Microsoft kills the Compact Framework?  What’s the ROI if they revive it and implement Wireless themselves?

It’s really difficult to answer those questions, and we’re not the only ones who are wondering these things.  I can say, though, that we’ve very recently decided that yes, we will continue to do both support and new development for the SDF.  What that new development will entail I can’t say.  Not because it’s some big secret, but because I can’t make those plans until Microsoft tells us their plans (and they haven’t).  If they decide to release a new version of the Compact Framework, I’d like to not have a load of functionality duplication between it and the SDF.

So, is the SDF a dead product?  No.  We will continue to support it and have plans for feature additions.  We just don’t know exactly what those features will be or when they will be written (confidence inspiring, I know). 

Will we provide Wireless support for CE7?  If Microsoft does not, then yes, we will.  Again, we don’t know if they will or not.  If they did, we don’t know when that would be.  Ideally, though, programming for WZC and Native WiFi should be the same, so if they don’t do it, we’ll add support that looks and feels just like what’s in the SDF today.  If they do add it, I’d be inclined to update our object model to match theirs (keeping the old stuff for compatibility though).

Don’t read too much into this.  Yes, I’m optimistic about the Compact Framework and Windows CE Windows Embedded Compact but I’ve been using them for over a decade and I’ve based a whole lot of my knowledge, business and life on them.  I almost have to be optimistic.  But let’s face it, CE and the CF are still great tools for delivering products.  We’re still shipping products based on them.  Still doing new development and new installs.  Still writing proposals for them. 

Yes, we’ve tested the waters with Android and iOS.  We’ve even delivered finished products for them both, but using those tolls only reinforced my feelings about the strength and possibilities of the CF and CE and we’re still committed to using and supporting them.

I've been working in the Windows Embedded space for over a decade now, and I must say it's a far different picture today than it was in years past.  That's not a jaded nostalgia either - Windows Embedded used to have a real annual conference at nice venues in Las VEgas.  We has good speakers and great content.  The teams in Redmond shared loads of info about what was going on and what was coming down the pike.  Teams cared about what they were doing and what their customers wanted.

Slowly, though, it seems to have atrphied to the state that it's in today.  I know of no one using Compact 7 in an actual product.  The Compact Framework hasn't had an update in something like 4 years and there is absolutely no word at all what its future might be.  The tools required to do development for non Windows Phone devices are no longer available unless you purchase a full (expensive) MSDN subscription.  I can usually count the number of questions that get asked in public forums and places like Stack Overflow in a week on two hands - sometimes just one.

Today I got what had to be one of the most telling things I've seen though.  A sign that the people is Redmond just don't care any longer either.  For years, Microsoft has sent out a monthly embedded newsletter - the Windows Embedded InfoBlast - and while the quality of the contents has been in the same slow decline as the rest of the industry, the one I received today just pegged the "I no longer give a shit" meter.  This is exactly how it looks in Outlook for me:

Obviously either no one cared enough to even look at that before it went out, or if the did they didn't care if anyone actually read it.  Looking at it is like looking into the sun, but without the benefit of the warmth on your face.

In my push to get our fundamental libraries up and working on Mono for Android we've added support for OpenNETCF Extensions and OpenNETCF IoC.  What that means is that now you can have a common code for a lot of application infrastructure that works on the Compact Framework, the desktop, Windows Phone, MonoTouch for iOS and Mono for Android.  So you can now create a single, common code base for your applications that includes data access, event aggregation, dependency injection and inversion of control.

Get the latest code over on Codeplex.

We've started doing work creating client applications for a few of our products to run on Android and iOS devices.  Since I'm a huge fan of code re-use, I took the time this week to port the OpenNETCF.ORM over to Xamarin's Mono for Android using a SQLite backing store implementation.  The biggest challenge was that SQLite doesn't support TableDirect not ResultSets, so it took a bit of code to get running.  Still, it took only a day and a half to get what I feel is pretty good support up and running.  I've not yet tested it through all of the possible permutations of queries, etc, but basic, single-table CRUD operations all test out fine.

So now a single code base can work on the Windows Desktop, Windows CE and Android (probably iOS and Windows Phone as well with very little work). If you're doing MonoDroid work, give it a try.

Occasionally I'm surprised at how old software never seems to really die off.  Take for example an old port I did of the zlib compression library to Windows CE.  Back in probably '05 I built the original sources for the Windows CE platform.  In '07 I created a managed wrapper for the library and some samples on how to use that library.  I put it on the web and then pretty much forgot about it.

Well when we migrated our web site to a new server, some old links died and this just happened to be one of them (if you know of others, please let me know) and today I got an email from someone asking if I still had the code.  Sure, it wasn't the day things went down, but it still means not only was someone looking for it, the cared enough to email me and ask.

For those looking for it, it's got a new, hoipefully more permanent home on Codeplex:  http://zlibce.codeplex.com

Lately it seems that I’m been doing a lot of posts referring to “a customer”.  Often they are different customers, but it really sounds impersonal, so in this one I’m going to name names and point fingers – in a friendly way, of course.

Last week Nicolas emailed me to get some advice on the Visual Studio 2008 Forms designer and the Compact Framework.  Specifically he wanted to know if it’s possible to get a custom TabControl to be designable.  My assumption is that either he’s inheriting from the stock version or they’ve created a fully custom control inheriting from ContainerControl – I didn’t ask because in either case the answer is simple: it’s not going to work in the designer.

I told him that it won’t work, but in retrospect I feel I’ve short-changed him a bit.  As a developer, I like to hear a bit more than an “abandon all hope, ye who sail here for there be sea monsters” kind of response.  Why doesn’t it work?  More importantly, what are my options for a workaround?

In this case it’s interesting to note that even if he could get the designer to work for this control, I’d recommend that he not do it.  And they why to that recommendation is far more interesting.

So, Nicolas, here’s the longer answer to your question.

First, you have to understand that the Studio Designer is very, very brittle.  Any little quirkiness tends to send it into fits, and once broke you often spend large amounts of time unloading things, resetting the toolbox, restarting Studio or even restarting the PC.  This is a huge time drain, so avoiding situations that break the designer is the first order of business.

Getting the designer working for a CF component is even worse.  CF controls often make use of things that the desktop doesn’t even have, which the designer really hates.  You also have to build the Controls for both versions of the CF (for Nicolas this is important since, at least last time I was with his team, they had versions of the application targeting CF 2.0 and CF 3.5).  A control built against CF 3.5 will never show up in the designer of a CF 2.0 project.  There’s also a major bug in the designer that limits CF 3.5 controls that I’ve written about before.

For designer support you also have to maintain an XMTA file and often end up having condition compiler statements which really make the code less readable.  Workarounds for most of these issues exist.  You can create separate set of “designer” assemblies that provide only stuff for the designer and minimal actual control logic.  The problem with this is that you then have to maintain these things, which sucks up developer time that should be spent actually solving your business problem.

You can’t create a desktop assembly and use it for the designer because the designer will then suck in the full .NET framework as a reference and attempt to deploy that to the device when you want to debug.

So if the designer is so brittle and worthless, what’s a developer to do?  Well, my general attitude is to provide “support” only for basic Controls, and by “support” I mean the inherent capability of the designer to show a box with the location and bounds of your control.  No rendering.  No styling.  No collection editing. 

Really the designer’s primary use for me is to aid in basic layout.  I need to put a Control on a Form, set it’s location and Size and that’s it anyway.  Anything else is done via code, and there’s nothing wrong with this.  Embrace it as how you must work and your life becomes much simpler.

That’s all well and good for a simple Control, but what about a container like Nicolas is after?  His team would like to be able to drop on a Tab control and design each individual Tab, right?  So what are they to do?

Well, I think they’re looking at the problem wrong to begin with.  I don’t blame them, people have been looking at this wrong for some time, and the simple existence of the TabControl tend to push people to look at it wrong.  In general, my recommendation is to not use the TabControl in the first place. 

First of all, it’s 2011.  That ass-looking TabControl would have been ok back in 1995 (if the devices had existed then) since it looks just like the ass-looking Windows 95 interface. 

It’s was an ok solution in 2000 when these devices were new and people thought of them as just “mini PCs” so extending the desktop paradigm to the device was what we did.    Yes, we wished we could do a little more to make it pretty by adding icons and custom drawing, but it worked and users really didn’t expect anything more.

But it’s 2011.  Users don’t use a stylus if they can avoid it.  They know an elegant UI when they see one because they’ve been using a smartphone.  Just because they have no choice in the app they use (this is an LOB app, so the user is locked in) is no excuse to not deliver something that is actually nice to use.  The TabControl does not meet that.  It’s tiny, it scrolls weird, and it’s ugly with no options to make it non-ugly.  Plus it’s  Tab motif.  Name the last mobile app you used on a phone that used tabs.  That’s what I thought. Abandon the piece of crap.

So what would I use?  Obviously this will be subjective, as it’s what I would personally do given a blank slate.  Nicolas is trying to put something into an already-existing, very large code base, so his mileage may vary, but I’m betting it won’t be too bad, and implementing this might actually do a lot toward getting other gains they really need like better transition time between views.

I’d start using the OpenNETCF IoC project.  I’d split each of the existing “tabs” into individual SmartParts, which are now fully designable since they’re just UserControls.  So there you are – the designer requirement is solved.  I’d then place on the Form a pair of DeckWorkspaces.  One would display the “selected” view and the other would replace the “tabs” of old with buttons or clickable images that would be used to select the current view.  It would look something like this in the designer for the Form:

And then the SmartPart that goes into the bottom workspace might be something like this in the designer (well it would probably be a bit different, but you get the idea):

See, the designer works.  It meets the business requirement that it provides a “tab-like” capability where the user selects an item across the bottom and the upper view changes.  But now it’s not just usable with a stylus but it’s also likely to be usable with a finger (gasp!) and aesthetically it doesn’t make my want to poke my own eyes out.  It’s a win-win.  Plus now you can lazy-load the views *on demand* rather than loading up every damned control on every tab when the Form is brought up, so the user is going to be pleasantly surprised there too.  Oh, and now it’s easy to change out “tabs” based on user rights or workflow and probably other benefits that I’m not thinking of.

Occasionally we’ve got to break out of the “what we know” and the “what we’ve always done” routine and look out at the horizon.  By doing so we can often make some simple changes and make things easier for both the developer and the user, and that is how we make progress.

I've published new updates to our MTConnect projects on Codeplex. Both the MTConnect SDK and the VirtualAgent have changes and for detailed info take a look at the change logs in the Source tabs on the project.  Here's a high-level list of what I think the important additions are:

• I've added a fully working reference implementation of an MTConnect Adapter for Okuma THINC controllers (full source is included).  If you have an Okuma machine with a THINC-supported controller on it, you now have a simple agent and adapter you can drop onto the machine to start publishing data immediately. I hope to find time to put together a reference implementation for Fanuc FOCAS controllers.  If you're interested or in need of that support, let me know and we can discuss prioritizing it and the features you need.
• I've added support for SHDR adapters.  At the [MC]2 conference in Cincinnati there was concern that once you selected an Agent technology (either ours or the reference MTConnect C++ Agent), then you were locked in to creating Adapters only for that Agent.  That is no longer the case.  Our Virtual Agent now can easily consume data from your existing C/C++ Adapters written against the reference Agent.  No changes are required in your existing Adapters at all.

If you have any questions on implementation, etc, feel free to contact me.  For more info on our entire line of MTConnect products, take a look at our web site.

So a customer asked me last week if I could provide them some managed code to allow them to insert a certificate and a private key into the certificate store on a Windows CE device.  A simple enough request, right?  Heh, isn’t that how they all start?

To be honest, I’ve done very little work with certificates in the past – basically I’ve created certs for use with Padarn and SSL but that’s about it. So my first order of business was to do some due diligence to try to get an idea of the scope of the problem.  I pulled up the MSDN docs of the Compact Framework’s support for X509 stuff.  It shows that there is device support for the X509Store as well as the X509Certificate so I told them it should be pretty easy to achieve their goal.  I mean the docs sure look like it would be easy.

Next I needed to write a little code to familiarize myself with the object model.  I fired up a device that most definitely has several certificates installed.

Then I wrote some simple code to give me an idea which of the six stores these fall into:

public void DumpCertCounts() 
{ 
    Debug.WriteLine("        Current User     Local Machine");

    var userStore = new X509Store(StoreName.Root, StoreLocation.CurrentUser); 
    var deviceStore = new X509Store(StoreName.Root, StoreLocation.LocalMachine); 
    Debug.WriteLine(string.Format("Root:          {0}              {1}", 
        userStore.Certificates.Count, 
        deviceStore.Certificates.Count)); 
    
    userStore = new X509Store(StoreName.My, StoreLocation.CurrentUser); 
    deviceStore = new X509Store(StoreName.My, StoreLocation.LocalMachine); 
    Debug.WriteLine(string.Format("My:            {0}              {1}", 
        userStore.Certificates.Count, 
        deviceStore.Certificates.Count));

    userStore = new X509Store(StoreName.CertificateAuthority, StoreLocation.CurrentUser); 
    deviceStore = new X509Store(StoreName.CertificateAuthority, StoreLocation.LocalMachine); 
    Debug.WriteLine(string.Format("CA:            {0}              {1}", 
        userStore.Certificates.Count, 
        deviceStore.Certificates.Count)); 
} 

Easy enough.  The problem was that then I actually ran the code.  This is the output.

Really?  Zero certificates in any store?  Was my code right?  Yes.  Did I target the right device from the debugger?  Yes.  Alrighty, so it seems that “existence of a class in the BCL” doesn’t necessarily mean “actual functionality is implemented.”  This doesn’t bode well.

Technically I don’t need to know what certificates are installed on the device for the customer’s request, right.  Sure, it would be nice to see if a cert is there before trying to install it, but we can always just wrap the call in a try/catch and ignore any exception thrown when we try to install a duplicate.  Not the ideal solution, but workable since this will be done infrequently.

I then generated some test certs with makecert.exe and pushed them to the device.  Now I needed to create code to import them, hopefully an import works better than enumerating existing certs. 

Let’s see, how would we bring in a cert?  How about the Import method on the X509CerticateCollection?  Oh, not supported in the CF.

Ah, but the Add method is, so I just need to create an X509Certificate and Add it.  Let’s see, the X509Certifiacte class has two static methods – CreateFromCertFile and CreateFromSignedFile.  Of course those aren’t supported in the CF.  That would be too easy.

How about from a constructor? Looks like the only constructor supported is the one that takes in a byte array.  What on earth is that byte array.  Oh, the example shows that it’s easy to get by Exporting from a certificate you already have.  How un-useful is that?

So it appears that the entire namespace in the Compact Framework is useless.  Actually worse than useless because I can’t create a direct replacement or I’ll end up with naming conflicts with the existing useless garbage.

So now I have to create the objects in the namespace and implement the methods required to achieve “import a certificate into the device store”.  The starting point is the C source code for the Certificates control panel applet you see above, which ships with Platform Builder.  It’s an ugly load of P/Invoking methods that deal with lots of pointers to structs that contains pointers to structs that contain pointers to structs that contain…you get the idea.

So I spent a day just getting the import of a CER file working (much easier than the PVK import is going to be) and my exact same test code now outputs this:

See, an implementation that actually does something.  I have no idea what was going on at Microsoft when this namespace was “implemented” or how it got out the door.  It definitely wouldn’t pass even the most rudimentary of functional tests.

This is a classic case of why I’d love to see the Compact Framework open/shared sourced.  I could actually go in and fix these things.

This post is part of my "Software Development" series. The TOC for the entire series can be found here.

Let’s start this post with a couple questions.  What is an ORM and why would you use one?  If you don’t know the answer to both of these questions, then this post is for you.  If you do know the answers, feel free to skip to the next post (after I’ve created it of course).

First, let’s look at what an ORM is. And ORM is an object-relational mapping.  According to Wikipedia, which we all know is the infallible and definitive resource for all knowledge, and ORM is “a programming technique for converting data between incompatible type systems in object-oriented programming languages.”  Ok, what the hell does that mean?  My definition is a little less “scholarly.”  I’d say that

An ORM is a way to abstract your data storage into simple class objects (POCOs if you’d like) so that you don’t have to worry about all the crap involved in actually writing data fields, rows, tables and the like.  As a developer, I want to deal with a “Person” class.  I don’t want to think about SQL statements.  I don’t want to have to worry about indexes or tables or even how my “Person” gets stored to or read from disk.  I just want to say “Save this Person instance” and have it done.  THAT is what an ORM is.  A framework that lets me concentrate on solving my business problem instead of spending days writing bullshit, mind-numbing, error-prone data access layer code.

Why would we use an ORM?  I think I’ve been fairly upfront that I consider myself to be a lazy developer.  No, I don’t mean that I take shortcuts or do shoddy work, I mean that I hate doing things more than once.  I hate having to write reams of code to solve problems that have already been solved.  I’ve been writing applications that consume data for years, and as a consequence, I’ve been writing data access code for years.  If you’re not using an ORM, you probably know down in your soul that this type of work flat-out sucks.  Anything that simplifies data access to me is a win.

Of course there are other, more tangible benefits as well.  If you’re using an ORM, it’s often possible to swap out data stores – so maybe you could write to SQL Server then swap a line of two in configuration and write to MySQL or an XML file.  It also allows you to mock things or create stubs to remove data access (really handy when someone tells you that your data access is what’s slowing things down when you’re pretty sure it’s not).

I can see that some of you still need convincing.  That’s good – you shouldn’t ever just take someone’s word for it that they know what they’re doing.  Ask for proof.  Well let’s look at a case of my own code, why I built the OpenNETCF ORM and how I was recently reminded why it’s a good thing.

A couple years ago I wrote an application for a time and attendance device (i.e. a time clock) that, not surprisingly, stored data about employees, punches, schedules, etc.  on the device.  It also has the option to store it on a server and synchronize the data from clock to server, but that’s not core to our discussion today.  The point is that we were storing a fair bit of data and this was a project I did right before I create the ORM framework.  It was, in fact, the project that made it clear to me that I needed to write an ORM.

Just about a month ago the customer wanted to extend the application, adding a couple features to the time clock that required updates to how the data was stored.  It took me very little time to realize that the existing DAL code was crap.  Crap that I architected and wrote.  Sure, it works.  They’ve shipped thousands of these devices and I’ve heard no complaints and had no bug reports, so functionally it’s fine and it does exactly what was required.  Nonetheless the code is crap and here’s why.

First, let’s look at a table class in the DAL, like an Employee (the fat that the DAL knows about tables is the first indication there’s a problem):

internal class EmployeeTable : Table 
{ 
    public override string Name { get { return "Employees"; } }

    public override ColumnInfo KeyField 
    { 
        get  
        { 
            return new ColumnInfo { Name = "EmployeeID", DataType = SqlDbType.Int }; 
        } 
    }

    internal protected override ColumnInfo[] GetColumnInfo() 
    { 
        return new ColumnInfo[] 
        { 
            KeyField, 
            new ColumnInfo { Name = "BadgeNumber", DataType = SqlDbType.NVarChar, Size = 50 }, 
            new ColumnInfo { Name = "BasePay", DataType = SqlDbType.Money }, 
            new ColumnInfo { Name = "DateOfHire", DataType = SqlDbType.DateTime }, 
            new ColumnInfo { Name = "FirstName", DataType = SqlDbType.NVarChar, Size = 50 }, 
            new ColumnInfo { Name = "LastName", DataType = SqlDbType.NVarChar, Size = 50 }, 
            // ... lots more column definitions ... 
        }; 
    }

    public override Index[] GetIndexDefinitions() 
    { 
        return new Index[] 
        { 
            new Index 
            { 
                Name = "IDX_EMPLOYEES_EMPLOYEEID_GUID",  
                SQL = "CREATE INDEX IDX_EMPLOYEES_EMPLOYEEID_GUID ON Employees (EmployeeID, GUID DESC)" 
            }, 
        }; 
    } 
}

So every table for an entity derives from Table, which looks like this (shorted a load for brevity in this post):

public abstract class Table : ITable 
{ 
    internal protected abstract ColumnInfo[] GetColumnInfo();

    public abstract string Name { get; } 
    public abstract ColumnInfo KeyField { get; }

    public virtual string GetCreateTableSql() 
    { 
        // default implementation - override for different versions 
        StringBuilder sb = new StringBuilder(); 
        sb.Append(string.Format("CREATE TABLE {0} (", Name));

        ColumnInfo[] infoset = GetColumnInfo(); 
        int i; 
        for (i = 0; i < (infoset.Length - 1); i++) 
        { 
            sb.Append(string.Format("{0},", infoset[i].ToColumnDeclaration())); 
        }

        sb.Append(string.Format("{0}", infoset[i].ToColumnDeclaration())); 
        sb.Append(")");

        return sb.ToString(); 
    }

    public virtual Index[] GetIndexDefinitions() 
    { 
        return null; 
    }

    public virtual IDbCommand GetInsertCommand() 
    { 
        SqlCeCommand cmd = new SqlCeCommand(); 

        // long, manual generation of the SQL and then creating the command

        return cmd; 
    }

    public IDbCommand GetUpdateCommand() 
    { 
        SqlCeCommand cmd = new SqlCeCommand(); 

        // long, manual generation of the SQL and then creating the command 

        return cmd; 
    }

    public IDbCommand GetDeleteCommand() 
    { 
        SqlCeCommand cmd = new SqlCeCommand(); 

        // long, manual generation of the SQL and then creating the command 

        return cmd; 
    }

Sure, I get a few bonus points for using inheritance so that each table doesn’t have to do all of this work, but it’s still a pain.  Adding a new Table required that I understand all of this goo, create the ColumnInfo right, know what the index stuff is, etc.  And what happens when I need to add a field to an existing table?  It’s not so clear.

Now how about consuming this from the app?  When the app needs to get an Employee  you have code like this:

public IEmployee[] GetAllEmployees(IDbConnection connection) 
{ 
    List
list = new List
(); using (SqlCeCommand command = new SqlCeCommand()) { command.CommandText = EMPLOYEES_SELECT_SQL2;
command.Connection = connection as SqlCeConnection; using (var rs = command.ExecuteResultSet(ResultSetOptions.Scrollable
| ResultSetOptions.Insensitive)) { GetEmployeeFieldOrdinals(rs, false); while (rs.Read())
{ IEmployee employee = EntityService.CreateEmployee(); employee.BadgeNumber = rs.IsDBNull(m_employeeFieldOrdinals["BadgeNumber"])
? null : rs.GetString(m_employeeFieldOrdinals["BadgeNumber"]); employee.BasePay =
rs.IsDBNull(m_employeeFieldOrdinals["EmployeeNumber"]) ? 0 : rs.GetDecimal(m_employeeFieldOrdinals["BasePay"]);
employee.DateOfHire = rs.IsDBNull(m_employeeFieldOrdinals["DateOfHire"]) ? DateTime.MinValue
: rs.GetDateTime(m_employeeFieldOrdinals["DateOfHire"]); employee.EmployeeID = rs.GetInt32(m_employeeFieldOrdinals["EmployeeID"]);
employee.FirstName = rs.GetString(m_employeeFieldOrdinals["FirstName"]); employee.LastName
= rs.GetString(m_employeeFieldOrdinals["LastName"]); string middleInitialStr = !rs.IsDBNull(m_employeeFieldOrdinals["MiddleInitial"])
? rs.GetString(m_employeeFieldOrdinals["MiddleInitial"]) : String.Empty; employee.MiddleInitial
= String.IsNullOrEmpty(middleInitialStr) ? '\0' : middleInitialStr[0]; // on and on
for another 100 lines of code) list.Add(employee); } } } return list.ToArray(); } 

Nevermind the fact that this could be improved a little with GetFields – the big issues here are that you have to hard-code the SQL to get the data, then you have to parse the results and fill out the Employee entity instance.  You do this for every table.  You change a table, you then have to go change the SQL and every method that touches the table.  The process is error prone, time consuming and just not fun.  It also makes me uneasy because the test surface area needs to be big.  How do I ensure that all places that access the table were fixed?  Unit tests help give me some comfort, but really it has to go through full integration testing of all features (since Employees are used by just about every feature on the clock).

Now what would the ORM do for me here?  Without going into too much detail on exactly how to use the ORM (we’ll look at that in another blog entry), let’s just look at what the ORM version of things would look like.

We’d not have any “Table” crap.  No SQL.  No building Commands and no parsing Resultsets.  We’d just define an Entity like this:

[Entity] 
internal class Employee 
{ 
    [Field(IsPrimaryKey = true)] 
    public int EmployeeID { get; set; }        
    [Field] 
    public DateTime DateOfHire { get; set; } 
    [Field] 
    public string FirstName { get; set; } 
    [Field] 
    public string LastName { get; set; }

    // etc. 
}

Note how much cleaner this is than the Table code I had previously.  Also note that this one class replaces *both* the Table class and the Business Object class.  So this is much shorter.

What about all of that create table, insert, update and delete SQL and index garbage I had to know about, write and maintain?  Well, it’s replaced with this:

m_store = new DataStore(databasePath);

if (!m_store.StoreExists) 
{ 
    m_store.CreateStore(); 
}

m_store.AddType<Employee>(); 

That’s it.  Adding another Entity simply requires adding just one more line of code – a call to AddType for the new Entity type.  In fact the ORM can auto-detect all Entity types in an assembly with a single call if you want.  So that’s another big win.  The base class garbage gets shifted into a framework that’s already tested.  Less code for me to write means more time to solve my real problems and less chance for me to add bugs.

What about the long, ugly, unmaintainable query though?  Well that’s where the ORM really, really pays off.  Getting all Employees becomes stupid simple.

var allEmployees = m_store.Select<Employee>();  

Yep, that’s it. There are overloads that let you do filtering.  There are other methods that allow you to do paging.  Creates, updates and deletes are similarly easy. 

Why did I create my own instead of using one that already exists?  Simple – there isn’t one for the Compact Framework.  I also find that, like many existing IoC frameworks, they try to be everything to everyone and end up overly complex.  Another benefit to the OpenNETCF ORM is that it is fully supported on both the Compact and Full Frameworks, so I can use it in desktop and device projects and not have to cloud my brain with knowing multiple frameworks.  I even have a partial port to Windows Phone (it just needs a little time to work around my use of TableDirect in the SQL Compact implementation). 

Oh, and it’s fast.  Really fast.  Since my initial target was a device with limited resources, I wrote the code for that environment.  The SQL Compact implementation avoids using the query parser whenever possible because experience has taught me that as soon as you write actual SQL, you’re going to pay an order of magnitude performance penalty (yes, it really is that bad).  It uses TableDirect whenever possible.  It caches type info so reflection use is kept to a bare minimum.  It caches common commands so if SQL was necessary, it at least can reuse query plans.

So that’s why I use an ORM. Doing data access in any other way has become insanity.

REST web services are pretty straightforward and really, really common (you used one to read this blog page).  As software gets implemented as services, it's getting more and more common for us as developers to have to make REST calls programmatically.  Lately I've been implementing a lot of services using Padarn on both the device and the PC and then implementing client libraries to access those services.  In doing so, it only made sense to create some infrastructure to make my life a little easier, and so the RestConnector (and DigestRestConnector) was born.

For a simple GET, such as to get the response for this page, the code is trivial:

var connector = new RestConnector("blog.opennetcf.com");
var response = connector.Get("/ctacke");

Other verbs like POST and PUT are nearly as simple.

var response = connector.Post("/upload", myData);

For services that require authentication, there's the DigestRestConnector that behaves the same, except the ctor takes in a UID/PWD pair as well. The classes support the four common verbs I use: GET, PUT, POST and DELETE. Of course since it's open-source, feel free to extend them as you wish.

The OpenNETCF Extensions library is a collection of extension methods and helper classes that I find useful in a lot of different projects. It's compatible with the Compact Framework, Tirethe full framework and Windows Phone.

Transferring data between processes in Windows CE is not difficult, and you can avoid using passing data through the message pump using WM_COPYDATA (which I've never considered a good idea, BTW).  Sockets and point to point queues are pretty straightforward and well documented for IPC. 

One mechanism that isn't well covered, and that works well for sharing larger blobs of data, is a memory-mapped file.  The SDF contains a MemoryMappedFile class (in the OpenNETCF.IO namespace) that allows you to use a shared memory region (in ram or on disk - your choice) and to access it just like you would any other stream with Write, Read and Seek.  Here's a simple example. Yes I realize my synchronization mechanism here isn't the cleanest, but it conveys the idea with the least code.

using System;
using System.Text;
using OpenNETCF.IO;
using OpenNETCF.Threading;
using System.Diagnostics;
using System.Reflection;
using System.IO;

namespace MMFPeer
{
    class Program
    {
        public const string SharedMapName = "MMF_PEER_NAME";
        public const long MaxMapSize = 1024;
        public const string SharedMutexName = "MMF_PEER_MUTEX";
        public const string DataReadyEventName = "MMF_PEER_DATA_READY";

        private MemoryMappedFile m_mmf;
        private NamedMutex m_mutex;
        private EventWaitHandle m_dataReady;

        private bool Sending { get; set; }

        static void Main(string[] args)
        {
            new Program().Run();
        }

        public void Run()
        {
            var processName = Path.GetFileNameWithoutExtension(Assembly.GetExecutingAssembly().GetName().CodeBase);

            // create the MMF
            m_mmf = MemoryMappedFile.CreateInMemoryMap(SharedMapName, MaxMapSize);

            // create a shared mutex
            m_mutex = new NamedMutex(false, SharedMutexName);

            // create a data-ready event
            m_dataReady = new EventWaitHandle(false, EventResetMode.ManualReset, DataReadyEventName);

            // fire up a "listener"
            new System.Threading.Thread(ReadProc)
            {
                IsBackground = true,
                Name = "MMF Peer Reader"
            }
            .Start();

            Console.WriteLine("Memory Mapped File Created.  Enter text to send to peer(s)");

            // wait for user input
            while (true)
            {
                var input = Console.ReadLine();

                if (input == null)
                {
                    Thread2.Sleep(5000);
                    input = GetMockInput();
                    Debug.WriteLine(string.Format("Platform does not have a Console installed. Sending mock data '{0}'", input));
                }

                if (input == "exit") break;

                // prefix our process name so we can tell who sent the data
                input = processName + ":" + input;

                // grab the mutex
                if (!m_mutex.WaitOne(5000, false))
                {
                    Console.WriteLine("Unable to acquire mutex.  Send Abandoned");
                    Debug.WriteLine("Unable to acquire mutex.  Send Abandoned");
                    continue;
                }

                // mark as "sending" so the listener will ignore what we send
                Sending = true;

                // create a "packet" (length + data)
                var packet = new byte[4 + input.Length];
                Buffer.BlockCopy(BitConverter.GetBytes(input.Length), 0, packet, 0, 4);
                Buffer.BlockCopy(Encoding.ASCII.GetBytes(input), 0, packet, 4, input.Length);

                // write the packet at the start
                m_mmf.Seek(0, System.IO.SeekOrigin.Begin);
                m_mmf.Write(packet, 0, packet.Length);

                // notify all clients that data is ready (manual reset events will release all waiting clients)
                m_dataReady.Set();

                // yield to allow the receiver to unblock and check the "Sending" flag
                Thread2.Sleep(1);

                // reset the event
                m_dataReady.Reset();

                // unmark "sending" 
                Sending = false;

                // release the mutex
                m_mutex.ReleaseMutex();
            }            
        }

        private int m_inputIndex = -1;
        private string[] m_inputs = new string[]
            {
                "Hello",
                "World"
            };

        private string GetMockInput()
        {
            if (++m_inputIndex >= m_inputs.Length) m_inputIndex = 0;
            return m_inputs[m_inputIndex];
        }

        private void ReadProc()
        {
            var lengthBuffer = new byte[4];
            var dataBuffer = new byte[m_mmf.Length - 4];

            while (true)
            {
                // use a timeout so if the app ends, this thread can exit
                if(!m_dataReady.WaitOne(1000, false)) continue;

                // avoid receiving our own data
                if (Sending)
                {
                    // wait long enough for the sender to reset the m_dataReady flag
                    Thread2.Sleep(5);
                    continue;
                }

                // grab the mutex to prevent concurrency issues
                m_mutex.WaitOne(1000, false);

                // read from the start
                m_mmf.Seek(0, System.IO.SeekOrigin.Begin);

                // get the length
                m_mmf.Read(lengthBuffer, 0, 4);
                var length = BitConverter.ToInt32(lengthBuffer, 0);

                // get the data
                m_mmf.Read(dataBuffer, 0, length);

                // release the mutex so any other clients can receive
                m_mutex.ReleaseMutex();

                // convert to a string
                var received = Encoding.ASCII.GetString(dataBuffer, 0, length);

                Console.WriteLine("Received: " + received);
                Debug.WriteLine("Received: " + received);
            }
        }
    }
}

There has been rampant speculation for some time that Windows CE was dead and that Microsoft was abandoning it.  The announcement that Windows 8 will run on ARM only added fuel to it, despite the fact that Win8 is undoubtedly going to have a large, desktop-style footprint and no capability for real-time operation.  Well, Microsoft finally decided to tell us what many of us suspected for some time.  Windows Embedded Compact (i.e. Windows CE) is still on their product roadmap.  It will have a v Next, and it will be supported in newer versions of Visual Studio (well native development will be anyway).  Read the full press release here.

With the upcoming MTConnect conference next week, we've been extremely busy getting things ready for our talks as well as our booth on the show floor.  I think we got feature complete (at least as far as we want for the show) today, so I'm merged all of the latest changes into the public trees for both the MTConnect Managed SDK as well as the OpenNETCF Virtual Agent.  I have an updated Machine Simulator that we'll be using for the show, but it's not quite ready for public consumption, so the release of that will have to wait until after we get back from Cincinnati.

Marshaling UI access to the proper thread is a very common task in app development, yet it still tends to be a pain in the ass.  You have to check if InvokeRequired is true (well you probably don’t *have* to, but not doing it feels dirty to me) and even using an anonymous delegate tends to be verbose.  And then there are also the simple bugs that are not always easy to spot.

So, like any good developer, I stole someone else’s idea and put it into the OpenNETCF Extensions.  Now, instead of doing this:

void MyMethod()
{
    if (this.InvokeRequired)
    {
        this.Invoke(new EventHandler(delegate
            {
                MyMethod();
            }));
        return;
    }

    // do stuff with the UI
}

You do this:

void MyMethod()
{
    Invoker.InvokeIfRequired(i =>
    {
        // do stuff with the UI
    });
}

Less code.  Less potential for error.  More readable.  What’s not to like?

The OpenNETCF Extensions library is a collection of extension methods and helper classes that I find useful in a lot of different projects. It's compatible with the Compact Framework, Tirethe full framework and Windows Phone.

This post is part of my "Software Development" series. The TOC for the entire series can be found here.

In this post, we’re going to look, at a higher level, at the reasons for and benefits of using a framework for Inversion of Control (IoC), Dependency Injection (DI) and Service Location. I’m not going to spend a large amount of time in this blog series describing the intimate details of what IoC, DI and Service Locators are.  Martin Fowler did a fantastic job of it and there’s no point in me just regurgitating his work.

Instead, I’ll give my vision of what they are and how they are relevant to how I architect and develop solutions.  It’s important to note that I’m starting out this series with high-level thoughts about architecture and design.  I’m not just laying down some code, leaving the decisions about how things will interact to some arbitrary, organic process.  This is how software development gets done. 

You’ve got to think about not just the next step, but visualize the end point several months, or even years out and try to connect the dots back to where you are today.  If I implement something in a certain way today, is it going to screw me 3 months down the road?  Spending an extra day now thinking about architecture is going to turn into saving weeks of the customer breathing down your neck and you pull out your hair and work late night trying to hammer a square peg into a round hole.

So let’s look at IoC, DI and Service Location and how they’re going to help us build better software.  Inversion of Control as a concept is something that’s really broad.  It’s really anything that turns the older procedural way of developing upside down (i.e. inverts program control, hence the name).  Moving from a console app to a windowed, event-driven app is technically inversion of control, so you’ve already been using IoC. 

To talk about IoC as a useful concept that’s actually going to be of use, we’ll be using some smaller units/principals of IoC.  The two we’re going to look at are Dependency Injection, or DI, and Service Location.  Neither one is complex or arcane, and you probably already use them to some degree.

Let’s assume we have two arbitrary classes, A and B, and that A uses an instance of B internally.  There are, essentially, 3 ways that A can get the instance of B. 

First, it can directly create it by calling new B().  While this is simple, it’s the least preferred, and generally worst, way to do it.  By directly creating B, A is now tightly coupled to B’s implementation.  B can’t be easily changed out to something else.  If B is in another assembly, A has to have a reference to it.  It’s also difficult to test A by itself. 

The second way that A can get B is that whoever created the instance of A could pass into it an instance of B.  Maybe through a constructor

var b = new B();
var a = new A(b);

or through a property

var b = new B(); 
var a = new A(); 
a.B = b;

This is called Dependency Injection. The former is constructor injection, the latter is property injection – not so complex, eh?  This is useful because, if B is an interface, it’s really easy to swap out the implementation passed to A and the assembly containing A doesn’t necessarily have to have a reference to the assembly holding the implementation of B – it only needs a reference to the interface.  This is really nice when we want to do mocking.

The third way that A can get B is to go get it from some central repository or “factory”.

B B { get; set; }

public A() 
{ 
   this.B = MyClassFactory.GetB(); 
}

This is service location.  A doesn’t really know what B is, it lets the service locator (MyClassFactory) resolve that.  This is really helpful for plug-in architectures as well as for lazy loading objects.

Generally speaking, your code should only be doing #2 (DI) and #3 (service location) for objects of any complexity.  This is not to say that you shouldn’t ever call the new operator in your code.  There’s obviously a grey line out there below which it would be pretty stupid to not just use new for.  If you need to use a simple entity class or structure, then creating one makes sense.  If you need access to the DAL and I see you creating a DAL object in your View, you’re fired.

There are plenty of framework out there that provide DI and service location -  Ninject, Unity, CastleWindsor, StructureMap, Autofac – the list goes on and on.  Instead of using one of them, however, I chose to roll my own.  Normally I wouldn’t recommend such a drastic action – after all reinventing the wheel isn’t usually wise – but in my case it was essentially required, so I’ll give you the short back story.

My team and I had been working on a large desktop application.  We had designed it from the start using Microsoft’s SCSF/CAB framework, which provide DI, service location and a load of other stuff.  It turned out that we were using maybe 10% of the framework, and that the framework’s Studio plug-ins were causing fits with some installations of Studio.  Spending time screwing with Studio plug-ins and trying to get things to compile is a terrible waste of manpower, so we were already getting close to jettisoning it when we decided that we wanted the core of our app logic to be Compact Framework compatible.

Well Microsoft’s “port” of the SCSF to the Compact Framework, called the MCSF, turns out to be a bloated, unbelievably slow, steaming pile of dog crap.  Side note: just because something compiles under the Compact Framework does not mean it should be used in the Compact Framework.  Well, I didn’t want to refactor everything we’d done to some other IoC framework, plus I couldn’t find one at the time that actually worked for the Compact Framework, so I decided to create one. 

I took the tack that I’d create it for the CF first, with a high emphasis on small footprint, minimal resource usage and speed and I simply matched the SCSF object model where our code base interfaced with it and where it made sense – in some places I didn’t like how the SCSF had done things, so I “fixed” their mistakes.  The end result was the OpenNETCF.IoC framework, which turns out to stack up quite well against the other frameworks.  It also has the huge benefit of working on the Full Framework, Windows Phone 7 and MonoTouch (probably MonoDroid as well, though I’ve not tested that). We’ll be looking at OpenNETCF.IoC in a lot more depth in this series.

Below is a handy table of contents for my “Software Development” series of blog posts

1. On Software Development (10/31/11) 
2. Inversion of Control, Dependency Injection and Service Locators oh my! (11/1/11)
3. An Intro to ORMs (11/21/11)

This post is part of my "Software Development" series.  The TOC for the entire series can be found here.

Developing good software is hard.  Really hard.  Sure, anyone can buy a book on writing software or pull up some code samples and get something that compiles and runs, but that’s not’s really developing software.  A lot of code in the wild – I’d bet a vast majority of it – just plain sucks.

It’s hard to point out where the blame lies.  It seems that most developers are environmentally or institutionally destined to write bad code. Schools teach how to write code, but not how to architect it or to follow reasonable design practices.  In the zeal for clarity, publishers churn out books, blogs and samples that show bad practices (when is it ever a good idea to access a data model from your UI event handler?).  Managers and customers alike push hard to get things done now, not necessarily done right – only to find months or years later that doing it right would have saved a boatload of time and money.  And let’s face it – many developers are simply showing up to work to pull a paycheck.  You know who they are.  You’ve no doubt worked with them in the past.  You’re probably working with them now.

I was watching Gordon Ramsay the other day and it occurred to me that he and I are alike in our own peculiar way.  I’m not saying that I see myself as the “Gordon Ramsay of Software Development” – hardly -   but we share a common trait.  Just as Gordon gets angry and starts spewing colorful language when he walks into a crap kitchen, it bothers the hell out of me to see complete idiots in my chosen field out there just making a mess of things.  When I see bad code – not necessarily minor errors, or code that could be refactored and made better – but just outright shit code that should not have occurred to a developer in the first place it pisses me off.  By the nature of my work, often getting called in only when the project is off the rails, I see it all the time. Code that, on review, a peer or mentor should have seen and said “Whoa!  There’s no way that’s going into our code base”.  Code that just makes it harder for the next person to do their job.

In an effort to simplify things for my own code, for my customers’ code as well as anyone who is willing to listen to my ravings, I’ve spent a lot of time building, testing, fixing and extending tools and frameworks that many of which I turn around and give away.  This isn’t out of altruism, no, it’s largely because I’m a lazy developer.  I hate writing the same thing twice.  When I start a project, I don’t want to spend large amounts of time building up the same infrastructure that every project needs. Building up a framework for handling UI navigation isn’t what I’d call interesting, but just about every project needs it.  Handling object dependencies and events is common.  Writing a DAL for serializing and deserializing entities is not just drudgery, I find it’s highly susceptible to errors because you end up doing a lot of copy and paste.

I have these cool tools and frameworks that I use in literally every project I work on now.  That’s great for me, but it doesn’t really help others, right?  Without reasonable documentation or explanation, only a small handful of people are going to go through the effort of getting the tools and trying to understand them – even if they are deceptively simple and could potentially save you weeks of effort. 

So I’ve decided to put together a series of blogs over the coming weeks and months that explain, hopefully in simple terms, what these frameworks do, how to use them, and most importantly, why they are worth using.  There’s nothing groundbreaking here.  I didn’t invent some new way to do things.  I’ve simply appropriated other peoples’ ideas and extended them to work in the environments that I work.

Generally I’ll be covering the following topics and frameworks:

• Dependency Injection and Inversion of Control (using OpenNETCF IoC)
• Event Aggregation (using OpenNETCF IoC)
• Plug-in Architectures and interface-based programming (using OpenNETCF IoC)
• Software features as services (using OpenNETCF IoC)
• Data Access through an ORM (using OpenNETCF ORM)
• Parameter Checking (using OpenNETCF Extensions)
• Exposing data services over HTTP (using Padarn)
• Whatever else I think of

If there’s a topic you’d like me to talk about, feel free to send me an email.  I may turn on comments here and let you post ideas, but I find that when I enable comments on my blog, I start getting more comment spam than I really want to deal with, so if comments are turned off just drop me a line.

One of the more common question groups I see about the Smart Device Framework really revolves around connecting to an access point.  Connecting to an Open AP is pretty straightforward, but as soon as you need to start adding encryption, privacy, passcodes and all that fun stuff, people tend to go off the rails.  And I can't blame them, the WirelessZeroConfigNetworkInterface class isn't the most intuitive interface.  What I've done in my own projects is to create a WiFiService class that wraps all of this (and a lot of other stuff too).  I'll try to get that full service to a publishable state in the not-too-distant future, but the core pieces for connectivity boil down to these few methods:

public bool ConnectToOpenNetwork(string ssid)
{
    if (!WiFiSupported) throw new NotSupportedException("No WZC WiFi Adapter detected on this device");

    return ConnectToNetwork(ssid, null, false, AuthenticationMode.Open, WEPStatus.WEPDisabled);
}

public bool ConnectToOpenNetwork(IAccessPoint accessPoint)
{
    if (!WiFiSupported) throw new NotSupportedException("No WZC WiFi Adapter detected on this device");

    return m_wzc.AddPreferredNetwork(accessPoint);
}

public bool ConnectToWEPNetwork(string ssid, string wepKey)
{
    if (!WiFiSupported) throw new NotSupportedException("No WZC WiFi Adapter detected on this device");

    return ConnectToNetwork(ssid, wepKey, false, AuthenticationMode.Open, WEPStatus.WEPEnabled);
}

public bool ConnectToWEPNetwork(IAccessPoint accessPoint, string wepKey)
{
    if (!WiFiSupported) throw new NotSupportedException("No WZC WiFi Adapter detected on this device");

    return ConnectToWEPNetwork(accessPoint.Name, wepKey);
}

/// 

/// This connects to a WPA network using TKIP encryption. /// 

/// 

/// 

/// 

public bool ConnectToWPANetwork(string ssid, string passphrase) { if (!WiFiSupported)
throw new NotSupportedException("No WZC WiFi Adapter detected on this device"); return
ConnectToNetwork(ssid, passphrase, false, AuthenticationMode.WPAPSK, WEPStatus.TKIPEnabled);
} /// 

/// This method will only connect to a WPA2 network using AES. /// If you need fallback
to WPA (using TKIP), use the overload that takes in an AccessPoint /// 

/// 

/// 

/// 

public bool ConnectToWPA2Network(string ssid, string passphrase) { if (!WiFiSupported)
throw new NotSupportedException("No WZC WiFi Adapter detected on this device"); return
ConnectToNetwork(ssid, passphrase, false, AuthenticationMode.WPA2PSK, WEPStatus.AESEnabled);
} /// 

/// Connects to a WPA or WPA2 (AES or TKIP) /// 

/// 

/// 

/// 

public bool ConnectToWPANetwork(IAccessPoint accessPoint, string passphrase) { if
(!WiFiSupported) throw new NotSupportedException("No WZC WiFi Adapter detected on
this device"); // quick validation var valid = accessPoint.AuthenticationMode == AuthenticationMode.WPA
|| accessPoint.AuthenticationMode == AuthenticationMode.WPAPSK || accessPoint.AuthenticationMode
== AuthenticationMode.WPA2 || accessPoint.AuthenticationMode == AuthenticationMode.WPA2PSK;
if (!valid) { throw new InvalidOperationException("The provided AP is not set up for
WPA"); } return ConnectToNetwork(accessPoint.Name, passphrase, false, accessPoint.AuthenticationMode,
accessPoint.Privacy); } private bool ConnectToNetwork(string ssid, string passphrase,
bool adhoc, AuthenticationMode mode, WEPStatus encryption) { EAPParameters eap = null;
switch (mode) { case AuthenticationMode.WPA: case AuthenticationMode.WPAPSK: case
AuthenticationMode.WPA2: case AuthenticationMode.WPA2PSK: eap = new EAPParameters()
{ Enable8021x = true, EapType = EAPType.Default, EapFlags = EAPFlags.Enabled, }; break;
} // stop scanning while connecting var wasScanning = Scanning; StopScanning(); try
{ lock (m_syncRoot) { return m_wzc.AddPreferredNetwork(ssid, !adhoc, passphrase, 1,
mode, encryption, eap); } } catch (ArgumentException ae) { return false; } finally
{ if (wasScanning) StartScanning(); } } 

I apologize that the above code won't just compile right out of the box - it's got some dependencies to other bits in the Service class, but my hope is that it at least gives the essence of what needs to be done to get the connectvitiy you need working.

A recent question on StackOverflow got me sidetracked into the context menus for Windows CE/Windows Mobile.  The question is pretty simple - when you create a ContextMenu, it automatically "selects" the first item, and the OP wanted to know how to undo that selection.  I spent a few hours screwing around with reflection and trying to get at the handle for the menu items so I could P/Invoke and unselect the item and only ended up failing (though I did post the meat of my work in my original answer).

After doing that work it occurred to me that we (OpenNETCF) used to have a PopupMenu commercial control that we long ago pulled from our catalog.  Well I looked on our old source control server and sure enough, it was there.  Since it was doing no one any good sitting in a bit bucket, I added it to our published open-source control set over on Codeplex.

I've again refreshed OpenNETCF's MTConnect Managed SDK with a few changes.  Most of the changes are the result of us dogfooding the SDK and making things more thread-safe and solid. 

In preparation for the upcoming MTConnect: Connecting Manufacturing Conference where we'll be both speaking and have a booth, I'm also creating some hands-on labs and tools.  One of the tools is a Sample Client application that consumes the Client side of the SDK.  The full source for the sample application is also available with the SDK download over on Codeplex.

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.

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.

I'm going through the Smart Device Framework's WZC code doing testing and hardening (yes, I realize it's long overdue) and I realize that it's not all that clear how to add a preferred network to a wireless adapter.  I've created the beginnings of a new Service class for the OpenNETCF IoC framework (though it's not required that you use IoC to use the service) that will help applications manage things.  I'll come back and update this code as I expand the service due to dogfooding it, but here's the start:

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Threading;

namespace OpenNETCF.Net.NetworkInformation
{
    public delegate void ScanCompleteDelegate(AccessPoint[] newNetworks, AccessPoint[] lostNetworks, AccessPoint[] stillAvailableNetworks);

    public class WiFiService
    {
        private List
m_knownAPs = new List
(); private object m_syncRoot = new object(); private AutoResetEvent m_stopScanEvent
= new AutoResetEvent(false); private WirelessZeroConfigNetworkInterface m_wzc; public
event ScanCompleteDelegate ScanComplete; public int ScanPeriod { get; set; } public
bool Scanning { get; private set; } public WiFiService(WirelessZeroConfigNetworkInterface
netInterface) { m_wzc = netInterface; // default to a 2 second network scan period
ScanPeriod = 2000; } ~WiFiService() { StopScanning(); m_knownAPs.Clear(); } public
void StartScanning() { if (Scanning) return; new Thread(ScanThreadProc) { IsBackground
= true } .Start(); } public void StopScanning() { if (!Scanning) return; m_stopScanEvent.Set();
m_knownAPs.Clear(); } public bool ConnectToOpenNetwork(string ssid) { return ConnectToNetwork(ssid,
null, false, AuthenticationMode.Open, WEPStatus.WEPDisabled); } public bool ConnectToOpenNetwork(AccessPoint
accessPoint) { return m_wzc.AddPreferredNetwork(accessPoint); } public bool ConnectToWEPNetwork(string
ssid, string wepKey) { return ConnectToNetwork(ssid, wepKey, false, AuthenticationMode.Open,
WEPStatus.WEPEnabled); } public bool ConnectToWEPNetwork(AccessPoint accessPoint,
string wepKey) { return ConnectToWEPNetwork(accessPoint.Name, wepKey); } /// 

/// This connects to a WPA network using TKIP encryption. /// 

/// 

/// 

/// 

public bool ConnectToWPANetwork(string ssid, string passphrase) { return ConnectToNetwork(ssid,
passphrase, false, AuthenticationMode.WPAPSK, WEPStatus.TKIPEnabled); } /// 

/// This method will only connect to a WPA2 network using AES. /// If you need fallback
to WPA (using TKIP), use the overload that takes in an AccessPoint /// 

/// 

/// 

/// 

public bool ConnectToWPA2Network(string ssid, string passphrase) { return ConnectToNetwork(ssid,
passphrase, false, AuthenticationMode.WPA2PSK, WEPStatus.AESEnabled); } /// 

/// Connects to a WPA or WPA2 (AES or TKIP) /// 

/// 

/// 

/// 

public bool ConnectToWPANetwork(AccessPoint accessPoint, string passphrase) { // quick
validation var valid = accessPoint.AuthenticationMode == AuthenticationMode.WPA ||
accessPoint.AuthenticationMode == AuthenticationMode.WPAPSK || accessPoint.AuthenticationMode
== AuthenticationMode.WPA2 || accessPoint.AuthenticationMode == AuthenticationMode.WPA2PSK;
if (!valid) { throw new InvalidOperationException("The provided AP is not set up for
WPA"); } return ConnectToNetwork(accessPoint.Name, passphrase, false, accessPoint.AuthenticationMode,
accessPoint.Privacy); } private void ScanThreadProc() { lock (m_syncRoot) { Scanning
= true; do { var et = Environment.TickCount; var current = m_wzc.NearbyAccessPoints;
var added = current.Except(m_knownAPs); var lost = m_knownAPs.Except(current); var
updated = m_knownAPs.Intersect(current); m_knownAPs = current.ToList(); var handler
= ScanComplete; et = Environment.TickCount - et; Debug.WriteLine(string.Format("Network
scan took {0}ms", et)); if (handler != null) { handler(added.ToArray(), lost.ToArray(),
updated.ToArray()); } } while (!m_stopScanEvent.WaitOne(ScanPeriod, false)); Scanning
= false; } } private bool ConnectToNetwork(string ssid, string passphrase, bool adhoc,
AuthenticationMode mode, WEPStatus encryption) { EAPParameters eap = null; switch
(mode) { case AuthenticationMode.WPA: case AuthenticationMode.WPAPSK: case AuthenticationMode.WPA2:
case AuthenticationMode.WPA2PSK: eap = new EAPParameters() { Enable8021x = true, EapType
= EAPType.Default, EapFlags = EAPFlags.Enabled, }; break; } // stop scanning while
connecting var wasScanning = Scanning; StopScanning(); try { lock (m_syncRoot) { return
m_wzc.AddPreferredNetwork(ssid, !adhoc, passphrase, 1, mode, encryption, eap); } }
finally { if (wasScanning) StartScanning(); } } } }

Today someone asked over on StackOverflow how to compile Bouncy Castle for Compact Framework 3.5.  Since SO has no way to add attachments, I'm parking the solution here.  Basically here are the steps:

1. Download the latest source (v 1.7 as of this writing)
2. Download my Visual Studio 2008 solution and project files
3. Put the csharp.cf.sln in the same location as the existing csharp.sln file
4. Put the crypto.cf.csproj in the same location as the existing crypto.csproj file
5. Open the csharp.cf.sln file and build

I'm still working on cleaning out our code archive and publishing things I feel might still be useful.  Today, I published the OpenNETCF Calendar controls, which provide some funtionality that has the look and feel of the Pocket Outlook UI.

Get the source over on Codeplex.

Recently I've seen some activity on Stack Overflow where some industrious people are attempting to get Studio 2010 to build non-Phone CF applications.  I assume this is for Continuous Integration/Build Server stuff, but it's a start toward a community workaround to the long-standing problem of Microsoft not giving us any help.  Part of the solution appears to be to copy over some of the targets files from an earlier version of Studio.  In an effort to aid in that, I've attached those files below.

msbuild.targets.cf3.5.rar (240.41 KB)
msbuild.targets.cf1_2.rar (255.88 KB)

Earlier today I published a tool for creating CE splash images. Well I already hit a limitation, so I've updated the tool.  It now supports all common image formats (PNG, JPG, GIF and BMP) instead of just BMP.  BIOSLoader also limits your image to 64k - anything larger might actually hand the device.  The tool now detects when the result will be larger than 64k and will offer to resize it before compressing as well.

The latest binary and source are up in Codeplex.

If you're booting an OS on a device that supports the BIOSLoader, an option is to display a "splash screen" image while the OS loads from disk.  The file is, by default, called 'splash.bmx', which is expected to be a compressed binary file, *not* an image.  The compressed binary file can be generated from a bitmap using bincompress.exe (which ships with Platform Builder).

While that seems all well and good, there are also some other limitations.  For example the source bitmap (pre compression) must be 256-color, and I believe there is likely a maximum file size as well (I'm sure the loader allocates a static block of RAM to hold the image).  Well my image editor of choice (Paint.NET) doesn't have a simple mechanism to save as a 256-color bitmap, not all of my PCs have Platform Builder (and thereforebincompress) installed, and I'm a fan of simplifying multistep processes in general.

So I created a very simply Windows app that you use to browse to an image, then click a button and it converts it to 256-color and generates the splash.bmx file for you.  It was just a couple hours of playing around, so it's not overly robust (it could probably use a command-line interface for automation, and a "preview" of the conversion would be nice) but it's functional for what I needed to get done this week.  Here's what it looks like:

I've published the work (source and binary) up on Codeplex.

Last night I was browsing around the Net on a back tracking a visit to the OpenNETCF Inversion Of Control (IoC) project.  I came upon a page where someone had done a quick set of benchmarks for many of the popular IoC engines out there [http://www.iocbattle.com/].  This got me wondering.  How would OpenNETCF IoC stack up against these, after all I've never done any performance comparisons against any other framework.

Well I downloaded the benchmarking code the original author had put together and added added an IoC version of the test (which was really easy to do).  I then ran the singleton test, which essentially registers a set of dependent classes by interface name (in theRootWorkItem.Services collection) and then uses the IoC engine to extract the from the store 1,000,000 times.  It then reports how long it took to do the extraction.  Simple enough.

Here are the results:

The hard numbers are not really important - the actual number is going to depend on your hardware - what is interesting is how they look relative to one anotehr.  You can see that if you exclude the new operator (which isn't IoC, it's just there for reference), then the Dynamo engine (which is the test author's engine) preforms the best.  Now I know nothing about that engine, so if you're interested, I'll let you investigate that further.

What was interesting to me is that IoC is three times faster than the next fastest IoC engine (AutoFac), five times faster than Structure Map, roughly 6 times faster than Castle Windsor or Unity and a whopping 25 times faster than the ever-popular Ninject engine.  Evidently my focus on performance when developign the engine paid off.

How about the time it takes to register all of the types that get created?  Are we paying the piper at creation time in order to save it at resolution?  Here are the time results for setup (instantiation of singletons):

Again, IoC is at near front of the pack.

Binary size isn't overly relevent any longer, I mean if you're using managed code then you've already made the decision that file sizes aren't critical, but it's still interesting to look at.  Here's a breakdown of the sizes of each of the libraries.  The libraries marked with an asterisk also have configuration files that are *not* included in the resported size (so deployment would actually be larger than what the graph shows).

All in all, I'm pretty pleased with the results.  We dogfood the OpenNETCF IoC framework for all of our projects, both desktop and Compact Framework, so it gets a fair amound of testing and beating and you can be assured that if there are bugs I'll do my best to resolve them.  If you've not taken a look at the project, give it a try.

I've published a refresh of the OpenNETCF MTConnect VirtualAgent code up on Codeplex.  This is a major refactor from the last publication which extracted the VirtualAgent engine capabilities into a separate IoC module.  This change greatly simplifies integrating VirtualAgent capabilities into an existing application as well as allowing an app to publish other Padarn REST services and ASP.NET pages without having to modify the VirtualAgent engine code base.

I've again refreshed OpenNETCF's MTConnect Managed SDK with a few changes, including:

• Added support for some current and sample filtering (not all filtering is supported, but I've added device name and data item ID filtering)
• Added AgentInformation to the EntityClient so you get information about the agent returning a data set for a probe
• Miscellaneous bug fixes and refactoring

As always, if you find a bug or would like me to work on implementing a specific feature from the specification, add it to the lists over on the Codeplex site.