|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here. ArchiveDisclaimer|
Device Memory Management
An important strength of the .NET Compact Framework is efficient resource usage, especially volatile RAM. Devices are not required to have hardware memory management units (MMU) or operating system virtual memory.
.NET Compact Framework Storage Size
For the .NET Compact Framework version 2.0, the storage size is as follows:
5.5 MB (ROM), uncompressed, on Windows Mobile 5.0.
Persistent storage is no longer compressed starting with Windows Mobile 5.0.
For the .NET Compact Framework version 1.0, the storage size is as follows:
1.55MB (ROM), compressed, on Pocket PC 2000/2002
1.35MB (ROM), compressed, on Windows Mobile 2003 for Pocket PC and Windows Mobile 2003 for Smartphone.
Running RAM requirements:
.5 MB+ (depends on application)
Typical application sizes:
5 - 100 KB
CAB File Installation
During the installation of the .NET Compact Framework version 2.0 SP1, you are prompted to install either to the device or to a storage card if present. If you elect to install to storage, then the global assembly cache is placed on a storage card and the files for the common language runtime (CLR) are placed in the \Windows directory. The global assembly cache requires approximately 4.5 MB of space and the CLR requires 1.0 MB.
The performance of the .NET Compact Framework varies for the CAB file installation depending on the memory implementation in hardware and software. For some devices, better performance can be achieved by installing the global assembly cache to a storage card.
The .NET Compact Framework is designed to operate optimally on systems with the following characteristics:
Approximately 5 to 10 times the flash memory or RAM file system capacity to store the .NET Compact Framework and its applications in dynamic RAM (DRAM)
A working space from as small as 128 KB to 1 MB in DRAM
Optional hard drive
The .NET Compact Framework uses available system memory carefully. No RAM is accessed until you run an application. Moreover, the .NET Compact Framework frees the RAM when you quit programs. The native operating system is not required to have its own memory protection capabilities. Exceptions are always thrown when un-owned memory is accessed.
When memory is scarce, the .NET Compact Framework aggressively releases internal data structures that are not needed by the currently executing code. Therefore, the program can continue running, even in low-memory situations. If the application requires more memory than is available, the .NET Compact Framework closes the application cleanly and releases all underlying resources. The .NET Compact Framework itself should not fail because of low memory.
The application domain host starts the .NET Compact Framework applications and the common language runtime. The .NET Compact Framework applications use code space and static and dynamic data space in the same manner as native applications. When no .NET Compact Framework applications are running, there is no RAM cost beyond the application domain host, and a small amount of static data is used by the common language runtime. Windows CE .NET creates an application domain host when a .NET Compact Framework application is started.
The .NET Compact Framework applications are packaged into .exe files and .dll files, which can be stored in a read-only or read/write file system in flash (or ROM for read-only). The common language runtime class loader can read these files in directly addressable blocks without making a memory copy and without requiring a memory management unit to create a memory-mapped view of the file.
Developers are encouraged to test applications on multiple devices to understand device-specific variances in performance.
Random access memory (RAM) is used to store dynamic data structures and JIT-compiled code. The .NET Compact Framework uses available RAM, up to a limit specified by the device, to cache generated code and data structures and then frees the memory when appropriate.
The common language runtime uses a code-pitching technique to free blocks of JIT-compiled code at run time when memory is low. This enables larger programs to run on RAM-constrained systems with minimal performance penalty.
Native code that forms the common language runtime can reside in read-only memory (ROM) or a RAM file system. The .NET Compact Framework uses available ROM, flash, or disk storage to enable applications to continue to run with lower performance in low-memory situations.
Files that contain Microsoft Intermediate Language (MSIL) instructions and metadata for class libraries are stored in either a ROM file system or a RAM file system. Class libraries can be downloaded into a read/write file system as part of the downloadable application installation process.