Specifying the Job Collection that a scheduled Azure WebJob is assigned to

Question

Is it possible to specify what job collection Visual Studio should use when it deploys an Azure Web Job with a schedule? By default it tries to create a new Free tier collection, but as I already have one (and the limit is one per account), it fails to deploy.

I want to set up a paid job collection, and have all my deployments go into that collection.

I am deploying the WebJob from Visual Studio's Publish as Azure WebJob... option. The error message in Visual Studio is:

An error occurred while creating the WebJob schedule: The subscription 'XXX' cannot have more than '1' free job collections. (/subscriptions/XXX/resourceGroups/CS-WestEurope-scheduler/providers/Microsoft.Scheduler/jobCollections/YYY)

I want to keep my existing free job collection (as it has other manually created HTTP jobs in it). It would be much better if I could specify myself where the WebJob schedule should go.

Thanks!

Answer 1

I have managed to work around this for now. I performed the following steps:

1. Remove my existing Free tier Job Collection in the Azure Portal website.
2. Deploy one or more of my new WebJobs from Visual Studio (including schedule information).
3. Return to the Azure Portal website, and change the Scale tab of the job collection from Free as it was created by Visual Studio to a Standard/Premium version.
4. In the Azure Portal website, create a new (free) Job Collection, and re-add my existing manually created HTTP jobs to it.

Once this is done, deployments from Visual Studio go to the automatically created Job Collection (automatically named WebJobs-WestEurope after the geolocation of my app), and the other collection is left alone for you to use how you wish.

Basically, Visual Studio needs to get in FIRST to create it's collection, and after that you can add collections as you wish. It seems like a limitation that you can't control which collection it chooses though, so you have to remember that a particular collection is magically tied to Visual Studio's deployments. I'm all for convention over configuration, but not convention DISALLOWING configuration.