As noted in a recent post, MS Press has published an e-book based on Scott Guthrie’s presentation, Building Cloud Apps With Windows Azure
. The book consistently features Azure Websites
as the default choice for hosting web applications, with one exception where it switches to Cloud Services
. In the queue-centric work pattern
chapter, the book uses a Worker Role
to handle backend processing for the Fix It sample application
. Scott made that choice when he was developing his presentation because at the time there was no way to host a backend process in Azure Websites. Since then, Azure WebJobs
was introduced. WebJobs is still in Preview, so the book and sample application weren’t changed for this edition, but we plan to feature WebJobs as the default choice for backend processing in the next updated edition. Like Websites in comparison to Cloud Service Web Roles
, WebJobs compared to Worker Roles are easier and quicker to deploy, easier to program and configure, and easier to test and troubleshoot. The release of Visual Studio Update 3
and the Azure .NET SDK 2.4
made the advantage even greater by providing automated deployment features for WebJobs. For details about that, see the new article How to Deploy Azure WebJobs to Azure Websites
. Another advantage of WebJobs is the ease with which you can write code that works with queues, blobs, and tables
, thanks to the WebJobs SDK. We recently published a new getting-started tutorial for the WebJobs SDK. The tutorial shows how to build and run a simple multi-tier application that uses queues and blobs, and you can easily compare Worker Role development to WebJobs development because a Worker Role version of the same tutorial and sample application is available:
Later we’ll update the Building Cloud Apps e-book and its Fix It application to use WebJobs and the WebJobs SDK. Until then, if you want to try the conversion yourself, it involves basically the following steps:
- Download the Fix It application code.
- Remove the Cloud Service and Worker Role projects from the solution.
- Add a WebJob project to the solution (see How to Deploy WebJobs).
- Add the WebJobs SDK NuGet package to the WebJob project (see Get Started with the Azure WebJobs SDK).
- Add the SQL connection string and Storage appSettings to the WebJob project App.config file.
- Create a non-async version of the CreateAsync method in FixitTaskRepository.cs. (This is required for the current beta 0.3.1 release of the WebJobs SDK; a future release will be able to call async methods.)
- Comment out the ProcessMessagesAsync method in FixItQueueManager.cs since you won’t need that method anymore.
- Add the following code to Program.cs in the WebJob project:
private static IContainer container;
private static ILogger logger;
private static IFixItTaskRepository repository;
static CancellationTokenSource tokenSource = new CancellationTokenSource();
static void Main(string args)
JobHost host = new JobHost();
private static void Initialize()
var builder = new ContainerBuilder();
container = builder.Build();
logger = container.Resolve<ILogger>();
repository = container.Resolve<IFixItTaskRepository>();
logger.Information("MyFixIt.WebJob entry point called");
public static void CreateFixIt([QueueTrigger("fixits")] FixItTask fixit)
This is basic proof-of-concept code, and like the current Fix It sample code doesn’t do all of the things you’d want to do in a production app. For example, WebJobs and the WebJobs SDK can handle graceful shutdown, but this code doesn’t implement that. An advantage of the WebJobs SDK is that it will do some of these things without requiring you to write any code, such as handling poison messages (not in the current beta version 0.3.1 but planned for a future version). For more information about WebJobs and the WebJobs SDK, see Azure WebJobs - Recommended Resources