0
votes

I have a Azure webjob built with dotnet core and it's been deployed to a deployment slot on Azure App Service. I've followed the instructions from: https://blogs.msdn.microsoft.com/azuredev/2018/08/22/webjobs-in-azure-with-net-core-2-1/ in order to publish the webjob in the right folder as well adding the run.cmd to call the dll.

The webjob is being deployed through VSTS. The same way as it's described in the blog post. (under App_Data\jobs\ folder). For some reason, it only dequeue the messages if I deployed to App_Data\jobs\continuous rather than App_Data\jobs\triggered as it was supposed to be. Any Clues?

2

2 Answers

1
votes

I think your issues is around the expectation of what a "Triggered Web Job" is supposed to do. It's confusing wording, but a Triggered WebJob only starts when triggered manually or on a schedule. What you want is a continuous WebJob. You can think of it as the WebJob continuously looking for a queue input that will trigger your code to execute.

David does a very good job of answering the question in this SO post, so I'll repost some of his answer:

It sounds like you are using the Azure WebJobs SDK. In SDK scenarios, even though your individual functions are 'triggered', the WebJob as a whole runs continuously (i.e. your exe keeps running and does its own internal triggering).

-1
votes

Many file types are supported, but for us Windows users it makes sense to use an exe, cmd, bat or PowerShell file. A Console App used to be an exe file, but in .NET Core, it produces a regular DLL file that we need to start manually.

As the link you provided, a WebJob to run it needs some executable script that it can use to get going. And for a .net core, it need to manually execute dll file to start it.

Though we also need to execute run.cmd, we could not create it by ourselves. You could download this webjob core sample which is using the Azure WebJobs SDK in dotnet core 2.0 apps. When you deploy to azure, it would automatically create a run.cmd file to start the webjob.