Skip to main content

Remote debugging Windows Azure Cloud Services from Visual Studio 2013

When your cloud services have been deployed and things are maybe not going quite as you expected, the first thing you may turn to is diagnostics. I recently ran into a scenario where using a Dev-Ops cloud logging service which was normally full of logs and graphical richness, decided to have it's own cloud moment and stop logging for a downtime period. This was compounded by issues that had arisen with a deployed service and understanding what was behaving unexpectedly was crucial, especially as all Integration, Smoke and Black Box tests as well as the local environment was working fine. I still had my trusty native Azure Diagnostics and Trace information inside table storage and text files but i needed more. In no time at all i was stepping through my code in the cloud as if it was running locally, well almost.

One of the nice features added to the Azure SDK 2.2 is remote debugging support for Windows Cloud Services. What makes it especially appealing is the ease at which you can debug Web and Worker roles, deployed to Azure using Visual Studio and just how simple it is to setup, which if you attempted in earlier releases of the SDK, you will appreciate.

Remote Debugging Walkthrough

Prerequisites



1: Create a Cloud Service


Feel free to skip this section if you are familiar with the process and want to jump to the good stuff.



Select a Web Role and Worker Role


Select Web API as the ASP.Net project web model



Having clicked 'OK' you will now have a cloud service project with two roles. Place your breakpoints in the desired locations, one in the worker and the other in the web controller as shown. Even though we haven't yet attached the debugger, it shows our intent for the next steps.





2: Setup Publish Settings


Now we have our boilerplate project, it's time to publish.
Select 'publish' from the cloud project as shown.



Either select 'Sign In' or if the pop up window appears in the next screen shot appears use that. either way enter your credentials you gained from creating your Azure account in the portal.




Once logged in, either create a new Cloud Service by selecting 'Create New' from the Cloud Service dropdown as shown below.


OR, select an existing Cloud Service if you created one previously as shown.
The important step at this point is to select 'Debug' as the Build Configuration as shown.



Select 'Enable Remote Debugging for all roles' as shown.



3: Publish


We are now ready to publish. Ensure the Remote Debugger is set to 'Enabled' as shown and select publish.



The progress of the deployment is shown in the Azure activity log as shown.



Once complete, the staging link will change to a deployment link as shown.



4: Attach to the debugger


Once the roles have initialized and started, you will be able to see your role instances in Server Explorer as shown.

Right click on an instance and select 'Attach Debugger'.


Click on the link in the Azure activity log shown previously to open your web role.
The web site runs in Azure as shown below.


Ensure your breakpoint is set in the controller and navigate to the API endpoint as shown below.


Your breakpoint is hit, in your local Visual Studio instance for your deployed role.



Additional Reading - How does it all hang together

When you turn on remote debugging, it packages Microsoft Visual Studio Remote Debugging Monitor (MSVSMON.EXE) as well as supporting components and deploys them to each virtual machine selected.


Orchestrating the process are two components, the Connector and Forwarder. 

Connector

The Connector  is a web service which establishes a secure tunnel between Visual Studio and the Forwarder


Forwarder

The Forwarder forwards commands in the form of requests to msvsmon.


The following diagram taken from MSDN illustrates the communication between Visual Studio, the Connector, Forwarder and msvsmon.





The configuration of the component endpoints is added to the ServiceDefinition.csdef during the package process. Of particular note are the port ranges used by each component as shown below.



Note - It may be possible to incur conflicts if other applications or services use the same port numbers. 


References



Visual Studio 2012 Support

Remote Debugging Windows Azure Cloud Services with Visual Studio 2012


Conclusion

This has been a big boost to deployment productivity and fault finding recently and it's certainly much easier than it was before to configure and get going. Happy debugging those cloud deployments!



Comments

Post a Comment

Popular posts from this blog

.Net TDD (Test Driven Development) by example - Part 1


Introduction In part 1 of this mini-series, we will develop a trivial business logic layer from scratch with a TDD approach with the goal of achieving the following:

Better code quality through Red, Green, RefactorDocumentation that grows as we develop and remains up to dateAutomatic regression test harness
This will primarily involve creating unit testsfirst, having them fail, making them pass and then refactoring the code to be of better quality and then re-running the tests. When using tools such as resharper to aid in refactoring code, having the tests in place right from the beginning really gives you peace of mind that you haven't broken anything. It also helps the thought processes while designing and developing an application or feature to be more targeted.

We will further develop the application in part 2 to add an MVC4 web client and continue the TDD story... 


Some BackgroundTest First or Test Driven development is a valuable software engineering practice. It c…

Azure Devops - Pull Request Merge Conflicts

Before a Git pull request can complete, any conflicts with the target branch must be resolved. Out of the box, at the time of writing this article, Azure DevOps requires this to be resolved locally. Following best practices to not allow direct commits to our release/master branches further exasperates the problem as we need to effectively clone the branch or go with a rebase approach, both of which break the natural flow of resolving the conflicts as part of the pull request.

With this extension, from the Microsoft DevLabs team via the Marketplace, you can resolve these conflicts online, as part of the pull request process, instead of being forced to break flow and resolve locally.




Online Experience After adding the extension the new conflicts tab is visible which enables conflict resolution in the familiar side by side review page as shown below:


Really nice extension, which should make resolving merge conflicts a much more straightforward part of the DevOps workflow. 

Additional - Ad…

Simple Git branching strategy for release cycles

Coming up with a branching strategy that works well can be challenging when working with multiple developers and managing release cycles. A simple approach is presented here to manage release cycles, with a small to medium sized team of developers while still being able to react to production issues and fix bugs. The primary goal being to isolate work streams without impacting development progress. BackgroundGit does not enforce any particular strategy when it comes to branching which is partly what makes it such a great and flexible repository. The problems start to arise though as you move into different stages of your development process. As an example, you have a release almost complete but don’t want to impede progress on the upcoming release cycle which is where the majority of effort is required. The Basic ApproachThe focus is around producing a release while still being able to react to hotfixes or production issues without impacting on going development of features. The branches…