Azure-webjobs-sdk: Expected release of Azure WebJobs SDK 3.0

[alecor191]

Hi,

could you please share some details about the release date for WebJobs SDK 3.0? (we're in the process of migrating to .NET Core and this is the last package we would need to be released)

Thanks!

[jonsagara]

We're in the same boat re: upgrading from .NET Core 1.1 to .NET Core 2.x. Are you waiting until .NET Core 2.1 drops?

Thank you!

[paulbatum]

We don't have a date for this yet. Our work on functions 2.x is the main effort that is driving the webjobs 3.x release. As we get closer to being GA ready for functions 2.x we'll get more confident in a date for webjobs 3.x. I can confirm that it would be sometime after .NET Core 2.1 lands because we have plans to use some Core 2.1 features in functions 2.x.

I'll leave this issue open until its been updated with a more concrete ETA.

[jonsagara]

Thanks for the transparency. Much appreciated. And thanks for all the hard work! 👍🏻

[tmenier]

What exactly _is_ 3.0? I see there's a bunch of issues labeled 3.x and several beta releases, but I can't find anything that sums up the main point(s). Is it all about .NET Core 2 support? Was there an announcement I missed?

[paulbatum]

@tmenier The 3.x release of webjobs is primarily about:

• running on .NET core,
• updating dependencies to latest versions
• binding extensibility improvements
• supporting Azure Functions v2.

I do not believe there was an announcement about webjobs specifically, but it was likely mentioned in the context of our announcements about Azure Functions v2.

[tmenier]

Great, thanks for the info!

[SFinistrosa]

Hi guys,

With the fresh release of .Net Core 2.1, do you have more info about release date for WebJobs SDK 3.0?

Thanks a lot.
Regards
Stephane F.

[paulbatum]

@SFinistrosa nothing additional to share right now - we are still making breaking changes to the public surface area in webjobs 3.x so we're not ready to move out of preview yet. To get an idea of the scope of change that is currently in flight, you could take a look at https://github.com/Azure/azure-webjobs-sdk/pull/1571/files

[paulirwin]

@paulbatum So you all decided to change the underlying platform, upgrade dependencies with breaking changes, and perform a massive refactoring all in one giant release? No wonder it hasn't launched yet 😉

[paulbatum]

@paulirwin Not sure how your attitude is helping here. We're the Azure Functions team. We work on the webjobs SDK because Azure Functions is built on it. We do the work we need to do to move Azure Functions forward. Every GA release require some amount of ongoing support (backporting of bug fixes, etc) - so of course we are going to try to minimize how many of these major version GA releases we do.

[paulirwin]

@paulbatum My apologies, it was a poor attempt at a joke. I greatly appreciate what you guys are doing. I'm just eagerly awaiting this next release for .NET Core support.

[paulbatum]

No worries. I get that from a release standpoint, it feels like webjobs is late to the .NET Core party. But keep in mind that many of the other projects (such as EFCore, ASP.NET Core, etc) started porting much earlier. We deliberately delayed our porting efforts when we realized how much dev time we’d save by waiting for net standard 2.0 and boy did that pay off.

[BowserKingKoopa]

I'm anxious for this as well. WebJobs is not in a good place right now. All my existing WebJobs projects have deteriorated into weird reference warnings (https://github.com/Azure/azure-webjobs-sdk/issues/1544).

I retreated back to WebJobs from Functions due to Functions not really working with .NET (https://github.com/Azure/azure-functions-host/issues/992)) only to find WebJobs is stagnant and deteriorating. Makes me nervous, as I have a lot of software dependent on WebJobs.

An updated version that gave us .NET Core support, or even that just fixed Visual Studio's reference freak outs would get me to a much happier place, while Functions tries to get .NET support working better.

[paulbatum]

As already discussed in #1544, its a tooling issue and not an issue with WebJobs itself. I linked to other threads with similar issues being reported for other libaries. VS has issues with old style csproj if you're referencing libraries that target .NET standard 2.0. This is a tooling problem that is occurring BECAUSE we are moving WebJobs forward (rather than just leaving it targeting .NET 461). I don't know how to make this more clear :/

[BowserKingKoopa]

I hear ya, that that particular issue is more of a Visual Studio problem than a WebJobs problem (though the distinction isn't always clear for a developer like me, for whom Visual Studio is very much the gateway to .NET). I'm just casting about for solutions to it, and WebJobs v3 that targets .NET Core would do the trick.

[grahambunce]

Hi, any update on this? Any information on expected beta cycles still outstanding (I notice you're up to beta7 although the last nuget package was beta5) or even an RC version? I agree with @BowserKingKoopa in that a .NET Core version that just targets WebJobs is better than the extensive re-work apparently needed to support the issues functions has (e.g. binding redirects)

[codymullins]

Is there anything we can do to help this get to a stable state - any PRs needed? At work we'd like to get our web jobs migrated to core along with our other projects.

[paulbatum]

We will be publishing a new set of beta packages sometime this month (July). We are aiming to release some RC packages towards the end of August. I can't comment beyond that at this point in time. As I mentioned above, work on the WebJobs SDK is funded by the Azure Functions team and is driven by the needs of that product. I know that might seem suboptimal if you're a WebJobs user and haven't moved to Azure Functions yet but I'm just trying to explain the current situation.

[BowserKingKoopa]

I can't move to Azure Functions even if I wanted to. It doesn't work with .NET. https://github.com/Azure/azure-functions-host/issues/992 I fled back to WebJobs to escape that ill-conceived mess only to have it follow me back.

[paulbatum]

In regards to PRs that can help move things along - I appreciate the offer but I do not have much in the way of suggestions right now. I'll try to keep an eye out for low hanging fruit that can be taken by community members.

See here for some queries that can help illustrate the work we are tracking for functions but as you will see, the majority of these work items are not WebJobs SDK items.

[grahambunce]

@paulbatum I take your point about the functions team funding the web jobs update and that’s a matter for the internal Microsoft bean counters, but from the outside as I’m sure you’re aware, it’s a ‘what the????’ moment. A fundamental part of azure web app architecture is stuck on full .net framework and can’t move to another fundamental Microsoft technology because of internal funding?

Not only that, to add insult to injury, azure functions is either so borked, or moved on so much from its original intention as simple glue between azure logic apps, that it really isn’t fit for purpose in a large scale system .... so now there is this major rewrite you’re having to do and really it seems that the underlying web jobs SDK platform could’ve gone to .net core ages ago.

So those of us who have tried azure functions ( in my case twice now) and have no desire to be burned again and just want a stable web jobs platform that does everything we need, in .net core, have to wait until you guys finish rewriting azure functions.

Not having a go directly at you Paul, but the whole situation is more than a little annoying.

[codymullins]

Yeah, this probably isn't the place to discuss it, but it's a little concerning that you mentioned those who "haven't moved to Functions yet."

The idea of Azure Functions is great. They have a lot of use cases. But WebJobs also have a pretty solid case too, that Functions simply don't fill for us. We've tried using Functions several times as well but we've ended up going down the road of using WebJobs for lots of things and as we continue to build them, we see ways to improve them where the answer isn't just moving to Functions.

I understand that Azure Functions is what is driving the development of WebJobs since they're built on the platform, and I also understand that Microsoft needs to make money from Functions. It would just be nice to know whether or not we should decide to move away from WebJobs or not if they're going to be a second class citizen. Again as @grahambunce not having a go at you either and I understand your position, I'm just nervous we chose a technology that was being pushed hard and is eventually going to have zero support because of Azure Functions.

[paulbatum]

I understand the concerns you've both raised and you're asking fair questions.

One of our priorities is to continue to work on the issues that are preventing .NET users from using Azure Functions. Some of those issues are addressed in our newest versions of V2, and some are still outstanding. We want to see WebJobs users moving to Azure Functions but we also know this will take time.

We continue to support WebJobs. Users such as yourself made a bet on WebJobs and we work to make sure you continue to be successful. If issues are reported that impact WebJobs users, we fix them even if those issues would not impact a functions customer.

The fact that WebJobs is heavily used by Azure Functions is a two-way street. It benefits in that functions drives new features, bug fixes, etc. We have a number of bindings that are now available for WebJobs that were only added because of functions. The area where it does not benefit is in terms of release cadence - our major version WebJobs releases are planned primarily around the needs of Azure Functions. I think its this last point that is key to the conversation in this thread and explains why we did not do a straight port to .NET Core and release it as a 3.x, ignoring the needs of Azure Functions - this would have set back our efforts to make Azure Functions available to developers on mac/linux and users that want to run on Linux in the cloud.

[grahambunce]

@paulbatum congratulations on reaching 3.0 rc1. Can you give any guidance on how far away we are on final and what is outstanding? There are a number of tickets about beta8 timers not working, configuration options not available etc and a general confusion about how to migrate from beta5 to beta8/rc1.

For example I’m using service bus and timers in beta5, and all seems ok but I don’t want to work out how to make the switch to rc1 now and then find stuff is still missing or it’s less stable than beta5 due to the underlying rewrite.

Also is a migration guide in the works?

[paulbatum]

We are approaching RTM. I went through the issues list and had trouble finding the timer related issues you mentioned. If you can link here that would be helpful.

Most of the migration guidance we have planned is more around doing the functions 1.x -> 2.x transistion and to a lesser extent webjobs 2.x -> 3.x. I don't expect to have a general doc about moving from the various 3.x previews towards 3.x RTM. Guidance on that topic is more likely to be given ad-hoc in response to individual issues.

[tjrobinson]

It appears to have been released:

• https://www.nuget.org/packages/Microsoft.Azure.WebJobs/3.0.0
• https://github.com/Azure/azure-webjobs-sdk/releases/tag/v3.0.0

[paulbatum]

Indeed! Yesterday was a busy day, sorry I didnt get to mentioning it here. We published packages yesterday, but there are related activities (such as documentation updates) that are still pending.

There are still a number of issues that we are tracking, and we already have some fixes that did not make it into this release (such as this one). So you'll definitely see some patch releases from us in the near future.

[edwardrbaker]

I spent the morning downgrading a new project to .net 4.7.2 because I didn't have webjobs sdk 3 so this is perfect timing. Thanks for all the hard work!!

[jsgoupil]

When are we expecting to get the documentation updated about this? This is quite unusable without the docs. I am disassembling WebHost.CreateDefaultBuilder and HostBuilder to figure out how to set this up the right way. Spending hours just to setup the WebJob...

[andriysavin]

@jsgoupil Take a look at the SampleHost in this repo.

[jsgoupil]

@andriysavin I have... and this is quite not enough.

I have all these questions.

• UseEnvironment("Development")... who does this? we need to use the environment variable.
• You seem to load appsettings.json when calling ConfigureWebJobs, but I don't think it loads the appsettings.Environment.json
• Do you load the app secrets?
• Name Resolver ? I see there is a DefaultNameResolver which might work with my code, but how do I override it?
• I probably don't need a Custom Job Activator anymore? But how to set this up
• Some information about HostId would be interesting
• Warning: Only got partial types from assembly: Microsoft.Azure.WebJobs.Extensions.Storage, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

Also, I am unable to get the DI to work. I copied everything from your sample now to give it a shot and I still get:
System.MissingMethodException: No parameterless constructor defined for this object.

[andriysavin]

@jsgoupil That's a very basic example, agree. Try too read docs on .Net Core Generic Host. Basically, with this model you can do almost all what you can with ASP.NET Core, including attaching KeyVault config provider, app settings and so on. But you still need Custom Job Activator AND register you function (non-static) class in DI:

.ConfigureWebJobs(b =>
                {
                    b.Services.RemoveAll<IJobActivator>();
                    b.Services.AddSingleton<IJobActivator, ServiceProviderJobActivator>();
                    b.Services.AddScoped<Functions>();

                    b.AddAzureStorageCoreServices()
                        .AddAzureStorage();
                })

I agree, we need good docs on this and more real world examples.