This workshop will be retired on May 1, 2025.
Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Well done!
You have completed Introduction to Visual Studio!
You have completed Introduction to Visual Studio!
Preview
Learn how to use the Visual Studio debugger.
This video doesn't have any notes.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
Visual Studio is constantly compiling and
analyzing your code while you're coding.
0:00
This helps catch errors, warnings,
and other problems early.
0:05
Inevitably, I still encounter situations
where there are errors when I go to build.
0:08
Maybe I renamed a variable that was
being referenced in another file and
0:13
I didn't remember to change
it in the other file.
0:17
Visual Studio can't catch
everything all the time.
0:19
The point is, you will encounter
compiler and other build errors and
0:22
Visual Studio can help
you to deal with them.
0:26
Let's introduce a compiler
error to this code.
0:28
I'll remove a semicolon from this line and
then click start.
0:30
The code compiles and I get this message.
0:34
There are build errors.
0:38
Would you like to continue and
run the last successful build?
0:39
I almost never answer yes to this.
0:42
In fact, I would check this box
to never show this message again.
0:44
I'll click No here and
0:49
what I see now in the bottom of
the screen is the Error List pane.
0:51
This lists all the errors and warnings
that the build system encountered.
0:57
I can double click on
any of these lines and
1:01
it will bring me directly to the line
that it thinks is causing the problem.
1:03
The first thing I'm looking for
are the squiggly lines I mentioned before.
1:08
I see them here at the end of the line
where I'm missing the semicolon.
1:13
If I had to pick three killer
features of Visual Studio,
1:17
I'd have to say the editor
with IntelliSense,
1:20
code navigation which I touched very
briefly on with search, and the debugger.
1:23
The interactive debugging provided by
Visual Studios sets the standard by which
1:29
all other IDEs are compared to.
1:34
I'll show you the very
basics of debugging.
1:36
In general, the main capability of
any debugger is the ability to pause
1:39
the execution of the code in order to
get a closer look at what is happening.
1:43
Code can be executed at a rate of
millions of lines per second, so
1:47
being able to pause it at any time and
inspect the values of variables, or
1:51
step through the code during
execution one line at a time,
1:56
is a huge benefit when tracking down bugs.
2:00
So how do you pause execution?
2:03
The most common way is
to set a break point.
2:05
You set a break point by first finding the
line of code that you wanna stop at and
2:08
then clicking on this gray
bar on the left side.
2:12
The program will pause right before
executing that line of code.
2:15
Let's try it out.
2:19
Let me add a couple of lines of code here
first to call the split name method and
2:20
write some output to the console.
2:24
Okay, that's better.
2:44
Let's say I wanna know what
the value of the input variable is,
2:46
when it's passed to the SplitName method.
2:48
I'll set a break point here on
the first line, and run the program.
2:51
The program ran for a bit and is now
stopped here where I set the break point.
3:02
You can see the yellow arrow on
the red break point dot, and
3:08
the whole line is highlighted in yellow.
3:11
As you can see, a lot of things
changed in the user interface.
3:15
These changes happened because
Visual Studio is now in debug mode.
3:18
First the toolbars changed, and
there are a couple of new toolbars added.
3:24
Also, a few new panes
appeared on the screen.
3:28
This diagnostic tools pane is a new
feature in Visual Studio 2015.
3:31
It allows us to see CPU and
3:36
memory performance information about
each line of code while we're debugging.
3:38
Debug time profiling is a big topic
that I'm not gonna go into for
3:43
this workshop, so I'm gonna go ahead and
close this pane for now.
3:47
These other panes are commonly
used during debugging.
3:51
The call stack pane shows how
the program got to this line.
3:54
We can see that this method was
called from line 19 in main.
3:58
The autos pane shoes all of
the variables that are in scope.
4:03
And we're reference leading up
to the point in the execution.
4:07
Here we can see that the value
of input is Jeremy McLain.
4:11
The locals pane shows all of the variables
that are in scope at the location
4:15
of the break point.
4:19
This is often a larger set of variables
than what is shows in the Autos pane.
4:20
The Autos and Locals panes are
automatically populated by the debugger.
4:24
And they can fill up fast.
4:29
If you wanna keep just
a few variables in view,
4:31
you can make your own pane of Watch
variables by using a Watch pane.
4:34
This helps when you're really just
concerned about one or two variables.
4:38
Just right click on the variable and
click on add watch.
4:42
The variable appears
in the watch one pane.
4:45
The watch pane can also be
used to evaluate expressions.
4:48
For instance, if I want to see
what input.split will return,
4:52
I can select the expression.
4:57
Right click and click add watch.
4:58
The statement appears in the watch window.
5:02
As you can see, the result of this
expression is a type string array.
5:04
To see the contents of the object,
5:08
just click on the little
triangle to the left here.
5:10
This works for any complex types, and
5:13
you can drill into objects
as far as you'd like.
5:15
Once you've paused the execution using
a brake point ,you may wanna step
5:18
through the code line by line.
5:22
To show off this feature,
let's restart the debugger and
5:24
stop at the beginning of the program.
5:27
To do that, I'm going to set a break
point here on the first line of main and
5:29
click start.
5:32
The debugger breaks execution
at the break point.
5:40
Now, we can step through the code.
5:43
There are three buttons here on
the toolbar that are used to step
5:45
through the code.
5:47
Hovering over the button displays what
it does, and its keyboard shortcut.
5:49
Step into executes the currently
highlighted line of code, and
5:53
moves to the next line.
5:57
If the currently highlighted
line contains a method call,
5:58
it will move to the first
line inside that method.
6:02
But there's a caveat.
6:05
By default the debug will only attempt
to step through the programmer's code.
6:06
It won't go into .net or
other external assemblies.
6:11
Of course, you can change
this behavior with a setting.
6:15
As you can see, the debugger steps
over the call to console.right but
6:19
it will step into the split name method.
6:23
If I click step into once again, it brings
us to the very end of the method and
6:25
stops on the closing curly brace.
6:30
It's often useful to pause
at the closing curly brace
6:32
to inspect what the method will return.
6:35
If I press step into one more time,
6:38
it brings us back to the line
with the method column.
6:41
I can keep pressing step into until it
gets to the end and the program exits.
6:44
Or I can click the Stop button at any time
to stop the program and the debugger.
6:50
The Step Over button works just
like the Step Into button.
6:59
Except it was always step over
methods without going into them.
7:02
This is very useful because often times,
we wanna step
7:07
through a section of code without stepping
into every method called by the code.
7:10
Finally, the Step Out button
will cause the debugger to run
7:16
through the end of the currently
executed method, or code block.
7:19
It will then pause on the next line that's
executed after the method returns or
7:23
the code block exits.
7:27
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up