.NET Compact Framework Limitations
You use the same Visual Studio .NET environment that you use when developing desktop applications,
but in order to fit the .NET Framework into the operating constraints of Windows CE, the following
limitations apply:
•
Method Overloads
—overloading a method provides alternative ways to call that method, but
it also increases the size of the Framework. As a result, the .NET Compact Framework
trimmed the overloads from almost all methods. Consequently, there is a good chance that a
particular method overload you used with a desktop application will not be available when
developing .NET Compact Framework-based applications.
•
Missing Control
s—a number of .NET Framework controls are not part of the .NET Compact
Framework. The absence of most of these controls (such as printing) is insignificant to mobile
developers. You can replace many of the missing dialogs with your own dialogs or by
accessing system dialogs directly using the Windows CE API.
•
XML Functionality
—as much as the .NET Compact Framework offers in the way of XML, an
equal amount of functionality was trimmed. A key missing XML-related component is the
System.Xml.Xpath
namespace. In its absence, you can use a combination of recursive and
iterative searches against the Document Object Model (DOM). Another missing key XML
component is Extensible Stylesheet Language Transformation (XSLT), which convert an XML
document into different formats. In addition, the .NET Compact Framework does not
currently provide support for developing device-based XML Web services.
•
Database Support
—the .NET Compact Framework offers a robust set of data-related tools.
SQL Server CE provides local database support, while on the server side, the .NET Compact
Framework provides support for SQL Server.
•
Binary Serialization
—due to size and performance considerations both the
BinaryFormatter
and
SoapFormatter
classes are not part from the .NET Compact Framework.
•
Access to the Windows Registry
—the .NET Framework uses the Microsoft.Win32.Registry
namespace to work with the Windows registry from an application. Because it relates to Win32
and not Windows CE, this namespace was not included in the .NET Compact Framework.
However, you can access the Windows CE registry by invoking the relevant Windows APIs.
•
Leveraging COM Components
—incorporating COM objects into a .NET Compact
Framework-based application is a two-step process. First, you must write an unmanaged DLL
wrapper using eMbedded Visual C++ that exposes the COM object. Then, you must use
Pinvoke
to access your DLL wrapper.
•
Security
—the .NET Compact Framework does not secure access to unmanaged code. Any
application can call any system or non-system API. There is currently no role-based security
with the .NET Compact Framework. The principal object has no understanding of known
identity or known role.
•
ate
•
•
oes not natively support GDI+, and therefore is not part of the
•
ou should
implement an XML Wed service façade for the component and access it that way.
XML Web Services
—the most notable exclusion from the .NET Compact Framework XML
Web service capabilities is the ability to use cookies. Cookies are widely used to maintain st
on the server between calls from a client. While the use of cookies in Web services is not as
prevalent as their use on Web sites, they are still in use. The .NET Compact Framework offers
limited cryptographic abilities with respect to Web services.
Printing
—the .NET Compact Framework provides no support for printing. There is no easy
way to interact with network printers. The workaround for accessing network printers is to
build a server-based application, which accepts and prints jobs submitted by your application.
GDI+
—Windows CE .NET d
.NET Compact Framework.
Remoting
—the initial release of the .NET Compact Framework does not support remoting. If
you need to communicate with .NET components situated on a remote machine, y
JETT•RFID Technical Reference Manual, MAN0339, Rev. A, Preliminary
5-3
