High-Tech Humanities

So much for the intuitive approach. I went back and read the tutorials and directions for the SDAuthUtil, and came across the two bits that made the difference. First, the SDAuthUtil on the development machine sets up ConmanClient on the device, the SDAuthUtil is closed, leaving ConmanClient running. Second, rather than selecting the emulator as the device, the actual device is configured with the IP address used for the SDAuthUtil, or that of the device. Then the application can be deployed from Visual Studio 2003 to the device, as expected.

Understanding that everything I've encountered was documented somewhere, it was a bit of a hassle and it still is quite a round-robin starting ConmanClient through SDAuthUtil. However, I was able to get the application running after having to install a String update for the compact .NET framework on the device, which only happens the first time I deploy the application to the running image.

Now, it seems pretty straightforward working on the app in Visual Studio 2003. Instead of running a debug build on the local machine, it runs on the device. Neat.

On the subject of installing Windows CE .NET multiple times to recover from installation errors, it appears that I have found a winning combination. Keep in mind this was after I uninstalled a previous version, and didn't manually remove the Virtual Switch driver as mentioned in the release notes - So, I can't really heap any blame on anyone other than myself, but it was a bit of obtuse thinking to make that a sometimes manual uninstall.

To restate the problem: A CE OS running on the emulator would not be assigned an ip address from my local DHCP server, preventing me from running SDAuthUtil, which prevented me from deploying my in-development application from Visual Studio 2003. I could consistantly install Windows CE .NET, usually without running into error 21337. The one time I did run into it, though, I could never recover from it because the emulator would then always fail to start. Even after following the uninstallation steps in the release notes - and here I can only guess as to the source of the problem - the active CE OS would not run through the Virtual Switch driver, and therefore would wind up with an internal 169.* IP address on subnet 255.255.0.0, instead of a 192.* IP address on subnet 255.255.255.0 for my local network. If I was supposed to be able to access the 169.* address from a different subnet without some other sort of NAT on my development machine (feel free call BS on that if I'm not describing this correctly). The documentation refers to accessing the 169.* address, but I never could, which lead me down the path of investigating the Virtual Switch.

After going through a number of installs and uninstalls, I tried a new tactic. I installed, made sure the Virtual Switch driver was enabled (it wasn't being set enabled upon installation, for some reason), then went right into an uninstall. I removed the CE Utilities for Visual Studio 2003 just to be sure. I restarted the machine and then made sure there were no registry keys, devices, or drivers left from uninstalling. This time, there were none. Next, I made sure there were no running applications or services, then installed again. This time, I didn't run into the 21337 error (I had run into the error on the previous install and repair attempt). Since I didn't run into the error, I didn't use the repair option. Next, I opened up an existing CE OS I had built, and tried running it. No luck. I checked to make sure the Virtual Switch was enabled, which it wasn't. I shutdown Platform Builder and the running emulation, enabled the Virtual Switch, then started it again. This time, it worked.

Next up: Application ConmanClient.exe has performed an illegal operation.

I have to admit that I like Visual Studio 2003 and Windows CE .NET (Platform Builder 4.2). There is a lot of good documentation and for the most part I've been able to start working on CE .NET projects fairly quickly. Oh, wait, except for a couple annoying little bugs. In order to (more easily) develop a .NET application for a CE device, one way to deploy the in-development application is with the SDAuthUtil application. Since I'm working with the emulator at the moment, this seemed like a relatively straight forward method: deploy the utility to the running CE OS(if it's not built into the image), run it, then run the counterpart on the development machine.

Heaven forbid you should shut down the Remote File Viewer after shutting down the emulator, though, because that will leave the process running. Even if you are able to close the viewer, you will be left with a few processes that will either prevent the viewer from being started again, or prevent the debugger from connecting to the emulator, and thus keep the OS from launching through Platform Builder. If after shutting down platform builder, the emulator, and the viewer (if you haven't killed the process), you would still see processes be cemg.exe, cepb.exe, and PBEMUL~1 in task manager. Time to kill those bad boys, too.

I came across this problem because I was having another problem. I had installed the beta of Windows CE .NET, then uninstalled it to install the final copy, except forgot to completely read the 148K release notes, in which it is mentioned that it is necessary to remove some registry keys and devices for the emulator even after uninstalling the product. I don't know for certain, but I believe this was the cause of my primary woe: I could configure the CE device for an outbound-only NAT connection, but not a fixed IP (at which point it picks of its own IP through a DHCP server, if so configured).

Round and round I went, and could only find information about uninstalling, removing the devices that aren't uninstalled, and then re-installing the product. Except, I'm one of the lucky few who run into the 21337 error, which means a double-install; install with the error, then repair the install. This isn't as straightforward as it sounds, though, because I may or may not have to reboot after the first install, and then, according to the various release notes and technical documents, I may have to repair the installation multiple times until I don't get the error. And, I have. Apparently, all of this was done to get the Virtual PC Emulated Switch driver, which now that I think about it, I didn't have the first time.

Now, I have several gigabytes of test CE builds from trying to figure out if I was missing a key networking module. Since I couldn't access the running emulation from my local network, I couldn't use SDAuthUtil, and therefore I couldn't test my CE app from Visual Studio 2003 (I could build then deploy it through the remote file viewer, but what a long way around). Apparently it was a product installation issue on both machines I attempted a product installation. At present, and after one more installation on Windows 2000, it works. After several installations and uninstallations, plus several repairs ending without error, the networking issues persist on a Windows XP machine. I can only assume it is still related to the Switch driver.

So let that be a lesson, or something.