Azure WebJobs: You need Connection Strings

If you run into any trouble after adding a fresh Azure Webjob to your project and try to run it, my guess will be it has to do with connection strings and a missing storage account. If you don’t have an Azure Storage Account then creating one will be the first step. You then need to define these two connections strings in your web app: Portal (Web App -> Configure):

  • AzureWebJobsDashboard
  • AzureWebJobsStorage


And the format for those connection strings:

Replace STORAGE_ACCOUNT_NAME with the name you give the storage account and get the PRIMARY_ACCESS_KEY from the Portal.

If you’re going to connect to a database, also make sure that the name of the connection string you’re using is present in the Portal as well. Otherwise, if you use something like ‘DefaultConnection’ (in your DB context) which is the default one, the Azure Web App will make sure to make that work, but WebJobs will not. When you look at the connection strings in the portal you will probably not find DefaultConnection, but something along the lines of “prod_db” etc. Either rename the connection string on both ends or make sure that ‘DefaultConnection’ is present so that WebJobs can access it.

Hopefully this little post can be of some help if you run into the same problems as I did.

DateTimeOffset: Preserving timezone information in Azure Mobile Services (.NET backend)

For the latest project at work we decided to try out Azure Mobile Services for our backend needs. It’s a simple one-controller backend that stores objects in DocumentDb storage and passes data along. If you haven’t checked out DocumentDb yet, it’s a NoSQL database-as-a-service from Microsoft, hosted in Azure.

The development went smooth, no real trouble and Visual Studio is really an amazing environment, but we stumbled upon one issue with DateTimeOffsets and timezones. When posting to our Web API we had a DateTimeOffset that included timezone information, but when it reached the Post-method in the controller it was converted to UTC automagically. This is something we would want if the data is being stored and passed back to clients which handles timezone conversion gracefully. In our case we want to preserve the date and time as is with the correct timezone as we’re passing this data along to other services such as sending text messages using Twilio.

To disable the conversion to UTC open up the WebApiConfig class and in the Register method add these three lines:

This configures the JSON serializer to preserve the timezone information (RoundtripKind), and that we explicity set IsoDateFormat (although this is default if I recall correctly, might just omit that), and the last one tells the JSON serializer to convert dates to DateTimeOffset. If you use DateTime then ignore this setting.

With these settings in place we preserve the data as is across the wire.

Running several WordPress sites on Azure

Azure is a great cloud service and two of the things that makes it so great is the web interface it provides a long with the possibility to quickly create web sites, virtual machines etc. based on pre-defined templates or in this case, WordPress. For instance, this blog is running on Azure and was created with a custom domain and a featured theme within minutes. With the easy process combined with the great management interface that is Azure Portal, I decided that I wanted another WordPress site, for marketing a hobby project that I am currently working on.