2

So I am trying to debug a process in MVC4. I send the POST request, watch it manipulate the database, etc etc. However, after I have seen the information I want to see, I click "Stop Debugging". In any typical GUI .NET application, I would think that the process would terminate, but it instead continues to execute. If I make any changes in the file and try to debug again, the breakpoints will not be hit because the files are not out of date from the previously ran process which is still running. I have 2 choices at this point - let it run or kill the w3wp.exe task with the Task Manager in order to continue debugging.

I have tried to click Debug -> Terminate All, but the process still continues to execute. I know this because I attach to the process (Debug -> Attach to Process) and it pauses at one of my many breakpoints throughout its execution.

Let it be mentioned that I am using Google Chrome to send the POST requests to the Controller, so it may not be terminating because I am not using IE - however, I do think that there is a better solution then using the IE browser.

In order to work around this, I have to go into the Windows Task Manager and kill the IIS process (w3wp.exe), which seems downright messy. Any ideas?

Kevin
  • 557
  • 4
  • 18
  • I suspect you must be missing something. While it's true that w3wp.exe does not terminate, when you *restart* your debugging session, it *will* use your updated code (it will compile new assemblies and IIS will naturally spawn a new app domain that will consume your new files). You should not have any difficulty debugging those new files in your new session without having terminated w3wp.exe. – Kirk Woll Nov 09 '13 at 03:08
  • That is what I thought, but it kept on using the code from the previous compiled binaries. I think it is because the compiled binaries have a lock by w3wp.exe and VS2012 will not update binaries that are locked. It is important to state that the time to execute this process takes a couple of minutes, so it may be because I am trying to execute it again within the time frame that it is still executing... – Kevin Nov 11 '13 at 00:53
  • If your web process is indeed taking a while, then it's true you could see the issue you describe. A new app domain will only be relavent when servicing new requests. If you are trying to step into an existing long-running request, then you will not see your changes. However, is it that much trouble just to re-run whatever it is you were doing? Naturally, when invoking a method -- however long it takes to finish -- I would not expect newly compiled code to be injected into it before it's done. – Kirk Woll Nov 11 '13 at 01:29
  • Simply re-running the process (which already takes 5 - 10 min) is not desired as the process is itself is behaving incorrectly with the database and I need to prevent it from adding the wrong data while I debug it. I mean, I can just remove all the database updates too when testing the code. I was just hoping that there was a cleaner solution – Kevin Nov 11 '13 at 16:07

2 Answers2

0

If I make any changes in the file and try to debug again, the breakpoints will not be hit because the files are not out of date from the previously ran process which is still running.

Once you modify any code file you require to re build the solution and then again Debug -> Attach to Process.

Please also note that Stop Debugging does not mean that it will kill process always. It will kill only Visual Studio Web Development Server or sometime IIS Express process with Visual Studio. Here you mentioned w3wp.exe. While this process is managed by IIS.

Nandip Makwana
  • 356
  • 4
  • 16
  • So I am using the normal IIS and not IIS express. Would you suggest using IIS express to have better control of that process? – Kevin Nov 11 '13 at 00:54
  • No keep using IIS, only make sure you re build and attach to process again or start debugging again (by pressing F5) once you modify any code file. – Nandip Makwana Nov 11 '13 at 16:25
0

Couple more graceful ways to restart your w3wp worker process:

  • in command line, run "iisreset"
  • in IIS Manager console, select the corresponding application pool and click "recycle"

For a graceful shutdown of a long-running business logic, try Application_Shutdown event in global.asax.

For not-so-graceful approach, ThreadPool may help you - threads on it are marked as Background and thus Windows won't wait for them to complete when main thread of w3wp exits. However this approach doesn't always work, because 3-rd party libraries (especially networking) may create non-background threads that, again, will delay shutdown.

For even faster and dirtiest, use Environment.Exit, triggered by some debugging-only event. http://msdn.microsoft.com/en-us/library/system.environment.exit(v=vs.110).aspx

Roman Polunin
  • 53
  • 3
  • 12
  • I tried iisreset but since the process takes a couple of minutes to execute, iisreset stalls until the process finishes executing. I would prefer if I could do a "iisreset force", but it does not seem like a possibility – Kevin Nov 11 '13 at 00:56
  • In this case, you have a problem with the design. Consider revising your application this way: 1) start long-running process in a background thread, 2) keep listening for application recycling events 3) try to terminate gracefully when you know that app is about to shut down. Here's a relevant post: http://stackoverflow.com/questions/4723573/how-to-listen-to-iis-shutdown-event-in-asp-net – Roman Polunin Nov 11 '13 at 16:46