Confusing error message when "WindowsAzure.Storage" package is referenced in project.json

[mgrabarz]

According to the documentation there are packages that are included by default to Azure Functions runtime environment, one of those packages is WindowsAzure.Storage package.
When someone references the same package in project.json by mistake (or because of the lack of Functions knowledge) very confusing exceptions start to pop up.

Repro steps

Details of the error and repro steps can be found here: http://stackoverflow.com/questions/42763467/azure-function-table-storage-in-binding

Expected behavior

I believe users should be warned that they try to reference duplicate packages, and that there is no need to reference them.
Also error that shows up after this incorrect configuration should be more precise, e.g.:
"Multiple versions of 'WindowsAzure.Storage' has been deployed to Function. Please note there are packages that are referenced by default in every FunctionApp, for more details please refer to documentation: https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference-csharp

The same behavior should be applied to all packages that are referenced by default.

Actual behavior

Following exception is thrown by Function:
'Microsoft.Azure.WebJobs.Host.Tables.TableAttributeBindingProvider+TableToIQueryableConverter1[TElement]'
violates the constraint of type 'TElement'. mscorlib:
GenericArguments[0], 'Submission#0+MetadataTable', on
'Microsoft.Azure.WebJobs.Host.Tables.TableAttributeBindingProvider+TableToIQueryableConverter1[TElement]' violates the constraint of type parameter 'TElement'.

Known workarounds

Remove redundant packages from project.json

Related information

N/A

[christopheranderson]

There isn't a simple fix for this in the runtime, so we're going to backlog this for now given it's low impact.

[Shrulik]

I think that with the introduction of the Precompiled Azure Funtion, which at the moment is the recommended way of developing, the impact grows significantly. In a Precompiled Azure function, it is a given I will add 'WindowsAzure.Storage' or my code won't compile and therefore I won't be able to build the relevant DLL to upload.

Maybe there is some workaround nuget setting that will help with this, like 'compile only' or 'provided' ( I will look into it ), but in any case, this will happen much more to people. Happened to me when I used an IQueryable binding, and I just reverted to doing things manually, I guess it worked since the Storage dependency is added only if required.

[MisinformedDNA]

I'm getting this error in a precompiled Azure Function. I have another Function app that works fine. Both reference Azure Storage 8.1.1. I don't have a project.json in either project, which I think is expected.

So what's the workaround for precompiled functions?

[lindydonna]

@MisinformedDNA This must be because you're referencing a different version than used in the runtime, we use 7.2.1. See https://github.com/Azure/azure-webjobs-sdk-script/blob/master/src/WebJobs.Script.Host/packages.config#L45

What's odd is that the script-based Function app works fine. @fabiocav Any feedback?

[MisinformedDNA]

I could match your version number, but this solution won't last in a PaaS service. I assume binding redirects would be high on the backlog then, correct?

[lindydonna]

@MisinformedDNA Agreed, and yes. Note that you only need to match the major version. We have binding redirects in place that will map anything up to the last major version, but we don't include the 8.x version of the Azure SDK to reduce confusion.

Here's the issue tracking binding redirects: #992

[petersondrew]

I've just ran into this issue with a precompiled function myself, and there's a serious snowball effect amongst the various dependencies (Microsoft.WindowsAzure.Storage, Microsoft.Azure.Mobile.Server.*). What if we had a nuget meta package for precompiled function projects that took hard dependencies on the versions deployed to the azure webjob host?

[Shrulik]

Is there any progress regarding this ?

[RobertoPrevato]

I faced the same issue with precompiled functions, but with Newtonsoft.Json. I was referencing the latest version (10.0.1), and getting weird runtime errors. For example: catching JsonReaderException wasn't working, because at runtime I was getting exceptions from the assembly referencing version 9.0.1; not catched by the assembly referencing the newer version!! And I was also getting weird errors when trying to configure the HttpRequestMessage JsonFormatter (with complaints at runtime about missing methods, working fine at compilation time). The problems went away when I downgraded to Newtonsoft.Json 9.0.1.

[mateusmcg]

I was facing this same issue and I tried to remove WindowsAzure.Storage of my project.json file but some other errors started to appear that i couldn't fix (This might be related to my lack of knowledge with Azure Functions).

When i changed the version of WindowsAzure.Storage of 8.5.0 to 7.2.1 in the project.json and all seems to work now.

Thought this might help someone...

[SBajonczak]

I had similar Problemthat when I use WindowsAzure.Storage 8.6.0, I getting the error that my blobtrigger paramaeter cannot bind to the ICloudBlob parameter. When I change it to 7.2.1 it works fine.

I wonder why I didn't see any manetion about this. A small hint like "hey whe support Version 7.2.1 for now" helps alot :)

[jcmontx]

Having this very same issue when returning a TableEntity from Azure Function

[fabiocav]

If you're using Azure Functions V1 and using one of the storage bindings, you need to use the Storage SDK 7.2.1.

[bobmclaren]

I was getting this same annoying "...violates the constraint of type parameter 'TElement'." error and I am indeed using Azure Functions v1 with storage bindings and using storage SDK 7.2.1. It turns out that, for some reason, adding a constructor with parameters causes the error.
This works fine:

public class MyPoco : TableEntity
{
}

This fails:

public class MyPoco : TableEntity
{
  public MyPoco(string name){
   PartitionKey = name;
  }
}

Just thought I would share this workaround for those that ended up here as I did.