By Greg DeMichillie [bio]
Posted: Jan. 20, 2003

• Illustration: SQL CE and Data Access
• Illustration: Device Development in Visual Studio .NET
• Illustration: Debugging Device Applications

The following is the full text of an article published by Directions on Microsoft, an independent research firm focused exclusively on Microsoft strategy & technology. Each month we make one or more key articles available to non-subscribers.

The .NET Compact Framework (CF), a version of the .NET Framework tuned for compact devices, is now available for developers, although the accompanying developer tools are still in beta. IT planners and ISVs planning custom applications for compact devices now have a consistent set of tools and APIs that span Microsoft’s desktop, server, and compact device platforms. Compact devices, however, have significant differences in storage capacity and capabilities and the CF does not aim to be a "write once, run anywhere" solution. Moreover, because of differences between the Pocket PC and Smartphone platforms the initial release of the CF is not compatible with Smartphone.

Making Devices Easier for Developers

The .NET CF is Microsoft's latest attempt to attract corporate developers to Windows for mobile devices. Devices like the Pocket PC (PPC) are attractive for corporate applications that serve mobile workers who must be able to continue working even while disconnected from the network (such as field sales personnel or delivery drivers). However, most companies do not want to maintain a special cadre of mobile developers to build and maintain such applications.

To address these needs, Microsoft's initial device platform, Windows CE, has APIs designed to resemble, as closely as possible, the Win32 APIs that are included in Microsoft’s desktop and server operating systems (OSs), thereby allowing developers to apply their desktop application skills to building applications for compact devices. In addition, the company adapted its popular Visual Basic (VB) and Visual C++ (VC++) developer tools, producing "embedded Visual Basic" (eVB) and "embedded Visual C++" (eVC++).

However, Microsoft's move from the Win32 APIs on the desktop and server to the .NET Framework has left Windows CE out of sync with the rest of the platform. (For more information on how the .NET Framework is transforming Microsoft’s development platform, see the Dec. 2002 Research Report, "Windows .NET Server: Microsoft’s Application Server") Moreover, the "embedded" versions of its developer tools for Windows CE have been maintained by a separate team and usually lagged at least one version behind their desktop counterparts.

The .NET CF and its associated development tools address these issues, bringing Microsoft's device platform back in sync with its desktop and server development platform and enabling the company to position the two platforms as sharing a common set of development tools and APIs.

Tuning .NET for Smart Devices

In building the .NET CF, Microsoft set out to dramatically reduce the size of the .NET Framework while at the same time maintaining as many of the APIs as possible so that developers would be able to transfer their knowledge. It is worth noting that Microsoft did not set out to build a "write once, run anywhere" solution. In fact, given the huge disparity in capabilities between conventional PCs and compact devices (screen size, processor speed, available memory), such an approach is not even feasible. Instead, the company set out to minimize the learning curve that developers face when building applications for compact devices.

The .NET Framework contains everything needed in order to run .NET applications on a desktop PC or server, but it requires approximately 20MB of disk space. This is too large to be used "as-is" on most compact devices, which may have as little as 32MB of storage available. To make the CF suitable for compact devices, Microsoft removed some APIs, streamlined the remaining APIs to reduce redundancy, and eliminated unnecessary text messages.

Removing APIs

Some APIs that are present in the .NET Framework are missing from the CF. In some cases this is because the APIs are dependent on features of the underlying Windows OS that are not available in Windows CE, such as transparent windows and gradients (the ability to blend smoothly from one color to another).

In other cases, APIs were removed simply because they were deemed less important for compact devices. Printing, for instance, is supported by Windows CE and the PPC platform, but the CF does not include any APIs that support printing. The following APIs, among others, were also removed:

• COM interoperability—while the CF does allow applications to access the underlying OS, they only have access to those functions that are packaged as Win32 APIs, not those packaged as COM objects
• Full XML support—the CF does support invoking Web services, but it does not support advanced XML features, such as XML validation or XML transforms
• Some graphical user interface (GUI) controls (such as ToolTips or a checked list box) that are available in Windows are not present in Windows CE, and thus those APIs are absent from the CF.

Streamlining APIs

In addition to removing entire APIs, the CF streamlines some APIs by removing some redundancies in the .NET Framework. Many of these redundancies provide multiple APIs that perform essentially the same function, but which are customized to make life easier for developers. For example, the .NET Framework includes several APIs for drawing a rectangle, but each takes different parameters: one version requires the developer to specify the top left and bottom right points of the rectangle, while another allows the developer to specify only one of the points along with the width and height. These API variations simplify the programmer’s task by reducing the amount of code that must be written and allowing the developer to choose the variation that is most suitable to the specific task at hand.

The CF eliminates many of these variations and instead provides only two versions: the "most useful" (the one likely to be used in common practice) and the "most generic" (the one that provides the greatest number of options). Although this simplification can make it slightly more difficult for a developer who is accustomed to using one of the other variants, it reduces the size of the CF while ensuring that the developer can still obtain the same functionality (albeit by writing slightly more complex code).

Paring Error Messages

The .NET Framework is composed not only of code to perform many of the functions that applications require but it also includes data. Thus, any attempt to reduce the size of the .NET Framework must also consider data as well.

The .NET Framework’s built-in error messages provide the biggest opportunity for data savings. When error conditions arise (such as an API being used incorrectly or when an application attempts to open a file that doesn’t exist), the .NET Framework informs the application, and if the application fails to handle the error, the .NET Framework displays an error message to the user. This error includes a numeric code as well as some text describing the general nature of the error. But most developers prefer not to rely upon these generic error messages. They instead write code for the applications to process the errors themselves and, if necessary, display a more customized error message to the user.

By eliminating these error messages and leaving only the numeric codes, the CF reduces the amount of data included. However, since the full error messages are often useful to developers while the application is being developed (because they help identify which error conditions the application is not handling itself), the CF is available in a special "debug" version that includes the error messages, allowing developers to more easily identify and fix errors in their application.

Enabling Device-Specific Features

Despite the need to reduce the overall size of the CF, it is also important to Microsoft that the CF allows developers to use some of the unique features offered by each device. Examples of new APIs offered by the CF include the following:

Infrared send/receive. Although many laptop computers offer infrared (IR) ports for sending and receiving data, such ports tend to be used more frequently on portable devices, often to exchange personal contact information. The CF includes new APIs that allow applications to send and receive information over the IR port, a feature that is not included in the desktop version of the .NET Framework.

SQL CE provider. The desktop Framework includes a number of data providers (components that enable the Framework to retrieve and update information from a database management system). The CF reduces this to two: a provider for connecting to Microsoft’s SQL Server (which is also present in the .NET Framework) and a new provider to SQL Server CE Edition, a version of the database that runs locally on the device. (For more information on SQL CE and building data-aware applications for the CF, see the illustration "SQL CE and Data Access".)

Application developers who want to use device features not directly supported by the CF (such as the phone dialer included in the Phone Edition of the PPC reference platform) must use the ability of the CF to interact with the underlying OS. Whereas the .NET Framework supports two methods by which managed code can interact with the native code of the OS—COM Interoperability for interacting with native code that is packaged as COM objects, and Platform Invoke (or P-Invoke) for native code that is packaged as a Win32 DLL—the CF supports only P-Invoke.

In addition, Microsoft is encouraging OEMs that produce add-on hardware that might be of interest to corporations (such as Symbol, which makes a line of barcode scanners for the PPC) to provide add-on class libraries to make that functionality directly available to CF developers.

Leveraging Visual Studio .NET

Making the "smart device" application development experience seem familiar to corporate developers of Windows applications requires more than just preserving as many APIs as possible. It also requires that developers be able to use the programming languages and tools they are familiar with, and for most Windows developers that means Visual Studio. (For more information on Visual Studio .NET and its future releases, see "Visual Studio Roadmap" on page 20 of the Oct. 2002 Update.)

Previous versions of Microsoft’s Windows CE tools (eVB and eVC++) were not produced by the same team as Visual Studio. Instead, a separate team within Microsoft took source code from desktop versions of the appropriate products and modified it, adding and removing features to suit the needs of Windows CE embedded-device developers. This adaptation took time and meant that the Windows CE tools, such as eVB and eVC++, were frequently out of sync with their desktop counterparts.

Because, unlike previous versions, Visual Studio .NET includes a comprehensive extensibility architecture, the CF team was able to plug in to Visual Studio .NET to extend and modify its features, rather than taking a "snapshot" of the source code and using that to build a separate product.

For example, to build the user interface for a CF application, a developer uses the same GUI designer that is used to create desktop applications. That designer has now been extended to detect differences between the complete .NET Framework and the CF, and to output the appropriate code. (For a visual example of this, see the illustration "Device Development in Visual Studio .NET".)

Once an application is written, developers rely on debugging tools to locate and fix errors. All the familiar debugging features of Visual Studio .NET (such as the ability to hover the mouse over a variable and see its value displayed in a ToolTip) can be used to debug CF applications. In addition, CF applications can be debugged either directly on the device (when it is connected in its cradle) or via an included emulator, which allows developers to test and debug applications without a physical device present. (For an illustration of debugging an application via the emulator, see "Debugging Device Applications".)

Not Yet in Devices

The CF is available for Windows CE .NET, the Pocket PC 2000, and the Pocket PC 2002 reference platforms, and it requires about 1.5MB of storage on the compact device. Because of differences in the underlying platforms, the initial release of the CF is not compatible with Microsoft’s Smartphone reference platform (although it does work with the larger form-factor PPC Phone Edition). The company has indicated that producing a version of the CF that works with the Smartphone is a high priority. (For more information on Microsoft’s Smartphone plans, see "Wireless WAN Strategy Takes Shape" on page 14 of the Nov. 2002 Update.)

The CF supports Windows CE’s "execute in place" architecture, which means that multiple applications can be using the CF at the same time without having to load multiple copies of the CF (which would increase the amount of memory required). However, no device manufacturers currently ship the CF in ROM, the best way to take advantage of this feature.

Microsoft has not announced any details on when the CF will be included in compact devices. Until manufacturers, such as Dell and Hewlett-Packard, include the CF in devices, customers themselves will need to deploy the CF to their devices (although Visual Studio .NET includes tools to make this process relatively painless).

Resources

More information on the .NET Compact Framework can be found at msdn.microsoft.com/vstudio/device/compactfx.asp.

A recent episode of "The .NET Show," a Microsoft Webcast program for developers, which includes demonstrations of the Compact Framework and discussions with the product team, can be found at msdn.microsoft.com/theshow/Episode029/default.asp.

The home page for the .NET Framework is at msdn.microsoft.com/netframework.