I had been working on a demo recently where I wanted to show an ASP.NET MVC site that was hosted in Windows Azure and was accessible over HTTPS. Easy enough, right?
While prepping the demo I kept noticing that when running my site in the Windows Azure compute emulator, the port would be set to something other than 443 (often 444 or 445).
That was kind of strange to me because I set the site to use 443. With the emulator, if you specify a port (like 443) and that port is not available, the emulator will increment the port number until it finds one it can use. With that knowledge, I set out to find what was using 443.
Turns out, the default web site in my IIS install on my dev machine was running and was set to use 443 for HTTPS.
I figured if I shut down the default web site, I would then free up port 443 and be able to use it via the Windows Azure compute emulator. I did that . . . and no joy. I figured maybe then I would need to restart the emulator. I did that by right-clicking on the emulator and selecting “Shutdown Compute Emulator”.
The emulator still would not run my site on 443 and instead launched it on 444. What the heck?
After much fussing around, and a little help from the esteemed Wade Wegner, I learned the emulator actually gets the list of available ports when the emulator starts up. And I’m not talking about a simple shutdown/start from the emulator’s menu. I mean when the entire thing first starts up. For me, this meant I needed to right-click on the emulator icon and select “Exit”. That essentially kills off the entire emulator process.
Now when I start my app, Visual Studio will relaunch the emulator. My site is now running on 443. Happiness!