views:

46

answers:

1

I'm sort of conceptually designing a plug-in I'd love to have here. What I'd want is to be a able to tag line in my code (something like how breakpoints are added) and then get a trace log of when execution runs though them. Rather than set breakpoints (because they don't work outside the debugger), I'd rather that inside the compiler, the extra logging be added so the AST.

The main point would be to compare different runs of a program; it crashes if I do A but not if I do B and most of the code should be the same so where is it diverging?

Right now I'm doing this with file IO and a diff tool; it works but is a bit clumsy.

I guess the question is: Could this be done and has something like this been done?

+1  A: 

I don't know of anything that exactly fits your description. However...

For debugging-only use, Visual Studio 2010 has "tracepoints". These are added in the same way as breakpoints, but rather than stopping the program, they output some text to the debug output. Because they're set in the debugger, they don't affect your source code at all.

If you want to trace activity in a release build, then just add System.Diagnostic.Trace.WriteLine() calls into your code. These can be controlled using TraceSwitches, so they can be disabled by default and only turned on if you need extra information to diagnose a problem. Unlike Debug.WriteLine() calls they are included (by default) in release builds as well as debug builds. Note that these trace calls do cost a small overhead even if the traceswitch is disabled, so avoid using them in performance critical regions of your code.

Jason Williams