Mobile CoDe.NET: Exploring the .NET Compact Framework : Page 7
"Windows CE or Mobile Web?" The .NET world can steer you in two very opposite directions: .NET Compact Framework or ASP.NET Mobile Controls.
by Nickolas Landry
Oct 6, 2003
Page 7 of 10
Exploring Namespaces and Classes
What makes .NET so powerful and so productive takes root in the base class libraries. We can be thankful the .NET Compact Framework team managed to port so many namespaces to smart devices considering the whole thing is less than 3 Megabytes big. Let's review what's in and what's out:
All the base data types are there; including their associated functions and methods for type conversion, display formatting, string manipulation, and array sorting,
Threading and synchronization classes (System.Threading) also made it. Storage classes (System.IO) can be used.
For those who need to build international applications, you'll be pleased to hear that System.Globalization and System.Resources are included in .NETcf.
Many collections are supported (System.Collections), but not Queues, SortedLists, and other specialized collections. Reflection is supported to peruse through mobile assembly metadata (System.Reflection).
Basic XML classes are supported, such as XmlDocument (for DOM parsing) and XmlTextReader/XmlTextWriter classes.
Networking (System.Net) is included for Windows Sockets programming, Http clients, Http servers, and other communication schemes.
Windows Forms is of course included, along with the designer classes for Visual Studio .NET.
And last but not least, data access using ADO.NET is included and fully compatible with server-side objects, such as the DataSet for seamless exchange in a distributed scenario.
Even if those namespaces are supported, many are only partially implemented and have missing classes and members. There are also some namespaces that are missing altogether for various reasons.
Namespaces Lost, No Grief
We can easily identify two types of missing namespaces: those that didn't make sense on smart devices or for which there was no underlying Windows CE feature, and those that were omitted because of size, performance, or limited resource considerations. Here are some namespaces that we lost at no high cost in functionality:
System.DirectoryServices isn't supported since Windows CE itself doesn't support Active Directory. If you need to query the AD, have a server-side component do it for you and then make a Web service call to that component.
System.EnterpriseServices isn't there either since there are no COM+ component services in Windows CE; this is a server-side engine.
System.Management was cut too because there are no WMI services on Windows CE... yet!
System.ServiceProcess has no use either since Windows NT-style background services are not supported on Windows CE. You would have to create a non-graphical application or?as is the case for MSMQ CE?write a device driver using eVC++.
System.Web and System.Web.Mobile don't exist in .NETcf because they are used to create server-side ASP.NET applications and the form factor is not suited for Web hosting. To use these Web applications from a Pocket PC or other smart device, simply use Pocket Internet Explorer; no programming required.
System.Security.Principal isn't implemented in .NETcf because, designed as a single user environment, there is no need for role-based security on a smart device.
Mourning for Namespaces
There are, however, namespaces that didn't make it and these are costly omissions since they prevent us from leveraging key Windows CE or .NET features. These are the namespaces we'll sorely miss.
System.Configuration, which means you can't use the standard .config files familiar to .NET developers. Your alternative is to either use (dare I say it?) the Windows CE Registry, or better yet, to implement your own custom configuration file schema and access method using file IO and/or XML. Check the sidebar on ActiveNick's Recommended Mobility Book; chapter 2 of that book shows you how to use supported XML classes to create a simple configuration settings class that is compatible with the .NET schema.
System.Messaging, your doorway to Microsoft Message Queue Server (MSMQ), isn't supported either, which is a disappointment since MSMQ CE does exist on Windows CE, providing you with an excellent asynchronous reliable messaging infrastructure that is ideal for seldom-connected devices. Your alternative is to use P/Invoke to call MSMQ CE.
As mentioned above, the .NETcf team pulled System.Runtime.Remoting out because of high costs in size and resources. Use either XML Web services calls or Windows Sockets.
Some XML classes didn't make it, namely the classes related to XmlDataDocument for relational and hierarchical views of XML, XPath for queries over unstructured XML data, XSL and XSLT for transforming XML data to other forms, and XML schema validation to verify correctness of XML document. It is recommended to process and transform XML data on the server-side using these mechanisms in the full .NET Framework before returning it to the mobile client device.
System.Runtime.Serialization.Formatters.Soap is also out, blocking the way to generic serialization. Mimicking this feature would require a custom serialization scheme. You would have to be careful to ensure compatibility with .NET serialization, so you'd be better to stick to passing application data, not object states that could corrupt your session if the deserialization scheme introduces an error.