我可以检测我的代码是否在 Azure 辅助角色中执行吗？

Question

I have some shared assemblies/projects that are used within Winforms apps, windows services and now Azure worker roles.

Is there any way that I can detect at runtime if I am running in an Azure role.

I have found how you can detect if running Azure emulator or not:

 Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.IsEmulated

But this does not do what I want. I would also prefer not to have to add references to any of the Azure assemblies in my shared assemblies.

Ideally I would like something similar to what I use to detect if running as a console vs a service:

System.Environment.UserInteractive

Is there anything that gives me this logic?

Answer 1

For anyone interested, thought I would sharehow I implemented, thanks to @Sandrino Di Mattia's answer:

You can check for the presence of the RoleRoot environment variable (for Cloud Services at least):

Note that this does NOT cater for a Winforms App as I only actually required it in the end for Services - ie detecting between service running as

• Azure Worker Role
• Windows Service
• Console Application

This is an outline:

public static class ServiceRunner
{
    private static bool IsAzureWorker
    { 
        get { return !string.IsNullOrEmpty(Environment.GetEnvironmentVariable("RoleRoot")); } 
    }

    public static void Run(string[] args)
    {
        if (IsAzureWorker)
        {
            //Running as Azure Worker
        }
        else if (Environment.UserInteractive) //note, this is true for Azure emulator too
        {
            //Running as Console App
        }
        else
        {
            //Running as Windows Service
        }
    }
}

Answer 2

You can check for the presence of the RoleRoot environment variable (for Cloud Services at least):

• MSDN

Or, why not simply add a setting to your config (AppSettings or Service Configuration):

  <appSettings>
    ...
    <add key="AppEnvironment" value="Azure.CloudService|Azure.Website" />
  </appSettings>

Then you can simply check if the setting exists with a specific value to see where you're running. This also means that during your (automated) build or deploy process you'll need to include this setting (this is possible with XDT for example).

Answer 3

We set an environment variable (in this example INAZURE) as a startup task via a batch file.

Contents of SetEnvVar.cmd batch file:

setx INAZURE True /M

Configure the batch file to start via your cscfg file:

<Startup>
  <Task commandLine="SetEnvVar.cmd"
    executionContext="elevated"
    taskType="simple" />
</Startup>

Then write something to read this environment variable. There is a static RoleEnvironment class in the Azure SDK you can use, but this references nasty unmanged assemblies that make build server configuration a PITA. Things may have gotten better in more recent releases of the Azure SDK.

I have a closely related blog article at: http://adrianwithy.com/2012/02/06/remove-msshrtmi-dll-as-a-dependency-in-your-azure-project/

Answer 4

When I tried the "RoleRoot" environment variable in a web role, it returned null, unfortunately breaking the elegant solution shown above. Perhaps Microsoft changed something since 2013 or the solution is only valid for worker roles, not web roles.

The alternative below I saw working properly for a from-the-box configured webrole (not running elevated). Although the role is by default running as "network service", it can detect the presence of "f:\\RoleModel.xml". Probably that is required because the configuration file contains information required in the role startup code. Note that the code does not depend on the actual drive letter, that may change in future Azure images:

/// <summary>
/// Returns true if the application is detected to be running in an Azure role (tested for web roles).
/// </summary>
public static bool RunningInAzure
{
  get
  {
    try
    {
      string sCurrentDrive = Path.GetPathRoot(AppDomain.CurrentDomain.BaseDirectory);
      if (!string.IsNullOrEmpty(sCurrentDrive))
        return File.Exists(Path.Combine(sCurrentDrive, "RoleModel.xml"));
    }
    catch { }
    return false;
  }
}

Tested for a web role, but I'd expect it to work the same for worker roles (please comment if it doesn't).

Answer 5

Like you say, adding references to all your end-products is not the way to go. I would say this is a problem solved very easily using Dependency Injection.

Define an interface which yields this information (in a shared assembly):

public enum DeploymentType { WinForms, WinServices, Azure }

public interface IWhatDeploymentAmIUsing {
    DeploymentType DeploymentType { get; }
}

And create a class that implements this interface.

WinForms (in your winforms project):

public class WinFormDeploymentType : IWhatDeploymentAmIUsing {
    public DeploymentType DeploymentType { get { return DeploymentType.WinForms; } }
}

WinServices (in your windows service project):

public class WinServicesDeploymentType : IWhatDeploymentAmIUsing {
    public DeploymentType DeploymentType { get { return DeploymentType.WinServices; } }
}

Azure (in your azure project):

public class AzureDeploymentType : IWhatDeploymentAmIUsing {
    public DeploymentType DeploymentType { get { return DeploymentType.Azure; } }
}

Now wire it up using your favorite DI tool.