Passing parameters from a resource group template in Azure to a WebJob

As it turns out, WebJobs retrieve their connectionStrings and appSettings from the Azure app service blade settings, same as the web application in which they're running! You can just use the built-in "connectionstrings" and "appsettings" resources underneath a Web Application in your Resource group template to populate these values for the WebJobs right from your template. This is particularly useful for things like WebJobs dashboard and storage connection strings.  Microsoft could really have done a better job of advertising this fact.

Running and debugging Azure WebJobs locally on your development machine

Check out this article: https://github.com/Azure/azure-webjobs-sdk/wiki/Running-Locally

It shows you how to locally run and debug Azure WebJobs, which as it turns out is extremely handy because you can interact with all the Queues, Tables, Blobs etc as you normally would and get a full debugging environment.

Properly invoking scheduled WebJobs

Recently we've found the need to start using Scheduled Azure WebJobs. However, the examples out there are all gargbage, even in the case where you can find an actual example using a scheduled WebJob rather than a continuous WebJob. So, for the benefit of anyone interested, including future me, here's the proper way to invoke a Scheduled WebJob in the entry point of the WebJobs assembly:

    /// <summary>

    /// The main entry point to the scheduled webjobs.

    /// </summary>

    public class Program

    {

        /// <summary>

        /// Main entry point for the scheduled webjobs

        /// </summary>

        public static void Main()

        {

            IKernel kernel = new StandardKernel();

            kernel.Load(new ServicesScheduledWebJobsNinjectModule());

            var jobHostConfiguration = new JobHostConfiguration

            {

                JobActivator = new ServicesScheduledWebJobsActivator(kernel),

                DashboardConnectionString = ConfigurationManager.ConnectionStrings["AzureWebJobsDashboard"].ConnectionString,

                StorageConnectionString = ConfigurationManager.ConnectionStrings["AzureWebJobsStorage"].ConnectionString,

            };

            var host = new JobHost(jobHostConfiguration);

            // Must ensure that we call host.Start() to actually start the job host. Must do so in

            // order to ensure that all jobs we manually invoke can actually run.

            host.Start();

            // The following code will invoke all functions that have a 'NoAutomaticTriggerAttribute'

            // to indicate that they are scheduled methods.

            foreach (MethodInfo jobMethod in typeof(Functions).GetMethods().Where(m => m.GetCustomAttributes<NoAutomaticTriggerAttribute>().Any()))

            {

                try

                {

                    host.CallAsync(jobMethod).Wait();

                }

                catch (Exception ex)

                {

                    Console.Error.WriteLine("Failed to execute job method '{0}' with error: {1}", jobMethod.Name, ex);

                }

            }

        }

    }

What the above does is the following:

• Configures the JobHost to use a dependency injection container via a custom IJobActivator implementation that, in our case, uses the Ninject dependency injection container.
• Configures the JobHost with a custom configuration so that we can control various items, including the connection strings for the dashboard and jobs storage.
• Starts the JobHost. This bit is important, because all the other examples out there neglect that this needs to be done.
• Dynamically resolves all schedulable methods that should be invoked, using the NoAutomaticTriggerAttribute built in to the WebJobs SDK. This attribute is used internally by the SDK to determine which methods need to be invoked manually (i.e. on demand) rather than by a continuous invocation used by Continous WebJobs.

Setting up continuous Webjobs in Azure

First things first: you need to properly setup your dashboard:

This means that in the 'Application settings' area of the panel for your Web app, you need to go into the 'Connection strings' setting and add blob storage connection strings with the names 'AzureWebJobsDashboard' and 'AzureWebJobsStorage', with a type of 'Custom'.

Second: if you have continuous web jobs associated with a Web app, you need to ensure that the Web app setting 'Always On' is toggled *on*.