locked
Multiple web sites no longer working with v1.5 RRS feed

  • Question

  • So I just upgraded to sdk v1.5 and I can no longer debug in Visual Studio (2010).  I'm getting the dreaded: error attaching to IIS process error.  I can run just fine without debugging.

     

    My azure web role is setup to run multiple web sites as described in this article:

    http://www.wadewegner.com/2011/02/running-multiple-websites-in-a-windows-azure-web-role/

    It was working just fine in v1.4 - debugger and all.  So when I removed all sites but one, it works just fine.  This does seem to be a bug in v1.5.  Please confirm.

    Friday, September 16, 2011 4:02 AM

Answers

  • In this release, the sites are now bound to IP address 127.255.0.0 instead of the loopback address used in previous releases. You should be able to debug the sites if you map their host names to the new address in your hosts file. For example,

    127.255.0.0 www.fabrikam.com

    127.255.0.0 www.contoso.com

    127.255.0.0 www.litware.com

    • Proposed as answer by Andy Cross Friday, September 16, 2011 6:39 AM
    • Marked as answer by MSDev23 Wednesday, September 21, 2011 3:37 PM
    Friday, September 16, 2011 4:45 AM
  • Is it because when multiple sites are present, the load balancer uses 127.255.0.0 and port 82?


    No. The load balancer uses 127.0.0.1 with multiple sites too and, as you've already seen, when you run the sites without debugging them, you can map their host names to 127.0.0.1 and they will run just fine. The problem is that to debug them, Visual Studio needs to attach to the worker process of each site. I believe it uses some mechanism that involves making HTTP requests to IIS with the DEBUG verb to select the correct process and attach to it. Presumably, the fact that the sites are now bound to different IP addresses breaks this mechanism. After you change the site's mapping to its internal address, Visual Studio is able to attach the debugger successfully.

    Note that by doing this, you are effectively bypassing the load balancer. It probably doesn’t make a lot difference because the workaround applies only if you launch a single role instance. If you have multiple role instances, then each instance will have a different IP address, and you can only map one of these addresses in the hosts file, so it will fail for all but one of the instances.

    Alternatively, you can keep the original mapping in the hosts file and start the project with CTRL + F5. Once it has started, you can attach the debugger manually to the worker process(es) involved.

     

    • Marked as answer by MSDev23 Wednesday, September 21, 2011 3:36 PM
    Monday, September 19, 2011 2:14 AM

All replies

  • In this release, the sites are now bound to IP address 127.255.0.0 instead of the loopback address used in previous releases. You should be able to debug the sites if you map their host names to the new address in your hosts file. For example,

    127.255.0.0 www.fabrikam.com

    127.255.0.0 www.contoso.com

    127.255.0.0 www.litware.com

    • Proposed as answer by Andy Cross Friday, September 16, 2011 6:39 AM
    • Marked as answer by MSDev23 Wednesday, September 21, 2011 3:37 PM
    Friday, September 16, 2011 4:45 AM
  • Thanks for the response Fernando.  I just want to make sure I understand this correctly (on the local emulator):

    - Each instance is running on 127.255.0.1, 127.255.0.2, etc...

    - The load balancer still listens at 127.0.0.1 and port 8x

    So if the above two statements are true, why can't I map the host names to 127.0.0.1?  Is it because when multiple sites are present, the load balancer uses 127.255.0.0 and port 82?

     

    Thanks again!

    Friday, September 16, 2011 12:38 PM
  • Is it because when multiple sites are present, the load balancer uses 127.255.0.0 and port 82?


    No. The load balancer uses 127.0.0.1 with multiple sites too and, as you've already seen, when you run the sites without debugging them, you can map their host names to 127.0.0.1 and they will run just fine. The problem is that to debug them, Visual Studio needs to attach to the worker process of each site. I believe it uses some mechanism that involves making HTTP requests to IIS with the DEBUG verb to select the correct process and attach to it. Presumably, the fact that the sites are now bound to different IP addresses breaks this mechanism. After you change the site's mapping to its internal address, Visual Studio is able to attach the debugger successfully.

    Note that by doing this, you are effectively bypassing the load balancer. It probably doesn’t make a lot difference because the workaround applies only if you launch a single role instance. If you have multiple role instances, then each instance will have a different IP address, and you can only map one of these addresses in the hosts file, so it will fail for all but one of the instances.

    Alternatively, you can keep the original mapping in the hosts file and start the project with CTRL + F5. Once it has started, you can attach the debugger manually to the worker process(es) involved.

     

    • Marked as answer by MSDev23 Wednesday, September 21, 2011 3:36 PM
    Monday, September 19, 2011 2:14 AM
  • Thanks for the detailed response, Fernando.
    • Edited by MSDev23 Wednesday, September 21, 2011 3:36 PM
    Wednesday, September 21, 2011 3:36 PM