This .Net Compact Framework opens up an entirely new world of devices for .Net developers, but is the environment at all like its big brother? Obviously, in shrinking a 23-MB runtime library into less than 1.5 MB for a mobile device, Microsoft had to discard something. So what did they leave, and do the changes preclude any compatibility between the two frameworks? Let's answer the last question first and then take a look at the primary ways the Compact Framework differs from its full-scale sibling.
The question of portabilityIn creating the Compact Framework, said Microsoft's Ed Kaim, the aim was twofold. Beyond the obvious goal of coming up with a .Net runtime that was smaller and less resource-hungry than the full version, Microsoft wanted to centralise development for all platforms in Visual Studio .Net. "We wanted to make it possible for a typical Visual Studio .Net developer to do everything they needed from inside the IDE, [and] keep the development experience the same for all platforms," Kaim said. Missing from this mission statement is any kind of "write once, run anywhere" portability, and Microsoft has been sending mixed messages on the subject. The latest example of this sort of thing is the newest episode of MSDN's "The .Net Show," which manages to send contradictory messages about whether it would be reasonable to assume that code written for one framework would run on another. So what's the real story? Kaim responded to this confusion by pointing out that although "write once, run anywhere" wasn't really a primary goal, it nevertheless is possible to achieve this level of portability, with due consideration and planning. Existing .Net applications will need to be recompiled for the Compact Framework, he said, but assuming that they don't reference any assemblies that are absent from the mobile API, there's no reason why the same code base can't be used with both runtimes.
