OpenNETCF and Windows Embedded Standard O/S - compact-framework

Question

If I have an application that is written in .net Compact Framework (and runs on Windows CE) and is theoretically compatible with Windows Embedded Standard O/S, would it still be compatible if it makes use of OpenNETCF functionality?
Things like running .exe files with help of OpenNETCF for example. I am assuming that OpenNETCF uses P/Invoke under the hood, which might make the application incompatible with other OS than Windows CE.
I don't use P/Invoke in my code, but I can't asnwer for sure whether OpenNETCF does or does not.
.net compact framework 2.0 and windows embedded standard

Answer 1

OpenNETCF does use P/Invoke extensively.
It is effectively a wrapper for some core OS functionality in Windows CE and its derivatives, that is not otherwise implemented in the Compact Framework. In practice this means extensive P/Invoking of coredll.dll; the basic OS module for Windows CE.
Windows Embedded Standard is Windows XP. For this reason I would not expect you to be able to use OpenNETCF.
Depending on the version you're using you may be able to get hold of the OpenNETCF code here (or buy the latest of course), and see what's going on under the hood. Also, what you may find is that the calls you are making to the OpenNETCF are actually implemented anyway when compiling for Windows Embedded Standard.
One way to approach this is to make another project to target this platform, containing exactly the same code files, but no reference to the OpenNETCF, then work through fixing the compile errors.
You can add a Conditional compilation symbol to either the CE project or the Windows Embedded project then fix the errors like so (This example is not for OpenNETCF, but you get the idea):
public static string ExecutingAssembly
{
get
{
#if WindowsCE
return Assembly.GetExecutingAssembly().GetName().CodeBase;
#else
return Assembly.GetExecutingAssembly().Location;
#endif
}
}
Obviously you will then have to create a build for each platform as the outputted assemblies will now be different.

Answer 2

As Chris points out, the SDF makes heavy use of coredll P/Invokes. That's not to say everything does, but it's certainly a minefield. I tend to have a CF project and a FFX project and places where I have overlap I use aliasing, like this:
#if WindowsCE
using Thread = OpenNETCF.Threading.Thread2;
#else
using Thread = System.Threading.Thread;
#endif
Then in the code you just do your normal
var thread = new Thread(...);
And things work out.
Now ages ago we did start an interesting side project of creating a coredll "shim" for the desktop. What that means is that a p/invoke to "coredll" on the desktop would actually call that DLL, which would in turn marshal the calls off to kernel32, user32 or whatever. Our testing for what we implemented (and there's a fair bit there) showed that it worked just fine, so if you're using a limited subset of APIs, just dropping it on the PC might make the CF assembly "just work".