Geek Answers Handbook

Can I tell if my code is running as an Azure production agent?

I have several common builds / projects that are used in Winforms applications, Windows services, and now Azure worker roles.

Is there any way to detect at runtime if I run the Azure role.

I found how you can determine if the Azure emulator is working or not:

Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.IsEmulated

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

Ideally, I would like something similar to what I use to determine if it works as a console and a service:

 System.Environment.UserInteractive

Is there anything that gives me this logic?

+6
source share
5 answers

You can check for the presence of a RoleRoot environment variable (at least for cloud services):

Or why not just add the parameter to your config (AppSettings or Service Configuration):

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

Then you can simply check if a parameter with a specific value exists to see where you work. It also means that during your (automated) build or deployment process, you will need to enable this option (this is possible, for example, with XDT).

+4
source

For anyone interested, I thought I'd share what I implemented thanks to @Sandrino Di Mattia's answer:

You can check for the presence of a RoleRoot environment variable (at least for cloud services):

Please note that this does NOT serve the Winforms application, since I only actually requested it at the end for the Services, that is, I found that it works between the services

  • Azure Worker Role
  • Windows service
  • Console application

This is the 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 } } }
+4
source

We set the environment variable (in this example, INAZURE) as the launch task through the batch file.

The contents of the SetEnvVar.cmd batch file:

 setx INAZURE True /M

Configure the batch file to run through 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 that you can use, but this points to nasty immutable builds that make the PITA build server configuration. Perhaps the latest versions of the Azure SDK have gotten better.

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

+1
source

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

In the alternative below, I worked correctly with a ready-made webrole (not working when lifting). Although the default role acts as a "network service", it can detect the presence of "f: \ RoleModel.xml". This is probably necessary because the configuration file contains the information needed for the role launch code. Please note that the code does not depend on the actual drive letter, which 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 web role, but I expect it to work the same for work roles (comment if this is not the case).

+1
source

As you say, adding links to all your end products is not the way to go. I would say that this is a problem that is very easy to solve using Injection Dependency.

Define the interface that gives this information (in the general 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 the azure project):

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

Now plug it in using your favorite DI tool.

0
source

More articles:


All Articles