Well the obvious answer would be: “if you wrote this magical piece of code and it turns out to be unexplicably slow”
While that’s a correct answer (after all: it’s free and it’ll point you in the right direction, nothing to loose right ?), there are some other less obvious scenario’s why Codetrack might be your new best friend.
Let me tell you about a few:
The one were your code acts weird and your hands are tied
(aka: the ‘please kill me now’ moment)
Every developer sometimes has this piece of code that works fine locally and for some reason it just doesn’t when you deploy it on a production server or at your clients machine.
Of course, karma doesn’t stop there: on these machines there’s no debugger and you’re not allowed to install one. Remote debugging ? Nope: firewalls all over the place and security won’t allow you to bypass them. Oh and did I mention you get 15 minutes tops on the server/pc ?
That’s where Codetrack might just save your day. There’s no installation required, you can just copy paste it to the evil machine do your thing and leave without a trace (pun intended).
Of course you’re not going to be interested in the performance this time, you want to enable the timeline feature and if needed include arguments. You can start by just tracing your own code using the filters, and if necessary retry tracing all methods (including the .NET FW itself)
You can even pause the tracing when starting your app and hit record right before things start to go wrong (so you don’t drown in all the data afterwards).
If all goes well you can now literally browse through the execution of your code, zooming in on every interesting call and check what arguments and returnvalue it has.
By the way: there’s no need to do it on the machine on which you took the trace, you can just as well do it on your own laptop, with a soothing cup of joe.
This scenario happened to me quite a few times, and I was always able to find the cause of all evil using Codetrack.
The one where your breakpoint doesn’t get hit
A while ago there was a new colleague and of course the first thing the poor guy had to do was to try and fix some bugs, so he could get to know the codebase.
In the evening there was just him and me sitting at our desks and he came up to me asking me if I could tell why his breakpoint wasn’t getting hit. Unfortunately I didn’t know anything about that piece of code either. But the guy had a really rough day with a bunch of serious issues in his private life, so I really wanted to help him out (well I would’ve helped anyway :-))
So we checked which paths led to the method in question, to try and see where we took the wrong exit. As you might guess this method got called in a gazillion ways and we didn’t have the time to start digging.
So I fired up codetrack using the timeline option. Within 2 minutes we found the reason why the breakpoint wasn’t hit. I didn’t fix all of his problems, but at least there was one less on the list. (btw: luckily all of his other problems are solved too)
The one where you want to know how they do it
Sometimes you see a cool piece of .NET software and you’re really curious how they made it. Or you have to get familiar with a new codebase.
Of course there are great tools like Ilspy, dotpeek, reflector and lots of others which let you easily peek into the code.
And that’s a great start. However sometimes it would be easier if you also could see what the execution flow of the code is or what arguments are passed to a method.
Also here codetrack can assist you and save you some time. (btw the Ilspy package is also used in codetrack and shows you the code as you select a call)
The one where the debugger fixes your problem
Sometimes you’ve got this problem and when you attach the debugger, all of a sudden everything runs just fine.
This might be because the debugger slightly alters the timing of your method calls, hiding the issue for example.
Well depending on the level of detail you select in your options, Codetrack might just be faster and still give you the information you need…
I used to do a lot of WPF stuff and some of the tricky things to debug is what happens when for instance a combobox gets expanded or closed. If you try putting a breakpoint in your code, your ui loses focus and you get a completely diffferent behavior. This is also a situation where codetrack can come in really handy !
Let me know when Codetrack made your day
There are probably tons of other examples or situations where Codetrack can make your developer life easier. And I’m pretty sure lots of handy features are just around the corner 😉
Oh and did I already mention it’s completely FREE ????
Get the latest version of Codetrack at http://www.getcodetrack.com
I’m really curious about your own Codetrack adventures, so don’t hesitate to share them with me !