Site Sections
Posts
80
Comments
214
Trackbacks
0
June 2009 Entries
Visual Studio application debugger
Lake Maggiore seen from the small village of Armio, Italy
You just finished that BSP, developed all required drivers and low-level code, configured hive-based registry, defined your device's memory layout... and now it's time to develop your application to leverage all that low-level/OS code and provide great services to your device's end users.
You may want to use visual languages like C# or VB.Net to develop it, using the power and ease of usage of the .NET Compact Framework or, you want (or need) to use C and C++  but you want to use advanced libraries like ATL,WTL and MFC.
The application development environment of Platform Builder is limited to C/C++ and APIs, it does not support visual and managed development. You can use Visual Studio 2005, 2008 (and hopefully soon 2010!) to develop your application, working will al the RAD tools and features that desktop developers know and appreciate.
To start developing in "application" mode, you should generate an SDK based on your OSDesign features, install it on your PC, and you are ready to begin application development.
If you don't know what an SDK is and why it's so important for application development you can find some information on the CE Base team blog here: http://blogs.msdn.com/ce_base/archive/2006/12/14/What-exactly-is-an-SDK.aspx and here http://blogs.msdn.com/ce_base/archive/2007/06/01/developing-applications-using-windows-ce-sdk.aspx.
Developing an application means more than writing code and building it... you'll have to debug your code running on the device and this means that you have to find a way to support Visual Studio debugger running inside your Windows CE OS image.
Platform Builder uses a kernel debugger, built into the OSImage when you enable KITL and Kernel Debugges options, and allow it to debug all the processes and drivers running on the connected device. Visual Studio instead uses and application debugger that can debug a single process (application) and this debugger is not included in the OSImage.
To be able to debug a native or managed application running on your device with Visual Studio you need a TCP/IP or ActiveSync connection and the debugger client up and running.
If you can connect to your device using ActiveSync the transfer and startup of the debugger client are handled by Visual Studio automatically and you don't need to configure anything.
If you device does not support ActiveSync, things are a bit more complicated.
Visual Studio remote debugger is composed by two executables (CMAccept.exe and ConManClient2.exe) and some helper dlls.
Those files are (well) hidden inside your Program Files\Common Files\microsoft shared\CoreCon\1.0\Target folder on your PC (the folder name may be localized if you are running windows in languages other than english... just to make the search a bit more interesting).
Here you can find a wince400 directory (it seems that the debugger is quite backward compatible) and inside it one directory for each of the CPU architectures supported by CE.
To be able to debug applications running on your device using Visual Studio integrated debugging features you have to include CMAccept.exe, ConmanClient2.exe, eDbgTL.dll and TcpConnectionA.dll inside your OS image (or copy them to a mass-storage device accessible by your system).
You may also want to include clientshutdown.exe, that will allow you to close a debugging session (sometimes you need to do that if the debugger on PC side is not working).
On the development PC you need to configure the IP of your device using the DeviceTools\Devices page of the VisualStudio options dialog.
To estabilish a debugging connection you need to execute ConManClient2.exe on your device, then launch CMAccept.exe and in less than three minutes, activate a connection from visual studio IDE using the "connect to device" command or using on of the deployment options that you can find inside the build menu.
Launching the debugger client files each time you need to debug can be quite annoying and the three minutes timeout of CmAccept can be useful from a security point of view, but not so important if you are working inside a close network or with a crossed network cable.
This small PB subproject (http://cid-9b7b0aefe3514dc5.skydrive.live.com/self.aspx/.Public/VSDebugger.zip) provides a way to include VS debugger files inside your OS image, launch them on device startup and allow you to quickly connect and reconnect to your device from your development workstation.
Unzip the file and add VSDeugger.pbxml project to your own OSDesign using the "project\add existing subproject" menu command and enjoy the conforts of application development!

P.S. remember to remove the subproject when you build an OS image for production devices. Leaving the VS debugger enabled will allow full access to your device OS and filesystem from any PC where VS2005 and VS2008 are installed!
Posted On Friday, June 12, 2009 6:30 AM | Comments (1)
Toradex logo

Cookies in Use
Archives
Post Categories
Links
Tag Cloud