-1

I'm trying to remote debug an asp.net core 1.1 api app (targeting .net framework 4.5.2) that's running on Azure.
I attach the debugger via Server Explorer. The debugger attaches to the correct process. But any breakpoint I set has the message "The breakpoint will not currently be hit. No symbols have been loaded for this document."
All answers I've seen to such a problem assume that the modules window shows all modules loaded by my project, but in my case the modules window is empty!
I'm on VS2017 15.4.
If I remember correctly, I was previously able to remote debug the same project with version 15.2. The problem started occurring when I updated to 15.3 but I didn't pursue it at the time.

Evandro Paula
  • 2,176
  • 2
  • 12
  • 23
Dan Z
  • 523
  • 5
  • 15
  • I always have this error when the version on the server is different (older) than the code version. – nico boey Oct 16 '17 at 07:19
  • @nico - the version of the code I'm using for debugging is exactly the same version used to build the app that's running on azure – Dan Z Oct 16 '17 at 07:42
  • I occasionally get hit by this, have you made sure that the deployed configuration is Debug and not Release? The breakpoints won't be hit if it's in release mode. – Nick Oct 16 '17 at 09:24
  • @Nick - for the record I'm in Debug configuration. But I don't think your comment is relevant, because even in Release I shouldn't be facing an empty modules window – Dan Z Oct 16 '17 at 11:08

2 Answers2

2

I submitted the problem on the MS forums: Can't remote debug Azure API app

and now I have received an official reply that it is indeed a bug in VS, and a fix will be available in the pending release (15.6).

They also suggested a workaround, which I tried and indeed worked: Manually Attach a Debugger to Azure Web Apps

Which involves:

  1. Going to the web app Application settings in the Azure portal, and making sure that Remote debugging is enabled,

  2. In the VS menu: Debug > Attach to Process..., entering the web app url with the debugging port, e.g.:

    myapp.azurewebsites.net:4022

  3. Then in the credentials that appears, entering the username & password that are available in the app's Publish Profile, which can be downloaded from the portal. If the username is $myapp, it should be entered like this: 

    $myappp\$myapp

  4. Then choosing Managed(v4.6, v4.5, v4.0) code and then the name of the Core app.

Actually, I had found and unsuccessfully tried similar approaches before. The key for me was step 3. The others had suggested entering the username as .\$myapp, or myapp\$myapp. So make sure to enter it as written above.

BTW, seeing that the above blog post is from almost 2 years ago (Feb 2016), whereas the problem I'm experiencing was introduced only a few months ago, it seems to be a cure-all, and it is therefore worthwhile, for anyone who has to deal with remote debugging Azure apps, to save this information for future reference.

UPDATE: After updating VS 2017 to version 15.5.2 the problem seems to have been fixed.

Dan Z
  • 523
  • 5
  • 15
  • Thanks this worked for me. Just stopped working a few weeks ago. Could have been a VS update. I am currently on 15.7.3 but at least this is a workaround – SpeedOfSpin Jun 08 '18 at 12:24
0

I have had the same issue with Visual Studio 2019. The fix for me was just to go in the VS menu: Debug > Attach to Process, and try to connect as describe by @Dan Z. The connection was not established, saying No connections found, but attaching a debugger from Cloud Explorer again, right after an attempt in "Debug > Attach to Process" is always successful. That is most probably a bug in VS

Dovlet Mamenov
  • 511
  • 6
  • 20