2

Overview

A custom assembly I made needs to use a differnt version of WindowsAzure.Storage depending on whether I run it locally, using Azure Fucnctions CLI, or remotely on Azure

Description

I am using a custom assemlby with Azure Functions to do some blob manipulation logic. As such, it depends on the assembly Microsoft.WindowsAzure.Storage. So I have a Visual Studio solution which contains:

  • A class library project, contianing the custom assembly
  • A class library projecx, containing the unit tests for the custom assembly
  • A functions project

As part of the build trigger, I am copying the custom assembly into an appropriate place in the fucnxtions, and using the reference tag to pull it in.

When working locally, I can use Azure Functions CLI to run the relevant function. When deploying to Azure, I can use the portal to run my function. (I deploy by local git repo, in case that is relevant).

The difficulty I am having is that the AF CLI seems to require a different version of the WindowsAzure.Storage assembly to be running than the true Azure Functions portal. I am passing the TraceWriter instance to the backing library, so I need to use Microsoft.Azure.WebJobs, which has it's own dependency on WindowsAzure.Storage.

To get the Azure functions working in the cloud, I use the versions:

Microsoft.Azure.WebJobs.Core v1.1.2
Microsoft.Azure.WebJobs      v1.1.2
WindowsAzure.Storage         v6.1.0

But then I see the following error message when using the local hosting environment:

Exception while executing function: Functions.SdcLaundrySriTrigger. 
mscorlib: Exception has been thrown by the target of an invocation. f-<Redacted>Trigger__1261552806: Method not found: 
'Void <RedactedClassname>..ctor(Microsoft.Azure.WebJobs.Host.TraceWriter, System.String)'.

I can make the issue for the local environment go away if I used a more recent version of the WebJobs libraries:

Microsoft.Azure.WebJobs.Core v2.0.0-beta1
Microsoft.Azure.WebJobs      v2.0.0-beta1
WindowsAzure.Storage         v7.2.1.0

(The change is made by upping the WebJobs version, and the WindowsAzure.Storage version goes up due to being a dependency). This then runs fine using func funcxtion run . But when I deploy this to the the Cloud Environment, I get the following error:

error CS1705: Assembly '<redacted>' with identity 
'<redacted>, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' uses
'Microsoft.WindowsAzure.Storage, Version=7.2.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' 
which has a higher version than referenced assembly 
'Microsoft.WindowsAzure.Storage' with identity 
'Microsoft.WindowsAzure.Storage, Version=6.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
 2017-02-14T16:49:56.279 Function completed (Failure, Id=f17a046f-e66b-4f50-a812-bc7532db7a0f)2017-02-14T16:49:58.007 Exception while executing function: Functions.<redacted>. Microsoft.Azure.WebJobs.Script: Script compilation failed.

At this point, the obvious thing to do is to drop the version of the storage assembly back to version 6.1.0.0 - but this pulls the version of the WebJobs assemblies back down to the ones I started with, which cause the function to not work locally.

Actual Behvaiour

It is not possible to have the function with the backing assembly be dependent on the same version of Microsoft.Azure.WebJobs locally and on Azure.

Expected Behaviour

Once I have the function running locally, and push it to Azure, it should have the same version.

Questions

Has anyone seen this before? Is there an easy workaround?

I know this looks superfically similar to This issue, but I do think it is a different issue. And it could be considered similar to This issue as well, but I still think it is not quite the same

Community
  • 1
  • 1
Iain Peddie
  • 83
  • 4
  • How are you referencing the storage assembly from your function? The CLI and the Azure runtime should have the same set of dependencies, they did get out of sync with the last CLI preview drop, but you shouldn't be seeing major versions mismatch. – Fabio Cavalcante Feb 15 '17 at 18:09
  • I have extracted logic into a custom assembly, which I am uploading. It is the version in the assembly that I have the issue with. I then included the Azure storage with NuGet - but the version needed to make things work locally and when delivered to Azure were mutually incompattible. – Iain Peddie Mar 10 '17 at 14:21

2 Answers2

0

I don' think you need to add external package or dlls for

  • Microsoft.Azure.WebJobs.Core
  • Microsoft.Azure.WebJobs
  • WindowsAzure.Storage

These are already being there by default for function app

You need this on your local project to have environment like azure function.

Try removing nuget dependancies for these items from project.json file if you have added it.

Utkarsh Patel
  • 305
  • 2
  • 8
  • also, this link provies some details about the assemblies which will be added automaticaly by function hosting enviroment [link]https://learn.microsoft.com/en-us/azure/azure-functions/functions-reference-csharp#importing-namespaces – Utkarsh Patel Apr 12 '17 at 06:18
  • Thankss for your response. Unforutnately, this doesn't address the problem. Yes, in the functions runtime, these assemblies are automatically pulled in. But I am talking about the case where I pull all my logic into a separate assembly. My intention is to unit test the code. In that case, you need to manually add those assemblies to the separate, custom assembly you write. And the versions needed when you build your custom assembly are different between local and Azure versions of functions (or, at least, were when I posted the original problem.) – Iain Peddie Apr 13 '17 at 13:12
0

I was able to get 7.2.1 to work both in local VisualStudio debug and in Azure. Trick was updating the project.json in the function dir:

{
  "frameworks": {
    "net46":{
      "dependencies": {
        "WindowsAzure.Storage": "7.2.1.0"
      }
    }
   }
}
the-king
  • 16
  • 1
  • If you need to pull a different version of the library than the one served automatically by Azure Functions, you can upload your dlls (in this case the `WindowsAzure.Storage` one) in the `/bin` folder. In that case, your code will pull in the right dependencies and ignore the ones that Azure Runtime offers – Chris May 16 '17 at 14:45