4

I maintain an ASP.NET web application (.NET 3.5) which is run as a "plugin" to an old "umbrella" ASP website.

To debug it after making some change, I...

  1. build the webapp and
  2. load the "umbrella" website
  3. which in turn will instantiate the IIS worker process (i.e. in its own application pool separate from the old ASP stuff).
  4. Then I attach my VS2008 debugger to that process.

Now that I have moved to hosting all this in IIS 7, I cannot get the debugger to hit a breakpoint unless I do an IIS reset between steps 1 and 2.

Why is this the case and how can I fix it? I imagine it is an IIS 7 setting?

Lisa
  • 4,333
  • 2
  • 27
  • 34
  • 50 rep is a big sacrifice for me but I'm really keen to fix the problem! – Lisa Aug 08 '11 at 01:35
  • 1
    Building the app should invalidate the AppDomain (if you're output dir is same as App Dir under IIS), so you shouldn't have to IISReset. How are you building and deploying? I guess we need more details here. – Mrchief Aug 08 '11 at 02:41
  • I have a virtual directory in IIS which is a symbolic link to the bin folder of the webapp code I'm debugging. I think this is a fairly sensible approach. I completely agree that building the app would invalidate the app domain. In fact I think this happens. Doesn't help me know what to do to make the process in new app domain hit debug breakpoints without IIS reset. – Lisa Aug 08 '11 at 05:39
  • @Mrchief On second thoughts, I'm wondering if the AppDomain *would* be invalidated because I'm rebuilding this as a plugin, not rebuilding the "umbrella" app. Any suggestions for me to verify exactly what is happening? – Lisa Aug 10 '11 at 04:18

1 Answers1

3

Is a new process really being started by the umbrella site or is it just looking for the .net site process and finding it, just uses it. I don't think your newly deployed code will be picked up by IIS necesarily. Certain files must be changed (eg web.config) for the process to recycle itself and pick up changes, otherwise IIS will continue to run the code that is in the current app pool process.

I think this is how IIS works - when you first browse your site, IIS fires up the app pool that is running it and the site runs and exists in memory. It stops looking at most of the physical files and just runs the site from within memory. If you make some changes to the code base IIS won't necessarily pick up on those changes. Only when you change certain files, like web.config, will IIS recycle the app pool and thus pick up the changes you've made. This leads to IIS running one set of code and VS2008 having a different (newer) set. When the code doesn't match you can't debug it.

I think you might be able to add to what files are watched for changes but I'm not sure how to do this.

Instead of doing an IISRESET you could just recycle the app pool. At least this will be quicker for you.

James Gardner
  • 671
  • 4
  • 21
  • This sounds like it is on the right track. I will have to verify that it solves the problem when I have time over the next few days. – Lisa Aug 08 '11 at 05:36
  • I can't find a wait to automate the recycling of the app pool from a typical VS2010 debugging workflow. Any advice? – Lisa Aug 08 '11 at 05:41
  • No, sorry. I was thinking just have IIS Manager open and hit the recycle button for the app pool. Not great but quicker then IISReset. For development purposes can you run the .net app as a standalone website or run site and debugger directly through VS2010 rather than attaching to a process? Again, this isn't really answering your question so I'll leave it at that. – James Gardner Aug 08 '11 at 21:24
  • Unfortunately I haven't figured out a way to run the debugger directly in the normal way with this particular project. All the other devs attach their debugger to the process since before the 3 months I've been at the company, but I'll look for a workaround. Thanks – Lisa Aug 08 '11 at 23:10
  • James, the suggestion to recycle the app is the best suggestion I've had and some other devs here have been doing it. It's slightly better than iisreset. Anyway, since I'm going on leave and won't be around for the rest of the bounty period you get the 50+. – Lisa Aug 10 '11 at 02:27
  • 1
    Thanks Lisa. I wish I could have given a more deserving answer. If I think of anything else I'll edit my answer. – James Gardner Aug 10 '11 at 02:46
  • Marking this as answer because I have not been able to find a better way to ensure the debugger is pointing at the correct process. I've found I can just leave IIS window open and hit Recycle as a part of my workflow fairly quickly now. – Lisa Sep 16 '11 at 02:50
  • 1
    +1 for the advice about restarting the App Pool. This meant that my W3WP process was still available in Visual Studio to attach my debugger to after recylcing. With an IIS reset it as not. This enabled me to debug my application start up code which I could not do easily after a full IIS reset. Thanks :) – Remotec Apr 03 '13 at 14:07