{"id":18562,"date":"2020-04-30T13:18:51","date_gmt":"2020-04-30T13:18:51","guid":{"rendered":"https:\/\/blog.jetbrains.com\/dotnet\/?p=24987"},"modified":"2020-04-30T13:18:51","modified_gmt":"2020-04-30T13:18:51","slug":"smart-step-enabled-default-debugger-updates-rider-2020-1","status":"publish","type":"dotnet","link":"https:\/\/blog.jetbrains.com\/zh-hans\/dotnet\/2020\/04\/30\/smart-step-enabled-default-debugger-updates-rider-2020-1","title":{"rendered":"Smart Step Into Enabled by Default and More Debugger Updates in Rider 2020.1"},"content":{"rendered":"

Rider 2020.1<\/a> has a lot of excellent features in store for you! In this post, we will look at how Smart Step Into lets us step into methods we’re actually interested in<\/strong>, some UI updates that help reduce mental context switches<\/strong> while debugging, and more!<\/p>\n

<\/p>\n

Smart Step Into is enabled by default<\/h2>\n

Debugging is hard. But Rider\u2019s Smart Step Into feature<\/a> makes it easier!<\/strong> Often, when debugging, we have multiple expressions in a single line of code, and it\u2019s hard to tell which statement is executing and when.<\/p>\n

Smart Step Into<\/strong> allows you to debug expressions while remaining on a line of code, without having to leave that line to see what\u2019s going on. This is now enabled by default!<\/strong><\/p>\n

\"Smart<\/p>\n

Note this setting is configurable at Build, Execution, Deployment | Debugger | Stepping | .NET Languages | Always do Smart Step Into<\/strong>.<\/p>\n

Method breakpoints<\/h2>\n

Rider now offers Method Breakpoints<\/strong> so you can break at the first execution of a method, with options to suspend, log, stack trace, and more. Use Ctrl+Alt+B<\/kbd>\/\u2318+\u2325+B<\/kbd> to show breakpoints, then Ctrl+N<\/kbd>\/Cmd+N<\/kbd> to add a method breakpoint (or any kind).<\/p>\n

\"Add<\/p>\n

Thread name display<\/h2>\n

Though you use easy-to-read and descriptive variable names, it doesn’t help much when thread variable names don’t show up in debugging or analysis tools.\u00a0For those writing multi-threaded code, you can now easily check out which thread is displayed on the execution line<\/strong>.<\/p>\n

Threads are assigned a number by default, but those who set the name of their threads<\/strong> will welcome that it’s now\u00a0easy to see which thread is currently executing<\/strong>.<\/p>\n

\"display<\/p>\n

Debugger window\u00a0changes<\/h2>\n

There have been a few changes made to the Debugger<\/strong> tool window. As you can see in the following image, threads have been incorporated into the window in a more seamless manner. If threads are named, the names show in addition to the thread’s id.<\/p>\n

Instead of showing a separate tab for threads, there is a quick access button along the left side for toggling the threads view<\/strong>, rather than threads view being visualized in a separate tab. Additionally, there\u2019s a tool button located on the left side for detaching from processes<\/strong>, and a filter to hide or show frames.<\/p>\n

\"New<\/p>\n

Check out these other great features<\/h2>\n

Rider now has the ability to detach from processes initially started with the debugger, without terminating the app (RIDER-3800<\/a>). This way, we don’t have to restart our application when we just wanted to detach the debugger.<\/p>\n

You can now also execute the Skip to Here\/Cursor<\/strong> action after stopping the debug session on an exception.<\/p>\n

Some other updates:<\/p>\n