#webjob

“System.BadImageFormatException: Could not load file or assembly ‘Microsoft.Azure.WebJobs.Host, Version=1.1.2.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies” error in Azure WebJobs

Hi,

We were getting the below error while trying to run an Azure WebJob

Got it fixed by updating the Microsoft.Azure.WebJobs nugget package to version 2.0. and publishing it again.

Hope it helps…

Una vez tengamos creado un proyecto de tipo WebJob de Azure, encontraremos en el proyecto dos clases, “Program.cs” y “Functions.cs”.

Es en la clase “Functions.cs” donde se va a realizar la integración con nuestro Azure Service Bus.

Tan sólo tendremos que definir los siguientes parámetros en el método “ProcessQueueMessage”:

public static void ProcessQueueMessage([ServiceBusTrigger("topic", "subscription")] BrokeredMessage message, TextWriter logger) {}

El primer parámetro “ServiceBusTrigger” define el topic y el segundo el subscriptor que estará escuchando al service bus.

Como os podéis imaginar en el parámetro "message" tendremos el mensaje que nos envía el Azure Service Bus y que según lo hayamos compuesto, tendrá un formato u otro.

La propiedad "message" tiene un método "GetBody()" el cual contiene el objeto serializado que envía el service bus y a parte podemos recorrer la propiedad "Properties" que es un diccionario donde podemos almacenar información adicional.

var fullNameTypeEvent = message.Properties["TypeEvent"].ToString(); var serializedEvent = message.GetBody();

Sólo nos quedará definir en el app.config o web.config las credenciales de acceso al Azure Service Bus, y las conexiones al Dashboard y Storage con las que el WebJob trabaja.

<connectionStrings> <!-- The format of the connection string is "DefaultEndpointsProtocol=https;AccountName=NAME;AccountKey=KEY" --> <!-- For local execution, the value can be set either in this config file or through environment variables --> <add name="AzureWebJobsDashboard" connectionString="XXX" /> <add name="AzureWebJobsStorage" connectionString="XXX" /> <add name="AzureWebJobsServiceBus" connectionString="XXX" /> </connectionStrings>

There's a new concept coming from Windows Azure Websites called WebJobs where you can have scripts running on a schedule, continuously or simply by invoking them manually.

In this article I'll talk about a simple way of deploying a .NET console application to Windows Azure Websites which will be deployed as a continuous job.

In short, a continuous job is treated similar to a windows service, as long as it's started/enabled, Azure will make sure it's up, it'll start the process (on all of your instances) and whenever the process goes down it'll simply bring it back up (after a 60 seconds delay).

The executable that is deployed as a continuous job should have some kind of an infinite loop (while (true)).

Note: While you can experiment with continuous jobs in free or shared websites, it'll only work properly in a standard website that has the "always on" setting set, this is since in free/shared sites the jobs process will be brought down after about 20 minutes of no requests to it (a request to the jobs process can be to check the status of current jobs).

Enough chit-chat, now to the main event, we have .NET code which we want to (continuously) run on Azure, here are the steps:

Write your .NET code as a .NET console application, here is a sample:

Add your code to a git repo.

git init

git add .

git commit -am Coding

Create a new web site with source control.

Get the url to your site's git repository

Push the repository to your site.

git push http://.../.git master

That's it, you now have your .NET console application running on Windows Azure Websites, just go to the WEBJOBS tab and take a look.

Note: Don't forget to enable the Always On feature if you're on standard to make sure this job will never stop running.

Now to see the continuous job logs click on the "logs" link (you'll need to enter your publishing user name and password, if you're on chrome even better - it just works), there you would see all the system logs (when the job started, stopped, etc...).

To see the logs produced by the application (console output and error) you need to enable application logging under the CONFIGURATION tab, your logs can go to your file system/azure storage table or blob.

Note: You can also use app settings/connection strings which would come from the site's configuration, same as you would do for your ASP.NET website.

There are more awesome things to say about webjobs, but that's in next posts.