In the first three parts of this series, I discussed the preliminaries of using cordbg to debug NetCF projects: getting connected, debugger modes and unsupported commands. In today’s installment, I want to introduce NetCF v2.0 beta 1 and the changes we have made with regards to debugging with cordbg. Please note that the information contained in this post is relevant to version 2.0.40607 of the .NET Framework SDK and is subject to change.
For those of you who have downloaded beta 1 of the new SDK, you can now build and debug .NET Compact Framework applications without needing any other tools. All the assemblies and tools to build and debug are included in the SDK install.
Launching your application for debugging
After installing the NetCF beta build, you will need to copy cmtnpt_tcpacceptv2.dll from the Program Files\Microsoft.NET\SDK\v2.0\CompactFramework\WindoesCE\[wce400|wce500]\<architecture> folder to the \windows folder on your device. Typically, the Program Files folder will be on your C: drive. The value <architecture> will depend on your target device’s process or (armv4, mipsii, x86, etc).
The next step is to launch your application (as described in Part I):
Connecting to the application
The connection command is simplified thanks to the new transport (cmtnpt_TcpAcceptV2.dll) no longer requiring authentication.
conn <ip> [<port>]
New debugger modes
The new version of cordbg provides some new modes, none of which have any bearing on .NET Compact Framework projects. These new modes are listed below as an FYI.
NetCF does not support Edit-and-Continue or Just-My-Code debugging.
While the SeparateConsole mode is technically supported, it does not impact NetCF debugging. NetCF applications run on a remote device and their console output is not sent back to the debugger, so this mode has no real bearing on NetCF.
I have been asked more than once, for a list of the new cordbg commands that NetCF supports… Well, here are the important one.
And now, in this corner….. SETIP!!!!!!!!!!!!!!!!!!!!
Yep, you asked for it and you got it. NetCF v2 (beta1) supports changing the instruction pointer while debugging. You can now, retry operations, skip code and basically get into almost as much trouble as you want to
What trouble, you may ask…. For those who have never experience the joys of leaping around randomly within your code, if you skip the wrong block of code, you may miss any required initialization code and render your debugging nearly useless.
Please note that you cannot set the instruction pointer outside of the function your application is currently executing. If you try, you will see:
Invalid line number
As for the new and unsupported commands, the list is below:
cr[eatehandle] Create weak handle given a value
deleteh[andle] Delete a given handle
disp[osehandle] Dispose a given handle
its determine if address is a stub
jmc-scl Set classes to user/non-user code
jmc-smod Set module to user/non-user code
jmc-sf Set functions to user/non-user code
listh[andle] List existing handles
ze[nc] Perform an edit and continue
zE[nC] Perform an edit and continue
zb[reakForEnC] Compile source for an edit and continue
zc[ompileForEnC] Compile source for an edit and continue
zgaf Prints all the active functions in current threads stack
That’s all for today… Enjoy the beta!
This posting is provided “AS IS” with no warranties, and confers no rights.