In this post , the .NETCF Team discusses the existing start-up policy, configuration options and the change that we are planning to bring in the next release to seeks inputs from the .NETCF developer community.

In CF 3.5 and earlier, by default, Vn application runs against Vn if Vn exists on the device. It can be promoted to Vn+ to take advantage of performance improvement or bug fixes using an app config file.

We are planning to change this default behavior in the next release. We are proposing that the Vn application runs against Vn+ where Vn+ is the latest and greatest CF runtime version present on the device with the compatibility mode of Vn. This way the applications don’t have to repackage with configuration changes on newer versions to get the benefits on the new release and at the same time, the app would continue to run with the compatibility mode with which it was built so there are negligible chances of app compatibility breakage.

Flowchart representation of proposed start-up policy





1. Vn Application on Vn

Be default, Vn application will run against Vn if Vn is the highest version present on the device

2. Vn application Auto-Promoted to Vn+

By default, Vn application will get promoted to Vn+ with Vn behavior if Vn+ is the highest version present on the device and would run in Vn compatibility mode.

3. Vn application restricted to Vn

There will be likely cases, though hopefully few, in which a Vn application will not work on Vn+. In these cases, the customers would want to use application configuration files to limit the application to run on Vn only.

4. Vn application promoted to Vn+ with Vn+ behavior

When a Vn application runs on Vn+, the default behavior is that it runs with Vn coercions. The customer can configure the compatibilityVersion in the app config file to make the application run with Vn+ behavior.

There may be situations in which a Vn application desires Vn+ behavior (such as when bug was fixed in Vn+ and the application writer desires the bug fix even though we coerce it for Vn apps). This, admittedly, is a less likely scenario as if an application writer is aware of Vn+ behavior; they will likely be using Vn+.

It is, however, possible that someone will write a Vn application that makes use of a Vn+ component which relies on Vn+ behavior. This scenario is indistinguishable from the previous from a runtime perspective but is far more likely from a customer perspective.

5. Vn+ application demoted to Vn

This is not a supported scenario, as Vn+ assemblies will not execute on the Vn runtime due to changes in metadata and compiler versions

How to configure the runtime and app compat behavior:


The new changes in the startup policy are not frozen and the intent of the post is to reach out to the community to get their feedback. Please do share your feedback at comments to this blog.


The .NETCF Team