In a previous post in this series, we have discovered remote debugging on Azure Web Sites and how to connect your visual studio to perform debugging. In order to fully utilize the remote debugging capabilities in Azure Web Sites, it is best to understand how it works.  In this blog we examine in detail the different parts that make Remote Debugger work; including server-side, client-side and debugging symbols.

Server-side: Turning the Remote Debugging Feature ‘ON’

The remote debugging feature needs to be turned on at the server side, which opens the TCP/IP ports required for the connection.  Once the feature is turned on, a timer starts, and after 48 hours the feature is automatically turned off.  This 48 hour limit is done for security and performance reasons.  You can easily turn the feature back on as many times as you like, but we recommend keeping it disabled when not actively debugging.

Turning on the feature is done for you automatically if you are using the automatic Azure SDK method.  Manual control of the remote debugging port can be found in the website’s configuration.  Please refer to the tutorials below for explicit direction.

The first time you try to connect to the site, it sets up the connection paths, and if your site hasn’t been accessed for a while, the site is down it will spin it up.  This means that it may take a few seconds the first time you connect.  The instance Visual Studio first connects to will be the same instance that is connected to subsequently.

Server-side: Visual Studio version

In Visual Studio remote debugging is done with the help of an application called MSVSMON that ships with Visual Studio, and also runs on the Server side on Azure. One challenge, the version of MSVSMON on the server must match the version of Visual Studio on the client side.  We are working on a way for the server to detect the version being used, but for now you must let the server know which version of Visual Studio you’re connecting with.  This step is also done for you by the Azure SDK.  The Azure SDK detects the Visual Studio version you are using and when it turns on the remote debugging feature it also communicates the VS version to the server.

Turning the remote debugger feature on and specifying the Visual Studio version is all that the server needs.  All this is done automatically for you if you’re using the Azure SDK and Visual Studio 2013.

Client-side: Visual Studio

On the client side, the Visual Studio debugger uses debugging symbols to work. The debugging symbols are constructed at compile time and are specifically matched to the libraries or executables created at that time.  There is a lot more detailed information on how to manage symbols in a collaborative development environment, here.

Visual Studio is set up by default to generate the debugging symbols (pdb) when you select to compile a debug build.  The ‘Release’ and ‘Debug’ default build configurations bundle this and other compiler configurations and optimizations.  It is possible to create ‘Release’ builds that also generate the pdb files, instructions here.  Other than performance, we don’t see any reason why you should not publish debug binaries with pdb files.

Debugging symbols (pdb)

In Azure Web Sites, the symbols (pdb) file used by Visual Studio can be in either the local machine or the server.  We have a special version of MSVSMON that can utilize the symbols in the server side.  If you publish the pdb files along with your binaries, MSVSMON will find them and use them.  Alternatively, you can also choose to manage your pdb files locally as you would normally.

If you are using GIT to deploy, the pdb file will need to be on the server side.  Instructions on how to compile a Debug configuration and a detailed explanation is found in the 3^rd post in this series.

Anything you can do with a Visual Studio remote debugger, you can do it on Azure Websites.

The debugger can attach to ANY existing process.  We are focused on websites and .NET processes, but there are many other things Visual Studio debugger can be used for, and we encourage you to learn more.  You can find a starting point here, and share your findings.

It’s worth noting here that Visual Studio graphically lets you know that the breakpoints are enabled. In our context that means that the connections are healthy, symbols are loaded and you’re ready to control the cloud.  When you create a breakpoint, it should be solid.

The next step now that you have a better understanding of how remote debugging works is to apply this knowledge to advanced scenarios. In the next post in this series, we will examine multi-instance environments and GIT deployment debugging.

Click here to read part one of this series.