Azure-functions-vs-build-sdk: Version 1.0.19 of the SDK seems to remove support for Storage Queues

[benm-eras]

I had an application using version 1.0.14 of this SDK and have several function making use of Azure Storage Queue triggers. Updating to version 1.0.19 today prevents my code from compiling seemingly because support for queues has been removed (maybe moved?).

I have a minimal reproduction here. The final commit has version 1.0.19 and will not compile, and the one before has version 1.0.14 and compiles just fine.

Here are the build errors:

And the red squigglies when trying to work with queues:

Maybe something has changed that I missed, but the Visual Studio tooling is still using the same attributes I am when you add a new Azure Function through the UI.

[hf-kklein]

The same issue applies to Azure Functions with [Table(...Connection="..."...)] arguments.

[benm-eras]

@hf-kklein do you have an open issue that this should be linked to?

[hf-kklein]

do you have an open issue that this should be linked to?

No, I just stumbled accross the same errors in my code and checked the Github issues, as always when Azure stuff breaks after an update. The symptoms/compilation errors are just the same, except for the fact that I'm not using QueueTrigger but Table as an argument. I think that both your and my problem do have the same cause and hopefully same solution, too. Therefore I wouldn't open a separate ticket.

[rafalFurman]

I believe you need to add package Microsoft.Azure.WebJobs.Extensions.Storage 3.0.0-beta8 for storage queue.

[tomaszzmuda]

I have the same issue. @rafalFurman I've tried to add this package manually, compilation works but after it fails in runtime.

[hf-kklein]

This morning my Visual Studio automatically updated the runtime to

Function Runtime Version: 2.0.12050.0

I also installed the preview "Microsoft.Azure.WebJobs.Extensions.Storage 3.0.0-beta8" mentioned by @rafalFurman.

Since then my unchanged code is compiling with Azure Functions SDK version 1.0.19.

[benm-eras]

@rafalFurman do you know if Microsoft.Azure.WebJobs.Extensions.Storage will be required to work with storage going forward, or is it just a workaround for an issue with version 1.0.19 of the SDK? My preference would be to just hold off updating the SDK until it's sorted out

[rafalFurman]

@tomaszzmuda Yesterday I had the same issue, today my VS downloaded update while starting my functions and It works for me now.

@benm-eras yes permanent. https://github.com/Azure/azure-functions-host/releases the idea is to loosen dependency on storage library so only the extension needs a release when storage releases new version.

[pavele]

If the Table attribute is moved from Microsoft.Azure.WebJobs to Microsoft.Azure.WebJobs.Extensions.Storage this is a breaking change. On top of that extensions storage is in beta and there is ZERO documentation regarding this major change!

[andyblack19]

Woah.
Yesterday my Azure Functions suddenly stopped firing after a restart. They should be triggered by a QueueTrigger. I guess they are now failing to start up after Azure runtime has been updated?
I know it's a beta runtime.. but this is a ridiculous.
No useful information available from the portal UI.. apart from a long list of messages sitting in the queue.

[rafalFurman]

@pavele Yea I was also surprised by breaking changes but runtime is in alpha as far as github repo release notes are concerned Azure Functions Runtime 2.0.12050-alpha

[andyblack19]

Confusing, as the Azure portal shows the runtime options of 'v1' or 'beta'.
Found this announcement below, including how to pin the runtime version locally and on Azure (available for 30 days) https://github.com/Azure/app-service-announcements/issues/129

[brianvu]

My code compiles after referencing the suggested package Microsoft.Azure.WebJobs.Extensions.Storage 3.0.0-beta8, but I'm running into this error while running locally...

It appears that the queueTrigger is not registered, even though the correct binding extension is installed.

[Tealons]

Having the same problems here to. Referencing a beta version does not feel right.... Going back to version 1.0.14 solved it for now.

[andyblack19]

Anyone else concerned that the runtime selection in the Azure portal says 'beta', but the team are pushing 'alpha' releases out?

[jeffhollan]

As part of v2 GA we cleaned up the dependencies and templates. Let me know if this is still an issue and will re-open / investigate.