Skip to content

Getting Started with Worker Roles

Jump to bottom
Colin Scott edited this page Aug 18, 2014 · 5 revisions

Creating

A Worker Role that is to use LightBlue is created using the standard Azure tooling. After creating a Worker role add a NuGet reference to LightBlue using:

Install-Package LightBlue -pre

Requirements

The Worker Role must be using the 2.4 version of the Azure SDK. The LightBlue NuGet package will ensure that the requisite NuGet packages for other dependencies are installed.

Configuring IoC

LightBlue currently supports the Autofac IoC container. This is used to provide the appropriate implementations of the LightBlue APIs based on whether the role is being run in LightBlue, the emulator or actual Azure. Configuration of Autofac is performed by calling the RegisterLightBlueModules() extension method on an Autofac ContainerBuilder instance.

    var containerBuilder = new ContainerBuilder();
    containerBuilder.RegisterLightBlueModules();

This will register with the container the core abstractions such as IAzureEnvironmentSource from the Environment API and IAzureSettings from the Settings API. These can be resolved directly or (preferably) be dependencies of other types resolved via Autofac. Also registered will be factory methods from the Storage API that provide the points of entry into the LightBlue storage abstractions.

Running

Worker roles are hosted in LightBlue by LightBlue.Host.exe, provided by the LightBlue.Hosts NuGet package.

LightBlue.Host.exe is the process that must be executed to start a Worker Role inside LightBlue. This may be executed in a script or from the command line. In Visual Studio it is convenient to set this as the external process to be run when the Worker Role project is run and to set that project as the Startup Project (or one of them in the case that you have multiple roles). This will allow you to debug the role as you would expect.

The host requires a number of command line parameters to be passed in order for it to correctly locate the role and the appropriate configuration. These are required both when run from a script and from inside Visual Studio. They are:

  • -a The path to the Worker Role assembly. This is either an absolute path or is a relative path to the host execution directory.
  • -n The name of the Worker Role. This is the name it is listed under in the Cloud Service project. It is used to look up the settings for the role from the configuration file. Specifying an unknown role name will result in an error.
  • -t (optional) The title of the Worker Role. If the host is spawned into a new window this will be the title of that window. Useful for when there are multiple hosts running. If not specified the name of the role is used.
  • -c The path to the configuration. If this path is a file that file is assumed to be an Azure .cscfg and is parsed for the relevant settings (expected to be under the element identified by the role name). If it is a directory LightBlue looks for the file ServiceConfiguration.Local.cscfg in that directory.

The host process is installed by the command:

Install-Package LightBlue.Hosts -pre

This package is a solution level package and does not get installed into any particular project. The hosts do not directly reference the LightBlue assembly and are not strictly required to be of the same version although different versions are not guaranteed to be compatible.

Worker roles may also be fired up in the Azure emulator or deployed to actual Azure in the same way as any other worker role. This is detected automatically and the appropriate implementations of the LightBlue APIs are provided. No configuration changes are required between environments.

Clone this wiki locally