Azure website debugging

Question

I understand that I can debug an Azure Web Role using the methods outlined here: http://msdn.microsoft.com/en-us/library/windowsazure/ee405479.aspx

What's the process for debugging a Windows Azure Website?

I'd like to be able to step through code, set breakpoints, ect.

Answer 1

As per this recent post, this is now possible.

Here are the necessary steps for Visual Studio 2012, taken from that post:

1. In the Windows Azure Management Portal, go to the Configure tab for your web site, and then scroll down to the Site Diagnostics section
2. Set Remote Debugging to On, and set Remote Debugging Visual Studio Version to 2012
3. 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
4. Select Show processes from all users
5. When you're prompted for credentials, enter the user name and password that has permissions to publish the web site
   1. 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=.
6. When the processes appear in the Available Processes table, select w3wp.exe, and then click Attach
7. 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.

Answer 2

The answer is the same as the answer to the question How to debug (asp.net) website in any shared hosting provider?

• Do your exception handling/logging properly
• Use <compilation debug="true" /> while debugging (and only while debugging)
• Enable all and any kinds of error reporting for the website (attached image below)
• [insert here your favorite way of debugging shared hosting site]

Answer 3

UPDATE: The Azure portal has changed and the Application Settings blade is being retired.

---

I think this deserves an updated answer for recent versions of the Azure Management Portal and VS.

This is how I achieved remote debugging for an ASP.Net Core 2.0 API using Visual Studio 2017 Preview 7.1:

1. Open the Azure Management Portal, browse to your Web App, click Configuration > General Settings, and turn on remote debugging. Previously it also asked for the VS version but this doesn't seem to be an option any longer, I'm assuming the remote debugging platform now auto-detects (but it may also be the case that VS versions prior to 2015 are no longer supported, see comments below)

2. Edit your publishing profile and set the configuration to Debug then republish the API to Azure:

3. Set breakpoints in your code

4. Open the Server Explorer pane in Visual Studio, and if you're not already connected to Azure with your Microsoft account, connect it.

5. Open Azure > App Service > [Resource Group] then right click your web app and select Attach Debugger. After a bit of configuration, it should attach and (if configured) VS will open a browser to your Azure web app.

6. Hit your website/API and your breakpoint should be hit.

Final notes I've collected:

• I have noticed that occasionally the "Attach Debugger" option is missing from the menu. It appears that selecting Stop from the menu (wait) then selecting Start is enough to make the option appear again, if stopping the service is an option. There may be other fixes.
• Some official documentation
• Don't forget to change the configuration on your publishing profile back to Release, and republish the Release version. Don't use Debug in production. Thanks @Manfred.
• Avoid long stops at breakpoints (Can anyone explain what the impact of this might be?)
• It appears that after 48 hours, the remote debug feature is automatically turned off (cannot confirm this yet)

Answer 4

Scott Hanselman recently blogged about this here.

This isn't as nice a setting breakpoints, but having logged information streamed to the console makes debugging slightly less painful.

Answer 5

Paul, this might be a step up for you from some of the suggestions above: "Glimpse is like the FireBug client side debugger, except it's implemented in JavaScript on the client side with hooks in to ASP.NET on the Server Side."

So while it doesn't let you set a breakpoint, at least you can watch the trace occur in real time rather than having to sift through log files.

http://www.hanselman.com/blog/NuGetPackageOfTheWeek5DebuggingASPNETMVCApplicationsWithGlimpse.aspx