Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
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