Welcome!

.NET Authors: Liz McMillan, Pat Romanski, Patrick Burke, Elizabeth White

Related Topics: .NET

.NET: Article

Questions and Answers on the .NET Compact Framework

Questions and Answers on the .NET Compact Framework
By Jon Box
Article Rating:
April 28, 2003 12:00 AM EDT
Reads:
 22,993

As many developers are already aware, the impending release of Visual Studio .NET 2003 will serve to bring the benefits of XML Web Services and the Microsoft Windows .NET Framework to smart devices via the inclusion of the .NET Compact Framework and Smart Device Projects. However, for those not already initiated, the following excerpts from Building Solutions with the .NET Compact Framework will explore the five basic questions that every developer asks when first thinking about the Compact Framework.

What Are the Goals of the Compact Framework?
Simply put, the goals of the Compact Framework (and Smart Device Projects) are fourfold:

  • To provide a portable (and small) subset of the Windows .NET Framework targeting multiple platforms. This includes the creation of a runtime engine, class libraries, and compilers for VB and C# that together are referred to as the .NET Compact Framework. This framework is not a simple port of the desktop version, but a complete rewrite designed to execute managed code on multiple CPU architectures and operating systems through an abstraction layer known as the Platform Adaption Layer (PAL). It is important to note that the Compact Framework was also designed to be a subset of the desktop version of the Framework. As a result, roughly 25% of the desktop types are represented in the Compact Framework.
  • Leverage VS .NET. Since VS .NET already provides a high productivity development environment, it is only natural that this environment should be utilized in developing mobile applications as well. To that end, the Smart Device Projects for VS .NET 2003 provide the project templates, emulator, debugger, and device integration to use the same IDE for desktop as for mobile development.
  • True Emulation. One of the requirements for developing robust (i.e., well-debugged) mobile applications is that they run as expected when installed on the device. To that end VS.NET includes emulators for Pocket PC and Windows CE that run exactly the same execution engine and class libraries as those installed on the device. In addition, the emulator supports localized packages for developing global applications. In this way, developers can be assured that the code they write and test with the emulator will execute correctly when deployed to the device.
  • Enable Web Services on Devices. Since XML Web Services are by definition device independent, they can be used from a variety of devices. By building support for consuming web services directly into the Compact Framework, developers can easily call web services.

    On Which Platforms Does It Run?
    Since 1992 Microsoft has produced a series of platforms (9 if our count is correct) built on the Windows CE operating system. A platform includes a specific set of hardware coupled with a version of Windows CE and associated software that makes it easier for developers and device manufacturers to target their solutions. The Compact Framework supports the Pocket PC 2000, 2002, and embedded Windows CE .NET 4.1 platforms. Although not officially supported, Compact Framework code also runs on Pocket PC Phone Edition devices that are a superset of Pocket PC 2002. Also not supported are smartphones such as the SPV from Orange.

    Because the Compact Framework is a managed environment, each device that executes applications written using the Compact Framework must have the framework installed. As of this writing, there were no devices shipping that included the Compact Framework as a standard component in RAM or in ROM. However, look for future devices running Windows CE .NET to include the runtime.

    What About ASP.NET Mobile Controls (aka the Mobile Internet Toolkit)?
    Many developers new to developing for mobility are at first confused by the differences between the Compact Framework and ASP.NET Mobile Controls. In a nutshell here are the primary differences.

  • The ASP.NET Mobile Controls are a server side technology whereas the Compact Framework is a client side technology. This means that code written using mobile controls must execute on a server, and not directly on the device, by producing markup language that is interpreted by the device using a browser or parser. Code written for the Compact Framework executes directly on the device using just-in-time (JIT) compilation and native execution.
  • The ASP.NET Mobile Controls are based on ASP.NET and use the ASP.NET HTTP runtime to handle and process requests via a set of ASP.NET server controls specially designed for small form factor devices. This means that mobile controls require an ASP.NET web server (IIS 5.0 or 6.0). The device issues requests that are processed on the web server by the controls producing markup language.
  • Both ASP.NET Mobile Controls and the Compact Framework are based on the desktop Framework and VS .NET. In the case of mobile controls, developers use VS .NET to write ASP.NET code using the ASP.NET server controls. The server side code is JIT compiled and executed on the web server by the common language runtime. In the case of the Compact Framework the code is written using SDP and subsequently downloaded to the device for JITting and execution using a compact version of the common language runtime.
  • The ASP.NET Mobile Controls are more flexible in that they can dynamically produce various markup languages depending on the requesting device they dynamically detect, including WML, cHTML, HTML, and XHTML (in Visual Studio .NET 2003 and the Framework v1.1). This means that mobile controls can support a broader range of devices (over 200 at last count) including wireless web phones, Pocket PCs, and virtually any device that supports HTTP and HTML. The ASP.NET Mobile Controls also include the ability to add device specific customizations so that as new devices come online their feature set can be identified.
  • Since code written for the Compact Framework is downloaded to the device, the Compact Framework supports connected, occasionally connected, and disconnected scenarios and supports local data storage using XML or SQL Server 2000 Windows CE Edition. ASP.NET Mobile Controls only support the former since an HTTP connection is required to request an ASP.NET page that uses the mobile controls. Basically, this means that mobile controls are targeted for building web sites for a broad variety of connected devices and at the same time not having to rewrite the vast majority of code to deal with differences between those devices.

    As a result you can (and in our estimation should) consider architecting and building your applications using the Compact Framework and SDP when the following are true.

  • You are developing code that will execute on the device, as opposed to applications developed with the ASP.NET Mobile Controls
  • Your applications must run in disconnected, connected, or occasionally connected modes
  • You are targeting the Pocket PC 2000, 2002 or embedded Windows CE .NET platforms

    What's Missing in the Compact Framework?
    In order to accommodate the restricted resources on smart devices the Compact Framework was designed as a subset of the desktop libraries and in fact includes just over 1,700 types, or roughly 25% of the desktop framework. As a result, developers familiar with the desktop Framework should not expect all the functionality they are accustomed to. The most important omissions are listed here:

  • ASP.NET. Because the Compact Framework is designed to support applications that execute on the device, it does not include any support for building web pages hosted on a web server running on the device.
  • COM Interop. Since the Windows CE operating system and the embedded Visual C++ (eVC) tool support creating COM components and ActiveX controls, it would be nice if the Compact Framework supported the same COM Interop functionality (complete with COM callable wrappers and interop assemblies) as does the desktop Framework. Unfortunately, COM Interop did not make it into the initial release of the Compact Framework. However, it is possible to create a DLL wrapper for a COM component using eVC++ and then call the wrapper using the Platform Invoke (PInvoke) feature of the Compact Framework, which allows native APIs to be called.
  • OleDb Access. The Compact Framework omits the System.Data.OleDb namespace and so does not support the ability to make calls directly to a database using the OleDb .NET Data Provider.
  • Generic Serialization. The desktop Framework supports binary serialization of any object through the use of the Serializable attribute, the ISerializable interface, and the XmlSerializer class in the System.Xml.Serialization namespace. This functionality is not supported in the Compact Framework. However, the Compact Framework does support serializing objects to XML for use in XML Web Services and serializing DataSet objects to XML.
  • Asynchronous Delegates. Delegates in both the desktop Framework and Compact Framework can be thought of as object-oriented function pointers. They are used to encapsulate the signature and address of a method to invoke at runtime. While delegates can be called synchronously, they cannot be invoked asynchronously and passed a callback method in the Compact Framework. However, it should be noted that asynchronous operations are supported for some of the networking functionality found in the System.Net namespace and when calling XML Web Services. In other cases, direct manipulation of threads or the use of a thread pool is required.
  • .NET Remoting. In the desktop Framework, it is possible to create applications that communicate with each other across application domains using classes in the System.Runtime.Remoting namespace. This technique allows for data and objects serialized to SOAP or a binary format to be transmitted using TCP or HTTP. This functionality is not supported (in part because Generic Serialization is not supported) in the Compact Framework where instead XML Web Services and IrDA can be used.
  • Reflection Emit. Although the Compact Framework does support runtime type inspection using the System.Reflection namespace, it does not support the ability to emit dynamically created MSIL into an assembly for execution.
  • Printing. Although the Compact Framework does support graphics and drawing, it does not support printing through the System.Drawing.Printing namespace.
  • XPath/XSLT. Support for XML is included in the Compact Framework and allows developers to read and write XML documents using the XmlDocument, XmlReader, and XmlWriter classes. However, it does not support executing XPath queries or performing XSL transformations.
  • Server-side Programming Models. As you would expect, the Compact Framework also does not support the server-side programming models including System.EnterpriseServices (COM+), System.Management (WMI), and System.Messaging (MSMQ).
  • Multi-module Assemblies. The desktop Framework supports the ability to deploy an assembly as a collection of files. This is useful for creating assemblies authored with multiple languages. This feature is not supported in the Compact Framework where a single file (.exe or .dll) represents the entire assembly.

    However, the Compact Framework does support two additional namespaces to support features particular to smart devices (see Table 1).

    In addition, support for the IrDA protocol has been included in the Compact Framework and exposed in the six classes found in the System.Net.Sockets and the System.Net namespaces.

    What Do Developers Need to Learn to Use the Compact Framework Effectively?
    Although VB 6.0 and embedded VB (eVB) developers will feel fairly comfortable with the VB syntax used in SDP, the object-oriented nature of the Compact Framework means that developers need to have a firm grounding in OO concepts in order to maximize their productivity.

    For example, the class libraries in the Compact Framework make extensive use of both implementation and interface inheritance. Developers familiar with these concepts can not only more easily understand the framework, but can write polymorphic code using the framework that is more maintainable and flexible than the component based development typically done in eVB. In the long run, using OO in their own designs allows developers to write less code and make the code that they do write more reusable. Therefore, to take maximum advantage of OO, however, a development organization should also get up to speed on the use of design patterns.

    Of course, because of its close association with the .NET Framework, existing Framework developers will also have a leg up.

    SIDEBAR

    Title:
    Building Solutions with the .NET Compact Framework

    Authors:
    Jon Box and Dan Fox

    Publisher:
    Addison-Wesley

    ISBN:
    0321197887

    Availability: June 2003

    • Published April 28, 2003 – Reads 22,993
    Copyright © 2003 SYS-CON Media, Inc. — All Rights Reserved.
    Syndicated stories and blog feeds, all rights reserved by the author.

    More Stories By Jon Box

    Jon Box is an Architect Evangelist in Developer & Platform Evangelism with the Microsoft Corporation. He coauthored Building Solutions with the Microsoft .NET Compact Framework, published by Addison-Wesley, and blogs at http://blogs.msdn.com/jonbox/default.aspx.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.