Development Fabric "Port walking" RRS feed

  • Question

  • Does anybody know if there is a way to _stop_ the development fabric from "Port Walking"? In other words, between builds, it is common for a web role to start on port 81 instead of 80, then next time on 82, etc. This is problematic when developing against a live STS (passive mode) site that wants to redirect to an FQDN, which we override in local HOSTS files for development purposes. However, as soon as the port changes from 80, this no longer works until to shutdown the development fabric and wait for the port 80 binding to release.


    Tuesday, September 28, 2010 2:39 PM

All replies

  • When I develop using a FQDN I turn off IIS which frees up port 80 for Azure. However, this is typically in the context of an external authentication provider (Windows Live Id) which requires me to configure a return URL post authentication - not in the context of a local STS.
    Tuesday, September 28, 2010 2:50 PM
  • That's exactly what we're doing...using an external auth provider (not a local STS) that requires a return URL. Also, IIS is not running locally...as mentioned above, the dev fabric will __normally__ start and run on port 80. However, we're find that occasionally (randomly?) between local builds/deployments, the browser initially opens on 81/82/etc...very annoying.

    Tuesday, September 28, 2010 3:47 PM
  • Do you ensure, using the development fabric UI, that the existing app has been torn down and is no longer resident in the development fabric?
    Tuesday, September 28, 2010 3:56 PM
  • I think this may be the crux of the issue...When you re-deploy from VS2010, it tears down the current app, and deploys the new package. From an "outsider's" point of view, this should be enough to start again on the same port. However, when the port-walking behavior begins, the only way to get back to port 80 is to complete shut down the fabric (right-click on the tray icon, and choose "Exit") and wait a few seconds.

    This has led us to believe that there is a behavior issue with the dev fabric...make sense?

    Tuesday, September 28, 2010 5:15 PM
  • To answer your initial question, yes - the "old" app always disappears from the fabric UI (however, I never assumed that meant it was actually tore down completely).
    Tuesday, September 28, 2010 5:16 PM
  • Bump for any ideas?
    Wednesday, September 29, 2010 5:56 PM
  • Hi,

    I've also encoutered such behavior. Restarting the local development fabric fixes the issue. I assume this has to be related to the "Undeployment" process. When you rerun your project, VS deploys your new packed to the development fabric. However the older instance (already out of UI) might still have to clean/shutdown and is still occupiing port 81.

    You can a "Pre-Build" event process to execute prior each build of your Cloud Service projec, which would be something like:

    "C:\Program Files\Windows Azure SDK\v1.2\bin\csrun.exe" /devfabric:clean

    If it doesn't work, then just do:

    "C:\Program Files\Windows Azure SDK\v1.2\bin\csrun.exe" /devfabric:shutdown

    That one will completely shutdown the development fabric, and new fresh instance will be launched. This might introduce delay in starting the application!

    While haven't tried it 100 times, I think this one solves the issue.

    Wednesday, September 29, 2010 8:16 PM
  • Well, at least on Vista x64, this doesn't make a difference. The first run starts on port 80, then after that we move to 81 (which seems a little more stable, but occasionally 82 comes up). Haven't tried on Win 7 yet....quite painful!
    Wednesday, September 29, 2010 8:41 PM
  • Have you tried it with the "shutdown" option, instead the "clean" ? I am runing side-by-side with local IIS started (on Server 2008 R2) and my dev fabric runs on port 81 always.
    Wednesday, September 29, 2010 8:49 PM
  • Yes...also just was experimenting with the /removeAll option as well (which made no difference - the second deployment immediately wants to run on port 81 instead of 80). Notice that our special affinity for port 80 is due to working with deployed STS's that need FQDN's in order to redirect correctly (see original post).

    I guess for now, we'll just have to baby-sit the service...it would be absolutely **grand** if the port remained stable (regardless of 80, 81, etc), just like the WebDev server does.
    Wednesday, September 29, 2010 9:07 PM
  • Oh,m

    by the way, I just remembered another issue with port 80. If you are using Skype, and haven't changed default settings, and Skype starts before any other program or service that will reserve port, guess what! Skype listens on port 80! It can be changed from "Tools" -> "Options" -> "Advanced" -> "Connection" -> uncheck the "Use port 80 and 443 as alternative for incoming connections".

    Thursday, September 30, 2010 5:37 AM
  • **laugh** Yes, ran into that already...

    Thursday, September 30, 2010 2:07 PM