Windows CE – Developing applications for "retail" devices.

When writing a managed application today against a debug (or retail) Windows CE 5.0 device (using Visual Studio 2005) you need to run two applications on your target device (conmanclient2 and cmaccept) before connecting VS to your target – for native applications you can use eMbedded Visual C++ 4.0/SP4 which can piggy-back your existing Platform Builder connection.

ActiveSync provides the link between the desktop and Windows Mobile devices for application development and debugging – but what about shipping CE based devices ? – the majority of embedded devices are shipping without support for ActiveSync, perhaps don’t have serial or USB support on the device and may just have a TCP/IP connection (and note that TCP/IP ActiveSync hasn’t been around since version 4.0) – so, given just an IP address how do you write/deploy/debug applications against a retail CE device – from eMbedded Visual C++ 4.0 this was of course possible using a simple command line on the device, clicking your heels together three times and spinning around in your chair – here’s how the command line looked, simple, eh!


With CE 6.0 both native and managed application development will be supported in Visual Studio 2005 – this means that you will have to run ConManClient2 and CmAccept on your device before connecting Visual Studio 2005 – also note that you have three minutes in which to connect VS 2005 to your device otherwise the connection times out. For device development and debugging this seems ok, and “open” devices like Pocket PC/Smartphone have ActiveSync to host their Visual Studio development/debugging connection – but what about CE based ’embedded’ devices – do you have much of a need to write/deploy/debug applications to a shipping ’embedded’ device ?

– Mike

Comments (4)

  1. Mike Dimmick says:

    The devices I generally work with are open devices, even the custom CE platform ones.

    Windows Mobile 5.0 is seriously annoying for trying to develop networked applications which use cell-based or WiFi radios. Turning off the radio stacks (disconnecting an active GPRS connection or disabling the WiFi adapter) when ActiveSync connects makes it impossible to debug some things, for example I can’t figure out how to get our UDP-based protocol to work through Desktop Pass-Through, and of course timings and bandwidth are massively different between GPRS and DTPT. My current technique is hit-and-hope: develop and test using a Pocket PC 2003 device, then validate on Windows Mobile 5.0.

    A word of caution when developing GPRS applications for Windows Mobile 5.0: the Autobind LSP can bite you. Why? Because a socket can only be bound _once_. If you disconnect from the GPRS network, then reconnect (for example if the device is suspended), you won’t necessarily get the same local address back when you reconnect. Your existing socket will not work, because it won’t be associated with any network interface on the system. You need to create a new socket.

  2. Ryan Casillo says:

    Windows CE 5.0 presented several challenges deploying to our embedded systems. In our development environment we wanted to be able to download our latest application builds and OS images to several CE boxes. First of all, this was not practical using a serial connection due to performance constraints. In addition we wanted to be able to remotely deploy our software to systems in other locations, which you can’t really do by serial connection. Having the ability to deploy using ActiveSync via TCP/IP would be ideal in our situation. Also, we didn’t want to have to run cMaccept every time we wished to deploy in our development environment, so we added a registry entry to disable this security. Another challenge for us was being able to deploy to our systems from a box that did not have Visual Studio installed. It would have been great if the Device Command Shell (ce.exe) was able to this without piggy-backing on Visual Studio (not to mention it broke our solution until we uninstalled it). So in the end, we ended up with a simple utility to send our files via FTP and move them to the correct remote location via Telnet.

  3. Bruce Casner says:

    Not only do I want to be able to do some debugging and new image uploading, mine is a headless device, which makes it difficult to type command line parameters.

  4. Adding the Platform Manager component to a CE 6.0 operating system design will generate build errors