Microsoft Azure Development Cookbook Second Edition
上QQ阅读APP看书,第一时间看更新

Debugging a Cloud Service remotely with Visual Studio

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.

Getting ready

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.

How to do it…

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:

  1. When we follow steps 1 to 9 of the previous recipe, we will see the Publish Microsoft Azure Application window.
  2. In Common Settings, choose Debug as the build configuration.
  3. Select the Advanced Settings tab.
  4. Check the Enable Remote Debugger option for all roles.
  5. Complete the publish process and wait for it to finish.

    Tip

    Please note that it is strongly recommended that you remote debug only in rare cases and, if needed, possibly for services in an isolated slot. For this purpose, consider to publish the solution into the staging slot of the CS.

    Note

    Attach the debugger.

  6. Locate a part of your code that is now running in Azure and set a breakpoint.
  7. Locate the Microsoft Azure node in the Server Explorer and find the Cloud Service you want to debug.
  8. Expand the node and select the deployment slot first; then, right-click on the instance to connect to (that is, Instance 0 under Production).
  9. Click on Attach Debugger.
  10. Perform the appropriate actions on the running code (firing events, for example) to cover the code where the breakpoint is set.

    Tip

    As this is a fully featured debug session, we can also inspect elements in the heap, add custom watch values, and, of course, use the immediate window against the remote VM instance.

How it works…

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).

There's more…

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.

    Tip

    Mostly, the error message is Allocation failed. Please retry later, try reducing the VM size or number of role instances, or try deploying to a different region, which is not very user friendly in this context.

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.

See also

Have a look at the following MSDN links to get additional information: