Extensions.Storage 3.0.0 & WindowsAzure.Storage 9.3.2 fails to bind to CloudQueueMessage #3784
Comments
|
@HiroyukiSakoh I've also seen this issue, unfortunately I had to regress the WindowsAzure Storage nuget to the same version used by the Functions SDK in a number of our components to allow us to move forward; the exception I've seen is coming from deep within the code when attempting to de-serialize the message. |
|
@fabiocav I can confirm a repro. In VS just make a queue triggered function, change the param type, then update from 9.3.1 to 9.3.2 and you'll hit it. This is a bug, we need to investigate. |
|
This is indeed a defect and not the expected behavior. We'll have this addressed and use this issue to track the work/fix. |
|
accroding to the document https://docs.microsoft.com/en-us/azure/cosmos-db/table-storage-how-to-use-dotnet, there is a tip:
It seems Microsoft.Azure.WebJobs.Host.Storage(3.0.0) still use WindowsAzure.Storage not the Microsoft.Azure.Storage.Common package. |
|
with 3.0.3 and 9.3.3 the issue is still there. Any clue when it will be fixed? |
|
For Googleability, I ran into this issue when I had an Http trigger that writes to a queue using The current Microsoft.Azure.WebJobs.Extensions.Storage 3.0.4 depends on {
"asBytes": "eyJ2ZXJzaW9uIjowLCJqc29uVmVyc2lvbiI6MCwibm9ybWFsaXplZFBhY2thZ2VJZCI6Im5pdG8uYXN5bmNleCIsIm5vcm1hbGl6ZWRQYWNrYWdlVmVyc2lvbiI6IjQuMC4xIiwibm9ybWFsaXplZEZyYW1ld29ya1RhcmdldCI6Im5ldDQ1Iiwib3BlcmF0aW9uSWQiOiI0MGMyM2IxMy0yYzU1LTRiN2MtYmYwNC04MDUzNTNmZDZlYjciLCJwYXJlbnRPcGVyYXRpb25JZCI6IjAwMDAwMDAwLTAwMDAtMDAwMC0wMDAwLTAwMDAwMDAwMDAwMCJ9",
"asString": "{\"version\":0,\"jsonVersion\":0,\"normalizedPackageId\":\"nito.asyncex\",\"normalizedPackageVersion\":\"4.0.1\",\"normalizedFrameworkTarget\":\"net45\",\"operationId\":\"40c23b13-2c55-4b7c-bf04-805353fd6eb7\",\"parentOperationId\":\"00000000-0000-0000-0000-000000000000\"}",
"dequeueCount": 0,
"$AzureWebJobsParentId": "40c23b13-2c55-4b7c-bf04-805353fd6eb7"
}This was observed using |
|
Small update on this. We're working on addressing the issue, but in the meantime, a mitigation option is to add the following to your project file (this will also be automatically handled by tooling): <Target Name="PostBuild" AfterTargets="PostBuildEvent">
<Exec Command="copy $(OutDir)$(ProjectName).deps.json $(OutDir)bin\function.deps.json" />
</Target>
<Target Name="PostPublish" AfterTargets="AfterPublish">
<Exec Command="copy $(PublishDir)$(ProjectName).deps.json $(PublishDir)bin\function.deps.json" />
</Target>Will keep this issue open until completely resolved, but the above should unblock the scenario. |
|
can confirm that this workaround is working for now.. |
|
question for Fabio's workaround: any ETA on a fix? Also can you please explain where the above goes in the project file? Is this the function that is triggered by the queue? We're working on a customer demo for Function/Queues and this is blocking....thank you. |
|
Still an issue with 3.0.6 and 9.3.1. After a build the Microsoft.WindowsAzure.Storage.dll file on disk in bin\Debug\netcoreapp2.2\bin says 9.3.1 For me the workaround isn't - same error. My workaround was to let it deserialize my json (what's in the queue message) to a poco. But that's suboptimal since I wish to log the contents of the raw CloudQueueMessage. Any clue when it will be fixed? |
|
@jasoncoding Can you please open a separate issue, include the details of what you're seeing and perhaps a repro. Based on what you're describing, you're dealing with something different than what is tracked by this issue. |
|
Linking to the SDK issue tracking the work needed to complete this |
|
@fabiocav The details of what I'm seeing are the exact details in this issue.
I didn't play around with every combination of Extensions.Storage and WindowsAzure.Storage so I can't comment on the precise cause but I experience the exact same effect described in this thread. If I get time I shall post a repro. |
|
@jasoncoding what you’ve stated above describes a different issue than what is described in the original issue. The fact that you’re experiencing issues with the.version that works for others, and the workaround doesn’t help, indicates that you have a different problem. The way this is manifested and the exception message may be the same, but it’s unlikely it has the same root cause. A separate issue, with details similar to what the original author provided, with a repro, would Help us identify the problem and better assist you. |
|
What task and settings would you use for this in Azure DevOps?
I was building with the Visual Studio build task (YAML below) in Azure DevOps and the function.deps.json doesn't get copied. steps:
- task: VSBuild@1
displayName: 'Build solution'
inputs:
solution: src/eCommerce.Web/eCommerce.Web.sln
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(Build.ArtifactStagingDirectory)"'
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
clean: true
maximumCpuCount: true
enabled: trueUPDATE steps:
- task: DotNetCoreCLI@2
displayName: 'dotnet build Functions'
inputs:
projects: 'src/**/*.Functions.csproj'
arguments: '--output $(Build.BinariesDirectory)\Atlas.Ecommerce.Functions --configuration $(BuildConfiguration)'One thing that threw me off is that the builld will fail if the "output" parameter has a slash in the wrong direction (for Windows). |
|
@MisinformedDNA thanks for that update, I'm sure it will be helpful to others. I'm tracking to have the build fix as part of the tool in this coming sprint. |
|
@fabiocav Workaround posted above works when deploying locally. However, after publishing from Visual Studio, I get the error on the portal. What am I doing wrong? Function (GetRecords) Error: Microsoft.Azure.WebJobs.Host: Error indexing method 'GetRecords'. Microsoft.Azure.WebJobs.Extensions.Storage: Can't bind Table to type 'Microsoft.WindowsAzure.Storage.Table.CloudTable'. |
|
I'm seeing the same issue with
|
|
@panjevic |
|
I'm having the same issue. v3.0.6 and v3.0.7 fail with the same error you're seeing. |
|
@soninaren Unfortunately this doesn't work for me, I'm still seeing the same issue. Tried creating new Function app and upgrading to v3.0.7 but that didn't work either. |
|
@panjevic I also encountered this issue where the workaround suggested by fabiocav worked locally but not when I do a publish. In my case my publish is a ZIP deploy. After searching the web for a day, I finally got it to work for the publish scenario using the below. The main difference is instead of doing a AfterTargets against AfterPublish, I instead do a BeforeTargets against CreateZipFile. Hope this helps you or others facing similar issues. I found the solution from AtOMiCNebula on link: #3568 |
|
Oh and this worked for me without needing to do: WEBSITE_USE_PLACEHOLDER= 0 |
|
@fabiocav Can we get an update on this? |
|
I'm running into this issue when using Durable tasks references fyi. @cgillum |
|
@APErebus This is a regression in the Durable Functions v2.0.0-beta3 release. We're tracking it here: Azure/azure-functions-durable-extension#975 |
@cgillum Awesome. Thanks for the info :) |
|
Closing this one as the original issue has been resolved. For the issue related to durable functions refer to Azure/azure-functions-durable-extension#975 |
ghost
locked as resolved and limited conversation to collaborators
I'm using function runtime version 2.0.12115.0 .
Extensions.Storage 3.0.0 & WindowsAzure.Storage 9.3.2 fails to bind to CloudQueueMessage.
Why does this error happen?
When using Extensions.Storage 3.0.0, do I have to always use WindowsAzure.Storage 9.3.1?
The text was updated successfully, but these errors were encountered: