Export (0) Print
Expand All

Fundamentals of Microsoft .NET Compact Framework Development for the Microsoft .NET Framework Developer

.NET Compact Framework 1.0
 

Denise Barnes
Microsoft Services for Embedded Partners - Consultant

December 2003

Applies to
   Microsoft® .NET Framework
   Microsoft .NET Compact Framework

Summary: This article is intended as a basic overview of the Compact Framework. This information was used as an introduction for developing applications using the .NET Compact Framework. (19 printed pages)

Contents

Introduction
Benefits and Goals
Data Types
Windows Forms
Networking
Threading
Native Code InterOp
Globalization
XML
SQL CE
XML Web Services Support
Differences from the .NET Desktop Framework
Application Development Using Visual Studio.NET
Conclusion
Related Links

Introduction

The Microsoft® .NET Framework 1.1 is an integral Microsoft Windows® component for building and running the next generation of software applications and Extensible Markup Language (XML) Web services—components that facilitate integration by sharing data and functionality over a network through standard, platform-independent protocols such as XML, SOAP, and HTTP. The .NET Framework consists of two main parts: the common language runtime (CLR) and a unified set of class libraries, including ASP.NET for Web applications and Web services, Windows Forms for smart client applications, and ADO.NET for loosely coupled data access.

The Microsoft .NET Compact Framework is the smart device development framework for Microsoft .NET, bringing the world of managed code and XML Web services to devices. The .NET Compact Framework is a rich subset of the .NET Framework, thus providing the same benefits as the .NET Framework. But the .NET Compact Framework is designed specifically for resource-constrained devices, such as PDAs and smart mobile phones. The .NET Compact Framework greatly simplifies the process of creating and deploying applications to mobile devices while also allowing the developer to take full advantage of the capabilities of the device.

.NET Framework

Code written on the .NET Framework platform is called managed code. The term "managed code" refers to the fact that the Common Language Runtime (CLR) provides several assurances for such code:

  • Managed code cannot have bad pointers.
  • Managed code cannot create memory leaks.
  • Managed code supports strong type-safety.

A key benefit of managed code is that the managed development environment handles certain common errors that plague Win32® programmers.

Managed code is compiled down to a combination of MSIL (Microsoft Intermediate Language) and metadata. These are merged into a Pre Execution Environment (PE) file, which can then be executed on any CLR-capable machine. When you run this executable, the JIT starts compiling the IL down to native code. The result is that all .NET Framework components run as native code. Code that requires the CLR at run-time in order to execute is referred to as managed code. The CLR is responsible for managing execution of code that runs on the .NET Framework. There are two DLLs responsible for this: mscoree.dll (native code that loads managed code) and mscorlib.dll (managed code: base class library, the runtime library).

.NET Compact Framework

The .NET Compact Framework is a subset of the .NET Framework. It consists of the base class libraries and has a few additional libraries that are specific to mobility and device development. The .NET Compact Framework runs on a high performance JIT Compiler. The Common Language Runtime (CLR) is built from the ground up to be specific to the .NET Compact Framework so that it runs more efficiently on small targeted devices that are limited in memory, resources, and must conserve battery power. To be able to run .NET Compact Framework applications, the targeted platforms must support the .NET Compact Framework runtime. .NET Compact Framework requires a minimum of Windows CE.NET (Windows CE version 4.1 for the released version of the .NET Compact Framework) with two exceptions: Microsoft Pocket PC, Microsoft Pocket PC 2002, and Microsoft Pocket PC 2002 Phone Edition support the .NET Compact Framework. Smartphone 2002 does not support the .NET Compact Framework; however, Smartphone 2003 does.

Figure 1. .NET Compact Framework Class Architecture

Benefits and Goals

.NET Framework

  • Shared code and increased efficiency
  • Robust code
  • Secure execution
  • Support for encryption
  • Automatic deployment
  • Rapid application development that requires fast time-to-market
  • Ability to call Win32 DLLs without having to rewrite them
  • Debugging and development can be used by Microsoft Visual Studio® .NET 2003
  • Code is not prone to fail due to uninitialized variables
  • JIT compilation is not interpreted
  • Garbage collection greatly minimizes memory leaks by cleaning up objects no longer in use

.NET Compact Framework

  • Shared code and increased efficiency
  • Robust code
  • Secure execution
  • Automatic deployment
  • Rapid application development that requires fast time-to-market
  • Single binary deployment that runs on various CPUs on the same platform without recompilation
  • Because recompilation is not necessary across .NET Compact Framework, controls, applications, and services can be easily moved from one device to another
  • Ability to call Win32 DLLs without having to rewrite them
  • Portable subset of .NET Framework
  • Debugging and development can be done by Visual Studio.NET
  • Code is not prone to fail due to uninitialized variables
  • JIT compilation is not interpreted. JIT Compilation ultimately runs the code as processor native code
  • Garbage collection greatly minimizes memory leaks by cleaning up objects no longer in use
  • Uses the same naming conventions as in the .NET Framework
  • Simple Object Access Protocol (SOAP)

Data Types

Namespaces and Class Library

Figure 2. Namespaces supported in .NET Framework and .NET Compact Framework

The .NET Framework consists of a set of class library assemblies that contain hundreds of types. These class library assemblies provide access to system functionality. The purpose of these class libraries is to provide a hierarchical namespace structure. These classes are language independent so that cross-language inheritance and debugging can be accomplished. These class libraries integrate completely into the Visual Studio .NET for simplified application development. The .NET Framework and .NET Compact Framework use the same naming conventions for namespaces.

.NET Framework

System is the root namespace for the set of functionality that is part of this CLR platform. System namespace contains the base Object of which all others are derived from. This namespace also includes types for exception handling, garbage collection, console I/O, tool types, format data types, random number generators, and mathematical functions.

The names spaces available are as follows:

  • .Console – Responsible for printing output (to consoles).
  • System.Windows.Forms – Responsible for creating rapid user interface.
  • System.Drawing – Responsible for building a form that contains buttons for user interaction to create graphics.
  • System.Text – Responsible for advanced string management.
  • System.Collections – Responsible for maintaining collections of data.
  • System.IO – Responsible for reading and writing to files.
  • System.Net – Responsible for transmitting data over a network.
  • System.Net.Sockets - Responsible for transmitting data over a network.
  • System.Runtime.Serialization – Responsible for persisting objects to storage.
  • System.Runtime.Remoting.Channels – Responsible for invoking remote object and building XML Web Services.
  • System.Web.Services Channels – Responsible for invoking remote object and building XML Web Services.
  • System.Threading – Responsible for enabling multithreaded programming.
  • System.Data – Responsible for providing base objects and types for ADO.NET.
  • System.Xml – Responsible for providing rich XML support.
  • System.Reflection – Responsible for allowing the user to examine metadata.
  • System.Security - Responsible for the underlying structure of the common language runtime security system, including base classes for permissions.

.NET Compact Framework

  • Creates a logical, consistent namespace hierarchy that makes it easier for developers targeting the runtime to find and use.
  • The same namespace can exist in different DLLs\Assemblies and can contain multiple namespaces.
  • Long namespaces have little impact on metadata bloat because the common prefix can be folded so that it is stored only once.

There are a couple of technical issues we should consider:

  • A given namespace cannot have two classes with the same name (that is, namespace Microsoft.Word, there cannot be two types named Font).
  • It is a best practice to have separate namespaces using a different type.
  • Most programming languages allow selective importing of a given namespace. For example, it is legal to define two types as System.IO.Path and System.GDI.Path. However if I import both System.IO and System.GDI, I could simply reference Path as its resolution.

Figure 3. System.Windows.Forms.Control Base Class

Figure 4. Unsupported System.Windows.Forms.Control Base Class

Windows Forms

.NET Framework enables rich client-side applications using Windows Forms. Windows Forms is a subset of Windows Forms class library. Using Windows Forms, you can access underlying power of Windows User and GDI. You can drag and drop within Visual Studio.NET.

Note   The .NET SDK provides more information for Windows Forms.

.NET Compact Framework

All the common features Windows Forms in the .NET Framework are present in .NET Compact Framework. These features are differently implemented in a separate manner to make them more efficient for size and performance.

Supported are:

  • Common controls such as:
    • Buttons
    • Listboxes
    • Tree-views
    • Listviews
    • Combo boxes
    • Textboxes
    • Picture boxes
    • Scroll bars
    • Labels
  • Bitmaps
  • Pens
  • Brushes
  • Colors
  • Drawing
  • Fonts
  • Support for Forms

Windows Forms applications running on devices will not run managed forms that host native ActiveX controls as in the .NET Framework.

Support for processor intensive features present in .NET Framework is not present in the .NET Compact Framework to achieve size and performance. This includes GDI+ features.

Figure 5. Supported controls

Networking

The System.Net.Sockets namespace is used to provide an interface to access the transport layer of protocol stacks. Multiple protocols can be exposed through this class. In addition, .NET Compact Framework provides additional classes that simplify common developer tasks encapsulating much of the necessary code that is common across all TCP client/server applications. Some of these are:

  • TCPListener
  • TCPClient
  • UDPClient

HttpWebRequest and HttpWebResponse classes provide a rich HTTP client. These classes also support many of the standard mechanisms for encryption and authentication such as SSL/TLS and basic HTTP authentication. Other Web requests can be implemented using other protocols such as:

  • WebRequest interface
  • WebResponse interface
  • IwebRequestCreate interface

These networking classes provide a synchronous and asynchronous (used to save thread resources) development model. This makes a simplified development model for programming by leveraging threads.

Threading

Threading is used for performing many tasks simultaneously. An example of threading is spell checking while writing an e-mail in Microsoft Outlook. A thread starts when an application is started.

Threading is implemented in the System.Threading namespace. This namespace enables multi-threaded programming. Support for creating and destroying threads are also included in these classes. To find what the current thread is, use the property of the CurrentThread on System.Threading.Thread. System.Threading.ReaderWriterLock provides a useful class for synchronizing access to data; System.Threading.ManualResetEvent provides a class for controlling flow from outside. You may also identify a thread by calling GetHashCode.

You can start applications by using the System.Threading.Thread class. You can also use System.Threading.ThreadPool (Windows thread pool) for service applications. Service applications use threading to handle multiple client connections or client jobs at the same time. JoinMethod is supported to notify when a thread has terminated, but it is not supported in .NET Compact Framework.

Native Code InterOp

Due to the fact that all code is not written in managed code (at least not in this point of history), there are times when you will have to call code written in C or C++ (Win32 DLL or COM object). The underlying Windows CE operating system is actually written in unmanaged code. You may have to interface with the operating system in situations where the .NET Compact Framework will not provide you with the functionality you require. A point to also consider is that there are DLLs you may want to use without having to rewrite them for the sake of development time.

The .NET Compact Framework supports a subset of the .NET Framework following areas:

  1. Platform Invoke (P/Invoke). This is used to call Windows DLLs. An example of this is interacting with code written by an OEM or hardware vendor as they may not have written their code as managed code. P/Invoke functions and attributes are found in the System.Runtime.InteropServices namespace.
  2. COM Interoperability (COM Interop). This is used to interact with COM objects. Unfortunately, this is not available with the .NET Compact Framework. This feature is memory and processor intensive that defeats the purpose of the .NET Compact Framework. A wrapper that is written using eMbedded Visual C++® would have to be provided. Something to note here is that generally eMbedded Visual C++ is used to write DLLs for Windows CE.NET devices. To edit the output binary file so that binaries targeting the Pocket PC use a tool called EDITBIN to edit the header information on the DLL. Make certain that features of the Windows CE.NET that are not supported on the Pocket PC are not invoked.

There are times when manual "Marshaling" may be needed in the .NET Compact Framework due to control crosses over from managed to unmanaged boundaries. Marshaling is when a manual conversion is applied. .NET Compact Framework provides no automatic marshaling for COM components except for those that are provided by P/Invoke.

.NET Compact Framework supports only one API calling convention called WINAPI. This convention is used by the Windows API for specific platforms.

Globalization

Classes for the .NET Compact Framework provides a culturally-aware formatting and functionality based on regional settings of the underlying operating system. A culture is defined as a representation of local conventions for language, formats used for calendar, dates, currency, and numeric values. The culture name is comprised of a neutral culture that defines the language being used and any specific information that defines the particular geographic location. The format used for the neutral portion of the culture is two lowercase letters. An example of this is "es" would be Spanish or "en" would be English. The subculture is then further defined by adding two uppercase letters to the neutral culture and separating the subculture from the neutral portion by a hyphen. An example of this is "en-US," which would represent English in the United States. By using this method of formatting, the application allows the same language to be used in various locations. For example English in the U.S. or United Kingdom would be represented as "en-US" and "en-GB."

There are times where a specific subculture may be insignificant. You would then specify a neutral culture using something called an invariant. The invariant culture is always associated with the English language, but no subculture is necessary or defined. This would be represented by using an empty string [""].

Culture names can be further examined in the Request for Comments (RFC) 1766. This provides a definition of protocols for culture names. You may also find a complete list of culture names in the CultureInfo class references by searching complete documentation for the .NET Framework.

The CultureInfo class can be used to retrieve information about the selection of the culture. It is a best practice to use Unicode in your application for character data. If necessary, you may also use the Encoding class to enable input/output of data into a specific code form, separate the user interface resources from the code logic, and use resource files to store localized user interface text and localized graphics. You may use the ResourceManager class to dynamically localize the user interface dynamically at run time. Always have a standard resource file with the default settings and user interface in the event that an unplanned event occurs for a regional setting that was not taken in consideration is presented.

Another aspect of globalization and/or localization is that the .NET Compact Framework supports the use of resource files for localized content. This allows the developer to create a single application assembly with multiple 'satellite assemblies' containing the embedded resource files for a specific culture. The application loads the appropriate resource file at run time based on the regional settings of the underlying operating system. Resource files can be text, XML, or a binary format. Only binary resource files can be embedded in a satellite assembly.

The CurrentCulture class property of the CurrentThread allows the change the default culture for your application. This is only supported in the .NET Framework. To support an alternative culture in the .NET Compact Framework application, you would use an object variable called CultureInfo.

Be certain that your application does not use custom formats or logic that will fail if the regional settings are changed.

XML

XML is supported in two ways for the .NET Compact Framework: the XmlReader and XmlWriter classes. To use any of the classes for XML, you must import the System.Xml namespace.

XmlReader is a class defined in the System.Xml namespace for the .NET Framework. This functionality provides you the ability to read an XML document only in a forward motion. If your application requires other navigation besides this, do not use this method. The XmlReader class allows you to read a document written in XML as a sequence of nodes. Each node represents an element, attribute, text value, or other components of the document. XmlTextReader will then return a Boolean value indicating whether or not the end of the document has been reached. This is much more expedient way to process memory. Keep in mind you are only able to move forward and not backwards in a document. Do not use XmlReader to find a parent element of a particular node. If you need this functionality, then you would need to include DOM functionality (provided in the XmlDocument class that is supported in the .NET Compact Framework), which is not encouraged due to performance reasons and memory constraints.

XmlWriter class is used to provide rapid, forward-only, and non cached output of XML to a file (or stream). To persist documents, you may use the XmlTextWriter class. This class is a derivative of the XmlWriter class. XmlTextWriter writes syntax-correct XML data. It also has support for namespaces and will translate special characters into text entities. Using the XmlTextWriter class, you are able to specify exactly where the XML data should be written to. You may also use the Indentation property to specify the number of characters you would like to use for indenting purposes, making the XML document easier to read. You can use this class to specify 'which' characters you would like to use for indentation.

Certain functions of XML are not supported on the .NET Compact Framework. They are:

  • XmlDataDocument Class – Relational and hierarchical view of a XML document
  • XML Path Language (Xpath) – Query over unstructured XML data
  • Extensible Stylesheet Language Transformation (XSLT) – Transform XML data to another format
  • XML Validation (XmlValidatingReader) - To validate XML correctness of a XML document

You have to evaluate how you would like to process your XML documents when using .NET Compact Framework. Some things to consider are navigation and size of memory for your XML document. If your XML document requires only forward-motion navigation, then the XmlReader and XmlWriter classes provide a great solution.

SQL CE

Microsoft SQL Server™ CE is a very compact, relational database that runs on the Smart Devices. You need a SQL Server 2000 developer license to download and install SQL Server CE.

SQL Server CE has built-in support for the .NET Compact Framework, uses compatible data types, and maintains a small footprint. SQL Server CE can be installed independently on a smart device or as part of a .NET Compact Framework application. SQL Server CE supports databases up to 2GB in size. It also supports Binary Large Objects (BLOBS) up to 1GB. Keep in mind the size of the local database is limited by the storage size available on the smart device. SQL Server CE is an ideal storage mechanism due to its capabilities for encryption for security purposes. This is also great for data connections that are wireless connections and/or online/offline connections.

If you are familiar with SQL Server Enterprise edition, SQL Server CE will be easy for you to adopt because the environment will be familiar and the capabilities of the SQL Server CE Data Provider are similar to those in the SQL Server 2000 Data Provider. SQL CE is composed of a database engine, a client agent, and a very small version of the Query Analyzer (Isqlw.exe). SQL Server CE supports a subset of Transact SQL. The Query Analyzer program allows a graphical interface to create and structure a database in a treeview form (this allows a graphical representation of the database objects). You can use the Query Analyzer to perform updates to data, a selection of data, or insert/delete data in the local database. SQL Server CE can store data in the relational format, extract that data, and then deliver it as an XML document for use with Web-based applications.

SQL Server CE supports the following data types:

  • Integer – tinyint, smallint, integer, and bigint
  • Numeric – real, numeric, and float
  • Binary – bit, binary, varbinary, and image
  • Unicode – national character (nchar), national character varying (nvarchar), and ntext
  • Others – money, datetime, and uniqueidentifier

To build an application using the .NET Compact Framework, you would use ADO.NET managed provider in the System.Data.SqlServerCE namespace. This class provides access to data stored directly in the database using Remote Data Access (RDA) and/or merge of replication. By using merge replication, you will ensure that the data is consistent between the server and client databases. This is a very powerful way to replicate data from a backend enterprise SQL Server to the SQL CE database on the device. This is useful for mobile applications that require information from the backend. Using the SqlCeRemoteDataAccess class, you can track changes made to the data instead of the pull method used by RDA. You can also use the SqlCeRemoteDataAccess to push data to the backend SQL Server.

The process to develop an application to use SQL Server CE is first to open the local database by creating a SqlCeEngine object. Then you update the local database by making a connection and executing SQL DDL statements. You make the connection by using the SqlCeConnection object. Once you connect to the database, you then use SqlCeCommand object to issue the DDL statements that will actually create the database table. Once the SqlCeCommand object is created, you then use ExecuteNonQuery method to run the DDS statements that creates the database. Next, you add data using SqlCeCommand object. Finally, you retrieve data from the database using the SQL Server CE Data Provider by one of two ways: (1) by using Data reader (implemented by the SqlCeDataReader object) that provides a very swift forward only motion to access data rows or (2) by using the Data adapter (implemented by the SqlCeData Adapter) that provides a 'Fill' method to fill DataSet objects with data in which you are also able to use data binding. Preferably use SqlCeDataReader because it allocates less memory than the DataSet method, which is easily destroyed after the population of the control. After the SQL Server CE database is created and the data is formed, you are then able to merge the information from the SQL Server CE database to a backend database such as SQL Server 2000. It is important to explicitly close or dispose of SqlServerCe objects after the connection is closed.

SQL Server CE database engine also uses SQL Server CE Client Agent to communicate with backend SQL Servers via IIS. RDA is responsible for pulling the data from the backend server and populating the data into the SQL Server CE database on the device. For better performance, data is actually compressed as it is transferred to the device.

SQL Server CE is a robust local store able to provide managed access to data using a rich device database. It is efficient and yet able to perform complex SQL querying to data stored locally on the device. It enables online/offline application data access and uses HTTP. It provides advanced performant synchronization. Keep in mind that SQL Server configuration is required on the backend, and the size of the SQL Server CE engine footprint on the device must be considered.

Later versions of SQL CE will support more intrinsic functions (ABS, LOG, SUBSTRING, and PI) and features (parameterized queries and unions).

XML Web Services Support

XML Web Services is used to support HTTP access remotely or locally on the device. XML Web Services is language and platform independent based on existing open protocols such as HTTP, SOAP, and XML. XML Web Services are a simplified way of exposing services across a network computer and/or server to connect to a service from a Web browser that supports XML (including connecting to a system of a different operating system). A note to mention here is that because XML Web services can communicate over HTTP, you are able make a call to an XML Web service from a Telnet session. When you make a call to an XML Web service, the server returns a response in XML. Moreover, unlike other remote access methods, XML Web services can navigate today's Internet firewall landscape.

If the backend source is not available due to loss of connectivity, the .NET Compact Framework allows you to cache data easily on the device. You can do this in XML or an optional format, such as SQL CE. Once connectivity is restored data on the backend is restored from the cached updates.

Because the XML Web Service is designed to run on the backend, a .NET Compact Framework application only has to create a proxy type connection to the backend service to invoke its methods. Generally, ASP.NET is written on the backend for IIS. .NET Compact Framework is then written as the client side application for the smart device. Web services passes data formatted in XML, which almost any client can parse.

Some of the benefits of XML Web Services in the .NET Compact Framework include cached information, synchronization logic is stored on the backend server, the smart device is able to communicate directly with the source, and calls to the XML Web Services can be invoked asynchronously or synchronously. Some other benefits include all encoding types are supported, Basic and Digest Authentication is supported, Secure Sockets Layer support for encryption (SSL), and SOAP Extension Framework (to include custom SOAP headers). XML Web Services is natively supported and an integral part of the .NET Compact Framework. Similar to the .NET Framework, invoking is the same process.

There are some limitations for the .NET Compact Framework to mention. There is no typed datasets, and there is no support for binary serialization or SOAP serialization (though object data serialization is supported). Due to the complexity of the state and synchronization, logic can get a little unwieldy. XML Web Services also carries a large amount of XML data transfer.

Differences from the .NET Desktop Framework

.NET Framework

  • ASP.NET – Built upon the CLR. Can be used on a server for building powerful Web applications. Web Forms created in ASP.NET can easily be used to develop dynamic web user interfaces. Not supported on .NET Compact Framework.
  • nGen (Install-time JIT) - Supported in the .NET Framework but not in the .NET Compact Framework.
  • Reflection emit - Supported in the .NET Framework but not in the .NET Compact Framework.
  • Desktop controls - 35 desktop controls are available and supported.
  • File change notifications – This is supported on the .NET Framework but not supported on .NET Compact Framework due to differences in device operating systems; there are limitations on the I/O models.
  • Expressions - Expressions used in applications within the full .NET are not binary compatible with .CF (but source code is). But code compiled for .NET Compact Framework is binary compatible with the .NET Framework.
  • Tooltips – This graphical user interface control is supported in the .NET Framework, but these APIs are absent from the .NET Compact Framework.
  • Checked List Box - This graphical user interface control is supported in the .NET Framework, but these APIs are absent from the .NET Compact Framework.
  • COM Objects – There is no support for developing COM objects in .NET Compact Framework.
  • .NET Remoting – There is no support for .NET Remoting in the .NET Compact Framework. XML services are to be used as alternative for this.
  • System.Windows.Forms Namespace - No drag and drop support, no printing, no Microsoft ActiveX® support, and no GDI+ in the .NET Compact Framework.
  • 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.
  • Thread Termination – JoinMethod is supported to notify when a thread has terminated. This is not supported in the .NET Compact Framework.

.NET Compact Framework

  • 28 of the 35 desktop controls are supported in the .NET Compact Framework. These controls are enhanced for the size and performance requirements in the Compact Framework.
  • Not all .NET properties, methods, and events are supported in the Compact Framework controls.
  • Supports the same Win32 API Access mechanism as the .NET Framework but has a simplified data marshalling layer.
  • Accessing COM objects via COM Interop is not possible.
  • OLE DB Wrapper – Not supported in .NET Compact Framework.
  • Datagrids – Not built in to the editing support as in the .NET Framework. The .NET Compact Framework can only bind Datagrids to a single table object. The .NET Compact Framework only displays rows from a single table, and these are not able to be expanded as in the .NET Framework.
  • Infrared Data Association classes - .NET Compact Framework provides for making infrared connections and Web listening classes for HTTP services to devices. These are not available on .NET Framework.
  • Infrared send/receive – The .NET Compact Framework includes new APIs that allow applications to send and receive information over the IR port. This feature is not present on the .NET Framework.
  • Serialization - Due to performance considerations, .NET Compact Framework does not support binary serialization using BinaryFormatter, or SOAP serialization using SoapFormatter. There is, however, support for serialization to transmit object data using SOAP in XML Web Services.
  • Web services - Although .NET Compact Framework applications can consume Web services, they can't provide them due to the lack of a Web server.
  • XML support - Scaled-down XML support is available. .NET Compact Framework applications 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 as these are resource consumptive.
  • Threads - .NET Compact Framework does not support priorities as in the .NET Framework.
  • Web Services – Only client implementation is supported in the .NET Compact Framework.
  • Win32 Calls - .NET Compact Framework does not support calls from Win32; you can make calls from Compact Framework into Win32. Communication between Win32 and Compact Framework is done by MessageWindows class.

Application Development Using Visual Studio .NET

.NET Framework

  • Native code - Win32 code is referred to as "native code." This is largely because CLR Runtime does not manage the memory, or guarantee the security and type-safety of the code. Development is usually written in C++ using Visual Studio .NET 2003.
  • MFC, ATL and STL can be applied.
  • Globalization (Unicode) - Date formatting and sorting tables for locality defers to the underlying operating system.
  • You can also build traditional graphical user interface applications that are not dialog-box style by processing input and drawing onto the application's main window (called a "form" in .NET).
  • To make .NET Compact Framework executables disclose less technical details for security purposes, you may use a tool such as an obfuscator that changes the metadata to make it less intelligible. Developers who are concerned about hiding proprietary information will investigate issues of whether Win32 or the .NET Compact Framework provides the level of protection they require.
  • Use SOAP 2.0 Toolkit that ships with Platform Builder (along with any necessary COM objects) to host a Web Server on Windows CE .NET.
  • Smart Device Programmability features of VISUAL STUDIO .NET 2003 use actual binaries that are in CE.NET within a virtual shell.
  • Support for side-by-side execution in the .NET Framework lets you have multiple versions of applications and components that use a version of the redistributable executable on one computer at the same time.
  • Assemblies originating from the Internet default security policy have been modified. They are assigned by the CLR to the Internet zone group to receive constrained permissions associated with the Internet permission set. This enables execution of Windows forms assemblies originating from the Internet to now receive sufficient permission to execute in a semi-trusted manner.
  • Native support for communicating with ODBC and Oracle databases exist. The .NET Framework Data Provider for ODBC ships with the .NET Framework. This provides access to native ODBC drivers such as with OLE DB .NET and access to native OLE DB providers.

.NET Compact Framework

  • .NET Compact Framework executables, by contrast, ship as Microsoft Intermediate Language/Common Intermediate Language (MSIL/CIL), which must be converted to native code. .NET Framework executables are also shipped as MSIL and converted to native code at runtime. The only exception to this is NGEN'ed executables, which are used with the desktop CLR to precompile assemblies to native code at installation time (intended only for .NET Framework and not the .NET Compact Framework).
  • .NET Compact Framework provides binary portability.
  • For ability to wrap COM for access by .NET Compact Framework applications, you must build a Win32 DLL with a set of wrapper functions around any Win32 ActiveX/COM library that you desire to use.
  • To make .NET Compact Framework executables disclose less technical details for security purposes, you may use a tool such as an obfuscator that changes the metadata to make it less intelligible. Developers who are concerned about hiding proprietary information will investigate issues of whether Win32 or the .NET Compact Framework provides the level of protection they require.
  • Use SOAP 2.0 Toolkit that ships with Platform Builder (along with any necessary COM objects) to host a Web Server on Windows CE .NET.
  • Visual Studio .NET 2003 uses actual binaries that are in CE.NET within a virtual shell.
  • P/Invoke is used for interoperability of managed code to call native code.
  • Same syntax as desktop is used.
  • Managed code in .NET Compact Framework automatically marshals simple data types.
  • You can create .CAB files directly from the project.

Conclusion

The .NET Compact Framework is no doubt a much smaller set of class of libraries than the .NET Framework, and .NET Compant Framework is tuned for size and performance for devices. Binary sizes are also distinct as the .NET Framework is about 20 times larger. The .NET Framework binary size is about 30MB, whereas the .NET Compact Framework is about 1.5MB.

Both the .NET Framework and the .NET Compact Framework provide a consistent and familiar programming model. There are key similarities such as namespaces, classes, method names, properties, and data types. Programming is simplified and more secure due to the architecture and design of these platforms. Developers familiar with .NET Framework programming will find it easier adopting the .NET Compact Framework and will enjoy the same experience as developers who are familiar with the .NET Framework.

Related Links

See the following resources for further information about the .NET Compact Framework:

Show:
© 2014 Microsoft