Reputation: 33048
I'm trying to run an HTTP triggered v2 function in Visual Studio 2019. It's supposed to write its output into an Azure Storage Table called "history".
I've decorated one my functions with
[return: Table("history")]
and I make it return a subclass of TableEntity
.
This results in an exception about it being "unable to bind Table to CloudTable". The reason for the exception is a check within the CloudStorageAccount
client's code:
bool bindsToEntireTable = tableAttribute.RowKey == null;
if (bindsToEntireTable)
{
// This should have been caught by the other rule-based binders.
// We never expect this to get thrown.
throw new InvalidOperationException("Can't bind Table to type '" + parameter.ParameterType + "'.");
}
Another function binds to a CloudTable
as an input parameter and suffers from the same exception.
Although binding to CloudTable
should work (https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-storage-table#input---c-example---cloudtable) it apparently does not.
Is this a bug in the client SDKs for Azure Storage or am I doing something wrong? I'm referencing these Nuget packages:
<PackageReference Include="Microsoft.Azure.Functions.Extensions" Version="1.0.0" />
<PackageReference Include="Microsoft.Azure.WebJobs.Extensions.DurableTask" Version="1.8.3" />
<PackageReference Include="Microsoft.Azure.WebJobs.Extensions.Storage" Version="3.0.6" />
<PackageReference Include="Microsoft.Extensions.Configuration.UserSecrets" Version="2.2.0" />
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.29" />
<PackageReference Include="Newtonsoft.Json" Version="12.0.2" />
Upvotes: 4
Views: 3049
Reputation: 369
I had similar problems, I got this when I tried to start my Azure Function V3:
Error indexing method 'Function' Cannot bind parameter 'Table' to type CloudTable. Make sure the parameter Type is supported by the binding. If you're using binding extensions (e.g. Azure Storage, ServiceBus, Timers, etc.) make sure you've called the registration method for the extension(s) in your startup code (e.g. builder.AddAzureStorage(), builder.AddServiceBus(), builder.AddTimers(), etc.).
As stated, I saw in my project that the WindowsAzure.Storage
had a warning sign and stated that it is deprecated.
The fix for me to get my project listening on Table Storage events was to change the using. Apparently I already got a reference to Cosmos in my project using the Microsoft.Azure.WebJobs.Extensions.Storage
Fixing the issue for me by removing the using: using Microsoft.WindowsAzure.Storage.Table;
and just replace it with using Microsoft.Azure.Cosmos.Table;
But be aware if you are using the ObjectFlattenerRecomposer.Core it is still using Microsoft.WindowsAzure.Storage.Table
and will not work with Microsoft.Azure.Cosmos.Table
yet. I have contacted the developer regarding this.
Upvotes: 0
Reputation: 33048
The problem is a version mismatch of two Nuget packages. When creating a new solution I was unable to replicate the issue and binding to CloudTable
worked just fine. Comparing to my solution revealed that my function project referenced another project which had a dependency on
WindowsAzure.Storage (9.3.3)
because I needed the TableEntity
type in there.
And now it's getting tricky. The functions project has a reference to
Microsoft.Azure.WebJobs.Extensions.Storage (3.0.6)
and that one has a dependency on
WindowsAzure.Storage (9.3.1)
The version difference of 9.3.3 and 9.3.1 leads to the binding problems. The solution is to either downgrade to 9.3.1 in the referenced project
or
alternatively (and probably recommended): remove WindowsAzure.Storage
from the referenced project and replace it with Microsoft.Azure.Cosmos.Table
which also contains TableEntity
. Important do NOT confuse this with Microsoft.Azure.CosmosDB.Table
(notice the "DB") which is being deprecated. Unfortunately, the comments for WindowsAzure.Storage (9.3.3)
tell us to change to exactly that incorrect package.
Concusion: it's a hot mess :-)
Upvotes: 10