Conditional Breakpoints in Visual Studio .NET
By Shivprasad Koirala
As developer debugging is your routine job and you would like your debugger to debug smartly rather than monotonously. For instance in the below code we have put a debug point and we do not want our debugger to just break monotonously.
Many times as a developer you come across functions with lots of input parameters as shown in the below code snippets. In real projects the input parameters would be much higher as compared to the below code snippets. Some times for various reasons you want to shuffle them, reorder them or remove some of them.
Many times due to project pressure and lazy attitude you violate encapsulation and create public variables for classes as shown below. Even though your inner heart knows that the best practice is to create set and get property function but your lazy attitude overrules it.
We all know exceptions get propagated from the last caller to the main caller. For instance let’s say from your static void main method you are calling “SomeMethod” and he in turn is calling “SomeMethod1”.
While debugging you often want to skip debugging on certain lines of code. For instance in the below code you have set the debug point to the first line, you would like to skip the in between lines and jump directly to “console.writeline” step.
In big project you have 100’s of classes and each of those classes can have lots of properties.
Now many times as a .NET developer we need connection strings to connect to databases. Connection string are long and cryptic and very difficult to remember. In this tip we will see a easy way of getting connection strings.
Conditional Breakpoints in Visual Studio .NET (2722 Views)