It looks like my boss has discovered an interesting incompatibility between the .NET Framework and the .NET Compact Framework (version 2.0).
We haven't actually confirmed this yet, but I'll describe the symptom and our suspicion about the problem now, and post a follow up if we find out what's really going on. If anyone else knows, or has alternative theories, please leave a comment 'cause I'd love to hear what you think.
Ok, so here's the background to the problem;
My boss has been working on a SmartDevice project in VS 2005. Specifically the project is designed to run on a custom build of Windows CE 5.0 on some hardware we've bought from Taiwan. Our problem has been that we've been unable to successfully build a version of CE (or even an emulator) that works. We've tried outsourcing this part of the project, but without any success. While we continue to try to build our own CE platform, development on our application software has continued. That's beside the point, except that it explains why we're building our project the way we are.
Since we have no CE platform or emulator (yet), we're building the (Smart Device) project, compiling it, and running the executable on our desktop PC's (running XP) to test it. If we really want to debug it, we compile it with debug symbols and attach the debugger to the exe after it's started. This has been working really well for us so far, and it should since exe's created with the compact framework are supposed to work %100 on desktop PC's with the full framework. As a side note, the compact framework is also installed on the desktop PC (it seems to have been installed with VS).
The problem we've discovered occurs when we add a web browser control to our Smart Device forms. The (full framework) .NET web browser control will only load in an application running in Single Threaded Apartment mode. This is normally specified in an application by applying the STAThread attribute to the Main procedure in Program.cs. Unfortunately, we can't find STAThread anywhere in our compact framework application or it's references (using intellisense or the object browser), and by default VS has marked the main method with MTAThread. We therefore presume STAThread is not supported in the compact framework.
The compact framework .NET version of the web browser control must therefore support applications with the MTAThread attribute applied. We tested this by creating a new SmartPhone application, placing a web browser on it's form and running it inside the standard SmartPhone emulator. The application and it's form loaded fine, and the web browser control didn't throw any exceptions. We couldn't run the binary for the SmartPhone application on XP though. I'm not sure if this is because of the problem we've discovered, or because SmartPhone applications aren't supposed to run on XP.
In any case, if we run our actual SmartDevice application on XP it crashes as soon as we load the form with the browser control on it. We get an exception stating the control cannot run in a process that is not a single threaded apartment.
- We can load and use the (compact framework) browser control in a project running under an emulator;
- We can run and load our application on XP if we're not using the web browser control;
- The full framework web browser control will only run in STA mode but the CF control appears to support MTA...
We suspect the problem is that at runtime the application is loading the full-framework version of the web browser control - even though that's not the one we referenced in the project itself. Since the controls are in fact different (the STA/MTA issue), this causes the application to crash. The end result is that compact framework applications aren't necessarily executable on desktop operating systems with the full .NET framework.
If this is the case, it's possible we could implement some kind of assembly binding policy to force the application to use the compact framework control, but I haven't done much work in this area and I'm not sure how, or if it will work with a compact framework executable.
Of course we're just guessing at what the problem is. If we had a working version of Windows CE we could try our application on it and see if it ran. If it did, that would go along way to proving the problem wasn't with our application or code, and that it is a compatibility issue. Until we can do that though, we can't be sure what the issue is.