Functions runtime (and emulator) fail to start if Microsoft.Extensions.DependencyInjection.Abstractions 5.0.0.0 is used

[richardhauer]

We are upgrading parts of our application to the new v5 runtimes (they are Blazor).
Those parts that still run on the Functions runtime are still using netcore 3.1.
Some assemblies in the solution are using the v5 of Microsoft.Extensions.DependencyInjection.Abstractions.

This library advertises that it has no dependencies on .NETStandard, Version=2.0 so it seems like is should really work.
Neither the emulator nor the real function apps will start with this library in and part of the dependency chain - the error raised is:

[2020-11-12T06:40:25.252Z] A host error has occurred during startup operation '069ab1bd-456f-4858-8133-73cd491c6a74'.
[2020-11-12T06:40:25.253Z] API.Validations: Could not load file or assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.
Value cannot be null. (Parameter 'provider')

I'm using the Core Tools v3.0.2996 released about a week ago.

Repro steps

1. Create a new Function App with HTTP Trigger in VS2019 16.8
2. Add Microsoft.Extensions.DependencyInjection.Abstractions v5.0.0.0 from nuGet
3. Run with debugging

Expected behavior

Runtime should support NetStandard v2 compatible libraries

Actual behavior

Crash on startup - functions are not bound to the runtime.

[NoahStahl]

Also saw this error when attempting to upgrade to .NET 5. Rolled back for now.

[pragnagopa]

Tagging @brettsam / @fabiocav / @ankitkumarr for more details and guidance

[eimerreis]

I'm facing the exact same issue

[AartBluestoke]

• when you run azure functions, it starts before it loads your code.
• only 1 version of a dll can be loaded at once.

Consequence: if you need a library that is a direct or indirect dependency of azure functions you can only use the version that is loaded. This is a case where azure functions is incorrectly reporting its hard dependencies.

eg: if you are using azure functions 3.0.7, then you must use a library binary compatible with dependencyInjection.abstractions 2.1.0
When your code (eg if you have a asp.netcore dependencency) asks for something that is only found in Abstractions >=5.0 the runtime (correctly) responds "sorry, that function isn't there", because all it has is the 2.1.0 dll in memory.

Therefore the many tickets that will be raised that are like this can only be solved by upgrading azure functions to a newer version which has a dependency on the 5.x line of the abstractions.

In this particular case, if azure functions used Microsoft.Extensions.DependencyInjection.Abstractions 5.0, then it would be fine because that library appears to be backwards compatible so the reverse error doesn't occur (no runtime failure if you expect 2.1 and actually get 5.0).

If that is not true for all libraries in common between azure functions and the libraries your code uses, then you will be pinned in terms of your dependencies and azure functions versions.

[richardhauer]

@AartBluestoke Yeah my investigations (after posting this issue) kinda landed in the same spot - seems that the runtime has already loaded a version of the DI library.

I guess where this will start to become a more significant issue is that the v5 HttpClient libraries are now pinned into the v5 DI library as well, so we're going to get to a point pretty quickly where there's a cascading set of dependencies that will prevent Azure Functions consumers from using a lot of the new code releases.

I've been tracking various posts regarding a possible Functions "v4" runtime that will support net5 but there is really no timeline anywhere. We need net5 because of Blazor, and using Functions under Blazor is a pretty common design pattern that is undermined by this lack of compatibility.

I think we can close this ticket, but ideally we need some visibility on how soon net5 will be usable in Functions as this is a blocker for adoption in a number of circumstances.

[richardhauer]

Potentially, loading the "customer Function code" into its own AppDomain and isolating it from the runtime would help alleviate this sort of issue, but presumably will raise different issues. Just a thought.

[NoahStahl]

It appears functions doesn't support .NET 5, with a preview possible by end of year: #6674 (comment)

[fabiocav]

Assigning to sprint 90 so we can provide some guidance for this scenario.

[sebader]

There seems to be GitHub issues for this all over the place in different repos. @fabiocav would it make sense to consolidate those at one place? I assume they are basically all the same thing, aren't they?
Apart from the ones linked above I also came across:
Azure/azure-functions-core-tools#2304
Azure/Azure-Functions#1729

[scotty-tarvan]

Just to add my 10 cents here and to try and make it clearer what's going on:

When the functions runtime executes it loads up a set of assemblies, these can be viewed by looking at AppDomain.GetAssemblies(). An example of an assembly loaded in functions runtime v3 is:

_Microsoft.Extensions.DependencyInjection.Abstractions, Version=3.1.10.0, Culture=neutral, PublicKeyToken=adb9793829ddae60_

If you reference something like EFCore v5 that requires **Abstractions v5 it will fail as it cannot load an assembly already in the AppDomain. This limits you to referencing assemblies that are loaded in the AppDomain.

This is a really tricky issue to work with as you need to look at every referenced assembly and make sure it does not exceed the assembly version loaded to the runtime of functions v3 - an example is EFCore where you stuck with v3.1.9 ~ its really time consuming and a huge pain to do an upgrade and not break anything. I recommend you do not upgrade until this is fixed.

This is a fairly common problem with tasks hosted in a runtime and I would love to get comments from the functions team as to how they will solve this problem. New app domain?

[ssa3512]

This seems to be binding redirects all over again. I thought .NET Core had solved that issue.

[AartBluestoke]

This seems to be binding redirects all over again. I thought .NET Core had solved that issue.

this has always been the case for azure functions - eg: Newtonsof.json dependency of v9 for azure functions v1;

[drfbwilliams]

This is not solved in anyway shape or form.

Adding a closed tag and basically placing an endless loop of redirects in github is utterly pointless.

It is the end of APRIL - where is the definitive fix on this issue that doesn't required a forced upgrade to Core 5?

Someone on your teams needs to take some leadership here and follow all of the messed up references to this and place a resolution.

Assign a team member to co-ordinate with all known inter referenced issues of this (Webjobs, SignalR etc) and get a combined resolution.

I am sick of reading about one team blaming another for this issue and just washing their hands of it.

[fabiocav]

@drfbwilliams I'm sorry if the information shared here hasn't been clear. But the roadmap when it comes to support for new .NET versions and framework assemblies has been shared here. This outlines the options available now and what the experience will look like in the future.

[drfbwilliams]

@fabiocav - thank you for the reply and the link to that information.

I understand the problem your team is facing and the reasons for moving to the out of process implementation, and I also believe it is the right decision to make.

At some point, the entire communication strategy has to change - documentation, even these repos are an absolute minefield to navigate and burn so much time. That is where the frustration sets in as I am sure you can understand.

But, you're not on your own there - delegate the comms stuff out to folks like @anthonychu or any of the other developer advocates and the comms teams. You and your team have got enough stuff to get through without being expected to be comms experts as well.

[fabiocav]

Closing this issue as there are no additional action items being tracked here. Please let us know if there are any other questions.