.NET debugging tools - comparison
Nowadays, it is difficult for us to imagine that we could create any significant project without access to a specialized IDE. Increasingly, we also reach for advanced debugging tools. In this article, we'll try to introduce you to several .NET technologies that can support your team in useful code debugging. But, what should you pay attention to while choosing a debugging tool? Check this comparison to find out!
Track the value stream effectively.
What is the most crucial factor of effectively localizing error cause? Understanding how the code works in detail and how it's executed. Every single tool supports the developer in this task in a different way. Some of them allow you to go back in the executions history, to understand why a particular state has appeared. While choosing your debugging tool, look around at those, which gives you the ability to not only inspect specific events but also to take a look at the whole structure. For example - a timeline with a history of execution of your code:
What happened in the application:
What you could do in Visual Studio:
Debug on production
As we all know, there are two types of bugs. Those detected at the development stage, and those which appear on production. While choosing a debugger, you should check what kind of support does it give you in debugging on production. Does it have the ability to gather data about what is happening on production, to detect bugs? Reverse debugging tools are equipped with such possibilities.
Will it help my DevOps team?
Another question, which you might ask yourself while choosing the debugger is how will the implementation of it affects DevOps. Will it support the whole process or disturb it? How does it influence individual DevOps elements:
Debugger for development
Debuggers are often considered as tools created to support growth. A good debugger should support the developer in each of the following debugging phases:
- noticing the error
- finding it’s cause
- fixing the error
Does the debugger give you the ability to inspect how did your changes affect the whole application system?
Debugger for QA
Do you probably wonder if a debugger can be a tool that helps testers? To answer this question, we need to think about what tasks testers are responsible for. Those are not only preparation of tests, but also creating detailed bug reports. There is an analogy in that - a debugger, not unlike the testers, is also responsible for providing the bug environment data. Therefore, why not use such a tool during the tests, to save time?
There is another factor which should be taken into consideration when choosing a debugger in terms of supporting testers. Code coverage is an important measure of tests effectiveness, so if debugger contains tools that allow you to look into this - that’s a big plus.
Does the debugger allow you to send detailed information about detected errors in a fast and easy way?
There is another factor that should be taken into consideration when choosing a debugger in terms of supporting testers. Code coverage is an essential measure of test effectiveness, so if debugger contains tools that allow you to look into this - that's a big plus.
Debugger for Operations
Monitoring an application and its health on production is one of the most critical tasks imposed on members of the DevOps team. Can the well-chosen debugging system support this vital task? The answer is yes. Keeping the terms of the SLA is much easier thanks to the constant monitoring of applications on production.
Would debugger support all kinds of .NET applications?
These days there is an unimaginable amount of technologies derived from .NET. SP.NET, ASP.NET MVC, ASP.NET Core, Xamarin, Entity Framework… we could go on like this all day. To be honest with ourselves – once we will learn some tools, we would like to use it as many times as possible. A good debugger can support your application no matter what technologies you have chosen.
Debugging Lambda functions
Only a few debuggers available online, giving you the ability to debug lambda functions. But why is it so difficult? While debugging them, you actually can't set any breakpoints! That sounds like the worst nightmare, isn't it? While choosing a debugger to consider if it's allowing you to debug under such exceptional circumstances.
Modern applications are incredibly complex systems. Many of them are multilevel, multithreaded, and multi-process. The search for an error root cause, in many cases, resembles looking for a needle in a haystack. Especially those multithreaded require great developer knowledge about the functioning of the entire system. Fortunately, some tools allow him to look at individual threads. How does it work? Check this recording from Visual Studio to find out:
Description: Threads inspecting inside IDE
Why not make a search engine for bugs?
There are search engines for bugs. What do I mean by these words? As I've mentioned before, some of the debugging tools give you the ability to inspect the variable values in the application. But there is even more - they also give you the ability to search through those values. Below is an example:
Historical travel within a current loop
There are two ways to inspect the values which are delivered from the production. We could take a look at "from the distance" to understand a whole application architecture better. Or examine them in detail. The so-called scope stack gives you the ability to dive into value changes within particular scopes - loops, methods.
Sharing the problems - debugging is a team game
Two heads are better than one, especially in the software development world. Developers have always known this, creating specialized forums where they could share their debugging problems. We may notice that the perfect debugger should have the ability to save and share debugging sessions. Those mechanisms are the key if you want to engage the whole team into solving a problem.
As every developer has his style of coding, they also have their methods of debugging. That's why the debuggers should enable filtering for a piece of essential information. Whitelisting, blacklisting, and exclusion rules - those tools making debugging much faster, with them, you won't drown in the flood of information.
Does the debugger give you the ability to check crashes on production?
Last but not least. The faster you detect the error and fix them, the less damage it will cause. That's why a debugger connected with an application on production should not only identify the bug but also give you information about how many users are affected by it and how many times it occurs, to help you decide what you should fix first.
Those are eleven decisive factors which you should consider while choosing a debugger! I hope that this article will help you to choose wisely from all available options. As you may notice in this article, we've embedded graphics from RevDeBug, which contains all those features.