.NET Compact Framework: The Architecture
The .NET Framework is what could be called a high-level platform in that it shields developers from the intricacies of the Win32 API and the low-level plumbing that would normally be required. The .NET Compact Framework works in the same way, isolating you from the nitty-gritty details of Windows CE development. It nonetheless remains important for developers to understand how that platform works and what kind of architecture lies underneath. Note that for the sake of discussion here, I assume you are already somewhat familiar with the basic architectural workings of the .NET Framework.
|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.|
The basic architecture of the .NET Compact Framework starts with the Execution Engine
(EE), which is the core component that manages everything else in .NET. This is where you'll find the Common Language Runtime (CLR) designed for the .NET Compact Framework. This CLR works just like the CLR in the .NET Framework by consuming IL assemblies to produce native code for the target CPU. Since the Execution Engine is built in native code, there is one set of EE files for every CPU and Windows CE OS supported. The CLR is contained in the MSCOREE.dll
files, which also contains the Platform Adaptation Layer
(PAL). This layer is akin to the Hardware Adaptation Layer
(HAL) in Windows NT-based operating systems (Windows NT 4.0, 2000, XP, 2003) in that is serves as a "translation" tier between generic code and a hardware specific CPU. This PAL is what enables any .NET Compact Framework assembly to run on any compatible Windows CE device using any CPU, whereas classic Embedded Visual C++ applications would require a separate recompile for each OS and CPU. Other native code files outside of the EE include NETCFAGL.dll
for the GWES (Graphics, Windowing, and Events Subsystem) interface, which is the graphical user interface between the user, application, and the operation system, and CGACUTIL.exe
for the Global Assembly Cache (GAC) manager.
Indeed, there is a GAC in the .NET Compact Framework where you can deploy you own assemblies for shared reuse. It comes preloaded with a subset of the .NET base class libraries, which are CPU- and operating system-independent managed DLLs you can call from your applications through references to reduce the overall amount of code required. These class libraries follow the same hierarchical structure of namespaces as the ones found in the .NET Framework 1.0 and 1.1. I'll come back to .NETcf namespaces very soon.
I mentioned earlier that only Visual Basic .NET and Visual C# .NET were supported in the .NET Compact Framework. This is not entirely true. Since the CLR only runs IL code, this means any .NET language could potentially be used to create .NET Compact Framework assemblies. The limitation to these two languages actually rests on the SDE which only initially supports VB .NET and C# from Microsoft. Should another company decide to port their .NET language to .NETcf and create an SDE-style compiler that understands the limitations, the compact CLR would accommodate it just as well. I have not seen any official announcement yet as far as .NETcf third-party languages are concerned.
One interesting difference in the architecture lies in the way error messages are handled. Typically, when an error is raised, an error message accompanies it and the developer can choose to display it or display their own message to the end user. In the .NETcf, Microsoft extracted all the error messages for memory considerations and put them in separate error string files (SYSTEM.SR.dll). There is one such file per supported language and you can choose whether to deploy an error string file or not along with your mobile application.
.NET Framework: Compact/Desktop Commonalities
As stated earlier, the .NET Framework and the .NET Compact Framework share many commonalities, and many of these have to do with the .NET programming model. For instance, both benefit from a verifiable type safe execution of assembly code in a managed environment, thanks to CLR services. This means that?unlike Embedded Visual Basic 3.0?you cannot rely on uninitialized variables or unsafe casts. Nor can you have bad array indexing or bad pointer math, which could corrupt your application.
And while it may be compact, the "mobile" CLR is just as complete. The Garbage Collector (GC) eliminates the need for reference counting (à la COM), allocates and deallocates memory, and prevents memory leaks. The "Blue Screen of Death" may not exist in Windows CE, but memory corruptions can still occur and the .NETcf GC safeguards what happens in those tiny application domains. Just-in-Time (JIT) compilation is also inherited from the desktop cousin. .NETcf strictly runs IL code and nothing else, and with many more CPUs on mobile devices than on the desktop, this design feature brings many more benefits, such as portability of assemblies, facilitated deployment, and more.
|Interestingly enough, the MainMenu control is automatically rendered in different locations based on the targeted OS.|
Should something go haywire in your code, error handling in .NETcf also relies on structured exception handling; using the same constructs you have become familiar with in .NET. And of course, there's the Common Type System
(CTS) which brings unity across data types and languages. You'll be pleased to hear that all the basic types (e.g. Boolean, integer, long, string, decimal, etc.) made it to the .NETcf, ensuring compatibility between desktop, server, and mobile code. As for complex types and other classes, it depends on their respective namespaces.
The object model is also the same, giving you full access to true OOP on mobile devices. This is a given since .NETcf supports the same IL assembler as .NET, which means you're using the same Visual Basic .NET and Visual C# .NET languages as .NET, and not some stripped-down variant. With this CLS (Common Language Specification) compliance comes many code mechanisms and development benefits such as object calling, cross-language inheritance, and source-level debugging across different languages.
|The good news is ADO.NET is very well supported in .NETcf, including DataSets and DataViews, as well as other classes.|
The bottom line is clear enough: There are so many features that are part of the common denominator here that it's probably easier to say that a .NET feature is supported in .NETcf unless stated otherwise. Which brings us to the question: What is different?