Smartdevice projects opened in a Compact 2013 development context are not automatically upgraded to Compact Framework 3.9. This article discusses techniques for upgrading of Smartdevice (Compact 7) projects to the Compact 2013 context (Compact Framework 3.9). This includes comparison of project files as well as use of the CEESharpWiz wizard.
Yesterday I was able launch a Compact 2013 OS image on a BeagleBone Black board which included the Compact13Tools shell components. Looked good and worked OK. This has a TI AM33x ARM7 Cortex A8 CPU as its heart.:
The OS used was a prebuilt image from the Codeplex project, BBBlackWinCE8BSP by Stephen Zhang: http://bbblackwince8bsp.codeplex.com/ It boots quite quickly, quicker than the Linux image in its Flash. I used a HDMI TV as its video monitor For the uninitiated, Beaglebone Black is essentially a (cheap) developer's embedded OS board with embedded Linux being the supported OS: http://beagleboard.org/ BeagleBoard is an Open Source project.
Compact 7 Managed Code projects known as SmartDevice projects, could target a variety of devices including Windows Mobile phones as well as embedded CE/Compact 7 devices. A generic SDK could be used in their development. SmartDevice projects that did not directly use hardware resources (eg. PInvoke) would actually run on the desktop! Development of SD apps for a CE/Compact OS, itself under development required a second instance of Visual Studio, In an undocumented feature though, developed Managed Code SmartDevice projects could be directly added as OS Subprojects!
During a majority of the Compact 2013 CTP period, participants were advised that Native Code and Managed Code projects from Compact 7 had to be recreated and rebuilt. The Compact 7 built binaries would not work on Compact 2013. The Compact 7 SmartDevice projects (Visual Studio 2008) couldn't be opened in the Compact 2013 SDK development context (Visual Studio 2012). When opened in VS 2012, the IDE reported that the project couldn't be upgraded. With the adoption by Compact 2013 the desktop C++ compiler, the structure of compiled binaries changed and hence the reason that Compact 7 Native code binaries can't be launched by Compact 2013 OS. Many legacy hardware drivers (which are native source) from previous CE versions no longer work and require porting to Compact 2013. Given that the source code for much of this older hardware is not public, it means that much legacy hardware will never run on Compact 2013.
X86 Native Code code just needs recompilation for Compact 2013. But Native Code ARM code requires some modification because of the adoption of Thumb 2 compilation. This is particularly important with porting BSPs from Compact 7 to 2013.
The rejection of Compact 7 Managed Code binaries always seemed like an overstatement though as they run against the CLR . Later in the CTP period, it was announced that Managed Code binaries would run on Compact 2013 (with the Compact Framework components) provided there was no PInvoke of hardware.
The Compact Framework version for Compact 2013 is 3.9, a variant of 3.5, and is close to the version that shipped with Windows Phone 7.5. Whilst the phone supports XAML Managed Code, CF 3.9 does not though. As previous, it cam be coded in C# or VB; no F# or C++ Managed Code. The main changes are "under the hood" with applications running much faster. There is an improved Garbage Collector which is more efficient in that it takes up less of the processor time. There are also performance improvements with multi-core support and caching of MSIL code compilation. Although multi-core is supported in Compact 7, it was rather stilled, especially with Managed Code. Managed Code only ran as if it was on a single core. Multi-code support has been properly implemented with CF 3.9. . Startup of apps can be faster where they share loaded assemblies and JITed machine code is shared across apps (and re-launched apps).Finally, ARM floating point Managed Code performs faster because it uses the ARM VFP instructions.
The upshot is that whilst "software only" CF 3.5 (or earlier) apps will run with CF 3.9, those that invoke the Win 32 API or hardware need to recompiled under CF 3.9 to run on a Compact 2013 system. .NETCF 3.5 code is source compatible with .NET CF 3.9. Compact Framework 3.5 projects can't be opened in a CF 3.9 development context but the 3.5 (or earlier) code files can be added to an existing CF 3.9 project and compiled in that context.
Ref.NET Framework Blog: "Introducing .NET CF 3.9 .."
In previous upgrades to Visual Studio, projects from the previous version would be "upsized" with a wizard. That is, the project file would be interpreted in the old context and then translated to the new context. In particular this handled upgrading projects from one version of .NET to the next.. Unfortunately, such a wizard was not made available for CF 3.5 in Visual Studio 2012. Three methods for doing tis are:
With this method, you create a new C# or VB SDK project, using an SDK from the new OS.. The project type (Console, Winform, Class Library etc.) matches the existing project type. For simplicity, give it the same project name as the existing project, so that metadata of the project matches this Replace the generated source code with the preexisting code and make any source code changes that might be required. Add the same references that the original project has (You might need to open the original project in Visual Studio 2008 to check for this. Compile the project and resolve any issues then test it on the target.
Another approach involves using a file difference app, such as WinDiff or BeyondCompare, to compare CF 3.5 and 3.9 project files. Having established the differences, make the changes in the project file to be ported. A bit of trial and error is required but it is do-able:
Use a third party wizard (eg. CEESharpWiz )
CEESharpWiz, as available on Codeplex, is able to import CF 3.9 SDK C# project into the OS project as Subprojects, much like the undocumented capability with Compact 7 with which that can be done directly. This is a later version of WECSharpWiz ; it could only create Managed Code Sources project, not import them. When importing CEESharpWiz takes the meta-information from the VS 2008 project file to create the new source file and capture source code and resources files for the new project.
CEESharpWiz is able to similarly import a CF 3.5 C# SmartDevice project into a Compact 2013 OS project as sources Subproject. Note that this isn't amn SDK project though but for an existing project that works on Compact 7, the sources project generated should build and run satisfactorily with a few fix ups. The main fix up is to do with resources as resource compilation is not currently supported. The setting of an image property must be set explicitly rather than implicitly as a resource in the .designer.cs code.This is was discussed in a previous blog here. See other limitations on the Codeplex page.
Once installed run the Wizard (see the Wiki for it on Codeplex). To import a project,:
Note, despite these limitation this tool was used to simply and quickly port the Compact13Tools apps to CECompactTools. It was also successfully used to port RegEdit from Compact 7 to Compact 2013 which has a complex directory structure.
Good luck!
Once a Managed Code app is debugged it should be possible to directly build it as part of the OS build, exactly like Native Code Subprojects. The following is a trilogy on this topic including a wizard for creating a C# OS Subproject that builds with the OS on embedded101.com:
Part 1
Part 2
Part 3