Productivity with Visual Studio: Debug | Part 3
Tags: csharp, dotnet, vscode, productivity
Published: 2020-08-02 23:44:28

Until now, in the first part and in the second, we have seen tricks for the code editor and improving our navigation in it. Now it's time for some tricks to improve our debugging.

Most of us know the basic commands like F5 to start debugging, F9 to set a breakpoint, or F11 to get into the implementation. In addition to these, there are many functionalities in the tool that we can use to make our work easier.

## Move the execution point
The first is to move the point where it is running. On the left side of the editor, we can find a yellow arrow, this indicates where the execution is stopped. If we need to go to another line to run from there, all we have to do is hold down the arrow and drag it to the desired place.

![Productivity with Visual Studio](https://withoutdebugger.azureedge.net/blog/20200727.ProductivityVS3/00.01.gif)

## Run up to a point
Suppose we have a breakpoint on the first line, but we want to run up to one in particular. We can do is click on the line and press **Ctrl + F10** or press right-click and select it from the Run to Cursor context menu 

![Productivity with Visual Studio](https://withoutdebugger.azureedge.net/blog/20200727.ProductivityVS3/01.01.gif)

Another path is through the green marker to the left of the code line. We position ourselves on the line to which we want to go, on the right, the green marker will appear, indicating that we can advance to that point by clicking on it.

![Productivity with Visual Studio](https://withoutdebugger.azureedge.net/blog/20200727.ProductivityVS3/02.01.gif)

We can go to an execution line without the need to execute the middle code. Again, if we stand on the line, we see the green marker on the left side. If we press the control, we will see that it turns yellow, we click and it will go to the line without executing the intermediate code. It is for this reason that when viewing the tracking window the object is null.

![Productivity with Visual Studio](https://withoutdebugger.azureedge.net/blog/20200727.ProductivityVS3/03.01.gif)

## Set breakpoints
Breakpoints don't just stop because we mark them. We can configure a breakpoint by configuring different conditions or when a particular event happens. It is very useful when we are debugging and we depend on the values ​​that the objects contain.

We can configure a property of an object to stop when it has changed. In the image, we can see how we should do it. We configure that when changing ProductId of the product object it stops. Notice how the line is gray.

![Productivity with Visual Studio](https://withoutdebugger.azureedge.net/blog/20200727.ProductivityVS3/04.01.gif)

Suppose we need to stop execution when a property takes a specific value. For this, on the red marker of the breakpoint, we press on the configuration gear and select Conditions. We see that we have several configuration parameters. We complete it to stop when p, which is inside a loop, in the Description property is equal to “Product 2”. This will make the loop run until the condition is as desired.

![Home](https://withoutdebugger.azureedge.net/blog/20200727.ProductivityVS3/05.01.gif)

Now instead of stopping, we also want to see all the outputs of the loop. We can use Actions. Again, on the breakpoint, we select the gear and select Actions. Here we can write a text and then enter {} the name of the variable or object that we want to print in the output window.

![Productivity with Visual Studio](https://withoutdebugger.azureedge.net/blog/20200727.ProductivityVS3/06.01.gif)

## View function values
Many times, we execute a method that returns a value, but we ignore it or do not assign it to a variable. This makes it not accessible at run time or debugging. The debugging time can be seen, if necessary, from the auto window. We can open it, at debugging time, from **Debug> Windows> Auto**.

![Productivity with Visual Studio](https://withoutdebugger.azureedge.net/blog/20200727.ProductivityVS3/08.01.gif)

## Verify unchanged objects from immediate window and observation
Whenever we execute a method from the immediate window we change the value of some property or object. As we see in the image, each time we execute the method, the value in the observation window is updated, notifying us that the value has changed. To have no effect, we can use the prefix **nse**.

![Productivity with Visual Studio](https://withoutdebugger.azureedge.net/blog/20200727.ProductivityVS3/10.01.gif)

## Decompile the IL code
Many times we create libraries to reuse in our projects. We refer to our project to the assembly that has a dll extension. In this example, we have Math.dll, it is a project that I create to use in the example.

Once we referenced it, it will work as a black box, where we can't see the implementation. Visual Studio gives us the possibility of being able to do it even though it is compiled. This functionality allows us to decompile the component and have the implementation code available.

To access the value we must use what is called a pseudo-variable, in this case, **$ReturnValue**. As we see in the image, after executing the method, we immediately write **$ReturnValue** in the window and we will see the result.

![Productivity with Visual Studio](https://withoutdebugger.azureedge.net/blog/20200727.ProductivityVS3/12.01.gif)

## Conclusions
With all this set of functionalities and tools, we can make it easier to search for any problem that we have in our application. In the next post, we will see tricks for refactoring. I hope you find it useful and take advantage of it.