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!

CEMGRC.EXE /T:TCPIPC.DLL /Q  /D:192.168.2.1:5913

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

• Anonymous
  August 14, 2006
  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.
• Anonymous
  August 15, 2006
  The comment has been removed
• Anonymous
  September 12, 2006
  The comment has been removed
• Anonymous
  November 25, 2006
  The comment has been removed