[Discussion] Platform upgrade for Azure Functions v2 apps coming in October 2020

[anthonychu]

Discussion issue for: https://github.com/Azure/app-service-announcements/issues/266

[shibayan]

Is it correct to understand that the Azure Functions Runtime version will remain v2 (maybe v2.1?) and the target .NET Core version will change to 3.1 (netcoreapp3.1)?

[anthonychu]

@shibayan The runtime will be upgraded to V3. If the app does not use any APIs that have changed between .NET Core 2.2 and .NET Core 3.1, it should continue to run on V3 without modification.

[shibayan]

@anthonychu Thanks! Existing Azure Functions have FUNCTION_RUNTIME_VERSION set to ~2. Is that done by you changing it to ~3? I will migrate to v3, but I am worried about the difference when I am creating a Function using IaC (Terraform).

[tomkerkhove]

This brings the question - Should .NET use the language server model like Python et al to avoid this in the future?

[ishepherd]

@anthonychu Will FUNCTIONS_V2_COMPATIBILITY_MODE setting still be available? (And will it be automatically applied for these affected apps)?

[anthonychu]

@anthonychu Will FUNCTIONS_V2_COMPATIBILITY_MODE setting still be available? (And will it be automatically applied for these affected apps)?

Yes. How this will work is the runtime will get updated to V3. FUNCTIONS_EXTENSION_VERSION will remain at ~2. This causes the app will run on the V3 runtime in V2 compat mode (setting FUNCTIONS_EXTENSION_VERSION to ~2 has the same effect as setting FUNCTIONS_V2_COMPATIBILITY_MODE to true).

As long as your .NET apps are not using APIs that changed between .NET Core 2.2 and 3.1 the upgrade should be seamless. We do encourage you to perform this upgrade yourself and test your application ahead of the automatic upgrade. You can do this by setting FUNCTIONS_EXTENSION_VERSION to ~3 and (if necessary) FUNCTIONS_V2_COMPATIBILITY_MODE to true.

[anthonychu]

This brings the question - Should .NET use the language server model like Python et al to avoid this in the future?

Yes. This is a direction we are actively investigating for future .NET versions.

[konstantinvlasenko]

Hello everyone!

We are getting this alert in portal for Functions v2. This is related to the anouncement. Correct?

• Can you also clarify fate of Function v1 as well. Would they be affected?

[pragnagopa]

cc @fabiocav

@konstantinvlasenko - yes, the advisory is related to this announcement. V1 apps are not affected by this.

[DanielLarsenNZ]

Hi @anthonychu, can you provide more details about what exactly is being upgraded in the platform? As in what is being added, upgraded and removed.

• Will v2 Framework runtimes be removed from D:\Program Files (x86)\SiteExtensions\Functions (if the customer does not opt-out)?
• Is Functions v2 really running on .NET Core 2.2 (as the wiki states)? This was EOL in December 2019
• Will any .NET Core 2 versions be removed from the Platform?
• Will App Service Environments also be upgraded?

[johndowns]

Also @anthonychu, as best I can tell, this is the state of play - can you please confirm?

• If the FUNCTIONS_EXTENSION_VERSION is set to ~2, it will move to Functions runtime v3 but in v2 compatibility mode. It will target .NET Core 3.1. It will receive patches.
• If the FUNCTIONS_EXTENSION_VERSION is set to ~2.0, it will stay on Functions runtime v2. It will target .NET Core 2.2. It will not be patched.
• If the FUNCTIONS_EXTENSION_VERSION is set to ~1 (or presumably ~1.0), it will stay on Functions runtime v1. This upgrade does not impact Functions V1 apps.
• If the FUNCTIONS_EXTENSION_VERSION is not present, it will get the latest major version - as of today that is Functions runtime v3.

If this is accurate, it might be helpful to put this somewhere explicit (like on the original post) to be super clear, as the post is a little ambiguous about what's happening.

[fowl2]

Much clearer, thanks @johndowns.

Presumably for Functions runtime v1 the .NET Framework will be patched with the rest of the Azure App Service - and even upgraded to 4.8 when that happens.

[pragnagopa]

@johndowns - No changes to V1 apps. We will be updating our documentation with upgrade instructions.

@DanielLarsenNZ -

Will v2 Framework runtimes be removed from D:\Program Files (x86)\SiteExtensions\Functions (if the customer does not opt-out)?

V2 runtime will exist but will only updated if critical fixes are needed.

Is Functions v2 really running on .NET Core 2.2

Yes, as of now Functions V2 apps are running on .Net core 2.2

Will any .NET Core 2 versions be removed from the Platform

No. Existing versions will remain but no more updates.

Will App Service Environments also be upgraded

Yes. This announcement includes all skus and ASEs

[harisubramaniam1]

Unfortunately, Service health alerts are only for app services that do not run on an Isolated ASP? I do not think those that have functions on Isolated ASP get these service health alerts and could potentially miss out on this?

[harisubramaniam1]

When I tried to pin the version to ~2.0, I get a warning message as below. I am opting out of the upgrade for now and hence the setting of ~2.0. But the warning message seems to indicate that once the support stops for the current version, it will be auto-upgraded to a major version. This message seems to contradict the announcement made here that pinning it to ~2.0 will prevent the functionapp host upgrade.

Can this be clarified please

[pragnagopa]

@harisubramaniam1 - thanks for reporting warning on Portal. This appears to be a UI issue and will follow up on fixing it.

[harisubramaniam1]

@pragnagopa Thank you for the clarification.

[srininz77]

1. We are running on Azure Functions runtime version pinned to 2.0.13351.0 targeting .net core 2.1. From what I read: “If the FUNCTIONS_EXTENSION_VERSION is set to ~2.0, it will stay on Functions runtime v2. It will target .NET Core 2.2. It will not be patched.” Can you please confirm if this is true if the functions_extension_version is set to “2.0.13351.0”

2. I also read that “We will be sending notices to subscriptions for applications that are using .NET APIs that are at risk for breaking with this platform upgrade.” We are running azure functions in ASE and I believe the resource health status is not available for isolated app service plans. Does this mean we will not receive any notices?

[anthonychu]

@pragnagopa Do you know if ASE customers were / will be notified of potentially breaking apps?

[pragnagopa]

@srininz77 - I understand you pinned runtime version due to : https://github.com/Azure/azure-functions-host/issues/6558. Version 2.0.13351.0 will be available until the issue is fixed. Once the issue is fixed, if you still want to run on Functions V2, please pin runtime version to ~2.0 . Our recommendation is to move functions V3 as soon as you can.

@anthonychu / @srininz77 - Our internal analysis of potential breaking apps does include ASEs.

[hctan]

Just to confirm, my azure function is set to ~2 (I don't see an ~2.0 option):

If I understand correctly, to test it out (I wish to stay at function V2) before the automatic upgrade, is it I can go to 'Application Settings', add: FUNCTIONS_EXTENSION_VERSION = ~3 FUNCTIONS_V2_COMPATIBILITY_MODE = true

Doing above would be similar to staying at ~2 as in my runtime version setting after 31st Oct right?

[ishepherd]

as of now Functions V2 apps are running on .Net core 2.2

@pragnagopa @anthonychu suggest you update the announcement, as it says:

Azure Functions V2 apps target .NET Core 2.1 (by default)

Also please confirm @johndowns's comment above. It's nice and clear so I started people linking to it, want to have official confirmation :)

[anthonychu]

@ishepherd We’re planning to follow up with some updates in the next couple of week. We’ll try to use the opportunity to also clear up the confusion. @jeffhollan

While they sound contradictory, both of those statements are true. By default, V2 apps target and are compiled against netcoreapp2.1. But they run on the V2 functions host which runs on .NET Core 2.2. The upgrade involves changing the host that runs your app. ~2 apps will run on the V3 host (running on .NET Core 3.1) in V2 compatibility mode.

Apps with the setting updated to ~2.0 will continue to run on the V2 host.

[anthonychu]

FUNCTIONS_EXTENSION_VERSION = ~3 FUNCTIONS_V2_COMPATIBILITY_MODE = true

@hctan These settings will cause the app to run on the V3 runtime with compatibility mode enabled. This is equivalent to how your app will run after the upgrade if you leave it on ~2.

If you want to pin the app to V2, you have to manually update FUNCTIONS_EXTENSION_VERSION to ~2.0. I would, however, strongly advise you try to run it on the V3 runtime (with or without V2 compatibility mode) as that will continue to receive security updates.

[hctan]

@anthonychu thanks for clarifying this.

[Bimmerdude]

Hi! We have a function that was written 4-5 years ago. That function is currently targeting framework 4.6. It is not clear to me how much of this is related to the function SDK and how much is related to .NET Core 3.1. We initially intended to just upgrade all functions to .NET Core 3.1 and function SDK v3. However, since this function actually makes calls specific to the full framework, we are wondering if this will break once the upgrade is completed in Azure. For example, this function makes calls to the log4net method GetLogger which used to have an overload that allowed you to specify only a string but this overload no loaded exists in the .NET Core 3.1 compliant log4net package. We are trying to assess the need to upgrade this function. It will be deprecated soon, however we may need to continue running it in parallel with it's replacement until after the October 31th deadline.

[pragnagopa]

@Bimmerdude can you confirm if your existing function app is running on V1 or V2?
Please note that V1 apps are not affected the platform upgrade. If you are running Functions V2 and cannot update to functions V3 which runs on .Net core 3.1 , please pin to ~2.0

[Bimmerdude]

@pragnagopa We're using V1 for this function.

[pragnagopa]

@Bimmerdude - V1 functions are not affected by the platform update. No changes needed at this time.

[jeffhollan]

UPDATE (Oct 5 2020): To prevent existing applications from being impacted, we will begin the process of automatically opting out apps that are still at risk for breaking that have not either upgraded to v3 or opted out already. We will opt the apps out by changing the FUNCTIONS_EXTENSION_VERSION to ~2.0. It is worth noting by redeploying from something like an ARM template users may inadvertently opt back in if they change that setting.

[Chris-Johnston]

Hello! Earlier today I received a notification to update my team's app to v3. AFAIK we've already been running .NET Core 3.1 and Functions v3 (FUNCTIONS_EXTENSION_VERSION is set to ~3) since Sept 16. Was this notification sent out in error?

Also, I'm glad that we have this discussion thread but it wasn't immediately clear that this existed. The link in the email goes to the issue (https://github.com/Azure/app-service-announcements/issues/266) which is closed, and only if you read to the end it's clear that there's a place to leave comments.

[pragnagopa]

@Chris-Johnston - to detect apps that are using any breaking APIs from .Net Core 2.2 to .Net core 3.1 we analyzed data for the past 30days. If you have already upgraded to V3, you can ignore the notification. Thanks!

[Chris-Johnston]

@pragnagopa Great, thank you!

[JerryCBH]

Hi,

1. I would like to confirm if we need to manually set FUNCTIONS_EXTENSION_VERSION to ~2.0 if we are auto opted out? Our current setting is ~2.
2. We received the notification to upgrade - does this mean we are using breaking APIs from .NET Core 2.2? I checked the list of breaking APIs https://docs.microsoft.com/en-us/dotnet/core/compatibility/2.2-3.1 and I don't believe we are using them.
3. To upgrade our function app. Would you recommend we upgrade Microsoft.NET.Sdk.Functions to 3.0.9 or 1.0.36? and Microsoft.Azure.WebJobs.Extensions.ServiceBus to 4.1.0
4. We use durable function library. Is it required for upgrade as well?

[jeffhollan]

@JerryCBH you do not necessarily need to set FUNCTIONS_EXTENSION_VERSION to ~2.0 as you mentioned if you got email it will be set for you sometime before Oct 31. That said worth noting it will be set so you don't inadvertantly overwrite it.

As for upgrading to 3.x, you'll likely want one of the 3.x versions of the Microsoft.NET.Sdk.Functions. The rest could likely stay the same. If building from Visual Studio (which your screenshot makes me think you are) likely the big change is updating the .csproj file to specify v3 https://docs.microsoft.com/en-us/azure/azure-functions/functions-versions#version-3x

[JerryCBH]

Thank you @jeffhollan ! We are building and deploying from Azure DevOps

[munkii]

We moved our function from netstandard2.0 to target netcoreapp3.1 and moved to 3.0.2 of Functions SDK from 1.0.23. Runtime version now says ~3

Despite this we recieved the warning email yesterday. From reading earlier posts it look like this was sent out because you were looking at data from the last 30 days. We only made the change around 5 days ago so that would explain the email.

Can we interactively run the same check on our current configuration to confirm we have done what is necessary to ensure we are in compliance? It looked like a previous poster was checking it via some Health Advisories but I can not see those in the Portal

[harisubramaniam1]

Just to be clear, just because there is a need to upgrade our function apps to V3 does not necessarily mean we have to re-target our .net core 2.1 apps to ,net core 3.1 right? It is just the host that is being upgraded to .Net core 3.1 and as long as the function app that is on .net core 2.1 does not use any APIs that has been deprecated on .net core 3.1, we are good to run our .net core 2.1 apps in func V3.

[pragnagopa]

@munkii - Once Functions_Extension_Version is set ~3 and you verified your app works as expected, no action needed. Yes we did use past 30days data for analysis.

@harisubramaniam1 - Your understanding is correct!

as long as the function app that is on .net core 2.1 does not use any APIs that has been deprecated on .net core 3.1, we are good to run our .net core 2.1 apps in func V3.

[fabiocav]

@harisubramaniam1 as Pragna stated above, you're correct, but part of the reason the notifications and announcements are going out is to give you time to validate that by using your existing code in Azure Functions 3.0 and validating the functionality.

[harisubramaniam1]

Thank you @pragnagopa

Thank you @fabiocav .

[martin-gay-reach-contact]

In response to @harisubramaniam1 - The documentation (https://docs.microsoft.com/en-us/azure/azure-functions/functions-versions#changing-version-of-apps-in-azure) - suggests "Azure Functions 3.x and .NET requires the Microsoft.NET.Sdk.Functions extension be at least 3.0.0."

Microsoft.NET.Sdk.Functions v3.0.0 - is dependent on .Net Core v3.x

So does this suggest we do need .Net Core 3.x even if we only want to upgrade the functions to v3

[jeffhollan]

@martin-gay-reach-contact I know you DO NOT have to upgrade to 3.1 to use the ~3 runtime, you do raise a fair question about what Build SDK (Functions.SDK) can be used it staying on 2.1 and moving to ~3. @fabiocav @pragnagopa do you know if the recommendation is to stay on a 2.x Microsoft.NET.Functions.SDK in this case?

[harisubramaniam1]

What does Microsoft.NET.Functions.SDK do apart from helping VS to generate functions.json?

If there is not much difference between functions.json between v2 and v3 and the .net core 2.1 app is not using any new bindings/triggers defined or specific to V3 FA would it be ok to continue on that V2 build SDK?

[rahulkumar58]

What does Microsoft.NET.Functions.SDK do apart from helping VS to generate functions.json?

If there is not much difference between functions.json between v2 and v3 and the .net core 2.1 app is not using any new bindings/triggers defined or specific to V3 FA would it be ok to continue on that V2 build SDK?

We are currently just changing the function version extension on the ARM template to ~3. But our SDK still remains on 1.0.* and the .csproj still is on v2 azure function. Our app itself is built using .net core 2.1

We deployed that and tested on Azure and the notification to upgrade our V2 functions to V3 goes away. Can we please have a confirmation if its ok to stay on 2.x Microsoft.NET.Functions.SDK

[pragnagopa]

@harisubramaniam1 / @rahulkumar58 - If you are updating FUNCTIONS_EXTENSION_VERSION to ~3 , our recommendation is to upgrade your app to Net Core 3.1 and reference 3.x version of Microsoft.NET.Functions.SDK

Even though app might not be using a any breaking APIs, there will always be subtle differences that can happen at runtime.

Here is a simple example:

If your V2 function app with <TargetFramework>netcoreapp2.1</TargetFramework> has following code:

throw new ArgumentOutOfRangeException(nameof(test), "Test Message.");

When running on Functions V2 runtime, it throws following exception on invocation:

System.Private.CoreLib: Exception while executing function: Function1. TestFunctionApp: Test Message.
Parameter name: test.

but the same function running on Functions V3 runtime will throw following exception on function invocation:

System.Private.CoreLib: Exception while executing function: Function1. TestFunctionApp: Test Message. (Parameter 'test').

Please note the change in exception message format.

[harisubramaniam1]

@pragnagopa @jeffhollan Then this is more of a forced upgrade to .net core 3.1 unfortunately. The impact then is wider than the initial announcement of platform upgrade I am afraid atleast for .net core 2.1 hosted applications. Ideally, when I am on an LTS version, I shouldn't be forced to upgrade that version to another LTS version.

Is there anyway to quantify what are the subtle differences in this case.

[rahulkumar58]

@pragnagopa If I choose to stay on .net core 2.1 with build sdk 1.0.* and just update the extn version to ~3, should I expect anything to break? I see that you have mentioned subtle differences, but that's more about how .net core 3.1 and there by the webjosb host and the related extensions does things correct? Should we worry about anything other than differences in exception message formatting?

[fabiocav]

@harisubramaniam1 when running in compatibility mode (which all apps moved to 3.0 will be using), the differences primarily come down in API and potential behavior changes between .NET Core 2.2 and 3.1.

To proactively test your application and verify any potential impact, I would recommend doing the following:

1 - Create a new Function App site 2 - Create an app setting named FUNCTIONS_V2_COMPATIBILITY_MODE and set its value to true 3 - Deploy your existing application onto this new site 4 - Run your validation scenarios

If you run into any issues, sharing that application information would allow us to look at the details and provide guidance specific to your scenario.

@rahulkumar58 yes, that should work, but I would also recommend validating with an actual site prior to the migration date to ensure everything works as expected.

[harisubramaniam1]

@fabiocav Thank you for that. Just to confirm,

1 - We could use Build SDK 1.0. on V3 function app and let the app remain on .net core 2.1(provided we set FUNCTIONS_V2_COMPATIBILITY_MODE to true and extensions to ~3) 2 - Then we test out the application with the new settings 3 - If there are issues we get back to you for advice 4 - If there are no issues then we can take the .net core 2.1 app with Build SDK 1.0. to production with FUNCTIONS_V2_COMPATIBILITY_MODE set to true and extensions set to ~3 settings 5 - If we test things out and we are happy that the application is working fine, do we still need to set FUNCTIONS_V2_COMPATIBILITY_MODE to true for production apps or can we go live without that but just with ~3?

The documentation here https://docs.microsoft.com/en-us/azure/azure-functions/functions-app-settings#functions_v2_compatibility_mode states that this setting will be available and supported only until 2.x runtime is supported. But a clarification issued above in this same thread notes that the FUNCTIONS_V2_COMPATIBILITY_MODE setting will be supported throughout V3. So I take it that it will still be supported even after 2.x