In the previous two blog post in this series about remote debugging Azure Web Sites we have seen how to connect your VS to Azure and taken a look inside how this works. In this 3^rd and last piece of this series, we will look into some more advanced scenarios. If you have multiple instances and wish to debug a specific instance, the server-side infrastructure supports this. First, a little background on multiple instances and then how to specify which instance you want.

Multiple instances has the inherent problem that site visitor sessions are localized in an instance.  Therefore, there needs to be a notion of ‘visitor stickiness’.  When a site visitor goes to a website for the first time, an instance is selected (at random or based on load or custom), but subsequentcalls must go to the same instance.  This is done by using cookies.  The first time a client (browser) visits an Azure-hosted website a cookie is downloaded onto the client.  Subsequent calls to the website are forwarded to the instance defined in the cookie.

Defining the Instance

Instance definition is done using a cookie with key ARRaffinity.  The values are randomly assigned to each instance and are unique.  In the current release of the Azure SDK, specifying the instance is not yet supported.  However, you can specify the instance you want to debug using the manual method.  See the “Connecting the Visual Studio Remote Debugger to Azure Web Sites (Azure Web Sites)”

When you give your user name and add the following: pound/hash “#” and the first few characters of the ARR affinity cookie.  The debugger matches using a ‘begins with’ match, so five characters should be enough.  For example:  jaime_e#55f03 for a user name of jaime_e and an ARR cookie that starts with 55f03.

Hint: If you saved your credentials in Visual Studio, (which uses the Windows Credential management system), you can clear these credentials by going to “Control PanelUser Accounts and Family SafetyCredential Manager” deleting the credential and restarting VS.

Finding the Instance value

In order to read the instance’s ARRaffinity you will need a way to locate and read the cookie that is stored in the client.  If the client is a browser, most browsers include a developer mode that includes (amongst many things) a tool for managing and viewing cookies.  For Internet Explorerand Chrome the key to access the developer console is F12. Depending on your client, and how it manages cookies, the method for reading the ARRaffinity value may be different.

Using Remote Debugger with GIT deployments in Azure Web Sites

Using remote debugging on GIT deployed source code is enabled by default in Azure Web Sites.  Source code that is deployed using GIT is compiled on the server side. The symbols file (pdb) will always be generated, but by default the code is compiled with optimizations for performance and not for debugging.

There are two ways to enable the use of Remote Debugging, by redeploying the source code (which triggers a recompile) with Debug configuration, or by disabling “Just My Code” debugging.

You need to explicitly tell the compiler to optimize for debugging using one of the methods below.

Configure compiler for debugging

When GIT deployed source code is being compiled, it will pass the compiler flags it finds in the SCM_BUILD_ARGS key.

Adding flags using the portal

In the Configure tab in the Azure portal for your website you will find a section called app settings.  Therein you can add a key/value pair to be used when the code is compiled.  Key= SCM_BUILD_ARGS, Value= -p:Configuration=Debug

Adding flags to the msbuild command

It is also possible to specify the compilation flags in your .deployment file.  This is useful if you want the setting to be part of your repository.  Note that it overrides any previous parts of the default command line.

SCM_BUILD_ARGS=-p:Configuration=Debug

Start Remote Debugging

From this point forth, use remote debugging as you would normally.  There were changes made to the version of MSVSMON on Azure Web Sites to specifically enable remote debugging when the pdb files reside in the server and not the client.  This is done automatically for you, and you do not need to do anything else.  The blog, “Connecting the Visual Studio Remote Debugger to Azure Web Sites” illustrates the steps needed to get started.

For more details on GIT in Azure Web Sites, visit the GitHub Project Kudu page.

Summary

In this series of blog posts, we have examined the topic of remote debugging from multiple angels, and given you some tools and insights into using this technology to make life easier. Naturally, the art of debugging is a far wider topic, and we hope that this information will be useful on your way to more robust and stable applications.

Click here to read part one of this series.

Click here to read part two of this series