Wed, November 17, 2004, 09:58 AM under
MobileAndEmbedded
One of the first complaints .NET desktop developers have when targeting the CF v1.0 for the first time is "
Debug.WriteLine doesn't work".
The fact is that with Smart Device projects the debug output does not come back to Visual Studio; rather it goes to the console on the target device. It is true that Debug/Console WriteLine statements do not appear when debugging on PocketPC devices/emulators, but this is not a CF issue; it is rather due to a lack of console on the PPC platform. Debugging a CF app on the CE emulator or a CE-based device results in the display of a console window
on the target with the debug statements. Note that even on a CE device, if you build it without the console (cmd.exe) you will get no debug output (I should know, since I have accidentally run into that scenario when we ported from CE 4.1 to 4.2, but I digress).
So what can you do about it? There are a number of options and I will link to them in this entry, ready for the next time someone asks :-)
Add a console to the target, e.g.
this oneRedirect the output to a file, e.g.
like thisSend the output back to the dev machine, e.g.
like that or
thatOf course you could switch away from using System.Diagnostics directly and write your own logging framework. As you'd expect, this has been done before and there are a number of 3rd-party solutions, some of which may be too simple and others too complex for your project's liking. So here are some options:
MSFT offer the
Enterprise Instrumentation Framework, but I doubt it supports the CF.
I have met references to
log4net a few times, but
I don't think it supports the CF it is under the Apache license.
Over at the useful openetcf there is a
logging system, but I must admit not having played with it, and I don't know if it works on the desktop
For my own projects (CF and full Fx), I have been using a class I wrote years ago. Features include:
1. Just one file to include in your project. Only one class with static methods.
2. Use of the standard Debug class internally, so the output goes to VS console (desktop) or device's console (CF)
3. CSV formatted output (inserting additional info such as timestamp etc.)
4. Redirection of output to a HyperTerminal on the desktop, when running a debug OS on your CE target
5. Support of 3 severity levels (Info, Warning/Assert and Error). Auto detectable based on project configuration (e.g. DEBUG, TRACE)
6. Further configuration available via TraceSwitch (both platforms) and optionally via config file (desktop only)
7. Writing to a file (on both platforms, path and name computed internally also take into account COM Interop clients)
8. Rolling of the filename, thus preserving debug info between different runs of the application
Feel free to play with
it.
If you are interested in the subject of tracing, you will love a new feature in Whidbey: Tracepoints. I was going to write about it, but many others have done so already [
1,
2,
3]
UPDATE:Visual Studio 2005 (and .NET Compact Framework v2.0) support Debug.WriteLine :-D