Microsoft recently announced the release of a scaled-down version of the .NET runtime meant for mobile devices. This .NET Compact Framework opens up an entirely new world of devices for .NET developers, but is the environment at all like its big brother? Obviously, in shrinking a 23-MB runtime library into less than 1.5 MB for a mobile device, Microsoft had to discard something. So what did they leave, and do the changes preclude any compatibility between the two frameworks? Let’s answer the last question first and then take a look at the primary ways the Compact Framework differs from its full-scale sibling.

The question of portability
In creating the Compact Framework, said Microsoft’s Ed Kaim, the goal was twofold. Beyond the obvious goal of coming up with a .NET runtime that was smaller and less resource-hungry than the full version, Microsoft wanted to centralize development for all platforms in Visual Studio .NET.

“We wanted to make it possible for a typical Visual Studio .NET developer to do everything they needed from inside the IDE, [and] keep the development experience the same for all platforms,” Kaim said.

Missing from this mission statement is any kind of “write once, run anywhere” portability, and Microsoft has been sending mixed messages on the subject. The latest example of this sort of thing is the newest episode of MSDN’s “The .NET Show,” which manages to send contradictory messages about whether it would be reasonable to assume that code written for one framework would run on another. So what’s the real story?

Kaim responded to this confusion by pointing out that although “write once, run anywhere” wasn’t really a primary goal, it nevertheless is possible to achieve this level of portability, with due consideration and planning. Existing .NET applications will need to be recompiled for the Compact Framework, he said, but assuming that they don’t reference any assemblies that are absent from the mobile API, there’s no reason why the same code base can’t be used with both runtimes.

What didn’t make the cut?
So what parts of the standard framework were left out? All things considered, the list of omissions isn’t too terrifying. Most of the classes that were removed from the Compact edition were those that represented expensive processes in terms of memory consumption or processor usage. The chief differences you’ll find are:

  • No ASP.NET—Since most mobile device operating systems don’t have integrated Web servers, the lack of any ASP.NET capabilities shouldn’t come as a shock.
  • No Web services—Although Compact apps can consume Web services, they can’t provide them, largely due to the lack of a Web server, as with ASP.NET.
  • Scaled-down XML support—Compact apps will have full support for reading and writing XML using the reader and writer classes, but they won’t have support for XSLT or XPATH. These were simply too resource consumptive to include in the platform.
  • No typed datasets—This is really an issue only if you have a Web service that returns data as a typed dataset, and you want your Compact app to consume it.
  • Assembly loading changes—Compact apps will not be able to load an assembly into a domain-neutral space. This is an advanced technique that Microsoft felt most developers wouldn’t miss in a mobile environment.

In addition to these items, Microsoft said it also trimmed down the size of the Compact Framework’s class library by removing quite a few helper methods and classes that the designers felt were redundant.

What’s still in there?
That leaves quite a bit of functionality still to be found in the Compact Framework. So much so, I think any .NET developer would be just as comfortable building apps for either version of the framework. Here are a few of the highlights:

  • Full ADO.NET support—The Compact Framework includes a full-featured version of ADO.NET, with all the things you’d expect from its big brother: Bound data controls, full support for XML, and even a native SQL Server CE provider and support for upsizing and back-end transfers to an enterprise-class RDBMS.
  • Datagrids and Treeviews—The lack of a datagrid control seriously hampered developers using Microsoft’s previous entries into the mobile development arena. After receiving feedback from these folks and from beta testers, Microsoft added both controls to the standard set of GUI widgets such as text boxes, command buttons, and the like.
  • Full socket API support—If your Compact app needs some Web server-like functionality, you can create it yourself. The Compact Framework includes the full library of socket programming objects found in the full version.
  • Built-in support for IR ports—These ports are standard equipment on most PDAs, and the Compact Framework includes full support for sending and receiving data over them.

Should my app use the Compact Framework?
Like all development tools, the .NET Compact Framework has areas where it will be extremely useful—and others where it won’t. The chief drawbacks in my mind are the need to get the framework’s runtime on the device in the first place and the fact that, at present, not all devices that support Windows CE will support the Compact Framework. Devices without display screens are currently particularly problematic.

Putting those concerns aside, the Compact Framework brings a large portion of the power of the .NET platform to mobile devices, making it ideal for building the rapidly developed, high-level applications that users need to perform business tasks. Developers of lower-level applications, like system utilities, will likely be best served by sticking to more traditional development kits, such as embedded Visual C++.