Home/ Questions/Q 6163061
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T21:45:42+00:00

I’m looking into moving an existing app to Azure. It will have an MVC

  • 0

I’m looking into moving an existing app to Azure. It will have an MVC app in one web role and some WCF services in another web role. When live, the site will live at http://www.myapp.com and the services will be at http://api.myapp.com with the MVC app configured to point to the services at http://api.myapp.com.

The problem is when pushing the app to the “stage” configuration on Azure. My understanding is that each push to stage will cause the services to live at a new url (something random like http://4aa5ae2071324585ba5a902f4242a98c.cloudapp.net/). In this case, what is the best way for my MVC app to discover the url of the services?

One option would be to setup a dns entry like http://stage.api.myapp.com and update my DNS CNAME record to point to the new Azure staging url every time I push to stage, but… yuck.

Another option would be to push to stage, get the new urls for the services, RDC to each instance of the MVC role and manually update the configurations. Also yuck.

Is there a simple way to do this? I know I could automate some of the steps above with something like PowerShell, but I’m really hoping there’s something baked into the Azure framework that makes this easy. It seems like it would be such a standard scenario.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The only way to dynamically discover what the staging URL will be is to have the instance check its own deploymentID. I am assuming here that the MVC website and the WCF service are in the same deployment. If you check the RoleEnvironment.DeploymentID, you will find that this corresponds exactly to the ‘random’ URL used in staging (i.e. http://[deploymentID].cloudapp.net).

    As long as you are dynamically creating the ChannelFactory on the clientside, it should be able to take its own DeploymentID and find the staging URL.

    Of course, this is only useful when deployed in staging. Why don’t you simply use the Production slot? That name is stable and you can rely on it or the CNAME (more likely) that you set for it. You can always have multiple hosted services (dev, QA, prod, etc.) and just use the production slot on them.

    • 0