Azure-webjobs-sdk: Storage v9 runtime failures

Created on 13 Feb 2018  Â·  30Comments  Â·  Source: Azure/azure-webjobs-sdk

From @baywet here:

Running into the same issue with .net 4.6.2, webjob 2.0.0 (or 2.1.0, doesn't matter) and storage v9. It looks like the namespace Microsoft.WindowsAzure.Storage.Table.DataServices has been removed in v9

This ends up being a run-time (rather than a build-time error), which stinks.

We need to see if this is something we can work around. If not, we may need to throw a nuget maximum version on our nuspec.

Most helpful comment

Are we able to get a v2.2 release on NuGet with this fix?

Thanks.

All 30 comments

Please avoid setting a maximum. You can break compatibility with other stuff requiring major rearchitecting of stuff that way.

How setting maximum can break more if it's already incompatible and can't work?

By preventing new versions of things like Microsoft Bot Framework from firing up at all (JWT tokens which weren't compatible with the latest version of asp.net mvc owin as an example). MS needs to start doing end to end unit testing on these nuget packages across all dependencies internally. It's a mess right now and needs to be fixed.

In the mean time they need to scramble to fix their bugs and not put blockers on compatibility. This should be a drop everything bug at this moment.

Agreed on the fact that the whole asp.net mvc default pipeline, owin pipeline and core pipeline coupled to the dot net standard breaking changes of libraries and a few other details is a mess. but let's not sidetrack.
Currently things break at runtime, which takes a long time to detect. With a maximum version at least this issue will be detected at dependency resolution time (way earlier).
The solution will be to upgrade to webjob sdk core if you want storage v9 (or if another dependency "forces" you)
Dependency management has always been a complex thing (look at npm packages for example).

(BTW, from other reports it seems like this is part of the .net core version as well so upgrading to there isn't going to fix this)

@JohnGalt1717
probably these lines causing the issue as this is the only reference of DataTables. And those are not part of core.
https://github.com/Azure/azure-webjobs-sdk/blob/dev/src/Microsoft.Azure.WebJobs.Host/AzureStorageDeploymentValidator.cs#L39-L46

Do a search for the error message. You'll find reports in .net standard.

This issue is Core unrelated

FYI - that code block came from this issue: https://github.com/Azure/azure-webjobs-sdk/issues/922. We may need to revisit this if it's the only thing that breaks v9.

Yet another time made sure that nuspec should cap Storage to <= 8.7. I just created empty console projects, installed WebJobs latest stable with nuget dependency behavior=highest. What I got? Of course Storage 9.0 what we all know won't work.

So either WebJobs 2.3 should require Storage >= 9.0 or WebJobs 2.2 should require Storage < 9.0 (what means 8.7).

A fix for this is now available in our Nightly Builds. Version 2.2.0-beta1-11224+ should no longer fail with this error. I'm going to close this issue, but please reactivate if you find the fix does not work in any scenario.

https://www.myget.org/feed/azure-appservice/package/nuget/Microsoft.Azure.WebJobs/2.2.0-beta1-11224

Are we able to get a v2.2 release on NuGet with this fix?

Thanks.

any update on this? Don't really want to pull in a nightly feed but happy to install a 2.2 preview from the public nuget?

Yes, we're working on getting an official 2.2 released.

Only just realised my deployed webjob was failing due to this. Is there an ETA. As if it's too long I will need to start or reverting to an older implementation.

On 2 Mar 2018 15:09, Brett Samblanet notifications@github.com wrote:

Yes, we're working on getting an official 2.2 released.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/Azure/azure-webjobs-sdk/issues/1574#issuecomment-369946461, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AB6rkoCv0NPLQLDUusftBkFF0cVlzxoYks5taWCngaJpZM4SD86N.

What is the workaround? If I use the nightly build I end up with a new exception:

System.MissingMethodException: Method not found: 'System.Threading.Tasks.Task 1<Microsoft.WindowsAzure.Storage.Shared.Protocol.ServiceProperties> Microsoft.WindowsAzure.Storage.Blob.CloudBlobClient.GetServicePropertiesAsync(System.Threading.CancellationToken)'.

@tgrunshaw can you share the WebJobs and Storage packages you're using? We've not seen that error in our tests so I want to make sure we can find it.

The best workaround is to move back to an earlier version of WindowsAzure.Storage. We build and test against 7.2.1, but 8.0 should work as well.

@brettsam - it turns out that exception was unrelated to this issue. I didn't realize that the version 2.* of the Webjob SDK doesn't support .NET core 2 and hence I was targeting netstandard1.3 dlls. With 2.1 the first error I got was: Microsoft.WindowsAzure.Storage is deployed incorrectly. Are you missing a Table Service assembly... which led me here as it's the exact same error. After updating to 2.2, netstandard1.3 is missing the GetServicePropertiesAsync(CancellationToken) method hence my new exception.

Using Webjobs version 3.* solved it for me.

is this looking close for release to public nuget as a beta?

We're looking to release a 2.2.0 soon -- we're doing final validation now. The build has been produced and is available on MyGet: https://www.myget.org/feed/azure-appservice/package/nuget/Microsoft.Azure.WebJobs/2.2.0. Once ready, we'll move it to nuget.

Why is this closed? File > New > Webjob, update nuget packages, produces this error still.

Because we close issues when PRs are merged.

@paulbatum aren't issues normally closed when they are merged and live? cannot see 2.2.0 on the live nuget feed released or in prerelease. Its still only available on the nightlies feed.

We close issues once the PR with the fix is merged. This is pretty normal from what I've observed... perhaps some projects leave their issues open until a release with the fix is completed, but if so I think they are in the minority.

@BowserKingKoopa / @tbertenshaw -- have you been able to validate that our v2.2.0 on myget fixes your issue?

Alternatively, you can move your storage packages back to 8.x to unblock yourself. If there's a specific reason you need Storage v9, can you let us know? It helps us understand what people are using.

We've got lots of moving parts with templates, Functions, tooling, etc, that have broken in the past when we updated these packages. We're working on validating all of these pieces before move to nuget.org. Unless we find an issue during these validation stages, the bits will be identical to those that are currently on myget.

The v2.2.0 from myget fixed it for me. Moving back to Azure Storage 8.x isn't an option. I reference some libraries that reference Azure Storage 9. It isn't up to me.

@brettsam yes the myget 2.2.0 fixed it for me.

2.2.0 fixed it for me too.

2.2.0 fixed it for me also, but any chance of having this pushed to nuget too please?

Was this page helpful?
0 / 5 - 0 ratings