For those of you who have deployed .NET CF 1.0 applications, you might want to consider running those applications under .NET CF 2.0. Remember that if both .NET CF 1.0 and .NET CF 2.0 are installed on a device, applications compiled under .NET CF 1.0 will use the .NET CF 1.0 runtime.
We know that .NET CF 2.0 provides a much richer class library and enhanced language features as compared to .NET CF 1.0 but that’s only part of the story. The .NET CF 2.0 runtime itself has undergone substantial improvement. The .NET CF 2.0 CLR offers much better execution speeds, faster memory allocation and more efficient memory recovery then the .NET CF 1.0 CLR. These CLR improvements are available to .NET CF 1.0 applications without requiring any changes to the code.
There are basically 3 ways to have your .NET CF 1.0 application execute with the .NET CF 2.0 CLR.
- Recompile the application under .NET CF 2.0 and distribute the recompiled executable
- Remove .NET CF 1.0 from the target device leaving only .NET CF 2.0
- Distribute a configuration file that tells the executable to prefer .NET CF 2.0
The first two choices have obvious limitations. Distributing a new executable can be problematic for any number of reasons and the new .NET CF 2.0 executable will not work unless .NET CF 2.0 has been installed therefore you run the risk of breaking working installations. Removing .NET CF 1.0 can be difficult especially if you don’t control you customer’s execution environment; also most Windows Mobile devices have .NET CF 1.0 installed ROM so that it can’t be removed.
The third choice is certainly the easiest and least risky. Thanks to the addition of configuration file support in .NET CF 2.0, we can distribute a simple configuration like the following.
<configuration>
<startup>
<supportedRuntime version="v2.0.5238"/>
</startup>
</configuration>
Placing this configuration file in the same folder as the executable and giving the file the same name as the executable file followed by a “.config” (ex. Myapp.exe.config – same config file naming rules as the full framework) overrides the application’s compile-time association with .NET CF 1.0. With this config file, the application will run under .NET CF 2.0 if it’s present on the device but will still run under .NET CF 1.0 if .NET CF 2.0 has not been installed because .NET CF 1.0 doesn’t support config files therefore the config file is ignored.
There’s more information and additional references on runtime version control with config files on the NetCfV2 page on the Channel 9 Windows Mobile Wiki
A word of caution
This probably goes without saying but I’ll say it anyway. You’ll want to be sure to fully test your application running under .NET CF 2.0 before distributing the config file to your users. Microsoft has done a great deal of testing to insure .NET CF 2.0 backward compatibility with .NET CF 1.0 but every situation is different.
To my knowledge there have been two cases identified where code that runs correctly under .NET CF 1.0 fails under .NET CF 2.0.
- In some cases a p/invoke call that uses the Win32 FindWindow function to get a .NET CF Window’s window handle will fail. This is because some of the .NET CF windows have changed their Win32 Window class name. Daniel Moth provides an excellent discussion of this issue on his blog.
- An attempt to make a Form a child to another control now fails under .NET CF 2.0. This worked under .NET CF 1.0 (although probably wasn't intended to). For more info on this issue, checkout this newsgroup thread.
Although the above issues may not be common situations (Microsoft warned us not to rely on the Window class names), they are show stoppers for any application that has them. For obvious reasons, you want to be sure you have no “show stoppers” before asking your customers to upgrade. ;-)
Posted
Jan 08 2006, 10:26 AM
by
jim-wilson