Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.NET Dependencies are Tied To a Specific Version Range #7194

Closed
MelbourneDeveloper opened this issue Mar 1, 2021 · 5 comments
Closed

.NET Dependencies are Tied To a Specific Version Range #7194

MelbourneDeveloper opened this issue Mar 1, 2021 · 5 comments

Comments

@MelbourneDeveloper
Copy link

MelbourneDeveloper commented Mar 1, 2021

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:

image

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
Azure/azure-functions-core-tools#2304

Closed - But, I don't know that these have been fully addressed
Azure/azure-functions-core-tools#141
#1239
#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.

image

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:
image

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.
image

You will see that it runs fine
image

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.

@jeffhollan jeffhollan transferred this issue from Azure/Azure-Functions Mar 1, 2021
@ghost ghost assigned soninaren Mar 1, 2021
@xiaosu
Copy link

xiaosu commented Mar 1, 2021

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 -
image
or sometimes it just reported build errors which does not exist when building from VS 2019.

@v-anvari v-anvari self-assigned this Mar 26, 2021
@priyankar-dutta
Copy link

It seems the only solutions for this issue till now are upgrading the Azure Function to .NET 5 (which is missing stuff) or downgrade the libraries to 3.x.x versions. This is a breaking issue and it should not require project teams to upgrade / downgrade packages just because the Azure Functions team refuses to fix an issue reported as early as Nov 2020 -
Azure/azure-functions-core-tools#2304

@espray
Copy link

espray commented May 13, 2021

@priyankar-dutta this versioning issue goes back to v1 functions with Newtonsoft.Json #4049

@v-anvari
Copy link

Adding this to triaged for further investigation

@v-anvari
Copy link

Hi @MelbourneDeveloper, These dependencies are formed in such a way that Nuget packages above 5.x.x supports only .Net 5. There were few issues in the past to make this scenario work better, but unfortunately this is as per design and the way the net stack typically works.

Closing this issue as this is by design

Some more information regarding the same is here - #7601

@v-anvari v-anvari removed this from the Triaged milestone Sep 27, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Nov 3, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants