From the beginning of the Azure era, developers have been asking to be provided with the capability of live debugging solutions in the cloud. As it is not a simple feature, Microsoft figured it out only in 2013. However, now, we do have the strong capability to remotely debug our Cloud Service from Visual Studio to enhance the testing experience and extend it to the live application.
To get ready, we need a ready-to-publish application with at least one valid role. Follow steps 1 to 9 in the previous recipe and proceed with the instructions in the next recipe.
We will configure a Cloud Service to be attached with a remote debugger; then, we will proceed with the debug session, using the following steps:
When we follow steps 1 to 9 of the previous recipe, we will see the Publish Microsoft Azure Application window.
In Common Settings, choose Debug as the build configuration.
Select the Advanced Settings tab.
Check the Enable Remote Debugger option for all roles.
Complete the publish process and wait for it to finish.
Locate a part of your code that is now running in Azure and set a breakpoint.
Locate the Microsoft Azure node in the Server Explorer and find the Cloud Service you want to debug.
Expand the node and select the deployment slot first; then, right-click on the instance to connect to (that is, Instance 0 under Production).
Click on Attach Debugger.
Perform the appropriate actions on the running code (firing events, for example) to cover the code where the breakpoint is set.
From steps 1 to 4, we republished the Cloud Service by enabling the capability to remote debug the running code.
From steps 5 to 10, we executed an attach to process-like operation, connecting to a remote Azure instance instead of a local process.
Tip
In step 7, we can also decide to debug the entire service, instead of a single instance. This capability is to be intended as an attach-to-each-role process, with advantages (that is, the first instance that meets the conditions will break the debugger) and disadvantages (that is, if each instance is frozen by the debugger, there will be potentially no thread free to serve the legitimate requests).
As remote debugging is not considered a best practice (there is also the Emulator to test our code), there are some constraints you should know about and deal with:
Depending on your Internet connection's quality, debugging will be slower or faster due to the amount of data exchanged between the VMs and the host.
Remember to softly use the debugging windows (Immediate, Watch, and Locals) in order to prevent VS from freezing (due to the network transfers).
Attaching the debugger to a single instance is preferable. Attaching it to the whole service (despite there being a limitation of 25 instances per role if remote debugging is enabled) is considered much slower.
To enable remote debugging, the remote VM uses some ports (30400-30424 and 31400-31424 for the time being), so avoid using them in the application as this will result in an error.
Until the Remote Debug feature was available, the only supported method to debug remotely was by collecting the IntelliTrace logs in the live instances and downloading them later in Visual Studio to analyze them. This method is quite complex, and it is not covered in this book.
Have a look at the following MSDN links to get additional information:
How to debug Virtual Machines from VS at http://msdn.microsoft.com/en-us/library/ff683670.aspx
How to collect the IntelliTrace data of the remote Cloud Services at http://msdn.microsoft.com/en-us/library/ff683671.aspx