3

We have a fairly complex system we're developing involving a few different applications (MVC, http-based WCF, TCP-based WCF, ADFS, and some generic Worker Roles), all deployed to Azure. For local debugging, we need these to run in the local Dev fabric as well as IIS. I've accomplished pretty much everything I need to and it all works, with the exception of one thing: I can't predict what IP address various things will bind to in the Dev Fabric. Sometimes it's 127.0.0.1, sometimes it's 127.0.0.3, and sometimes it's 127.0.0.4 (and maybe some others?). For my config file transforms and ADFS relying-party trusts, I need to know what these IPs will be in advance.

How do I manage/control (or at least predict) these IP addresses specifically for my web site? (WCF is all good) If I can actually get everything deployed to my dev fabric with the proper IPs being referenced, then everything works! However, it's very cumbersome to do and takes several tweaks to web.config and app.config transformation files every single time I need to (not to mention reconfiguring the ADFS server every time it changes), so this isn't a sustainable situation by any means!

Jaxidian
  • 13,081
  • 8
  • 83
  • 125
  • Which version of the Azure SDK are you using? – mcollier Feb 15 '13 at 17:49
  • I'm using v1.8 of the tools (Oct 2012) and it appears my one DLL I just checked (StorageClient) is v1.7.0.0. If upgrading is necessary, that's fine - we can do that (and will soonish anyways). – Jaxidian Feb 15 '13 at 18:45
  • 1
    FYI, it appears my question is identical to [this question](http://stackoverflow.com/questions/11967902/azure-compute-emulator-is-it-possible-to-control-the-ip-of-individual-instances) but that answer isn't seeming to apply to me. No matter what port I try, 127.0.0.1 doesn't take me to my web role. As of this moment, https://127.0.0.5:444 is what's taking me there. It's really painful having to reconfigure things so frequently (and for every single dev) every time this changes... – Jaxidian Feb 18 '13 at 14:14
  • Okay, that question isn't quite identical. Seems he wants instance-specific IPs. I'm fine with the "load balancer" IP. I just need something predictable, though. – Jaxidian Feb 18 '13 at 14:35
  • have you tried this http://blog.syntaxc4.net/post/2011/01/06/changing-the-windows-azure-compute-emulator-ip-address.aspx – dicemaster Feb 22 '13 at 16:45
  • @gauravvgat That info is no longer valid with modern versions of the SDK. The best I could find were `x64` and `x86` folders under `C:\Program Files\Microsoft SDKs\Windows Azure\.NET SDK\2012-10\bin\runtimes\base`, both of which had `IISConfigurator` in it. However, there is no config file for the `IISConfigurator.exe` in there. – Jaxidian Feb 23 '13 at 01:05
  • I bet you tried this already, but shutting down (and/or) exiting the development fabric used to fix up IP/Port issues for me in the past. – Nico Feb 23 '13 at 10:13

1 Answers1

1

We had a similar challenge with an ASP.NET MVC solution that uses a second web role running a WIF STS for Claims-Based Authentication. The web.config of the MVC application needed to know the non-load balancer IP address of the STS when running in the local emulator.

In addition, we have custom code building URL routes that only sees the internal IP address (127.255.0.X) assigned by the emulator. These routes would cause problems when passed back through the load balancer. We also shutdown the Default Web Site in IIS to guarantee the port remapping done by the emulator.

With the Azure 1.8 SDK, we observed the local emulator would consistently assign the 127.255.0.X addresses when the application was started from the command line and all other deployments in the dev fabric were removed.

We built a PowerShell script to startup the Web Roles from the command line once the solution was packaged inside VS2010. We have a build configuration and web transformation called AzureLocal we use to package for the local emulator.

Import-Module WebAdministration
Stop-WebSite 'Default Web Site'

$env:WindowsAzureEmulatorInstallPath = (Get-ItemProperty -Path "Registry::HKLM\Software\Microsoft\Windows Azure Emulator" -Name InstallPath).InstallPath
$env:ServiceHostingSDKInstallPath = $env:WindowsAzureEmulatorInstallPath + '.NET SDK\2012-10'

$env:Path = $env:WindowsAzureEmulatorInstallPath + 'emulator;' + $env:WindowsAzureEmulatorInstallPath + 'devstore;' + $env:ServiceHostingSDKInstallPath + 'bin;' + $env:Path

csrun /devfabric:start
csrun /devstore:start
csrun /removeAll
csrun /devfabric:clean

csrun Application\Foobar.Extensions.Azure\csx\AzureLocal Application\Foobar.Extensions.Azure\bin\AzureLocal\app.publish\ServiceConfiguration.Local.cscfg

Write-Host "Application Pools to Attach for Debugging"
get-item IIS:\AppPools\*

$ie = New-Object -ComObject InternetExplorer.Application
$ie.Navigate("https://127.255.0.1:444")
$ie.Visible = $true

Your applications sounds to have more moving parts than our STS and MVC combination, but if you can script the startup outside Visual Studio then you can get predictable address assignment.

tawman
  • 2,478
  • 1
  • 15
  • 24
  • You answered my question with a very small part of your answer: "and all other deployments in the dev fabric were removed". This is our problem. The allocated IP addresses keep incrementing when other things are deployed to the dev fabric but reset when you remove all deployments. This certainly isn't ideal but this is the key part to what we have to allow us to debug things without a huge amount of downtime between each compiling. Rebooting/restarting the emulator was just too much overhead each time, but we can work with this at least. Sure wish we could manage it better! – Jaxidian Feb 26 '13 at 17:13
  • @Jaxidian I understand where you are coming from as it took us a lot of trial and error to arrive at a workable local config for multiple dev machines. – tawman Feb 26 '13 at 18:13