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
Functions V4 - Require a minimum version for supported extensions #1987
Comments
A quick note for anyone landing on this issue after encountering the error: This documentation page has a table that shows how to reference the 2.x bundle and satisfy the requirement: Pasting here also for convenience - you need the following entry in your host.json file:
If you're a .NET user encountering an error like this: Then a NuGet update to version 4.0.4 (or later) of the Microsoft.Azure.WebJobs.Extensions.Storage package will be sufficient to resolve the issue. Similar applies for similar errors for the other extensions. |
@paulbatum now, running an older functions project (.net 3.1, etc), we still get these errors if we run |
@tommck That would be because your running that .NET 3.1 project on functions V4 using the V4 core tools. You should continue to use the V3 tools when working with V3 projects (until you want to upgrade them). I know VS makes this straightforward by running the right tools version based on the project, but if you're running off the command line you'll need to pick the version explicitly. You can download a V3 core tools release manually from here. Alternatively you could try this unofficial version manager, funcvm. |
@paulbatum I do work with both frameworks. how do I tell Just use the funcvm? :( |
func.exe is not multiversion, its single version, so you don't pass a param to func.exe, you choose which func.exe you want to run. Thats what VS does under the covers, and similarly thats what funcvm does. So without using any other libraries/tools, you would download and unzip one of the V3 releases and then run func.exe from that directory e.g. |
When I use https://www.nuget.org/packages/Microsoft.Azure.WebJobs.Extensions.Storage/5.0.0, I still got an error like this: |
@heavenwing please file a new issue in https://github.com/azure/azure-functions-host - tag me on the issue, include your csproj, and share more details about whether you are hitting this error locally, or only when deploying. |
Hi there, I receive this error when trying to start the logic apps designer. I figure it's cause the logic apps designer brings in a different extension bundle that's old. I can't figure out how to fix it, but I assume I need to change the version of the
|
@hannesne - Logic Apps VS Code extension doesn't support Functions Core tools V4. Can you try making "path" environment variable point to V3 Functions Core tools folder before starting the designer? |
@pchevallier since this is a JavaScript app you are most likely using an extension bundle. You can update the bundle by modifying your host.json - the changes are discussed in this comment. Whether you can do it directly via the portal depends on how you have setup your function app in terms of deployment method. You might be able to edit the file directly, using the App Files section in the left hand side, like so: Alternatively, this might show you a warning about the file being read only, because you have deployed from a package. If that is the case, you'll need to deploy a new package containing the changes to the host.json file. In that case I'd recommend you just make the change and deploy in the same way that you would for any type of change to your function code. |
I was having the same issue and this workaround did the trick for me with a JS function app. |
to fix issue #10 "Referenced bundle Microsoft.Azure.Functions.ExtensionBundle of version 1.8.1 does not meet the required minimum version of 2.6.1. Update your extension bundle reference in host.json to reference 2.6.1 or later" microsoft#10 Azure/Azure-Functions#1987
Added support for the new Azure function version V4 Azure/Azure-Functions#1987
[Functions V4 - Require a minimum version for supported extensions](Azure/Azure-Functions#1987 (comment))
@paulbatum: FYI, I've retargeted your aka.ms link to this new section in the versioning article. |
[Functions V4 - Require a minimum version for supported extensions](Azure/Azure-Functions#1987 (comment))
This solution does not work for me . I am using java |
I'm getting this error for some reason too... Why does
Opened a ticket here too
|
On building the Function app after adding the extensionBundle snippet to host.json I've received the following error message:
Any advice on how to resolve? TIA! |
Deploying to Azure (yesterday and today) we are getting an error about the ServiceBus extension being out of date but we are using 5.9.0. Any ideas what our actual issue could be? Microsoft.Azure.WebJobs.Script.ExternalStartupException : Error building configuration in an external startup class. ---> Microsoft.Azure.WebJobs.Script.HostInitializationException : One or more loaded extensions do not meet the minimum requirements. For more information see https://aka.ms/func-min-extension-versions. ExtensionStartupType ServiceBusWebJobsStartup from assembly 'Microsoft.Azure.WebJobs.ServiceBus, Version=4.1.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' does not meet the required minimum version of 4.2.1.0. Update your NuGet package reference for Microsoft.Azure.WebJobs.Extensions.ServiceBus to 4.2.1 or later. at Microsoft.Azure.WebJobs.Script.DependencyInjection.ScriptStartupTypeLocator.ValidateExtensionRequirements(List CsProj file:
|
@jenp-jb the csproj you shared looks fine, I can't see any problems there. I think there must be something wrong with your build output, maybe an old version of the extension is still lying around? The clue here is that |
@paulbatum I've had a look at the Azure files using Kodo - but I just don't see any old Dll lingering around unless I'm being blind. |
Can you share the contents of your extensions.json file? I think it should look like this:
|
|
@jenp-jb everything you shared looks correct. I am really struggling to come up with an explanation for how that error would occur given the details you've shared, but I guess there must be some detail I'm missing. If you haven't already, I encourage you to file a ticket through azure support. |
@paulbatum just an FYI turns out we had missed the setting for run as package for this repo - it's weird that it was displaying this error when the running processes didn't include the old dll, but we eventually tracked down this setting not being set as expected and the message seems to have gone away. Thanks for your assistance! |
Hello @paulbatum I experience a similar issue as @heavenwing has. I upgraded an azure function to v4 and currently receive the following error in Azure Portal.
I have applied some changes, such as applying the Also I added the package Microsoft.Azure.WebJobs.Extensions.Storage to the project, however still receiving the above error. Interestingly I can see the my queue or time triggered function have been executed. |
Can someone confirm that this is the correct behaviour:
This can happen at any time? Even in critical business processing periods and there is no other way to fix it other than upgrading the SDK's and making any necessary code changes. Are there any warnings/alerts informing customers of changes before they occur? |
@GoEddie That summary doesn't seem correct. This minimum version enforcement only applies in functions host version 4.x, and upgrading from 3.x to 4.x is a customer initiated action. Here's the documentation page about host versions: When you start the 3.x->4.x upgrade process in your local dev environment (VS, VSCode, CLI, etc) you would see the same error immediately, so you know its coming before you've even deployed. If you have a deployed function app that seems to be suddenly giving this error when it was running previously, I can only think of two possibilities:
It is true that 3.x is out of support, so to be on a supported version of functions you need to go through this upgrade. Communications for 3.x going out of support were sent well in advance. This particular change is listed in the breaking changes: |
@paulbatum thank you, we must have updated to v4 at some point I guess. |
Also experiencing similar behavior on this, were you able to get a resolution? |
Hello @paulbatum , am experiencing similar issue as @heavenwing @goanwied I have the same issue with below error after Fuction app is upgraded to 4x. AZFD0005 Error building configuration in an external startup class. Microsoft.Azure.WebJobs.Script.ExternalStartupException : Error building configuration in an external startup class. ---> Microsoft.Azure.WebJobs.Script.HostInitializationException : One or more loaded extensions do not meet the minimum requirements. It's a .Net app(v6). Upgraded from 3x to 4x
Please suggest resolutions. It's a showstopper in the test environment. |
I had the same issue as @heavenwing, @goanwied and @avinashvarma1. I had the following error, even though my Nuget package version was set to 5.13.5, checked everything in this thread and it all looked correct.
It turns out the error was cached in storage, and clearing it removed the error. Found this solution in Stack Overflow:
|
This issue proposes that functions V4 should require a minimum version for each of the supported functions extensions (storage, eventhubs, servicebus, etc).
Discussion for this proposal: #1988
Sent here by an error message?
Read this comment below for instructions on how to resolve.
Motivation
We often fix bugs in our extensions, or update our extensions to use newer Azure SDKs that have relevant bug fixes. Unfortunately, we are not able to guarantee that our customer receive those fixes. As a result, often the first step when engaged in a support case is to have a customer update their extensions to the latest version. Sometimes we ask the customer to do this simply because the newer extension has better logging, and that can make a big difference for tracking the problem down.
For functions V4, we could reduce the size of this problem by adding logic that rejects extensions that are no longer supported. For example, we are still releasing fixes for Microsoft.Azure.WebJobs.Extensions.Storage 4.x, but the same is not true for 3.x - so why even let a v4 function app load a 3.x storage extension?
Spec
The functions host will enforce the proposed minimum versions in the table below. If an older version of one of the following extensions is present, the host will throw an error specifying the minimum required version and fail to start.
We can modify these to be less restrictive in terms of required patch version if we want to reduce how many customers will have to do an update as part of their upgrade to V4.
Note that none of the above versions reference any of the modern Azure SDKs that were released recently. Many of those SDKs have breaking changes and this proposal does not attempt to enforce that customers use those. Such a change would require customers to do significant code rewrites to be able to move to functions V4, which is not desirable.
A side effect of this will be to reject loading an application that is using the 1.0 extension bundle. We would probably implement a check for that so that we can provide a friendly error message (please upgrade to the 2.0 bundle).
Impact
Every non .NET user on the 1.0 bundle would be impacted when they try to upgrade to V4. Updating their host.json to reference the 2.0 bundle should be relatively straightforward as we have not seen much evidence of breaking changes between the major versions of the libraries in bundles 1.0 and 2.0.
For a .NET user, they would have to do a set of NuGet updates to get the supported extensions installed. Because Azure SDK API surface area is more directly accessable in .NET function apps, some of these customers would need to make small code changes to get their code compiling, but there are no known breaks that force a significant code rewrite.
We suspect around 60% of apps upgraded to V4 will require this change.
Compat-mode support
It would be straightforward to put this behind a flag, but doing so defeats the purpose. I suggest only adding a compat flag if we discover really significant upgrade blockers that are impacting customers from upgrading to V4 (especially once .NET 3.1 end-of-life gets close).
Alternatives
We could try to use more aggressive detection of older extensions as part of the support case submission flow. However this means that customers will spend more time struggling with bugs during development time that have been fixed long ago. It also will not deflect github issues being filed about previously fixed issues.
Detection
Yes this is trivial - we already have detectors that check the extension versions, and we can also write a detector that catches the "extension is too old and not supported" error and directs the user with specific instructions.
Support
In the long term, this change should have a positive support impact. Cases are often resolved by just having a customer upgrade their extensions. In the short term, we might see some support case volume due to customers hitting this error when upgrading to V4. We should be able to deflect a significant portion of that by implementing a detector as mentioned above. The remaining support volume would be due to customers that do not want to upgrade their extensions for unanticipated reasons. I expect this would be low volume.
Support would need to be notified of the change, but ideally deflection would be in place by the time the change is enforced.
Documentation
We'd need to update the documentation for each binding to spell out this minimum version that applies to V4.
Components impacted
I believe this change would only impact the host. We can consider an analyzer (helps catching the problem as part of CI).
Performance
No expected perf impact.
The text was updated successfully, but these errors were encountered: