1

I created a new ASP.NET 5 RC1 WebApp using Visual Studio 2015 and published it to Azure. I turned on remote debugging and selected VS 2015 for the debugger. I can attach to the WebApp, but any breakpoint I set is not showing up completely red. Hovering over the breakpoint gives you the message "The breakpoint will not be currently hit. No symbols have been loaded for this document." I did a bunch of searches to see if anyone else had encountered this issue. I found some articles that seemed to indicate the solution:

Remote debugging Azure website: Breakpoints not hit

Azure Website Remote Debugging with git deploy not working

I tried turning off "Just my code" and adding the app setting, but neither of these worked. I even had a colleague try the same thing from his system and his Azure account to make sure it wasn't just an environmental issue on my system. Does anyone know how to fix this?

Community
  • 1
  • 1
Steve W.
  • 413
  • 1
  • 5
  • 12
  • Can you clarify the type of WebApp you are created? e.g. is it a standard MVC 4 app, or is it using the pre-release ASP.NET 5 (aka dnx, which works very differently)? – David Ebbo Dec 11 '15 at 17:08
  • It's a ASP.NET 5 MVC 6 app. I verified the same steps work for a ASP.NET 4.x app. – Steve W. Dec 12 '15 at 17:32

1 Answers1

2

The problem is the VS 2015 Azure tooling is not yet DNX aware at the debugger level. So for now, you'll need to manually attach the debugger, using the steps documented in this article.

Once you get the list of processes, you'll want to attach to the dnx.exe process, instead of the usual w3wp.

I just tried with a new ASP.NET RC1 app, and was able to set and hit breakpoints. It took a while to attach and load symbols, so be patient :)

David Ebbo
  • 42,443
  • 8
  • 103
  • 117
  • This worked. Thanks! One caveat. It appears you need to be use a x86 version of your app since the VS debugger is x86. I had x64 version of my WebApp deployed and it wouldn't work. – Steve W. Dec 14 '15 at 16:57
  • That's strange, I would have expected it to be able to attached to either type. – David Ebbo Dec 14 '15 at 19:17
  • BTW, are you referring to the bitness of your Azure Web App (set in portal), or of the DNX app you deployed? – David Ebbo Dec 14 '15 at 19:19
  • The WebApp. I didn't think about the setting in the portal. Should I just flip the setting in the portal to match that of the app I'm deploying? The error message I saw didn't seem to indicate that was the problem. – Steve W. Dec 14 '15 at 19:25
  • No, the portal setting should be irrelevant since it's running in a different process. So you're doing the right thing, and I'm not sure why 64 bit doesn't work. Maybe worth tackling as a separate question where someone else might know the answer :) – David Ebbo Dec 14 '15 at 23:43