When we released the Azure SDK 2.2 the server side support for remote debugging Windows Azure Web Sites was not yet in production. Because of this the command was not shown in Visual Studio. We have now published the server side support in Windows Azure Web Sites, and the feature is now automatically enabled in Visual Studio.
In this post you will find the download links required to try out the new features as well as more info about the support.
How to get the new features?
In order to remotely debug your site you will need to download and install the following.
· Any version of Visual Studio 2013 which supports remote debugging
After installing the Azure SDK 2.2 you will now see a new menu option, Attach Debugger, for your Azure Web Sites. In the image below you’ll find this new menu option.
Now let’s see how you can use this new feature.
Remote debugging walkthrough
For a new site running in Windows Azure Web Site you’ll need to follow the following steps to get your remote debugging session started.
2. Invoke the Attach Debugger menu option in Server Explorer
To have the best debugging experience you should publish your site using the Debug build configuration. You can configure this for your publish profile on the Settings tab of the Web Publish dialog. The drop down is shown in the following image.
After publishing your application you can use the Server Explorer in Visual Studio to access your web sites. If you haven’t already you may need to sign in to Windows Azure in Visual Studio. You can do this using the Connect to Windows Azure button on the Server Explorer. See the image below for that button.
After signing in you will see your Web Sites under the Windows Azure node in Server Explorer. Right click on the site that you would like to debug and select Attach Debugger. When this is invoked the remote debugging agent will be started on your web site, you site is restarted with the agent attached, your default browser will be opened to the URL of your site, and Visual Studio will attach the remote debugger. The first time you do this the delay will be about 20 seconds, but subsequent usages will attach much quicker. If you disable the remote debugger option in the portal you’ll experience the ~20 second delay again.
After that you can debug your remote site as you would your local project. You can step through code, set breakpoints, break on exceptions, evaluate expressions, and all the other goodness you are used to.
Note: currently the support here is designed for single instance sites. If you attach to a web site running multiple instances, you will attach to a random instance. In the future we may look at providing a better experience here, but we do not have any specific plans yet.
Remote debugging with Visual Studio 2012
You can also remotely debug your Windows Azure Web Site with Visual Studio 2012, but you’ll need to configure a few things manually for now. We are working to bring the same experience for remote debugging to Visual Studio 2012 but we are not there yet. For now you can use the steps below for Visual Studio 2012.
- In the Windows Azure Management Portal, go to the Configure tab for your web site, and then scroll down to the Site Diagnostics section
- Set Remote Debugging to On, and set Remote Debugging Visual Studio Version to 2012
- In the Visual Studio Debug menu, click Attach to Process
- In the Qualifier box, enter the URL for your web site, without the http:// prefix
- Select Show processes from all users
- When you’re prompted for credentials, enter the user name and password that has permissions to publish the web site. To get these credentials, go to the Dashboard tab for your web site in the management portal and click Download the publish profile. Open the file in a text editor, and you’ll find the user name and password after the first occurrences of userName= and userPWD=.
- When the processes appear in the Available Processes table, select w3wp.exe, and then click Attach.
- Open a browser to your site URL.
- You might have to wait 20 seconds or so while Windows Azure sets up the server for debugging. This delay only happens the first time you run in debug mode on a web site. Subsequent times within the next 48 hours when you start debugging again there won’t be a delay.