Azure-functions-host: .NET Dependencies are Tied To a Specific Version Range

[MelbourneDeveloper]

Several manifestations of this problem have already been reported, but I don't think the other issues capture the scope of the problem. I will try to outline the crux of the problem rather than the specifics.

The Problem

The Azure Functions SDK comes with a pre-packaged set of dependencies (NuGet packages/assemblies). We call this the safe range. Any dependencies that you pull into the functions project need to be compatible with the SDK version. There seems to be some leeway with versioning, but if you use a version that is outside the excepted range, functions will give you errors like this:

The recommended workaround seems to be to downgrade every package in the dependency mesh to match the versions in the Azure SDK. This is fundamentally difficult or impossible. Our libraries may depend on a new feature/fix in some NuGet package or a feature in a NuGet package that is not compatible with the SDK version. If we have a large dependency mesh, it's next to impossible to align all the assembly versions to match the SDK.

Here are some issues that are manifestations of this problem:

Open
https://github.com/Azure/azure-functions-core-tools/issues/2304

Closed - But, I don't know that these have been fully addressed
https://github.com/Azure/azure-functions-core-tools/issues/141
https://github.com/Azure/azure-functions-host/issues/1239
https://github.com/Azure/azure-functions-host/issues/992

A Point of Confusion

Many Microsoft libraries now have version number 5.0.0. On the face of it, it looks as though these libraries are meant to work with .NET 5, and their release coincided with the release of .NET 5. In fact, the APIs are in sync. You might be thinking that these libraries depend on .NET 5, but this is not the case. For example Entity Framework Core 5 targets .NET Standard 2.1 and runs on .NET Core 3.1 or any other .NET implementation that supports .NET Standard 2.1. They don't necessarily depend on .NET whatsoever.

Here is a sample solution that uses EF Core 5 and Microsoft.Extensions.Logging.Console 5 on .NET 3.1 for unit tests, and for a console app. These run fine, so the expectation that Azure Functions running on .NET Core 3.1 would run fine as well.

https://github.com/MelbourneDeveloper/Samples/tree/master/GithubIssues/AzureFunctions

For example, this console app uses logging V5 and runs on .NET Core 3.1:

Recreate the Problem

EF Core 5 drags in dependencies that are incompatible with Azure Functions SDK 3. Logging is one of them. Run the functions app in the solution. You will see the errors.

Now, remove the dependency on the project that depends on EF.

You will see that it runs fine

Wrap-up

The problem is that we don't write code and tests to target Azure Functions. We write code to target a particular framework. In this case, it is .NET Core 3.1. We expect that if the tests run on .NET Core 3.1, they will run on Azure Functions SDK 3. Sure, we might be able to downgrade some assemblies or upgrade to Azure Functions for .NET 5, but this problem is going to keep occurring in the future. What happens when the EF team upgrades to EF 6? Will we have to wait for a new Azure Functions SDK before the functions are compatible with EF 6?

In my opinion, there should be some way for Azure Functions to dynamically bind to the highest version of the assembly. If this doesn't work, there should be a clear error as to why this failed.

But, if this problem isn't addressed, it means that teams have to spend all their time writing, curating, and testing their code carefully so as to comply with Azure Functions. They should be focusing on simply unit testing for the platform: .NET Core 3.1.

[xiaosu]

I was trying to run the AF under .net 5 from command line (func host start --verbose), it sometimes stuck in the middle of the build process like this -

or sometimes it just reported build errors which does not exist when building from VS 2019.