VS2005 and Windows CE 6.0 Debugging

2
votes

Firstly, I'm running VS2005 SP1 and Windows 7 Ultimate.

I'm trying to debug an application of mine on a device running Windows CE 6.0.

I have done a lot of digging and it seems a large amount people have a similar difficulty but it's caused by a broad range problems and if there are any solutions, none of them have helped me so far.

My problem is that I cannot target WinCE 6.0 when I debug. The only devices I am able to target are:

  1. Pocket PC 2003 Device
  2. Windows CE 5.0 Device
  3. Windows Mobile 5.0 Pocket PC Device

When I attempt to simply target "windows ce 5.0 device" I get errors, for example:

Post-deploy error 0x00000001 returned after calling '\Windows\wceload.exe /noui \Windows\System_SR_enu.cab'.    Device Connectivity Component

I have found installation processes for building application on VS2005 and WinCE 6.0 and I followed the guide with successful installations. The process was as follows, Install:

  1. VS2005
  2. VS2005 SP1
  3. MSDN (Optional)
  4. WinCE 6.0
  5. WinCE 6.0 Platform Builder SP1
  6. WinCE 6.0 R2
  7. WinCE 6.0 R3

Any idea on possible solutions?

Thanks

1
visual-studio-2005windows-cetarget-platform

1 Answers

2
votes

Have you installed a CE 6.0 SDK? I think that's your missing piece. You can circumvent the error you're seeing with a 5.0 target by manually copying the indicated resource CAB to the device and running it before deploying your app.

EDIT

The SDK, generally speaking, would come from the device OEM. If, for some reason, you can't get an SDK from the OEM then you can install any SDK targeting the same processor and it will work. Bear in mind that the SDK can "filter" out libs and headers, so if you have a trimmed-down SDK, then you may not have some of the headers and libs you want (though you can always dynamically load the functions you need). Likewise, if the target device doesn't have a feature that's in your SDK, you may be able to build and link and app that won't run on the device. If the device has custom API (for I/O or whatever) that typically comes with their SDK, then those would also be missing if you use a different SDK. Still, it's better than nothing.

Myself, I have a couple SDKs that I build for x86 and ARM that just have pretty much the kitchen sink thrown in. I just install and use those SDKs for most device development.