Question

How can I reliability detect whether my Azure application is running in development fabric and not in 'the cloud' ?

RoleEnvironment.IsAvailable is true for both. I want something that is true in only one case.

I'm asking this because I want users of my library to be able to use my library for free in dev fabric. Hence manually putting separate identifier or flag in config file and keeping two configs for dev and deploy is not feasible.

Was it helpful?

Solution

One option is to take a look at RoleEnvironment.DeploymentId - if you're running in the dev fabric, it should have a name like 'deployment(n)' where n is some sequential number. If you're running in production, the deployment id should resemble a Guid.

Another thing you can do is look at an role's instance name. In production, it should end in _0 (representing instance 0). In the dev fabric, it will end in .0

EDIT 1/8/2013 - realized this answer I gave over 2 years ago is quite outdated! Now there's also RoleEnvironment.IsEmulated - check out the details here.

OTHER TIPS

The Windows Azure 1.5 SDK introduced the RoleEnvironment.IsEmulated static bool property to determine from code whether the role instance is running in the Windows Azure compute emulator. This information can be passed to startup tasks too. There is a great article from Steve Marx here about that.

For example:

The development fabric does not fully simulate the behavior of the Windows Azure load balancer. For example, if code running in a web role instance calls the SetBusy method from within the RoleEnvironment.StatusCheck event handler to indicate that the role instance should be taken out of the load balancer's rotation, you will still be able to access your role from your browser while its status is RoleInstanceStatus.Busy.

Also azure fabric normally runs under one of the few fixed OS Images. So you can also investigate System.Environment. for some patterns that occur only in azure fabric (i.e. specific OS version matching to Windows Azure OS or something like this).

There is a very simple technique I have been using for a while - and find myself using it frequently. The trick is to set an environment variable on your dev machine and using basic DOS batch file (or PowerShell) techniques, jump over the stuff you don't want if that variable is present. This environment variable will not be present in the cloud.

I blogged about it here: Azure FAQ: Can I create a Startup Task that executes only when really in the Cloud?

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top