Windows Azure SDK 2.2 release added support for remote debugging many types of Windows Azure resources. With remote debugging support from within Visual Studio, you are now able to have more visibility into how your code is operating live in Windows Azure and debug in-production cloud application.
Once you turn on remote debugging, it packages the msvsmon along with other component needed to communicate and deploy it to your VM. There are two main components called connector and forwarder
Connector: The connector is the a web service which listens for commands like start the forwarder component, get processes etc.
Forwarder: The forwarder listens to an endpoint for incoming request from VS to forward it to msvsmon
You would see below configuration once you turn on remote debugging. The endpoint changes are added to the configuration file during the build. In your output directory you’ll find Cloud.build.csdef/cscfg (or similarly named) files, in which you can see what actually gets deployed. The debugger uses ports 30400-30424 and 31400-3142 and configuration looks like as below.
<ConfigurationSetting value="xxxxx" name="Microsoft.WindowsAzure.Plugins.RemoteDebugger.CertificateThumbprint"/><ConfigurationSetting value="true" name="Microsoft.WindowsAzure.Plugins.RemoteDebugger.Connector.Enabled"/> <Endpoint name="Microsoft.WindowsAzure.Plugins.RemoteDebugger.Connector" protocol="tcp" publicPort="30400" port="30398" address="10.78.78.4"/><Endpoint name="Microsoft.WindowsAzure.Plugins.RemoteDebugger.Forwarder" protocol="tcp" publicPort="31400" port="31398" address="10.78.78.4"/>
RemoteDebugger.Connect uses instanceInputEndpoint to listens to the specified port for all instance and once receive request from Visual studio, it establish a TLS connection between VS and Remote forwarder. Remote debugging is done over a custom TLS connection, rather than via msvsmon’s built-in connection security, because msvsmon was not designed to be used over the internet. The forwarder is the server-end of that connection that listens to the endpoint for incoming request from VS and it forwards incoming traffic to the msvsmon instance running on the same box. Once the connection in established then it will hit the breakpoint in your code in VisualsStudio.
To enable remote debugging for your cloud service, select Debug as the Build Configuration on the Common Settings tab of your Cloud Service’s publish dialog wizard:
Then click the Advanced Settings tab and check the Enable Remote Debugging for all roles checkbox:
Once your cloud service is published and running live in the cloud, simply set a breakpoint in your local source code:
Then use Visual Studio’s Server Explorer to select the Cloud Service instance deployed in the cloud, and then use the Attach Debugger context menu on the role or to a specific VM instance of it. You can also attach multiple instance if available.
Once the debugger attaches to the Cloud Service, and a breakpoint is hit, you’ll be able to use the rich debugging capabilities of Visual Studio to debug the cloud instance remotely, in real-time, and see exactly how your app is running in the cloud.
Instances: Publish will fail if the role has more than 25 instances.
Traffic: As the debugger communicates with Visual Studio and that Azure charges for outbound data. The data transferred is not big and shouldn’t be too big a deal.
Native debugging: For CTP tooling does not enable native debugging.
Ports: The debugger uses ports 30400-30424 and 31400-31424. If you use ports that conflict with the debugger ports you’ll see the following message: "Allocation failed. Please retry later, try reducing the VM size or number of role instances, or try deploying to a different region."
VS Restart after full deployment: If you do a full deployment and the VIP changes you need to restart VS to attach the debugger.
A GOOD WALKTHROUGH WOULD HAVE BEEN NICE
Thanks Srinivasan for your feedback. MSDN has published an article with step by step setup. Let me know if this helps.