Azure-functions-host: Support assembly redirect configuration for function context/resolver

[fabiocav]

Details to follow.

Creating an this issue to track basic function level assembly binding redirect for the function assembly load context/resolver.

[paulbatum]

Hey folks, fixing this is still a priority for us however it keeps getting pre-empted by critical work.

[apmorton]

I would argue this is pretty critical work, given the amount of user feedback on #992

As an example of how the inability to configure assembly redirects is a pretty critical issue at this point in time, take the WindowsAzure.Storage dependency as an example.

The version specified is currently 7.2.1, and is _over a year old_.
It lacks a number of features that were added in 8.0.0, and basically makes it near impossible to use these features under azure functions.

Due to this, I am basically blocked on a project until one of two things happens in azure functions:

• WindowsAzure.Storage gets updated to at least 8.0.0
• We get the ability as users to configure assembly binding

As a user, I have no options - and am basically forced to return to webjobs in an app service.
I am sure many others are in a similar boat right now due to this issue.

[fuguutoo]

Echoing @apmorton here, and others from #922, lack of assembly redirection and/or timely update of major dependencies is a deal-breaker.

Our project was in a similar predicament with Autofac, Azure.Documents.Client, and most especially Newtonsoft.Json.

It's not critical for us _any more_ because the window of opportunity has closed; #922 is almost a year old and we couldn't wait any longer. When compared to the pace of evolution of other aspects of the platform, that sort of turnaround is, frankly, unacceptable.

[Coderrob]

@fuguutoo if you use a project to generate the assembly bindings to app config, or manually you can use a super mega appsetting hack to force resolutions if you have to use Azure Functions. We converted all our processing from AF to webjobs because of this, but one of my colleagues opened this a while ago. https://stackoverflow.com/questions/38093972/azure-functions-binding-redirect

[paulbatum]

Apologies for my rather brief comment earlier in this thread. By critical work I meant:

1. addressing issues impacting in-production customers
2. landing key milestones for the .NET Core port of functions (which currently targets azure storage 8.5.0)

I understand this is a fundamental, blocking issue stopping many scenarios from taking advantage of functions and that lack of tangible progress over a long time frame has meant you've needed to explore other options. Believe me, it has been frustrating for us to see this work slip from month to month. But live site issues impacting apps that are already in production take priority, as does work that unblocks many other dependencies (e.g. porting to .NET Core).

[jboarman]

We've passed the _New Year_ mile marker... Are we there yet?

[fabiocav]

@jboarman some progress was made on this (design, basic documentation on scenarios it would address, etc.) and we hope to assign this for implementation very soon. We'll also add the details I mentioned to this issue ahead of implementation, which will help gather feedback and understand what this will and will not address.

[rjk]

@fabiocav thanks for the update. I imagine you can't give an ETA yet, but what is a typical timeframe from when a feature this size is assigned for implementation to when it's deployed & available for use? e.g. 1 month, 3 months, 6 months?

Everyone seems to be aware, but this issue (and #992 generally) is a real discouragement to use Azure Functions as a platform for .NET.

[KZeronimo]

@fabiocav is this related to the effort described in this issue?

[paulbatum]

@KZeronimo No. That pull resolved an issue that was preventing people from using .NET standard assemblies.