[MUSIC].
>> Hello, everyone. My name is Harshada,
and I'm a Product Manager to Visual Studio debugger team.
I'm going to be sharing some debugging tips and
tricks from Visual Studio 2022.
I'm sure those are going to help you
improve your debugging productivity.
We'll look at two brand new types of breakpoints, that's,
temporary breakpoint and dependent breakpoint,
and some UI improvements that are on
the breakpoint staff that can
help you save some time when you're debugging.
We'll also see how you can use ''Force Run to Cursor'' to
fast-forward your debugging when you're
evaluating the complex scenarios,
while we'll see how you can use external sources,
not from Solution Explorer,
to debug and browse through some external dependencies,
such as NuGet libraries and DarkNet libraries.
Finally, we'll look at how you can use
the improvements from a dash to process dialogue.
You'll find the right process to attach and
statute debugging. Let's get started.
Breakpoints are a great way to evaluate your code,
but sometimes you don't want
your breakpoint to hit every single time.
You just want your breakpoint to hit once or twice,
for example, here in this function.
I have this breakpoint on line 33.
I have already fixed my code,
and I just wanted to do a one last time to evaluate that.
I may not even need this breakpoint again.
What I can do is, I can convert
this breakpoint to be a temporary breakpoint.
I can go to the Settings Window and check
this checkbox code ''Remove Breakpoint Once Hit''.
Once that's done, the breakpoint will
get converted into a temporary breakpoint,
and will get removed automatically once it's hit.
Let's continue our debugging here and see how it works.
When you continue, you see
as soon as the breakpoint is hit once,
it will get automatically removed.
I think this could be helpful in many scenarios,
specifically if you're working with loops and you just
want to evaluate the [inaudible] of your loop.
You can place a breakpoint, debug through it,
and you just don't have to remember
deleting or disabling a breakpoint again.
Sometimes there are scenarios when you just want to
downstream your breakpoint when a certain condition is met,
or you just want your breakpoint to be hit when
certain function is evoked from
a particular part of your application code.
For example, here, I have three breakpoints here,
and I want my breakpoint on line 57 to
hit the breakpoint on line 30 when this hit,
while I want my breakpoint on line 42
to be hit when the breakpoint on line 57 is hit.
I may be able to do that using the conditional breakpoints,
but that could be a little complicated
and it may not even be possible.
What I can do is, I can convert
this breakpoint to be dependent on each other.
To do so, I'm going to go up to
the Settings Window on the breakpoint on line 57,
and I'm going to check this checkbox.
That will give me a drop-down box with
all the breakpoints available in my application code.
With this demo, I'm going to be
selecting the breakpoint on line 31
because that's the breakpoint I want
my breakpoint to be dependent on.
Once I do so the breakpoint on line 57 will
get converted to a dependent breakpoint and then disabled state.
Similarly, I'm going to do that for the breakpoint on line
42 and convert that to be dependent on breakpoint on line 57.
These dependent breakpoint will remain
disable until the prerequisite breakpoints are hit.
Now when I continue my debugging here,
as soon as the breakpoint on line 30 is hit,
the breakpoint on line 57 gets enabled.
While if I continue further,
as soon as the breakpoint on line 57 is hit,
the breakpoint on line 42 get enabled.
This could be again helpful in many scenarios.
Of course, the breakpoints will remain
dependent as long as you have this checkbox checks.
I feel this will be really handy if you wanted to create
a common path in your application code
from one breakpoint and going into another,
such as game loops or utility APIs.
There are so many new UI improvements
that are the breakpoint experience,
that can definitely help you save some time while debugging.
For example, this gray glyph while
hovering in the breakpoint data area,
they can exactly lead me where I can exactly set my breakpoint.
You can also actually drag
your breakpoint from one location to another.
This will be really helpful to repurpose your breakpoints.
This also works with the advanced breakpoints,
such as conditional breakpoints and trace points,
as long as the actions and
[inaudible] settings again and
you can just repurpose the breakpoints.
Finally, there is
this new context menu on the right-click data area,
which can give you a very quick way to set the breakpoints.
You can set the temporary breakpoint with just one click,
while for the trace point and conditional breakpoint,
it will take you to the Settings Window with
all the [inaudible] Checkbox Text.
You're all ready to set the breakpoints and start your debugging.
Sometimes there are scenarios when I
just wanted to skip over a block of
code if I'm not interested to
debug line by line, for example here.
Another way my function on line 67,
but I'm only interested on
line ED5 to evaluate the data in the items.
I can do that today using continue,
but then I can even use a step over.
For the fast-forward, I can even use the runtime execution here.
But the problem is I have these two breakpoint,
so even the runtime execution will stop my code execution.
I either have to delete,
disable those breakpoints or just keep hitting those breakpoints.
That could be time-consuming.
An alternative to that is this new command
called ''Force Run to Cursor'' Again,
hover over the line I'm interested in and hold Shift,
that will give me two arrows,
that is, Force Run to Cursor.
Once clicked it will actually
execute the whole program until that line.
It will magically skip
all the breakpoints and
first asset section that could occur in between.
I can also do that using
the right click context menu and using the same command.
This could be really helpful if you
are working with complex scenarios,
and you just wanted to fast-forward your debugging.
When you're debugging the project
dependent on the external libraries,
you need to understand how to exactly use those libraries.
You also need to figure out how that library exactly works,
browsing through the source code is
normally the best way to do so.
External sources node and the
Solution Explorer can help you with that,
disappears when you're debugging.
This will give you the source of
all the modules which has a symbols
loaded and also our information associated with it.
Of course, the availability of the decompiled modules in here
completely depends on how you have
your Symbols settings in the Settings Window.
If you have, just my core settings turned on or not.
In case you do not see here modules interested in this node,
you can use modules without sources symbol node.
This will actually give you the list of
all the external sources applicable to your source.
You can do a selective symbol
loading for the module you're interested in.
You can just right-click and click ''Load Symbols''.
Once the Symbols are loaded,
this will appear under
the external sources and you
are all ready to browse through the source code.
It may even ask you sometimes if
you want to download the source from the Internet.
I normally check that, they don't ask me,
but then again, ask me
options so I don't see the option every time.
Once those symbols are loaded,
you'll see the modules under the external sources.
Now you can all browse through the source code.
It may even ask if you want
to download the source from the Internet.
I normally select the ''Don't ask again'' option so I
don't see this pop-up every time. Let's do that.
Once the sources are available,
you are all set to browse through it, search through it,
and you can even place a breakpoint to debug through it.
This could be really helpful if you are actually working
with many dependent libraries
such as NuGet libraries and External Document Libraries.
There are several new improvements in
the Attached Process Dialogues that can
help you find the right process very quickly,
for example, this show process tree here.
Once this checkboxes checked,
it will give you a parent-child view
of the processes of the label.
In case if you wanted to attach a child process,
you can easily see the correlation between that.
Then your command line column will also give you
the command line details and
the process ID associated with the processes.
The title column can also show you
an actual details for the W3 WPF processes.
This information is really helpful if you're
working with multiple document application or
multiple web application and you
have multiple identical looking processes.
You don't have to go back and forward
from Task Manager to get the right process.
I did find the right process.
Finally, this automatic refresh checkbox here will keep
the list up to date with all the latest processors available.
You don't have to keep pressing
the ''Refresh'' button to get the latest changes.
One of my favorite improvements from the attached
to process dialogue is this select Window option.
This could be really helpful if I wanted
to debug any other applications on my machine.
This can help me select any learning process on my desktop
by just pointing and clicking through it.
I can select a window and I can directly attach to its process.
I don't have to go back and attach to process dialogue and
search through the process and then do
the guesswork to find the right process.
That's all I had. I hope this debugging tips will help you save
some time and improve
your debugging productivity. Thanks for joining.