[BUG] Someone removed TableAttribute input binding from Azure Functions!

[longtimedeveloper]

Library name and version

Microsoft.Azure.WebJobs.Extensions.Storage 5.0

Describe the bug

Someone removed TableAttribute input binding for Azure Functions in version latest stable version of Microsoft.Azure.WebJobs.Extensions.Storage 5.0.

This has been in Azure since DAY ONE!

This is a MASSIVE BREAKING CHANGE...

Workaround
Use Microsoft.Azure.WebJobs.Extensions.Storage 4.05

Expected behavior

Table InputBinding works. TableAttribute in Microsoft.Azure.WebJobs.Extensions.Storage SDK

Actual behavior

TableAttribute is no longer in Microsoft.Azure.WebJobs.Extensions.Storage 5.0.

MASSIVE BREAKING CHANGE!

Reproduction Steps

Create Azure Function with a Table input binding.

Can't. Table not found in any referenced assembly.

Environment

Microsoft Visual Studio Community 2019
Version 16.11.7
VisualStudio.16.Release/16.11.7+31911.196

Azure Functions project.

Microsoft.Azure.WebJobs.Extensions.Storage 5.0

[longtimedeveloper]

UPDATE: I've given up using Microsoft.Azure.Functions.Worker.Extensions.Storage now using Azure.Data.Tables instead.

[AlexGhiondea]

Hi!

Thank you for raising this issue. We acknowledge that the latest Extensions bundle version does not include support for Tables, and we are working on adding it. The new extension will be based on the latest Azure.Data.Tables package and we hope to have a beta version of it released early next year.

In the meantime, there are a couple of workarounds if you are using Azure Tables:

• Remain on the v4 version of the Functions Extensions which has support for Tables until the new extension is released
• Directly interact with the Azure Tables service from the Azure Function code by using the Azure.Data.Tables library linked above.

Please reach out if you have any more questions about this.

[longtimedeveloper]

@AlexGhiondea thank you for the input. I've refactored my app to use Azure.Data.Tables and code the library calls. Actually not that difficult once I figured out that Azure.Data.Tables is the newer package.

Thanks again, Karl

[AlexGhiondea]

@longtimedeveloper good to hear that you were able to get unblocked by directly using the Azure.Data.Tables package! I'll ping this thread once we have a package available that you can try if you are interested!

[zingz0r]

Why is this closed?? This should have one of the highest priority. It isn't mentioned anywhere, that Table binding was removed on purpose.

With .Net 6 for blobs we are forced to use Azure.Storage.Blobs because other packages are deprecated and throws CultureInfoExceptions...

Since
Microsoft.Azure.WebJobs.Extensions.Storage 4.05 doesn't support the new BlobClient binding (only 5.0.0 does) if you are using Tables and Blobs you are screwed.

So the only solution is to rewrite functions to manually connect to table storage using Azure.Data.Tables.

Dropping core functionality without any documentation and warning is a joke. This is unacceptable!

[longtimedeveloper]

@zingz0r I've had to move to Azure.Data.Tables as well for all my Azure functions. This came as a bit of a shock to me as well, having written my Azure functions 3 years ago, been working every day since, and just like you, trying to move to .NET 6.

The good news is, the modifications didn't take too long after I established patterns for my TableService that I wrote that handles the calls to Azure.Data.Tables APIs. None of my functions make calls to Azure.Data.Tables, they only use the TableService . Abstracting away any Microsoft libraries from my functions really helped me. More good news, the Query API is much simpler than the previous library call setup. Now you can pass a Lambda and execute the Query, nice!

One note of caution is the Get, and GetAsync methods throw an exception if the record is not found. This caused a lot of friction with developers and is recorded here: #16251 The good news is, the Team has decided to provide a fix. The issue thread is long but does cover the problem and solution.

So for now, I'm using Get, and GetAsync but am wrapping them in a try/catch block until the Team provides the API fix to allow developers to avoid exceptions for no record found. As an alternative, you can use Query and QueryAsync and deal with their results to return the single record you expect.

Hope this helps, best regards, Karl

[AlexGhiondea]

We are working on building the Tables Extension and we hope to have something you can try early next year. We're using #25342 to track the work and we'll will post updates and package links to that issue.

@zingz0r I'd like to understand more about the issues you are facing with .NET 6 and the exceptions you are seeing being thrown - would you mind sharing a bit more about when you're seeing them?

[zingz0r]

https://docs.microsoft.com/en-us/dotnet/core/compatibility/globalization/6.0/culture-creation-invariant-mode

Starting in .NET 6, an exception is thrown if you create any culture other than the invariant culture in globalization-invariant mode.

Azure/azure-storage-net#1050

[AlexGhiondea]

Hi everyone and Happy New Year!

I wanted to let you know that we have a version of the package ready for you to give a try! More information about it are here.

[AlexGhiondea]

Hi everyone! I wanted to circle back here and announce that we have released the GA version of this library:
https://www.nuget.org/packages/Microsoft.Azure.WebJobs.Extensions.Tables/1.0.0

[Bartmax]

[jsquire]

@Bartmax: Your screenshot appears to indicate something different than the focus of this issue. I'd suggest opening an issue in the Azure Functions worker process repository, here so that the team best able to assist has visibility.