if (RoleEnvironment.IsAvailable) { // Azure-specific actions }
With this check, you could, say, build a class library that has specific behaviors depending on the environment in which it’s running.
Now, let’s assume the Azure environment is available, and you need to take a specific action depending on whether you’re running in the Dev Fabric vs. the Azure Fabric. Unfortunately, there’s no specific method or property in RoleEnvironment that helps us out.
This brings me to today’s tip: Determining whether an app is running in Dev Fabric or Azure Fabric.
The Deployment ID
While there’s no direct call such as RoleEnvironment.InDevFabric, there’s a neat trick I use, making it trivial to figure out. A disclaimer first: This trick is dependent on the specific way the Dev Fabric and Azure Fabric generate their Deployment IDs. This could possibly change with a future SDK update.
Whenever you deploy an Azure application, the deployment gets a unique Deployment ID. This value is available in:
RoleEnvironment.DeploymentId.
As it turns out, the deployment ID has two different formats, depending on runtime environment:
- Dev Fabric: The deployment ID takes the form of deployment(n), where n is sequentially incremented with each Dev Fabric deployment.
- Azure Fabric: The deployment ID is a Guid.
private bool IsRunningInDevFabric()
{ // easiest check: try translate deployment ID into guid Guid guidId; if (Guid.TryParse(RoleEnvironment.DeploymentId, out guidId)) return false; // valid guid? We're in Azure Fabric return true; // can't parse into guid? We're in Dev Fabric }
Taking this one step further, I wrote a small asp.net demo app that prints out the deployment ID, along with the current instance ID. For example, here’s the output when running locally in my Dev Fabric:
Here’s the same app, published to, and running in, the Azure Fabric:

Try it yourself
I uploaded my demo code so you can try it out yourself. You’ll need to change the diagnostic storage account information in the asp.net role configuration, prior to deploying it to Azure.
Nice tip, David. But diagnostics may not be a good example for this case, as Diagnostics connection string can be configured to point to Dev/Azure store. Also I think, format of the deploymentid is not officially documented to be in respective formats(but nice observation though!!!). So I am afraid that this approach may not work as expected, if future SDK versions make DeploymentId in DevFabric also as Guid type for consistancy sake. (Just something to be aware of)
ReplyDeleteHi Rajesh,
ReplyDeleteYou're absolutely right - this method is completely dependent on the dev fabric and SDK producing specific output for deployment ID. I'll update my post with an appropriate disclaimer.
As for the example: I was simply trying to illustrate that you can take different actions depending on the environment in which you're running (which might be helpful during early stages of development).
Regards,
David
David,
ReplyDeleteThanks for the insight. This determination helps to automate the process of switching resources between development and production.
Hopefully there will be an method in the future to guarantee the determination.
Cheers,
Jeff
David,
ReplyDeleteWould RoleEnvironment.IsAvailable every be false in the cloud? I seem to be running into issues in Application_Start and it looks like it is false in the cloud. Maybe it's not "Available" until it is "Ready". Ever run into this? (I'm checking with MS right now).
Thanks,
Nate
Thanks David,
ReplyDeleteHave a question - do you know of a way to find all deployment IDs running under a specific subscription?
thanks,
Nava
I am constantly getting RoleEnvironment.IsAvailabale as False.. Please help me to sort this issue.
ReplyDelete