Is it possible to execute azure web jobs on .NET core ? I would like to Azure Web Jobs on my Linux server. How do I achieve that?
We're investigating this.
Is there an approximate ETA for this?
Dev activities on the .NET core migration/port will begin very soon, and while we don't have an ETA we can share, you'll be able to track progress here as we move forward.
I second this request. At least porting the SDK to .NETStandard would be very helpfull!
@BorisWilhelms that's indeed the plan. We'll have detailed issues tracking progress and a branch setup for the port.
How are you planning on handling the ServiceBus dependency?
Microsoft.ServiceBus.Messaging is abandoned and Microsoft.Azure.ServiceBus is yet another one of those Microsoft from-scratch-rewrites that are going so swell these days.
Last I checked they were removing BrokeredMessage and crowdsourcing how to name the class factory via Twitter. That team sure would benefit from a sane, senior, shipping dependency to guide them.
Hi,
I just wanted to share my thoughts here. For service bus dependency we can target AMQP 2.0 standards. That way we will have a generic library that can run with rabbit MQ or Service Bus or Event hub. The respective destination can be adapters. Also on successful queing we can raise the events from Library itself. This will be useful when using the same for server less programing like Azure functions.
If we build that in similar fashion for Databases and other sinks also.
So ultimately Azure web jobs will be a PaaS agnostic Server less library like Serverless (https://serverless.com/). That way we can write PaaS agnostic coding in the platform we love which is .NET core.
Hope I'm making sense
Even PaaS specific additions like AWS, Azure or Cloud foundry ( there is a full fledged other vendor PaaS in Linux world like openWhisk, PWS, PCF ) can be done as adapter
Any update on this?
This issue should have been closed a while back, as it was completed with the first release of webjobs 3.0.
Most helpful comment
I second this request. At least porting the SDK to .NETStandard would be very helpfull!