-
Notifications
You must be signed in to change notification settings - Fork 447
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
Comments
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 - |
@priyankar-dutta this versioning issue goes back to v1 functions with Newtonsoft.Json #4049 |
Adding this to triaged for further investigation |
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 |
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
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.
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.
The text was updated successfully, but these errors were encountered: