High-Tech Humanities

I recently encountered this bug, Cannot Deploy Smart Device Application After You Remove and Reinstall ActiveSync, with the following error message, Error: Cannot establish a connection. Be sure the device is physically connected to the development computer

To fully understand this bug, one must first understand that there are a set of requirements needed to debug a device, and that those requirements may be fulfilled by installing Visual Studio 2003 and ActiveSync in a particular order. Add to that a registry modification or two. When the requirements are met, a developer follows a few more configuration steps (I myself [must] use SDeviceAuthUtil) to allow Visual Studio to communicate with the device, then hits the debug button and off they go debugging their application. However, one day, this connectivity may stop working for no particular reason. At that point, KB 813579 comes into play because any attempt to debug (and sometimes deploy, as was my case) is met with failure. ActiveSync continues to work, the device continues to have no problems with a network connection, and you can even ping the device from the development workstation. But Visual Studio 2003 has had enough and refuses to play anymore.

And, if one were to follow the instructions in that article to recover from the bug, then that person will spend the next several hours or more uninstalling and reinstalling, only to find out that the fix may or may not work.

For a long time, I knee-jerk reaction to development problems has been to search Deja News (now Google Groups) for others who have had that problem primarily because I have found the KB articles to either be too hands-off in providing a solution (culminating in a "Declaration of Re-installation") or too modularized (eg: circa twenty KB articles all describing the same problem, each with a different solution). I have neither the time nor the inclination to routinely re-install software that may or may not fix a specific problem, and have found better success by locating people who have had the same problem.

In this case, I spent several late-night hours trying to find a solution, and returned to the KB Article because at some point one must admit that spending ten hours running in a circle is not a good use of time if spending two hours re-installing might work. So, I tried the Visual Studio 2003 re-install. No good.

Back to the groups. In one group, I found a link to a forum topic on OpenNETCF.org which included a number of helpful suggestions. From the suggestions offered in the topic, I went back and created my own winning combination.

Now, I want to instruct the astute reader that my particular experience with this bug may not apply to them because after seeing the number of people with this problem, and no specific solution, I don't want to get anyone's hopes up. First, here is a brief list of things I tried that didn't work: a hard reset, re-installed Visual Studio 2003, un-installed and re-installed the Smart Device components of Visual Studio 2003, uninstalled and re-installed ActiveSync (which turned out to be 3.5), applied the ProxyPort.reg file, applied a copy of ProxyPort.reg from another machine, applied a copy of ProxyPort.reg obtained from the previously cited OpenNETCF.org forum topic, and uninstalled and re-installed ActiveSync 3.7 (which didn't fix the problem .. yet).

Then, I re-read the forum topic, and added my own two bits two it. This, folks, after all of the previous efforts (so I don't know if any of those attempts helped at all, but I doubt it), was the winning combination: un-installed ActiveSynce 3.7, applied ProxyPorts.reg from the Visual Studio CE Utilities add-on, re-installed ActiveSync 3.7, verified registry entries were correct, restarted machine for posterity, started Visual Studio 2003, started the SDAuthUtilDevice.exe on the device, ran SDAuthUtil from Visual Studio (I had tried this much earlier in my attempts, but it had failed), and this time it connected.

While I am not certain which specific steps are necessary - is it just the registry entries, or a combination of the registry entries and then installing ActiveSync after applying them, or something else - I do know that early on I had checked the registry and found that my entries for ProxyPorts had been wiped clean. Also, the order of installation was crucial because I had tried various versions of these steps, such as installing the ProxyPorts after installing ActiveSync and then trying to run SDAuthUtilDevice, but that wouldn't work.

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.