Debugging in Visual Studio

What’s new for debugging in Visual Studio  

It’s easy to stay in your IDE all the time when you’re working with code that’s running on your local machine, and Visual Studio 2017 has plenty of new debugging features to help you there. What Microsoft showed at the Build conference is extensions and services and previews of new features that let developers stay in Visual Studio, where their familiar tools are, even when the code they’re working with is in a container, or on an iPhone, or in a live production environment, or running in Linux. There’s even a local instance of the Azure Functions runtime; if you’re coding against that in Visual Studio 2017, you can now debug serverless code locally.

There are also tools for refactoring (like null checks and converting to interpolated strings) and notifying you of changes in the codebase that might cause problems earlier in your development cycle, to help you switch to continuous integration and deployment devops models. With the 15.3 preview release of Visual Studio 2017, live unit testing now works against .NET Core as well as the full .NET Framework, so you can see as you type your code if it’s going to fail a unit test or violate your code style. When the live unit test symbol appears to warn you of a problem you can select the test that’s going to fail and step through the code to debug that test.

Safe debugging with intelligent snapshots

With the Azure Application Insights service, you can use the new Visual Studio Snapshot Debugger to debug live .NET applications in production, without users even noticing that you’re doing it. The service automatically collects top-throwing exceptions using a shadow copy of the running process  – so you don’t get every error, just the significant ones.

You don’t need to write a lot of logging or exception handling code; just include the Snapshot collector NuGet package in your app – although you can configure collection parameters and mark lines of code you have concerns about if you want. Those ‘snap points’ are like break points, but for code running in production, against production data, rather than code running locally with test data. You can view the snapshots that are collected in the portal, in the application map, or you can install the Snapshot Debugger extension to view them in Visual Studio, where you can see the line of code where the exception was thrown, along with the production state of that process, including the call stack and objects. You can step through a debuggable instance of the snapshot to look for the problem, as well as seeing details like who was using the app when the exception was thrown (so you can see if it’s affecting an important customer you might want to contact).

Because you’re in Visual Studio, you can use a Code Lens to see who wrote the line of code, or you can switch to local debugging to test the fixes you make to the code.

Snapshot debugging with Application Insights and Visual Studio 2017 (Image: Microsoft)

Debugging on Linux and in containers

Now that Windows 10 includes the Windows Subsystem for Linux, if you’re writing code for Linux you don’t need to do remote debugging or connect to a Linux VM on your system. You can use WSL to run Linux tools, including compilers, on the same PC where you’re running Visual Studio, so you can set break points and step through your Linux code running on Windows to debug it.

Containers are becoming popular because they make your developer environment consistent with the production environment, meaning there should fewer bugs that you only find when the code is deployed onto a system with a different configuration than your laptop. If you’re moving existing applications into containers, the 15.3 preview release of Visual Studio 2017 supports Windows Nano Server and Linux Docker containers, with Nano debugging support for Docker, and the Continuous Delivery Tools extension supports ASP.NET and ASP.NET Core. (Features from the extension like build notifications will move into Visual Studio itself, but this the DevLabs Extensions are a way for the Visual Studio team to preview new features before they’re ready to include in the main IDE.)

Visual Studio 2017 doesn’t just scaffold the Docker assets you need to containerise your app (and set up a continuous integration pipeline to Visual Studio Team Services with deployment to Azure); when you make the deployment target Docker, the debugger target changes to Docker as well.

Visual Studio 2017 also now supports cross-container debugging. Instead of remoting into a container, which makes it tricky to debug across different processes, you can set breakpoints in Visual Studio as normal and when you step through them, you follow the code execution even if it goes from one container to another. That’s critical if you want to use containers as a way to modernise existing apps, because you don’t lose the debugging tools that you’d have if the same application was running directly on a server. Add in the open source Draft tool that Microsoft has just released that both containerises an existing app and deploys it to a pre-set Docker service and you don’t have to learn a whole new way of debugging and managing apps to work with containers. (Draft is a command line tool but it could easily be built into a Visual Studio extension).

PowerShell and AI-driven security

Beyond Visual Studio, there are also new options in Visual Studio Code, including v1 of the PowerShell extension with debugging tools including a variables view, a call stack, a watch window and several breakpoint types.

If you’re interested in improving accessibility, you can now turn on Narrator in Windows 10 developer mode, so you can see and hear your app as visually impaired users will see and hear it. And if you want to do security testing to find bugs that are beyond the Code Analysis tools built into Visual Studio, the new Microsoft Security Risk Detection service (currently in preview) lets you upload your code (with a test harness) to a VM where the same AI-driven fuzz testing Microsoft uses to check the Windows and Office code creates test cases to detect more issues that you can feed into your bug tracking system.