News 1

How to Experiment With Core Debugging in VS Code


In March 2016, Microsoft developers launched a debugging function for the new ASP.NET Core CLI toolset in Visual Studio, as another way to make it easy to isolate and fix bugs in Core code.

This version was initially for the prerelease version of the .NET Core CLI toolset, not the DNX experience (please see the ASP.NET teams Q&A blog post to understand the changes). Initially, according to a Microsoft Developer Evangelist article, the following wasn’t enabled to start with (although updates have continued since):

  • No separate console window is created when you start debugging, all program output appears in the Debug Console of VS Code. This means that to use Console.ReadLine in a console application during debugging you have to start the application with dotnet run outside of VS Code and then attach the debugger.
  • No Edit & Continue (the ability to modify code and have the changes applied while debugging)
  • Cannot edit the value of variables during debugging
  • No TracePoints or Conditional breakpoints
  • Set Next Statement is not supported

However, when it comes to debugging, that is where RevDeBug has things covered. Getting started means ensuring the following is installed or upgraded (more information on GitHub):

Within the debugging functionality of the ASP.NET Core CLI toolset, you get the following:

  • Breakpoints: Set breakpoints with one click or press F9 in the Editor.
  • Watches: Define expressions you want to watch more closely.
  • Locals: Automatically see the value of local variables.
  • Call Stack: Locate information on method calls in the Stack.
  • Debug Console: Shows debug messages from the ASP.NET Core CLI toolset in Visual Studio.
  • Current Values: Here is another way you can see variable values, when you hover over them.

We have found that used alongside RevDeBug in Visual Studio, Core code debugging is far easier than it was a few years ago. Here are a few of the features that impressed us.

#1: Stop at Entry

Setting up a stopAtEntry flag causes the Microsoft debugger functionality (part of the ASP.NET Core CLI toolset) to break when required, which means you can step through code without creating breakpoints.

#2: Configure ASP.NET for different browsers and web applications

In here you will find a configuration called .NET Core Launch (web), which is a great way to debug - supported by RevDeBug - web applications in different browsers. Although it is set up for the default browser, you can use launchBrowser to modify the one you need in the command files.

#3: Change the launch URL

Although the server is configured to detect and use a default server, usually set to the following - ${auto-detect-url} - you can also modify the launch URL. When you need to debug a specific URL, such as when dealing with inbound webhooks from third-parties, you can overwrite the default value in the manual navigation toolbar.

#4: Use symbolPath to work across platforms and operating systems

There are times when debugging Core code when you need to specify an array of paths to your debugging symbols. For this, the creators of this debugging functionality made it easy to generate symbols for different platforms and operating systems. Here is an example:
"symbolPath":"[ \"/Volumes/symbols\" , \"/OtherVolume/otherSymbols\" ]"

#5: Only deal with justMyCode

There are also times when you don’t want to debug code that someone else has written, which is why Microsoft .NET teams came up with the justMyCode option. They set this as a default option, which means it can work alongside RevDeBug, thereby making it simple to spot your code, rather than a framework or that from external components. If you need to interact with that code, disable this by setting it explicitly to false.

Find out more about the benefits of reverse debugging.

We would love to hear from developers who have used RevDeBug alongside the debugging feature in the ASP.NET Core CLI toolset for feedback and more information about the experience.

Back to list