1

I am trying to debug a combination of an ASP.NET MVC 5.2 application along with a console app (that is communicating to the ASP application), so while working on it I'm regularly making changes to the console app without modifying the web app. I am trying to have both set as the (multiple) startup projects, however this problem happens when I just have the web app set as the (single) startup project.

Problem

When I make a modification to the ASP.NET code (or dependencies) and then Start Debugging (F5), it recompiles, launches my browser, and everything is good.

If I stop debugging, then immediately start again (without making any changes), it doesn't attach the debugger. On a breakpoint, I get the error "The breakpoint will not currently be hit. No symbols have been loaded for this document"

enter image description here

Other observations

I did notice after I press Stop in VisualStudio, iisexpress stays running with web app still working.

Interestingly, when I go to "Attach to process" after I've started debugging (but while it doesn't have symbols loaded), iisexpress.exe is grayed out, indicating it's already attached.

If I use "Attach to process" to attach to the running iisexpress.exe while debugging is not started (but no other code changes or recompilations have been done), it also doesn't load symbols.

How can I get it to load symbols correctly? This could include forcing iisexpress to stop when I stop debugging, or forcing the web application to always recompile even if there are no code changes.

gregmac
  • 24,276
  • 10
  • 87
  • 118
  • I did find a workaround, which is to [touch the web.config in a post-build event and force IISExpress to restart](http://stackoverflow.com/questions/12590963/can-visual-studio-restart-iis-express-on-new-debugging-session). I don't really understand why this works -- it's still the same source code, binaries and pdb files -- while simply attaching VS to the existing process doesn't. Surely there is a better way than this, though? – gregmac Dec 03 '15 at 15:45
  • Another workaround: clean your solution between debugging sessions. – Chris Simmons Jan 23 '16 at 18:36
  • I had to close both instances of VS2013 and VS2015. Open VS2015 and not VS2013. – JoshYates1980 Feb 25 '16 at 18:54

0 Answers0