For a CSX, needing multiple dlls, we experienced conflicts related to different dll versions required by dependencies.
In order to make our legacy dll code work in an azure functions, we need some kind of binding redirect like in classical .Net projects.
Otherwise we need to run our tasks in webjobs or recompile projects we don't own !
But we want Azure functions ! ;-)
Thanks
@EmmanuelDURIN Are you using a project.json or just uploading the dll files? I tried switching to a project.json, but I've been running into this for the last several hours:
2017-03-01T22:39:39.101 Could not load file or assembly 'Google.Cloud.Logging.Log4Net, Version=1.0.0.0, Culture=neutral, PublicKeyToken=185c282632e132a0' or one of its dependencies. The system cannot find the file specified.
With a project.json of:
{
"frameworks": {
"net46": {
"dependencies": {
"Argu": "3.7",
"FSharp.Configuration": "0.6.4",
"FSharp.Data": "2.3.2",
"FSharp.Data.SqlClient": "1.8.2",
"Google.Cloud.Logging.Log4Net": "1.0.0-beta08",
"Microsoft.SqlServer.Types": "11.0.2",
"Newtonsoft.Json": "9.0.1"
}
}
}
}
Is there any way to turn on or view the fusion logs?
Also related: http://stackoverflow.com/questions/38093972/azure-functions-binding-redirect
@ctaggart can you put a repo on GH with a repro so we can take a quick look.
@EmmanuelDURIN binding redirects are not currently supported, but can you share more information about your scenario? What kind of conflicts are you running into? Between different functions, or runtime assemblies? How are you referencing the assemblies? With more information, we can make some recommendations on things you can try.
@fabiocav We need support for binding redirects. It is not possible to use many libraries without it. In this case, I can't use Google.Cloud.Logging.Log4Net. In order to use Azure Functions, I need this one. Here is the generated project.lock.json. There is a dependencies on 1.16.0 and 1.20.0 of Google.Apis.Auth.
Seconding @ctaggart, lack of binding redirects is a significant problem.
I have a dependency on FSharp.Core, 4.4.1.0. I also have a dependency on FSharp.Data, and get run-time errors when I call functions from it:
Could not load file or assembly 'FSharp.Core, Version=4.3.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference.
Even though FSharp.Core is backwards compatible.
I'm looking forward to having a solution for binding redirects. This one is a blocker for us.
@ctaggart there is a workaround for your scenario (that's why I was asking for additional details). I'll make sure I can repro your issue and share the workaround.
@fabiocav
I just posted a sample reproducing my problem :
https://github.com/EmmanuelDURIN/Azure-Function-That-Needs-BindingRedirect
General binding redirect support is tracked here: #992
Any update on the workaround you mentioned?
@fabiocav - can you follow up with workaround.
Backlogging this until the out of proc stuff is ready - https://github.com/Azure/azure-webjobs-sdk-script/issues/1319
Support for binding redirects is a must now that we can have functions in a web project... otherwise the usage of many nuget libraries fails.
@channeladam please follow #992 for updates on this.
As a point of clarification, there's no specific support for the web project type in the Functions runtime (I know, some of the information around is a bit confusing), so some of the features exposed by the project are not supported.
Could do it in code?
http://blog.slaks.net/2013-12-25/redirecting-assembly-loads-at-runtime/
@willwhite1 yes, that is doable. Just need to be careful on how you subscribe and make sure you cooperate since the runtime also uses similar techniques. Again, depending on your scenario, there are workarounds you can apply, so it might be worth sharing more (you can open new issue to cover your specific scenario).
Closing stale issue.
Most helpful comment
Support for binding redirects is a must now that we can have functions in a web project... otherwise the usage of many nuget libraries fails.