4
votes

I have an existing webjob (.NET 4.6.1) that runs fine and gets triggered whenever a message arrives in a queue. I'm investigating how to migrate some applications to .NET Core 1.0 and as part of that I did some research.

It looks like at this point in time, .NET Core 1.0 only supports webjobs that run on a schedule and have no special Webjob features, such as this example: https://blog.kloud.com.au/2016/06/08/azure-webjobs-with-dotnet-core-rc2/

To have a queue message trigger the job I need the features of the Webjob packages. When I add any of the WebJobs Nuget packages (including beta versions), I get the error:

Package Microsoft.Azure.WebJobs.Core 2.0.0-beta2 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package Microsoft.Azure.WebJobs.Core 2.0.0-beta2 supports: net45 (.NETFramework,Version=v4.5)
    One or more packages are incompatible with .NETCoreApp,Version=v1.0.

I did apply a workaround for the Azure Storage already as described in: https://jeremiedevillard.wordpress.com/2016/09/27/use-the-azure-storage-library-in-netcore-application/ but thas apparently does not solve the issue for the Webjob package.

I am aware of some workaround of deploying a non-.NET Core webjob next to a .NET Core website as described here: How do I deploy an Azure WebJob alongside a .NET Core Web App via Git? but - although that would work - I just want to know if I can port my webjob to .NET Core 1.

Does anyone know a way to do this?

TIA, Jeroen

2
so you have your answer ?Thomas

2 Answers

3
votes

As far as I know, Azure WebJobs that use of WebJobs SDK in .NET Core is not supported currently. The following is the snipped from the davidebbo mentioned. More details info please refer to the issue.

To clarify, Azure WebJobs that use .NET Core work fine. It's specifically the use of the WebJobs SDK that is not yet supported.

3
votes

Since there's no push/notify mechanism built in Azure Storage Queues, it's still polling.

You could just poll the queue every X seconds and check for new messages. That's what the SDK is doing anyway, but in a civilized, elegant way. Nothing wrong with doing that.

From: https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted

Azure Storage Queues

Push-style API: No


Service Bus Queues

Push-style API: Yes
OnMessage and OnMessage sessions .NET API.