Azure Webjobs Part 2 – building an Azure Webjob

As I mentioned in part one of this 2-part “straight to TV” drama, Azure Webjobs are pretty awesome! They’re Scheduled Tasks without the secrecy. They’re Azure Worker Processes without the cost! You can host them on Azure for free as a Web App (recently renamed from “Websites”) and straight out of the box you get an awesome Dashboard that allows you to check the status of your Webjob and replay any single invocation at a single click.

WebJobs are amazing for doing processes that take a decent chunk of time and processing power, so you don’t hold up the your website’s thread and slow down any responses. For the WebJob that I recently wrote, I dump the url and database Id of a pdf file into the Message Queue, and the WebJob grabs the PDF, creates a thumbnail of the first page, saves it back to my Azure Blob Storage container and adds the thumbnail url back into the database – all for free and without freezing up the UI of my CMS.

In part one I showed you how to add messages to an Azure Message Queue. In this post I will show you how you can build an Azure Webjob to process and do something with those messages.

You will need to have the latest Azure SDK installed, which you should have done already if you followed part one. Oh you didn’t read part one yet? Shame on you…

Set up a WebJob project

First we need to create a new project – in Visual Studio, choose ‘Create New Project’ and choose ‘Azure WebJob’ from the options:


You can see this project looks pretty much like a console app – there’s a Program.cs file and an App.config file just like you would expect in a Console Application. The slight difference here is that there is a Functions.cs file. It’s this Functions.cs file that contains the method that will be triggered when a message is added to your message queue (the auto-generated comments on the method tell you pretty much the same thing):


ProcessMessageQueue parameters

You can see there are two parameters to this ProcessMessageQueue method. The first parameter is the actual message that you will be expecting from the Message Queue. Out of the box this is just a simple string, but as I demonstrated in part one it can be any object type you want. You just need to ensure that whatever object type you add to the message queue matches the object type you specify as this ProcessMessageQueue parameter. You will also notice that the message parameter is decorated by a [QueueTrigger(“queue”)] attribute. This is the bit that triggers this function when data is added to the Message Queue. You will need to swap the “queue” text in there to match the Message Queue name you already specified (remember that this needs to be all lower case in order for this to work…

The second parameter TextWriter allows you to write to the WebJob logfile, the contents of which you can view through the Dashboard (more to come on that later) in the same way you would use console.log() in a Console Application.

Add your Storage Account Connection Strings

The only other thing you need to do in order to get this basic WebJob example running is to tell it how to connect to your Message Queue. In order to do this, you need to add your Azure Storage Connection String (which I told you how to find in part one) into the App.config file. Out of the box there is already a placeholder Connection String in the App.config, so all you need to do is add your own data in there:


You will notice there are two Connection String placeholders in the App.config file. The AzureWebJobsStorage Connection String is the one you want to configure at this point. We’ll get on to the AzureWebJobsDashboard Connection String a bit later.

It’s that simple!

Yes it really is that simple to create a WebJob – now you just have to stick whatever code you want inside your ProcessMessageQueue method, so you can process the data that you stuck in the Message Queue in the first place. You can make that bit as simple or as complex as you like!

Publishing your WebJob

Publishing a WebJob to an Azure Web App is pretty simple too – right click on your WebJob project and choose ‘Publish as Azure Webjob…’:


On the next screen that pops up you will see a whole load of options for when and how your WebJob should run (I have chosen ‘Run Continuously’ for this demo) and click OK.

Next you will be able to choose your publish target – select ‘Microsoft Azure Websites’:


Next you will be asked to Sign In with your Azure account, and then you get to choose either an existing website or create a new one:


Choosing ‘New’ will take you to a screen where you can choose a name for your website, select which region you want to host it in and create a new database if you want to:


Now click ‘Create’ and your website will be created for you, and the publishing settings for the site will automatically be downloaded into your publishing profile:


Finally, click ‘Publish’ to publish your WebJob. The first time you publish a WebJob it takes a while, as it’s uploading all the DLLs etc that you’ve created with your code. Any subsequent publishes all seem to be pretty quick so I assume it’s just pushing up any files that have changed since the last publish.

Debugging your WebJob

So now we have published the WebJob it’s time to discover a pretty awesome feature – you can attach your local Visual Studio to your remote WebJob and debug it in real time! In Visual Studio view the Server Explorer (View > Server Explorer) and you will see ‘Azure’ showing at the top. Expand that and you will be able to see your Storage accounts and your Websites, along with all the other areas of Azure.

Expand the Websites node and you will see your WebJob appear there as a website. Drill down into this website (WebJobs > Continuous) and you will see your WebJob. Right click on your WebJob and select ‘Attach Debugger’:


Stick a breakpoint in your ProcessQueueMessage method and we will now trigger the WebJob by adding data manually to the Message Queue. Again in Server Explorer, navigate to your Message Queue (if it doesn’t yet exist, you can just right click on the Queues node and create it):


Opening up the Message Queue shows an empty table of messages. There is a set of icons on the top right of this table – click the ‘Add Message’ icon:


You will see a dialog box pop up – add some text in here (if your WebJob is expecting a more complex object, stick some Json in here to represent that object):


You will see the message added to the Message Queue table:


Now just sit back and relax for a few moments, and wait for your WebJob to be triggered. Cross your fingers and toes and shortly you should hit the breakpoint you added to your ProcessMessageQueue method (you did add a breakpoint didn’t you?):


Yes it really is that simple to set up a WebJob!

The Dashboard

There’s only one thing left to show you before I go to bed, and that’s how to get the Dashboard up and running.

In Server Explorer if you right click on your WebJob and click ‘Dashboard’ you will probably see something like this:


If you can’t be bothered to read all that text I’ll save you the task. Basically you haven’t yet set up the Connection String for your Dashboard. You need to set this in 2 places – in your App.config file and also in your WebJob ‘Configure’ section in the Azure Management Portal.

To set the Connection String in your App.config, simply add the Storage Account info in the AzureWebJobsDashboard Connection String (you can use the same Storage Account that you used for the Message Queue, or set up a new one if you wish).

In the Azure Management Portal, choose your WebJob and click on ‘Configure’ from the top menu. Scroll towards the bottom of the page and you will see the Connection Strings section. Add your Connection String data in there. You will need to post that entire long string into the ‘Values’ textbox – DefaultEndpointsProtocol=https;AccountName=…;AccountKey=…) and choose ‘Custom’ from the dropdown menu on the right:


Now re-publish your WebJob with that extra config setting, and refresh the Dashboard page again. It should look a bit more like this:


This Dashboard is pretty cool – it tells you the status of the WebJob, it shows you the logfile output of the WebJob (click the ‘Toggle Output’ button to see the log messages). It also allows you to click on the function that you just invoked (the line at the bottom of this image) and view the details of that invocation (click the ‘Toggle Output’ button again and you will see the line of text we wrote to the logfile):


Finally you can also replay this invocation by hitting the ‘Replay Function’ button at the top of the screen which re-submits that message back to the Message Queue for you. This is really useful if the function fails, and you want to try it again to either debug it or run it once you have fixed a bug.

So that’s a really quick introduction to creating WebJobs – I hope I’ve covered all the basics and you can get up and running with this awesome Azure feature! Let me know in the comments if you’ve run into any issues setting this up, and I will try to help out if I can!

Bedtime – good night!

Posted in Code, Code samples, Web development, Windows Azure Tagged with: , , , ,
  • Pingback: Azure Webjobs part 1 – using Azure Storage Message Queues | Maff Rigby()

  • Derek Adkins

    You sir, are my hero. Thanks for a fantastic article with clear explanations and examples. This is exactly what I was looking for.

  • k3nn c.p.

    Hi Maff, need help on how I can set up my webjob to run locally (no azure whatsover). I’m having error on the connectionstring (i left it blank). To have a webjobhost run locally: I run the WebJobsSDK and I have the dashboard running on the default port (http://localhost:44450/azurejobs) and can view the dashboard page (empty and no webjobs). so now, how do I set connectionstring to point to my local webjobhost? and then link that with the actual webjob project in another solution? and I’m thinking I should see the actual webjob project being listed in my locally run dashboard (shouldn’t it?). i’ve read about running it locally from github wiki ( but i don’t know how this all links with each other. newbie on azure here so please be gentle 😀

    • Hi there!

      You can run webjobs locally using the Azure emulator (it’s included in the Azure SDK). If you set your connectionstring values to “UseDevelopmentStorage=true” then the webjob will use the Azure emulator storage account.

      The connection in your app config should look like this:

      Hope this helps,


  • hi Maff, how did you get “Attached Debugger” under a webjobs node? Neither of my VS 2015 and 2013 (both the latest) have it.

    • Hi abatishchev,

      Check your webjob is started and running before you try to attach your debugger to it. Right click the webjob and click ‘Start’ if it’s not running. Then wait for a few moments and right click again and choose ‘Refresh’ just to ensure you’ve got the latest status.

      Next time you right click on the webjob, if it’s running you should see the option to attach your debugger to the webjob.



      • I tried everything. Even update Azure SDK to the latest and reapplied Update 3 on VS 2015. My wejobs are running, I tried few different environments. I suspect the problem for me is that I’m running them in a slot, not parent app. Can I ask for a favor and try this scenario at your end? I’ll submit a bug if it won’t work for you as well.

        • zainul abedin

          Hi, did you get the solution for this as I have got the same problem

          • Unfortunately Made didn’t come back on my ask. But from my perspective debugging webjobs in a slot is a broken feature. This just doesn’t work. Don’t know whether it works properly outside a slot since don’t have such configuration. What’s your?

About Maff

Maff Rigby

I'm a certified .Net, Umbraco and AngularJS freelance developer with over 15 years experience in the IT industry. As well as writing code I love to teach; I run a number of workshops and 1-1 coaching sessions on Angular JS and Umbraco, and share what I know and learn here!

I’m social (ish)

Connect with me on LinkedIn, follow me on Twitter, or fail to find me on Facebook.