10

I am writing an Azure Function that is using 2 nuget packages (A and B) from my private feed. Package A uses Dapper version 1.50.2 directly and package B uses Dapper.SimpleCrud 1.13.0 which has a dependency on Dapper version [1.42.0, 2.0.0).

Within the Azure Function I have added project.json where I specify package A and B and their versions.

When I look at the installed packages within the azure function I see Dapper 1.42.0 and 1.50.2 are both installed. when I attempt to call methods in package A and B I get an error on the azure function logs saying that it could not find Dapper version 1.40. (depending on how I set my project.json it would be either Dapper 1.40 or 1.50 that is not found by Azure Function)

I have created a test version of the Dapper.SimpleCRUD package where the dependency on dapper is from [1.50.2, 2.0.0) and every thing works.

I have also tried to add Dapper 1.50.2 to project.json in the hopes that it will be used by Dapper.SimpleCRUD, but it still seems to pull in Dapper 1.42.

Is there some setting that I missing on Azure Functions to allow this setup to work or is this a limitation on Azure Function package management ?.

Thanks for any help you can provide.

Nish
  • 101
  • 1
  • 3
  • 1
    This seems to be a general issue with Azure Functions and .NET, still, tracked here: https://github.com/Azure/azure-webjobs-sdk-script/issues/992. Some progress has been made as described at https://stackoverflow.com/questions/38093972/azure-functions-binding-redirect – Rory Jan 17 '18 at 00:47

2 Answers2

6

I seems like an issue (AFAIK even as late as Oct 2016) that they still haven't figured out a good way of doing binding redirects in azure function.

I ran into a similar issue with my azure function using two different nuget packages with same dependency (but different versions).

There was a similar question asked here : Azure Functions binding redirect

I ended up keeping the least possible number of nugets to avoid binding redirects. If this is not possible with your project try using for webjobs (atleast as a short term solution) till azure functions supports this.

Pavel Chuchuva
  • 22,633
  • 10
  • 99
  • 115
frictionlesspulley
  • 11,070
  • 14
  • 66
  • 115
  • Thanks for your response. It seems this is a issue that happens periodically. I spent all of yesterday trying to fix this issue and built my version of Dapper.SimpleCRUD and it worked. Today I rolled back my dependencies to the original Dapper.SimpleCRUD that has minimum [1.42 ) and re-started my app service and every thing works fine( calls that uses Dapper.SimpleCRUD and calls to other packages that use Dapper 1.50.2 ..... – Nish Nov 26 '16 at 22:52
  • 2
    Nish, if you continue to encounter problems, please file an issue with detailed steps/description on GitHub (https://github.com/Azure/azure-webjobs-sdk-script) so we can investigate. I'm also working on (an overdue) post with detailed information about the options and behavior of managed dependencies in Azure Functions, which may help clear up some of the questions. – Fabio Cavalcante Nov 28 '16 at 02:28
  • @FabioCavalcante Did you ever write a blog post explaining how to manage dependencies in Azure Functions? I have two super popular open source projects and I get a ton of false positive bug reports from customers who don't seem to understand how to manage dependencies in Azure Functions. It would seem like the blog post is still long overdue. – John Zabroski May 24 '22 at 01:19
0

Out of process azure functions introduced in .net 5.0 and buffed up in .net 6.0 solves this and more!

https://learn.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-process-guide#benefits-of-running-out-of-process

When your .NET functions run out-of-process, you can take advantage of the following benefits:

  • Fewer conflicts: because the functions run in a separate process, assemblies used in your app won't conflict with different version of the same assemblies used by the host process.
  • Full control of the process: you control the start-up of the app and can control the configurations used and the middleware started.
  • Dependency injection: because you have full control of the process, you can use current .NET behaviors for dependency injection and incorporating middleware into your function app.
frictionlesspulley
  • 11,070
  • 14
  • 66
  • 115