diff --git a/docs/TOC.md b/docs/TOC.md index b549dfe913b..ad2d0328d55 100644 --- a/docs/TOC.md +++ b/docs/TOC.md @@ -1,11 +1,11 @@ # [Welcome to Visual Studio 2017!](welcome-to-visual-studio.md) # [What's New](ide/whats-new-in-visual-studio.md) # [Installation](install/TOC.md) -# [Visual Studio IDE Feature Tour](ide/visual-studio-ide.md) +# [Visual Studio IDE](ide/index.md) # [Visual Basic](/dotnet/articles/visual-basic) # [Visual C#](/dotnet/articles/csharp) # [Visual C++](/cpp/top/visual-cpp-in-visual-studio) -# [JavaScript](javascript/javascript-in-visual-studio.md) +# [JavaScript](/scripting/javascript) # [Python](python/getting-started-with-python.md) # [Visual F#](/dotnet/articles/fsharp/) # [Data Access](data-tools/TOC.md) diff --git a/docs/_breadcrumb/toc.yml b/docs/_breadcrumb/toc.yml index e67b18e3cd3..f09cb6e219f 100644 --- a/docs/_breadcrumb/toc.yml +++ b/docs/_breadcrumb/toc.yml @@ -53,14 +53,14 @@ topicHref: /visualstudio/modeling/analyze-and-model-your-architecture - name: Debugging tocHref: /visualstudio/debugger/ - topicHref: /visualstudio/debugger/debugging-in-visual-studio + topicHref: /visualstudio/debugger/index items: - name: DIA SDK tocHref: /visualstudio/debugger/debug-interface-access/ topicHref: /visualstudio/debugger/debug-interface-access/debug-interface-access-sdk - name: Profiling tocHref: /visualstudio/profiling/ - topicHref: /visualstudio/profiling/profiling-tools + topicHref: /visualstudio/profiling/index - name: Testing tocHref: /visualstudio/test/ topicHref: /visualstudio/test/improve-code-quality diff --git a/docs/csharp-ide/refactoring/sync-type-and-file.md b/docs/csharp-ide/refactoring/sync-type-and-file.md index d8231ef52e3..3ccece0f61f 100644 --- a/docs/csharp-ide/refactoring/sync-type-and-file.md +++ b/docs/csharp-ide/refactoring/sync-type-and-file.md @@ -33,7 +33,7 @@ translation.priority.ht: # Sync a type to a filename, or a filename to a type in C# # -**This feature is available in Visual Studio 2017 and later.** +**This feature is available in Visual Studio 2017 and later. Additionally, .NET Standard projects are not yet supported for this refactoring.** **What:** Lets you rename a type to match the filename, or rename a filename to match the type it contains. @@ -60,4 +60,4 @@ translation.priority.ht: ![Inline result](media/synctype_result.png) ## See Also -[Refactoring (C#)](../refactoring-csharp.md) \ No newline at end of file +[Refactoring (C#)](../refactoring-csharp.md) diff --git a/docs/debugger/TOC.md b/docs/debugger/TOC.md index 42682d6d970..cc6325693d9 100644 --- a/docs/debugger/TOC.md +++ b/docs/debugger/TOC.md @@ -1,5 +1,4 @@ -# [Debugging in Visual Studio](debugging-in-visual-studio.md) -# [Debugger Feature Tour](debugger-feature-tour.md) +# [Debugging Feature Tour](debugger-feature-tour.md) # [What’s New for the Debugger in Visual Studio](what-s-new-for-the-debugger-in-visual-studio.md) # [Debugger Basics](debugger-basics.md) ## [Get Started with the Debugger](getting-started-with-the-debugger.md) diff --git a/docs/debugger/debugger-feature-tour.md b/docs/debugger/debugger-feature-tour.md index 6e89c986386..17a05ac5a98 100644 --- a/docs/debugger/debugger-feature-tour.md +++ b/docs/debugger/debugger-feature-tour.md @@ -33,252 +33,201 @@ translation.priority.mt: --- # Debugger feature tour -This topic introduces the features of the Visual Studio debugger in an easy-to-follow walkthrough. +This topic introduces the features of the Visual Studio debugger. If you want to follow along by opening your own app in Visual Studio, you can do that, or you can follow along with a sample app using the [step-by-step Beginner's Guide](../debugger/getting-started-with-the-debugger.md). -You can either read along to see the features of the debugger or you can download the complete sample used in the feature tour and follow the step-by-step instructions yourself. To download the sample and follow along, go to [Photo Viewer Demo](https://code.msdn.microsoft.com/windowsdesktop/WPF-Photo-Viewer-Demo-be75662a). +The features described here are applicable to C#, C++, Visual Basic, JavaScript, and other languages supported by Visual Studio (except where noted). -Although the demo app is C#, the features are applicable to C++, Visual Basic, JavaScript, and other languages supported by Visual Studio (except where noted). +## Set a breakpoint and start the debugger -## Start the tour! +To debug, you need to start your app with the debugger attached to the app process. F5 (**Debug / Start Debugging**) is the most common way to do that, but right now you may not have set any breakpoints to examine your app code, so we'll do that first and then start debugging. -1. To follow along these steps in Visual Studio, download the sample [on this page](https://code.msdn.microsoft.com/windowsdesktop/WPF-Photo-Viewer-Demo-be75662a). +With a project open in Solution Explorer and a file open in the code editor, set a breakpoint by clicking in the margin to the left of a line of code. - > [!IMPORTANT] - > You need to install Visual Studio with the .NET Desktop Development workload to run the app we're using in the demo. +![Set a Breakpoint](../debugger/media/dbg-tour-set-a-breakpoint.gif "SetABreakPoint") -2. Unzip the project. +Press F5 (**Debug / Start Debugging**) and the debugger runs to the first breakpoint that it encounters. If the app is not yet running, F5 starts the debugger and stops at the first breakpoint. -3. Open Visual Studio and select the **File / Open** menu command, then choose **Project/Solution**, and then open the folder where you downloaded the project. +Breakpoints are a really useful feature when you know the line of code or the section of code that you want to examine in detail. - ![Open Project](../debugger/media/dbg-tour-open-project.png "Open Project") +## Navigate code in the debugger using step commands -3. Open the WPF Photo Viewer Demo / C# folder, choose the photoapp.sln file, and select **Open**. +We are showing the keyboard shortcuts for most commands because they make navigation of your app code quicker (equivalent commands such as menu commands are shown in parentheses). - The project opens in Visual Studio. Solution Explorer in the right pane shows you all the project files. +Press F11 (**Debug / Step Into**) to start your app with the debugger attached. F11 is the **Step Into** command and advances the app execution one statement at a time. When you start the app with F11, the debugger breaks on the first statement that gets executed. - ![Solution Explorer](../debugger/media/dbg-tour-solution-explorer.png "Solution Explorer") +![F11 Step Into](../debugger/media/dbg-tour-f11.png "F11 Step Into") -4. Press F5 (**Debug / Start Debugging** or the green arrow ![Start Debugging](../debugger/media/dbg-tour-start-debugging.png "Start Debugging") button in the Debug Toolbar). +The yellow arrow represents the statement on which the debugger paused, which also suspends app execution at the same point (this statement has not yet executed). - ![Photo Viewer App](../debugger/media/dbg-tour-wpf-app.png "Photo Viewer App") +F11 is a good way to examine the execution flow in the most detail. (To move faster through code, we will show you some other options as well.) By default, the debugger skips over non-user code (if you want more details, see [Just My Code](../debugger/just-my-code.md)). - F5 starts the app with the debugger attached to the app process, but right now we haven't added any breakpoints or done anything special to examine the code. So the app just loads and you see the photo images. +>[!NOTE] +> In managed code, you will see a dialog box asking if you want to be notified when you automatically step over properties and operators (default behavior). If you want to change the setting later, disable **Step over properties and operators** setting in the **Tools / Options** menu under **Debugging**. - In this tour, we'll take a closer look at this app using the debugger and get a look at the debugger features. +## Step over code to skip functions -5. Stop the debugger by pressing the red stop ![Stop Debugging](../debugger/media/dbg-tour-stop-debugging.png "Stop Debugging") button. +When you are on a line of code that is a function or method call, you can press F10 (**Debug / Step Over**) instead of F11. -## Start the debugger by stepping through code +F10 advances the debugger without stepping into functions or methods in your app code (the code still executes). By pressing F10, you can skip over code that you're not interested in, so you can quickly get to code that you are more interested in. -To debug, you need to start your app with the debugger attached to the app process. - -Mostly, we will use the keyboard shortcuts here, because it's the best way to get fast at executing your app in the debugger (equivalent commands such as menu commands are shown in parentheses). - -1. Press F11 (**Debug / Step Into**) to start the app with the debugger attached. - - ![F11 Step Into](../debugger/media/dbg-tour-f11-start.png "F11 Step Into") - - The yellow arrow represents the line of code on which the debugger paused, which also suspends app execution at the same point (this line of code has not yet executed). - - F11 is the **Step Into** command and advances the app execution one statement at a time. F11 is a good way to examine the execution flow in the most detail. (To move faster through code, we will show you some other options in later steps.) By default, the debugger skips over non-user code (if you want more details, see [Just My Code](../debugger/just-my-code.md)). - - >[!NOTE] - > In managed code, you will see a dialog box asking if you want to be notified when you automatically step over properties and operators (default behavior). If you want to change the setting later, disable **Step over properties and operators** setting in the **Tools / Options** menu under **Debugging**. - -2. Press F10 (**Debug / Step Over**) a few times until the debugger stops on the first line of code in the **OnApplicationStartup** event handler. - - ![F10 Step Over](../debugger/media/dbg-tour-f10-step-over.png "F10 Step Over") - - F10 advances the debugger without stepping into functions or methods in your app code. By pressing F10 on the InitializeComponent method call (instead of F11), we skipped over the implementation code for InitializeComponent (which maybe we're not interested in right now). - -## Set a breakpoint +## Step into a property -1. Now, in the **OnApplicationStartup** event handler, set a breakpoint by clicking in the margin to the left of the last line of code. +As mentioned earlier, by default the debugger skips over managed properties and fields, but the **Step Into Specific** command allows you to override this behavior. - ![Set a Breakpoint](../debugger/media/dbg-tour-set-a-breakpoint.gif "SetABreakPoint") +Right-click on a property or field and choose **Step Into Specific**, then choose one of the available options. -6. Press F5 (**Continue**) and the debugger runs to the line of code where you set the breakpoint. +![Step into Specific](../debugger/media/dbg-tour-step-into-specific.png "Step Into Specific") - F5 either continues running the app to the next breakpoint or, if the app is not yet running, it starts the debugger and stops at the first breakpoint. +In this example, **Step Into Specific** gets us to the code for `Path.set`. - Breakpoints are a really useful feature when you know the line of code or the section of code that you want to examine in detail. +![Step into Specific](../debugger/media/dbg-tour-step-into-specific-2.png "Step Into Specific") -## Restart your app quickly +## Run to a point in your code quickly using the mouse -1. Click the **Restart** ![Restart App](../debugger/media/dbg-tour-restart.png "RestartApp") button in the Debug Toolbar (Ctrl + Shift +F5). +While in the debugger, hover over a line of code until the **Run execution to here** button ![Run to Click](../debugger/media/dbg-tour-run-to-click.png "RunToClick") appears on the left. - When you press **Restart**, it saves time versus stopping the app and restarting the debugger. The debugger pauses at the first breakpoint that is hit by executing code, similar to pressing F5 (if the code isn't executed, you won't hit the breakpoint). +![Run to Click](../debugger/media/dbg-tour-run-to-click-2.png "Run to Click") -## Step into a property +> [!NOTE] +> The **Run execution to here** button is new in [!include[vs_dev15](../misc/includes/vs_dev15_md.md)]. -1. With the debugger paused on this line of code: +Click the **Run execution to here** button. The debugger advances to the line of code where you clicked. - ```` - mainWindow.Photos.Path = Environment.CurrentDirectory + "\\images"; - ```` +Using this button is similar to setting a temporary breakpoint, which is also handy for getting around quickly within a visible region of app code (you can click in any open file). - Right-click on the line of code and choose **Step Into Specific**, then **SDKSamples.ImageSample.PhotoCollection.Path.set** +## Advance the debugger out of the current function - ![Step into Specific](../debugger/media/dbg-tour-step-into-specific.png "Step Into Specific") +Sometime, you might want to continue your debugging session but advance the debugger all the way through the current function. - As mentioned earlier, by default the debugger skips over managed properties and fields, but the **Step Into Specific** command allows you to override this behavior. For now, we want to look what happens when the `Path.set` property setter runs. **Step Into Specific** gets us to the `Path.set` code here. +Press Shift + F11 (or **Debug / Step Out**). - ![Step into Specific](../debugger/media/dbg-tour-step-into-specific-2.png "Step Into Specific") +This resumes app execution (and advances the debugger) until the current function returns. - The `Update` method in this code looks like it could be interesting, so lets use the debugger to examine that code up close. +## Run to cursor -5. Hover over the `Update` method until the green **Run execution to here** button appears on the left. +Stop the debugger by pressing the **Stop Debugging** red button ![Stop Debugging](../debugger/media/dbg-tour-stop-debugging.png "Stop Debugging") or Shift + F5. - ![Run to Click](../debugger/media/dbg-tour-run-to-click-2.png "Run to Click") +Right-click a line of code in your app and choose **Run to Cursor**. This command starts debugging and sets a temporary breakpoint on the current line of code. - > [!NOTE] - > The **Run execution to here** button is new in [!include[vs_dev15](../misc/includes/vs_dev15_md.md)]. If you don't see the green arrow button, use F11 instead to advance the debugger. +![Run to Cursor](../debugger/media/dbg-tour-run-to-cursor.png "Run to Cursor") -6. Click the green arrow ![Run to Click](../debugger/media/dbg-tour-run-to-click.png "RunToClick") button. +If you have set breakpoints, the debugger will pause on the first breakpoint that it hits. - Using the green arrow button is similar to setting a temporary breakpoint, which is also handy for getting around quickly within a visible region of app code (you can click in any open file). +Press F5 until you reach the line of code where you selected **Run to Cursor**. - The debugger advances to the `Update` method implementation. +This command is useful when you are editing code and want to quickly set a temporary breakpoint and start the debugger. -7. Press F11 to step into the `Update` method. +## Restart your app quickly - ![Step into Update Method](../debugger/media/dbg-tour-update-method.png "Step Into Update Method") +Click the **Restart** ![Restart App](../debugger/media/dbg-tour-restart.png "RestartApp") button in the Debug Toolbar (Ctrl + Shift +F5). - Here, we find some more code that looks interesting; it appears the app is getting all *.jpg files residing in a particular directory, and then creating a new Photo object for each file. This gives us a good opportunity to start inspecting your app state (variables) with the debugger. +When you press **Restart**, it saves time versus stopping the app and restarting the debugger. The debugger pauses at the first breakpoint that is hit by executing code, similar to pressing F5 (if the code isn't executed, you won't hit the breakpoint). - Features that allow you to inspect variables are one of the most useful features of the debugger, and there are different ways to do it. Often, when trying to debug an issue, you will be attempting to find out whether variables are storing the values that you expect them to have at a particular point of execution. +If you do want to stop the debugger and get back into the code editor, you can press the red stop ![Stop Debugging](../debugger/media/dbg-tour-stop-debugging.png "Stop Debugging") button instead of **Restart**. ## Inspect variables with data tips -1. Click the green ![Run to Click](../debugger/media/dbg-tour-run-to-click.png "RunToClick") button again to pause the debugger on the `Add` method call. +Now that you know your way around a little, you have a good opportunity to start inspecting your app state (variables) with the debugger. Features that allow you to inspect variables are some of the most useful features of the debugger, and there are different ways to do it. Often, when trying to debug an issue, you will be attempting to find out whether variables are storing the values that you expect them to have at a particular point of execution. -2. Now, hover over the File object (`f`) and you will see its default property value, the file name `market 031.jpg`. +While paused in the debugger, hover over an object with the mouse and you will see its default property value (in this example, the file name `market 031.jpg` is the default property value). - ![View a Data Tip](../debugger/media/dbg-tour-data-tips.gif "View a Data Tip") +![View a Data Tip](../debugger/media/dbg-tour-data-tips.gif "View a Data Tip") -3. Expland the object to see all its properties, such as the `FullName` property. +Expland the object to see all its properties (such as the `FullPath` property in this example). - Often, when debugging, you will want a quick way to check property values on objects, and the data tips are a good way to do it. +Often, when debugging, you will want a quick way to check property values on objects, and the data tips are a good way to do it. - > [!TIP] - > In most supported languages, you can edit code in the middle of a debugger session if you find something you want to change. For more info, see [Edit and Continue](../debugger/edit-and-continue.md). To use that feature in this app, we would first need to update the app's version of the .NET Framework. +> [!TIP] +> In most supported languages, you can edit code in the middle of a debugging session if you find something you want to change. For more info, see [Edit and Continue](../debugger/edit-and-continue.md). ## Inspect variables with the Autos and Locals windows -1. Take a look at the **Autos** window at the bottom of the code editor. +While debugging, take a look at the **Autos** window at the bottom of the code editor. - ![Autos Window](../debugger/media/dbg-tour-autos-window.png "Autos Window") +![Autos Window](../debugger/media/dbg-tour-autos-window.png "Autos Window") - In the **Autos** window, you see variables and their current value. The **Autos** window shows all variables used on the current line or the preceding line (In C++, the window shows variables in the preceding three lines of code. Check documentation for language-specific behavior). +In the **Autos** window, you see variables along with their current value and their type. The **Autos** window shows all variables used on the current line or the preceding line (In C++, the window shows variables in the preceding three lines of code. Check documentation for language-specific behavior). -2. Next, take a look at the **Locals** window. +> [!NOTE] +> In JavaScript, the **Locals** window is supported but not the **Autos** window. - The **Locals** window shows you the variables that are currently in scope. +Next, take a look at the **Locals** window. The **Locals** window shows you the variables that are currently in scope. - ![Locals Window](../debugger/media/dbg-tour-locals-window.png "Locals Window") +![Locals Window](../debugger/media/dbg-tour-locals-window.png "Locals Window") - Currently, the `this` object and the File object (`f`) are in scope. For more info, see [Inspect Variables in the Autos and Locals Windows](../debugger/autos-and-locals-windows.md). +In this example, the `this` object and the object `f` are in scope. For more info, see [Inspect Variables in the Autos and Locals Windows](../debugger/autos-and-locals-windows.md). ## Set a watch -1. In the main code editor window, right-click the File object (`f`) and choose **Add Watch**. +You can use a **Watch** window to specify a variable (or an expression) that you want to keep an eye on. - You can use a **Watch** window to specify a variable (or an expression) that you want to keep an eye on. +While debugging, right-click an object and choose **Add Watch**. - Now, you have a watch set on the `File` object, and you can see it's value change as you move through the debugger. Unlike the other variable windows, the **Watch** window always shows the variables that you are watching (they're grayed out when out of scope). - - > [!TIP] - > If you need to track the value of the variable even when it's out of scope, in C# you can right-click in the **Watch** windows and choose **Create an Object ID**. - -2. On the `Add` method, click the green ![Run to Click](../debugger/media/dbg-tour-run-to-click.png "RunToClick") button again (or press F11 a few times) to advance through the `foreach` loop. +![Watch Window](../debugger/media/dbg-tour-watch-window.png "Watch Window") - ![Watch Window](../debugger/media/dbg-tour-watch-window.png "Watch Window") - - You might also see the first picture get added to the main window of the running sample app, but this happens on the UI thread, so images may not be visible yet. +In this example, you have a watch set on the `File` object, and you can see it's value change as you move through the debugger. Unlike the other variable windows, the **Watch** windows always show the variables that you are watching (they're grayed out when out of scope). + +> [!TIP] +> If you need to track the value of the variable even when it's out of scope, in C# you can right-click in the **Watch** windows and choose [Create an Object ID](https://docs.microsoft.com/en-us/visualstudio/debugger/watch-and-quickwatch-windows.md#bkmk_objectIds). - For more info, see [Set a Watch using the Watch and QuickWatch Windows](../debugger/watch-and-quickwatch-windows.md) +For more info, see [Set a Watch using the Watch and QuickWatch Windows](../debugger/watch-and-quickwatch-windows.md) ## Examine the call stack -1. Click the **Call Stack** window, which is by default open in the lower right pane. +Click the **Call Stack** window while you are debugging, which is by default open in the lower right pane. - ![Examine the Call Stack](../debugger/media/dbg-tour-call-stack.png "ExamineCallStack") +![Examine the Call Stack](../debugger/media/dbg-tour-call-stack.png "ExamineCallStack") - The **Call Stack** window shows the order in which methods and functions are getting called. The top line shows the current function (the `Update` method in the tour app). The second line shows that `Update` was called from the `Path.set` property, and so on. +The **Call Stack** window shows the order in which methods and functions are getting called. The top line shows the current function (the `Update` method in the this example). The second line shows that `Update` was called from the `Path.set` property, and so on. The call stack is a good way to examine and understand the execution flow of an app. - > [!NOTE] - > The **Call Stack** window is similar to the Debug perspective in some IDEs like Eclipse. +> [!NOTE] +> The **Call Stack** window is similar to the Debug perspective in some IDEs like Eclipse. - The call stack is a good way to examine and understand the execution flow of an app. +You can double-click a line of code to go look at that source code (without advancing the debugger) and that also changes the current scope being inspected by the debugger. - You can use right-click menus from the **Call Stack** window to do things like insert breakpoints into specified functions, restart your app using **Run to Cursor**, and to go examine source code. See [How to: Examine the Call Stack](../debugger/how-to-use-the-call-stack-window.md) - - You can double-click a line of code to go look at that source code (without advancing the debugger). +You can also use right-click menus from the **Call Stack** window to do things like insert breakpoints into specified functions, restart your app using **Run to Cursor**, and to go examine source code. See [How to: Examine the Call Stack](../debugger/how-to-use-the-call-stack-window.md) ## Change the execution flow -1. With the debugger paused on the `Add` method call, use the mouse to grab the yellow arrow pointer on the left and move the yellow arrow pointer up one line to the `foreach` loop. - - ![Move the Execution Pointer](../debugger/media/dbg-tour-move-the-execution-pointer.gif "Move the Execution Pointer") - - By changing the execution flow, you can do things like test different code execution paths or simply re-run code without restarting the debugger. - -2. Now, press F5. - - You can see the images added to the app window. Because you are re-running code in the `foreach` loop, some of the images have been added twice! So, sometimes you need to be careful with this feature, and you see a warning in the tooltip. You may see other warnings, too. - -## Run to cursor - -1. Choose the **Stop Debugging** red button ![Stop Debugging](../debugger/media/dbg-tour-stop-debugging.png "Stop Debugging") or Shift + F5. - -2. In the `Update` method, right-click the `Add` method call and choose **Run to Cursor**. This command starts debugging and sets a temporary breakpoint on the current line of code. - - ![Run to Cursor](../debugger/media/dbg-tour-run-to-cursor.png "Run to Cursor") +With the debugger paused on a line of code, use the mouse to grab the yellow arrow pointer on the left and move the yellow arrow pointer to a different point in the code execution path. Then you use F5 or a step command to continue running the app. - You should be paused on the breakpoint in `OnApplicationStartup` (since that is the first breakpoint. +![Move the Execution Pointer](../debugger/media/dbg-tour-move-the-execution-pointer.gif "Move the Execution Pointer") -3. Press F5 to advance to the `Add` method where you selected **Run to Cursor**. +By changing the execution flow, you can do things like test different code execution paths or simply re-run code without restarting the debugger. - This command is useful when you are editing code and want to quickly set a temporary breakpoint and start the debugger. +> [!WARNING] +> Often you need to be careful with this feature, and you see a warning in the tooltip. You may see other warnings, too. Moving the pointer does not undo any changes to the state of your application. -## Step out - -Let's say that you are done examining the `Update` method in Data.cs, then you might want to step out of the function using the **Step Out** command. - -1. Press Shift + F11 (or **Debug / Step Out**). - - This resumes app execution (and advances the debugger) until the current function returns. - - You should be back in the `Update` method call in Data.cs. - -2. Press Shift + F11 again, and the debugger goes up the call stack back to the `OnApplicationStartup` event handler. +## Examine an exception -3. Press F5 to continue. +When your app throws an exception, the debugger takes you to the line of code that threw the exception. + +![Exception Helper](../debugger/media/dbg-tour-exception-helper.png "Exception Helper") -## Examine an exception +In this example, the **Exception Helper** shows you a `System.Argument` exception and an error message that says that the path is not a legal form. So, we know the error occurred on a method or function argument. -1. In the running app window, delete the text in the **Path** input box and select the **Change** button. +In this example, the `DirectoryInfo` call gave the error on the empty string stored in the `value` variable. - ![Cause an Exception](../debugger/media/dbg-tour-cause-an-exception.png "Cause an Exception") +The Exception Helper is a great feature that can help you debug errors. You can also do things like view error details and add a watch from the Exception Helper. Or, if needed, you can change conditions for throwing the particular exception. - The app throws an exception, and the debugger takes you to the line of code that threw the exception. - - ![Exception Helper](../debugger/media/dbg-tour-exception-helper.png "Exception Helper") +> [!NOTE] +> The Exception Helper replaces the Exception Assistant in [!include[vs_dev15](../misc/includes/vs_dev15_md.md)]. - Here, the **Exception Helper** shows you a `System.Argument` exception and an error message that says that the path is not a legal form. So, we know the error occurred on a method or function argument. +Expand the **Exception Settings** node to see more options on how to handle this exception type, but you don't need to change anything for this tour! - In this example, the `DirectoryInfo` call gave the error on the empty string stored in the `value` variable. (Hover over `value` to see the empty string.) +## More features to look at - The Exception Helper is a great feature that can help you debug errors. You can also do things like view error details and add a watch from the Exception Helper. Or, if needed, you can change conditions for throwing the particular exception. +- [Edit and Continue](../debugger/edit-and-continue.md) For a subset of languages (C#, C++, Visual Basic), the Edit and Continue feature allows you to edit code in the middle of a debugging session if you find something you want to change. - > [!NOTE] - > The Exception Helper replaces the Exception Assistant in [!include[vs_dev15](../misc/includes/vs_dev15_md.md)]. +- [Debug Multithreaded Applications](../debugger/debug-multithreaded-applications-in-visual-studio.md) Describes how to debug multithreaded applications. -2. Expand the **Exception Settings** node to see more options on how to handle this exception type, but you don't need to change anything for this tour! +- [Remote Debugging](../debugger/remote-debugging.md) Describes how to debug apps running on other machines or devices. + +- [IntelliTrace](../debugger/intellitrace.md) Describes the IntelliTrace feature in Visual Studio Enterprise. You can use it to record and trace your code's execution history. -3. Press F5 to continue the app. +- [Network Usage](../profiling/network-usage.md) Describes a profiling tool that you can use to debug web services and other network resources in Universal Windows Apps (UWP). Use the tool to examine payloads. - Congratulations on completing the tour of the debugger! We hope you learned a lot about some of its main features! +- [Debug Interface Access SDK](../debugger/debug-interface-access/debug-interface-access-sdk.md) Describes the Microsoft Debug Interface Access Software Development Kit (DIA SDK). The DIA SDK provides access to debug information stored in program database (.pdb) files generated by Microsoft postcompiler tools. ## See Also [Debugging in Visual Studio](../debugger/debugging-in-visual-studio.md) \ No newline at end of file diff --git a/docs/debugger/first-look-at-the-debugger.md b/docs/debugger/first-look-at-the-debugger.md new file mode 100644 index 00000000000..86f5b7fb6fe --- /dev/null +++ b/docs/debugger/first-look-at-the-debugger.md @@ -0,0 +1,102 @@ +--- +title: "Get Started with the Debugger in Visual Studio | Microsoft Docs" +ms.custom: "H1Hack27Feb2017" +ms.date: "02/07/2017" +ms.reviewer: "" +ms.suite: "" +ms.technology: + - "vs-ide-debug" +ms.tgt_pltfrm: "" +ms.topic: "get-started-article" +ms.assetid: 0b3138c4-b840-446a-a15c-10ed8e2dd050 +caps.latest.revision: 5 +author: "mikejo5000" +ms.author: "mikejo" +manager: "ghogen" +translation.priority.ht: + - "cs-cz" + - "de-de" + - "es-es" + - "fr-fr" + - "it-it" + - "ja-jp" + - "ko-kr" + - "pl-pl" + - "pt-br" + - "ru-ru" + - "tr-tr" + - "zh-cn" + - "zh-tw" +--- +# Get Started with the Visual Studio Debugger +The Visual Studio debugger is easy to use in any language. Here we’ll show how to debug a simple C# program, but you can apply the same steps to code in other languages such as C++ and JavaScript. + +To watch a video showing similar features, see [Getting Started with the Debugger](https://www.youtube.com/watch?v=FtGCi5j30YU&list=PLReL099Y5nRfw6VNvzMkv0sabT2crbSpK&index=6). + +## Debug a Basic C# Project + Let’s start with a simple C# console application (**File / New / Project**, then select **Visual C#** and then **Console Application**). If you’ve never worked with Visual Studio before, see [Walkthrough: Create a Simple Application](../ide/walkthrough-create-a-simple-application-with-visual-csharp-or-visual-basic.md). The **Main** method just adds 1 to an integer variable 10 times and prints the result to the console: + +```CSharp +static void Main(string[] args) +{ + int testInt = 0; + for (int i = 1; i <= 10; i++) + { + testInt += 1; + } + Console.WriteLine(testInt); +} +``` + + Build this code in the **Debug** configuration. This configuration is set by default. For more information about configurations, see [Understanding Build Configurations](../ide/understanding-build-configurations.md). + + Run this code in the debugger by clicking **Debug / Start Debugging** (or **Start** on the toolbar, or **F5**). The application should exit almost immediately, so you can’t actually tell whether anything was printed in the Console window. + + You can stop the execution long enough to see the Console window by setting a breakpoint and then stepping ahead. To set a breakpoint, put your cursor in the `Console.WriteLine` line and click **Debug / New Breakpoint / Function Breakpoint**, or just click in the left margin at the same line. The breakpoint should look like this: + + ![Set a breakpoint](../debugger/media/getstartedbreakpoint.png "GetStartedBreakpoint") + + For more information about breakpoints, see [Using Breakpoints](../debugger/using-breakpoints.md). + +## Inspect Variables + Debugging often involves finding variables that don't contain the values you expect at a particular point. We will show some of the ways that you can inspect variables. + + Start debugging again. Execution stops before the `Console.WriteLine` code executes. You can cause it to execute by stepping ahead (click **Debug / Step Over** or **F10**). In this case you could have chosen **Step Into** (**F11**) and gotten the same result; we’ll explain the difference later on. The line with the last curly brace of the method should have turned yellow. Look at the Console window. You should see **10**. + + You can hover over the **testInt** variable to view the current value in a data tip. + + ![DBG_Basics_Data_Tips](../debugger/media/dbg_basics_data_tips.png "DBG_Basics_Data_Tips") + + Just below the code window you should see the **Autos**, **Locals**, and **Watch** windows. These windows show the current values of variables at the time of execution. Both the **Autos** and the **Locals** windows show **testInt** with a value of **10**. + + ![Autos window when debugging](../debugger/media/getstartedwindows.png "GetStartedWindows") + + For more information about these windows, see [Autos and Locals Windows](../debugger/autos-and-locals-windows.md). + + Let’s see how the variable value changes as we walk through the program. Set a breakpoint on the `testInt += 1;` line, and restart debugging. You should see that **testInt** in the **Locals** and **Autos** windows is **0**, and **i** is **1**. When you continue debugging (**Debug / Continue**, or **Continue** on the toolbar, or **F5**), you can see that the value of **testInt** changes to **1**, then **2**, and so on. When you get tired of looking at these changes, remove the breakpoint (**Debug / Toggle Breakpoint**, or click on it in the margin), and continue debugging. If you want to remove all the breakpoints, click **Debug / Delete All Breakpoints**, or **CTRL+SHIFT+F9**, and click **Yes** on the dialog box that asks **Do you want to remove all breakpoints?**. + +## Stepping Into and Over Function Calls + You can execute code in the debugger statement-by-statement (**Step Into**) or you can execute code while the debugger skips functions (**Step Over**) to quickly get to code that you're more interested in (function code is still executed). You can switch between both methods in the same debugging session. + + To see the difference between **Step Into** and **Step Over**, we need to add a method that is called by another method. Add a method to the C# application and call it from the Main method. The code should look something like this: + +```CSharp +static void Main(string[] args) +{ + Method1(); + Console.WriteLine("end"); +} + +private static void Method1() +{ + Console.WriteLine("in Method1"); +} +``` + + Set a breakpoint on the `Method1();` call in the Main method and start debugging. When execution breaks, click **Debug / Step Into** (or **Step Into** on the toolbar, or **F11**). Execution breaks again at the first curly brace in Method1(): + + ![Stepping into code](../debugger/media/getstartedstepinto.png "GetStartedStepInto") + + Stop debugging and start again, and when execution breaks at the breakpoint, click **Debug / Step Over** (or **Step Over** on the toolbar, or **F10**). Execution breaks again at `Console.WriteLine("end");`. + + If you want to know more about navigating code with the debugger, see [Navigating through Code with the Debugger](../debugger/navigating-through-code-with-the-debugger.md). \ No newline at end of file diff --git a/docs/debugger/getting-started-with-the-debugger.md b/docs/debugger/getting-started-with-the-debugger.md index 31d0f06e132..15d9db3b14b 100644 --- a/docs/debugger/getting-started-with-the-debugger.md +++ b/docs/debugger/getting-started-with-the-debugger.md @@ -1,102 +1,292 @@ --- -title: "Get Started with the Debugger in Visual Studio | Microsoft Docs" -ms.custom: "H1Hack27Feb2017" -ms.date: "02/07/2017" +title: "Debugger Feature Tour | Microsoft Docs" +ms.custom: "" +ms.date: "03/04/2017" ms.reviewer: "" ms.suite: "" ms.technology: - "vs-ide-debug" ms.tgt_pltfrm: "" ms.topic: "get-started-article" +helpviewer_keywords: + - "debugger" ms.assetid: 62734c0d-a75a-4576-8f73-0e97c19280e1 -caps.latest.revision: 5 +caps.latest.revision: 1 author: "mikejo5000" ms.author: "mikejo" manager: "ghogen" translation.priority.ht: - - "cs-cz" - "de-de" - "es-es" - "fr-fr" - "it-it" - "ja-jp" - "ko-kr" - - "pl-pl" - - "pt-br" - "ru-ru" - - "tr-tr" - "zh-cn" - "zh-tw" +translation.priority.mt: + - "cs-cz" + - "pl-pl" + - "pt-br" + - "tr-tr" --- -# Get Started with the Visual Studio Debugger -The Visual Studio debugger is easy to use in any language. Here we’ll show how to debug a simple C# program, but you can apply the same steps to code in other languages such as C++ and JavaScript. - -To watch a video showing similar features, see [Getting Started with the Debugger](https://www.youtube.com/watch?v=FtGCi5j30YU&list=PLReL099Y5nRfw6VNvzMkv0sabT2crbSpK&index=6). - -## Debug a Basic C# Project - Let’s start with a simple C# console application (**File / New / Project**, then select **Visual C#** and then **Console Application**). If you’ve never worked with Visual Studio before, see [Walkthrough: Create a Simple Application](../ide/walkthrough-create-a-simple-application-with-visual-csharp-or-visual-basic.md). The **Main** method just adds 1 to an integer variable 10 times and prints the result to the console: - -```CSharp -static void Main(string[] args) -{ - int testInt = 0; - for (int i = 1; i <= 10; i++) - { - testInt += 1; - } - Console.WriteLine(testInt); -} -``` - - Build this code in the **Debug** configuration. This configuration is set by default. For more information about configurations, see [Understanding Build Configurations](../ide/understanding-build-configurations.md). - - Run this code in the debugger by clicking **Debug / Start Debugging** (or **Start** on the toolbar, or **F5**). The application should exit almost immediately, so you can’t actually tell whether anything was printed in the Console window. - - You can stop the execution long enough to see the Console window by setting a breakpoint and then stepping ahead. To set a breakpoint, put your cursor in the `Console.WriteLine` line and click **Debug / New Breakpoint / Function Breakpoint**, or just click in the left margin at the same line. The breakpoint should look like this: - - ![Set a breakpoint](../debugger/media/getstartedbreakpoint.png "GetStartedBreakpoint") - - For more information about breakpoints, see [Using Breakpoints](../debugger/using-breakpoints.md). - -## Inspect Variables - Debugging often involves finding variables that don't contain the values you expect at a particular point. We will show some of the ways that you can inspect variables. - - Start debugging again. Execution stops before the `Console.WriteLine` code executes. You can cause it to execute by stepping ahead (click **Debug / Step Over** or **F10**). In this case you could have chosen **Step Into** (**F11**) and gotten the same result; we’ll explain the difference later on. The line with the last curly brace of the method should have turned yellow. Look at the Console window. You should see **10**. - - You can hover over the **testInt** variable to view the current value in a data tip. - - ![DBG_Basics_Data_Tips](../debugger/media/dbg_basics_data_tips.png "DBG_Basics_Data_Tips") - - Just below the code window you should see the **Autos**, **Locals**, and **Watch** windows. These windows show the current values of variables at the time of execution. Both the **Autos** and the **Locals** windows show **testInt** with a value of **10**. - - ![Autos window when debugging](../debugger/media/getstartedwindows.png "GetStartedWindows") - - For more information about these windows, see [Autos and Locals Windows](../debugger/autos-and-locals-windows.md). - - Let’s see how the variable value changes as we walk through the program. Set a breakpoint on the `testInt += 1;` line, and restart debugging. You should see that **testInt** in the **Locals** and **Autos** windows is **0**, and **i** is **1**. When you continue debugging (**Debug / Continue**, or **Continue** on the toolbar, or **F5**), you can see that the value of **testInt** changes to **1**, then **2**, and so on. When you get tired of looking at these changes, remove the breakpoint (**Debug / Toggle Breakpoint**, or click on it in the margin), and continue debugging. If you want to remove all the breakpoints, click **Debug / Delete All Breakpoints**, or **CTRL+SHIFT+F9**, and click **Yes** on the dialog box that asks **Do you want to remove all breakpoints?**. - -## Stepping Into and Over Function Calls - You can execute code in the debugger statement-by-statement (**Step Into**) or you can execute code while the debugger skips functions (**Step Over**) to quickly get to code that you're more interested in (function code is still executed). You can switch between both methods in the same debugging session. - - To see the difference between **Step Into** and **Step Over**, we need to add a method that is called by another method. Add a method to the C# application and call it from the Main method. The code should look something like this: - -```CSharp -static void Main(string[] args) -{ - Method1(); - Console.WriteLine("end"); -} - -private static void Method1() -{ - Console.WriteLine("in Method1"); -} -``` - - Set a breakpoint on the `Method1();` call in the Main method and start debugging. When execution breaks, click **Debug / Step Into** (or **Step Into** on the toolbar, or **F11**). Execution breaks again at the first curly brace in Method1(): - - ![Stepping into code](../debugger/media/getstartedstepinto.png "GetStartedStepInto") - - Stop debugging and start again, and when execution breaks at the breakpoint, click **Debug / Step Over** (or **Step Over** on the toolbar, or **F10**). Execution breaks again at `Console.WriteLine("end");`. - - If you want to know more about navigating code with the debugger, see [Navigating through Code with the Debugger](../debugger/navigating-through-code-with-the-debugger.md). \ No newline at end of file +# Debugger feature tour + +This topic introduces the features of the Visual Studio debugger in an step-by-step walkthrough. If you want a higher-level view of the debugger features, see [Debugger Feature Tour](../debugger/debugger-feature-tour.md). + +You can either read along to see the features of the debugger or you can download the complete sample used in the feature tour and follow the step-by-step instructions yourself. To download the sample and follow along, go to [Photo Viewer Demo](https://code.msdn.microsoft.com/windowsdesktop/WPF-Photo-Viewer-Demo-be75662a). + +Although the demo app is C#, the features are applicable to C++, Visual Basic, JavaScript, and other languages supported by Visual Studio (except where noted). + +## Start the tour! + +1. To follow along these steps in Visual Studio, download the sample [on this page](https://code.msdn.microsoft.com/windowsdesktop/WPF-Photo-Viewer-Demo-be75662a). + + > [!IMPORTANT] + > You need to install Visual Studio with the .NET Desktop Development workload to run the app we're using in the demo. + +2. Unzip the project. + +3. Open Visual Studio and select the **File / Open** menu command, then choose **Project/Solution**, and then open the folder where you downloaded the project. + + ![Open the sample project](../debugger/media/dbg-tour-open-project.png "Open Project") + +3. Open the WPF Photo Viewer Demo / C# folder, choose the photoapp.sln file, and select **Open**. + + The project opens in Visual Studio. Solution Explorer in the right pane shows you all the project files. + + ![Solution Explorer files](../debugger/media/dbg-tour-solution-explorer.png "Solution Explorer") + +4. Press F5 (**Debug / Start Debugging** or the **Start Debugging** button ![Start Debugging](../debugger/media/dbg-tour-start-debugging.png "Start Debugging") in the Debug Toolbar). + + ![Photo Viewer app](../debugger/media/dbg-tour-wpf-app.png "Photo Viewer App") + + F5 starts the app with the debugger attached to the app process, but right now we haven't added any breakpoints or done anything special to examine the code. So the app just loads and you see the photo images. + + In this tour, we'll take a closer look at this app using the debugger and get a look at the debugger features. + +5. Stop the debugger by pressing the red stop ![Stop Debugging](../debugger/media/dbg-tour-stop-debugging.png "Stop Debugging") button. + +## Set a breakpoint and start the debugger + +To debug, you need to start your app with the debugger attached to the app process. + +1. In the `MainWindow` constructor of MainWindow.xaml.cs, set a breakpoint by clicking in the margin to the left of the first line of code. + + ![Set a breakpoint](../debugger/media/dbg-tour-set-a-breakpoint.gif "SetABreakPoint") + +6. Press F5 or the **Start Debugging** button, the app starts, and the debugger runs to the line of code where you set the breakpoint. + + The yellow arrow represents the statement on which the debugger paused, which also suspends app execution at the same point (this statement has not yet executed). + + F5 either continues running the app to the next breakpoint or, if the app is not yet running, it starts the debugger and stops at the first breakpoint. + + Breakpoints are a really useful feature when you know the line of code or the section of code that you want to examine in detail. + +## Restart your app quickly + +1. Click the **Restart** ![Restart App](../debugger/media/dbg-tour-restart.png "RestartApp") button in the Debug Toolbar (Ctrl + Shift +F5). + + When you press **Restart**, it saves time versus stopping the app and restarting the debugger. The debugger pauses at the first breakpoint that is hit by executing code, similar to pressing F5 (if the code isn't executed, you won't hit the breakpoint). + + The debugger will stop again at the breakpoint you just set, in the `MainWindow` constructor. + +## Navigate code in the debugger using step commands + +Mostly, we will use the keyboard shortcuts here, because it's a good way to get fast at executing your app in the debugger (equivalent commands such as menu commands are shown in parentheses). + +1. Press F11 (**Debug / Step Into**) twice to advance the execution of the app to the `InitializeComponent()` function. + + ![Use F11 to Step Into code](../debugger/media/dbg-tour-f11.png "F11 Step Into") + + F11 is the **Step Into** command and advances the app execution one statement at a time. F11 is a good way to examine the execution flow in the most detail. (To move faster through code, we will show you some other options also.) By default, the debugger skips over non-user code (if you want more details, see [Just My Code](../debugger/just-my-code.md)). + + >[!NOTE] + > In managed code, you will see a dialog box asking if you want to be notified when you automatically step over properties and operators (default behavior). If you want to change the setting later, disable **Step over properties and operators** setting in the **Tools / Options** menu under **Debugging**. + +2. Press F10 (**Debug / Step Over**) a few times until the debugger stops on the first line of code in the `OnApplicationStartup` event handler. + + ![Use F10 to Step Over code](../debugger/media/dbg-tour-f10-step-over.png "F10 Step Over") + + F10 advances the debugger without stepping into functions or methods in your app code (the code still executes). By pressing F10 on the `InitializeComponent` method call (instead of F11), we skipped over the implementation code for `InitializeComponent` (which maybe we're not interested in right now). + +## Step into a property + +1. With the debugger paused on this line of code: + + ```` + mainWindow.Photos.Path = Environment.CurrentDirectory + "\\images"; + ```` + + Right-click on the line of code and choose **Step Into Specific**, then **SDKSamples.ImageSample.PhotoCollection.Path.set** + + ![Use the Step into Specific feature](../debugger/media/dbg-tour-step-into-specific.png "Step Into Specific") + + As mentioned earlier, by default the debugger skips over managed properties and fields, but the **Step Into Specific** command allows you to override this behavior. For now, we want to look what happens when the `Path.set` property setter runs. **Step Into Specific** gets us to the `Path.set` code here. + + ![result of Step into Specific](../debugger/media/dbg-tour-step-into-specific-2.png "Step Into Specific") + + The `Update` method in this code looks like it could be interesting, so lets use the debugger to examine that code up close. + +5. Hover over the `Update` method until the green **Run execution to here** button ![Run to Click](../debugger/media/dbg-tour-run-to-click.png "RunToClick") appears on the left. + + ![Use the Run to Click feature](../debugger/media/dbg-tour-run-to-click-2.png "Run to Click") + + > [!NOTE] + > The **Run execution to here** button is new in [!include[vs_dev15](../misc/includes/vs_dev15_md.md)]. If you don't see the green arrow button, use F11 in this example instead to advance the debugger. + +6. Click the **Run execution to here** button ![Run to Click](../debugger/media/dbg-tour-run-to-click.png "RunToClick"). + + Using this button is similar to setting a temporary breakpoint, which is also handy for getting around quickly within a visible region of app code (you can click in any open file). + + The debugger advances to the `Update` method implementation. + +7. Press F11 to step into the `Update` method. + + ![Result of stepping into the Update method](../debugger/media/dbg-tour-update-method.png "Step Into Update Method") + + Here, we find some more code that looks interesting; it appears the app is getting all *.jpg files residing in a particular directory, and then creating a new Photo object for each file. This gives us a good opportunity to start inspecting your app state (variables) with the debugger. + + Features that allow you to inspect variables are one of the most useful features of the debugger, and there are different ways to do it. Often, when trying to debug an issue, you will be attempting to find out whether variables are storing the values that you expect them to have at a particular point of execution. + +## Inspect variables with data tips + +1. Hover over the `Add` method call and click the **Run execution to here** button ![Run to Click](../debugger/media/dbg-tour-run-to-click.png "RunToClick") to pause the debugger on the `Add` method call. + +2. Now, hover over the File object (`f`) and you will see its default property value, the file name `market 031.jpg`. + + ![View a data tip](../debugger/media/dbg-tour-data-tips.gif "View a Data Tip") + +3. Expland the object to see all its properties, such as the `FullPath` property. + + Often, when debugging, you will want a quick way to check property values on objects, and the data tips are a good way to do it. + + > [!TIP] + > In most supported languages, you can edit code in the middle of a debugger session if you find something you want to change. For more info, see [Edit and Continue](../debugger/edit-and-continue.md). To use that feature in this app, we would first need to update the app's version of the .NET Framework. + +## Inspect variables with the Autos and Locals windows + +1. Take a look at the **Autos** window at the bottom of the code editor. + + ![Inspect variables in the Autos Window](../debugger/media/dbg-tour-autos-window.png "Autos Window") + + In the **Autos** window, you see variables and their current value. The **Autos** window shows all variables used on the current line or the preceding line (In C++, the window shows variables in the preceding three lines of code. Check documentation for language-specific behavior). + + > [!NOTE] + > In JavaScript, the **Locals** window is supported but not the **Autos** window. + +2. Next, take a look at the **Locals** window. + + The **Locals** window shows you the variables that are in the current scope. + + ![Inspect variables in the Locals Window](../debugger/media/dbg-tour-locals-window.png "Locals Window") + + Currently, the `this` object and the File object (`f`) are in the current scope. For more info, see [Inspect Variables in the Autos and Locals Windows](../debugger/autos-and-locals-windows.md). + +## Set a watch + +1. In the main code editor window, right-click the File object (`f`) and choose **Add Watch**. + + You can use a **Watch** window to specify a variable (or an expression) that you want to keep an eye on. + + Now, you have a watch set on the `File` object, and you can see it's value change as you move through the debugger. Unlike the other variable windows, the **Watch** window always shows the variables that you are watching (they're grayed out when out of scope). + + > [!TIP] + > If you need to track the value of the variable even when it's out of scope, in C# you can right-click in the **Watch** windows and choose [Create an Object ID](../debugger/watch-and-quickwatch-windows#bkmk_objectIds). + +2. On the `Add` method, click the green ![Run to Click](../debugger/media/dbg-tour-run-to-click.png "RunToClick") button again (or press F11 a few times) to advance through the `foreach` loop. + + ![Set a watch on a variable](../debugger/media/dbg-tour-watch-window.png "Watch Window") + + You might also see the first picture get added to the main window of the running sample app, but this happens on the UI thread, so images may not be visible yet. + + For more info, see [Set a Watch using the Watch and QuickWatch Windows](../debugger/watch-and-quickwatch-windows.md) + +## Examine the call stack + +1. Click the **Call Stack** window, which is by default open in the lower right pane. + + ![Examine the call stack](../debugger/media/dbg-tour-call-stack.png "ExamineCallStack") + + The **Call Stack** window shows the order in which methods and functions are getting called. The top line shows the current function (the `Update` method in the tour app). The second line shows that `Update` was called from the `Path.set` property, and so on. + + > [!NOTE] + > The **Call Stack** window is similar to the Debug perspective in some IDEs like Eclipse. + + The call stack is a good way to examine and understand the execution flow of an app. + + You can double-click a line of code to go look at that source code (without advancing the debugger) and that also changes the current scope being inspected by the debugger. + + You can also use right-click menus from the **Call Stack** window to do things like insert breakpoints into specified functions, restart your app using **Run to Cursor**, and to go examine source code. See [How to: Examine the Call Stack](../debugger/how-to-use-the-call-stack-window.md) + +## Change the execution flow + +1. With the debugger paused on the `Add` method call, use the mouse to grab the yellow arrow pointer on the left and move the yellow arrow pointer up one line to the `foreach` loop. + + ![Move the execution pointer](../debugger/media/dbg-tour-move-the-execution-pointer.gif "Move the Execution Pointer") + + By changing the execution flow, you can do things like test different code execution paths or simply re-run code without restarting the debugger. + +2. Now, press F5. + + You can see the images added to the app window. Because you are re-running code in the `foreach` loop, some of the images have been added twice! + + > [!WARNING] + > Often you need to be careful with this feature, and you see a warning in the tooltip. You may see other warnings, too. Moving the pointer does not undo any changes to the state of your application. + +## Run to cursor + +1. Choose the **Stop Debugging** red button ![Stop Debugging](../debugger/media/dbg-tour-stop-debugging.png "Stop Debugging") or Shift + F5. + +2. In the `Update` method, right-click the `Add` method call and choose **Run to Cursor**. This command starts debugging and sets a temporary breakpoint on the current line of code. + + ![Use the Run to Cursor feature](../debugger/media/dbg-tour-run-to-cursor.png "Run to Cursor") + + You should be paused on the breakpoint in `OnApplicationStartup` (since that is the first breakpoint. + +3. Press F5 to advance to the `Add` method where you selected **Run to Cursor**. + + This command is useful when you are editing code and want to quickly set a temporary breakpoint and start the debugger. + +## Step out + +Let's say that you are done examining the `Update` method in Data.cs, then you might want to step out of the function using the **Step Out** command. + +1. Press Shift + F11 (or **Debug / Step Out**). + + This resumes app execution (and advances the debugger) until the current function returns. + + You should be back in the `Update` method call in Data.cs. + +2. Press Shift + F11 again, and the debugger goes up the call stack back to the `OnApplicationStartup` event handler. + +3. Press F5 to continue. + +## Examine an exception + +1. In the running app window, delete the text in the **Path** input box and select the **Change** button. + + ![Cause an exception to be thrown](../debugger/media/dbg-tour-cause-an-exception.png "Cause an Exception") + + The app throws an exception, and the debugger takes you to the line of code that threw the exception. + + ![Exception Helper](../debugger/media/dbg-tour-exception-helper.png "Exception Helper") + + Here, the **Exception Helper** shows you a `System.Argument` exception and an error message that says that the path is not a legal form. So, we know the error occurred on a method or function argument. + + In this example, the `DirectoryInfo` call gave the error on the empty string stored in the `value` variable. (Hover over `value` to see the empty string.) + + The Exception Helper is a great feature that can help you debug errors. You can also do things like view error details and add a watch from the Exception Helper. Or, if needed, you can change conditions for throwing the particular exception. + + > [!NOTE] + > The Exception Helper replaces the Exception Assistant in [!include[vs_dev15](../misc/includes/vs_dev15_md.md)]. + +2. Expand the **Exception Settings** node to see more options on how to handle this exception type, but you don't need to change anything for this tour! + +3. Press F5 to continue the app. + + Congratulations on completing the tour of the debugger! We hope you learned a lot about some of its main features! + +## See Also + [Debugging in Visual Studio](../debugger/debugging-in-visual-studio.md) \ No newline at end of file diff --git a/docs/debugger/includes/remote-debugger-download.md b/docs/debugger/includes/remote-debugger-download.md index 1fa254d057f..ee55208ab78 100644 --- a/docs/debugger/includes/remote-debugger-download.md +++ b/docs/debugger/includes/remote-debugger-download.md @@ -18,8 +18,8 @@ translation.priority.ht: |Version|Link|Notes| |-|-|-| - |Visual Studio 2017 RC|[Remote Tools](https://www.visualstudio.com/downloads/#remote-tools-for-visual-studio-2017-rc)|Always download the version matching your device operating system (x86, x64, or ARM version)| - |Visual Studio 2015 Update 3|[Remote tools](https://www.visualstudio.com/downloads/#remote-tools-for-visual-studio-2015-update-3)|Always download the version matching your device operating system (x86, x64, or ARM version)| + |Visual Studio 2017|[Remote Tools](https://www.visualstudio.com/downloads/#remote-tools-for-visual-studio-2017)|Always download the version matching your device operating system (x86, x64, or ARM version)| + |Visual Studio 2015 Update 3|[Remote tools](https://my.visualstudio.com/Downloads?q=remote%20tools%20visual%20studio%202015)|If prompted, join the free Visual Studio Dev Essentials group or you can just sign in with a valid Visual Studio subscription. Then re-open the link if necessary.| |Visual Studio 2015 (older)|[Remote tools](https://my.visualstudio.com/Downloads?q=remote%20tools%20visual%20studio%202015)|If prompted, join the free Visual Studio Dev Essentials group or you can just sign in with a valid Visual Studio subscription. Then re-open the link if necessary.| |Visual Studio 2013|[Remote tools](https://msdn.microsoft.com/library/bt727f1t(v=vs.120).aspx#BKMK_Installing_the_Remote_Tools)|Download page in Visual Studio 2013 documentation| |Visual Studio 2012|[Remote tools](https://msdn.microsoft.com/library/bt727f1t(v=vs.110).aspx#BKMK_Installing_the_Remote_Tools)|Download page in Visual Studio 2012 documentation| diff --git a/docs/debugger/media/dbg-tour-f11-start.png b/docs/debugger/media/dbg-tour-f11-start.png deleted file mode 100644 index cf51398d455..00000000000 Binary files a/docs/debugger/media/dbg-tour-f11-start.png and /dev/null differ diff --git a/docs/debugger/media/dbg-tour-f11.png b/docs/debugger/media/dbg-tour-f11.png new file mode 100644 index 00000000000..9ed0eec7639 Binary files /dev/null and b/docs/debugger/media/dbg-tour-f11.png differ diff --git a/docs/debugger/media/dbg-tour-run-to-click.png b/docs/debugger/media/dbg-tour-run-to-click.png index 759ccf979e5..59118c5b832 100644 Binary files a/docs/debugger/media/dbg-tour-run-to-click.png and b/docs/debugger/media/dbg-tour-run-to-click.png differ diff --git a/docs/debugger/media/dbg-tour-set-a-breakpoint.gif b/docs/debugger/media/dbg-tour-set-a-breakpoint.gif index 02304d91e1c..99faa5d86a7 100644 Binary files a/docs/debugger/media/dbg-tour-set-a-breakpoint.gif and b/docs/debugger/media/dbg-tour-set-a-breakpoint.gif differ diff --git a/docs/ide/TOC.md b/docs/ide/TOC.md index d1bd87452a0..6908a40e707 100644 --- a/docs/ide/TOC.md +++ b/docs/ide/TOC.md @@ -165,8 +165,8 @@ ## [Using the Task List](using-the-task-list.md) ## [Find code changes and other history with CodeLens](find-code-changes-and-other-history-with-codelens.md) ### [CodeIndex Command](codeindex-command.md) -# [Debugging in Visual Studio](../debugger/debugging-in-visual-studio.md) -# [Profiling Tools](../profiling/profiling-tools.md) +# [Debugging](../debugger/debugger-feature-tour.md) +# [Profiling](../profiling/profiling-feature-tour.md) # [Improve Code Quality](../test/improve-code-quality.md) # [Designing User Interfaces](../designers/designing-user-interfaces.md) # [Architecture](../modeling/analyze-and-model-your-architecture.md) diff --git a/docs/ide/index.md b/docs/ide/index.md index 2c64aa605f8..0f0f4469439 100644 --- a/docs/ide/index.md +++ b/docs/ide/index.md @@ -12,24 +12,6 @@ Learn about how the Visual Studio integrated development environment (IDE) can h Tutorials, videos, and other documentation show you ways to create code and apps by using Visual Studio.