.NET Framework: Compact/Desktop Differences
You'll probably agree that we're already getting a lot as part of the .NET Compact Framework, especially if you've done mobile development with other toolkits or mobile platforms before. But it's time I told you what we lost along the way from Windows to Windows CE.
For starters, there is no ASP.NET in the .NET Compact Framework. This means you get none of the System.Web namespace aside from the client classes from System.Web.Services
(calling XML Web services from mobile clients is
supported). When you think about it, it kinda
makes sense since very rarely will you want to host a full Web server on a Windows CE-based smart device.
A big bummer is that we get no COM interoperability, which means the compact CLR doesn't include the COM marshaler from .NET that is able to translate inbound and outbound calls between .NET objects and COM objects. Windows CE does support COM and this limitation of .NETcf makes it difficult for your mobile code to "talk" to mobile COM libraries, such as the Pocket Outlook Object Model (POOM). COM Interop was omitted because of size and mobile resource considerations. It was important to keep the size of the mobile CLR down and COM Interop was simply too expensive. Your only way out of a .NETcf application domain is Platform Invoke (P/Invoke), which enables you to call Win32 DLLs in Windows CE, whether they are native or third party in nature. COM objects would then have to be "wrapped" using a native message-based DLL built with eVC++. This native wrapper would make all the COM interactions and your .NET application would talk to the wrapper through P/Invoke. Interoperability and COM Interop in .NETcf is too big a topic for the scope of this article, so I'll come back to it in a future issue. Also, note that there is no support in .NETcf for writing a COM object.
The base class libraries are a subset of the full .NET Framework 1.0, bringing you roughly between 25% to 30% of the classes and functionality. It is important to note that this difference in compatibility goes all the way down to the method level. The same class might exist in both .NET and .NETcf, but it doesn't mean the .NETcf version will have all the class members (properties, methods, or events) from the full version. Sometimes a class isn't implemented at all, and sometimes it's only partially implemented. Look up the documentation and IntelliSense to figure out what's in and what's out.
|A .NETcf application will always load the exact version of a shared library that was referenced at compile-time.|
Another huge drawback is the lack of a .NET Remoting infrastructure to perform remote calls to server-side objects over HTTP or TCP/IP using binary or SOAP formatters. This is again because of size considerations since the Remoting infrastructure is fairly heavy on system resources. Client Web services calls are fully supported, and while the XML/SOAP overhead can be pretty costly when it comes to remote invocation over a wireless WAN connection that surfs at 30-40 Kbps, it remains your only high-level alternative. For more control and efficiency, you could build your own proprietary Remoting infrastructure using Windows Sockets in the System.Net namespace.
If you're a fan of delegates (and you should be), note that while they work just fine in .NETcf, asynchronous delegates (i.e., BeginInvoke
methods) are not supported. This can be misleading since the documentation seems to indicate they work. Don't be fooled, they don't?even despite the presence of the two async methods in the Delegate class as reported by IntelliSense. Try as you might, even if you code it, the application will compile successfully but as soon as the CLR tries to enter the procedure containing the illegal code, a NotSupportedException
will be thrown. Listing 1
shows such an excerpt of faulty code. All appearances lead to conclude this should
work, but it doesn't and Microsoft confirmed async delegates are not supported in .NET Compact Framework 1.0.
Because of the nature of the file system in Windows CE that differs from Windows NT-based systems, the .NET Compact Framework sports a different IO model. The primary consequence here is that you cannot capture file change notifications since none are fired by the operating system itself.
Don't worry. We may be losing some things in the transition to the mobile world, but we are also gaining a few, such as the System.Net.IrDA namespace for programmatic access to the infrared port found in almost all Windows CE smart devices. This is a namespace that is exclusive to .NETcf and cannot be found in the full .NET Framework.
Additionally, here are some additional noteworthy features that are not supported or behave differently in the .NET Compact Framework:
- No generic serialization, although SOAP calls can be serialized and deserialized as in .NET when making XML Web service calls.
- No reflection emit (System.Reflection.Emit), which means you won't be able to compile code at run-time to create IL assemblies dynamically.
- No install-time JIT (nGen) where assemblies are pre-compiled from IL to native code before execution.
- You cannot load assemblies into a domain-neutral code area for use by multiple application domains.
- There is no support for multimodule assemblies, although .NETcf does support satellite assemblies.
- You get no late binding (i.e., As Object in VB .NET).
- And there are, of course, other important security differences and considerations, as well as different size and scalability characteristics that I will highlight throughout this article and in future articles.
The features noted in this section are by no means an exhaustive account of all the differences between the .NET Framework and .NETcf, but it gives you a fairly good idea to get started. Remember that experience counts just as much here as it does for desktop or server development, and with time, you'll figure out what you can and cannot do in mobility projects and learn how to effectively design applications with these considerations in mind.