azurerm_windows_function_app dotnet version not set correctly

[royjia]

Is there an existing issue for this?

• I have searched the existing issues

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

1.1.8

AzureRM Provider Version

3.2.0

Affected Resource(s)/Data Source(s)

azurerm_windows_function_app

Terraform Configuration Files

resource "azurerm_windows_function_app" "fun-app" {
  name                        = "${local.name_slug}functionapp"
  location                    = azurerm_resource_group.rg.location
  resource_group_name         = azurerm_resource_group.rg.name
  service_plan_id             = data.azurerm_service_plan.asp.id
  storage_account_name        = azurerm_storage_account.sa.name
  storage_account_access_key  = azurerm_storage_account.sa.primary_access_key
  functions_extension_version = "~4"
  site_config {
    always_on = true
    scm_use_main_ip_restriction = "false"
    worker_count = 2
  
    application_stack {
      dotnet_version = "6"
    }
}
}

Debug Output/Panic Output

Deploys without issue

Expected Behaviour

The expected behavior is to deploy a windows function app with function runtime ~4.

Actual Behaviour

The actual result of deployment is runtime version "custom" and the only supported drop down is ~3. I'm assuming the reason for "custom" is the function app was created with dotnet version 3.1 and does not support runtime ~4 only ~3, however I specified dotnet 6 in TF. When I create manually in azure portal the function app is created with the correct dotnet 6. I can even import the manually created function app to the same resource in terraform state with no issues.

Steps to Reproduce

Just try to create a function app using the new azurerm_windows_function_app with dotnet 6 and runtime ~4.

I'm assuming the configuration for dotnet 6 is under application stack and runtime version is under functions_extension_version.

functions_extension_version = "~4"
application_stack {
dotnet_version = "6"

I tried both options 3.1 and 6 (as documented) both yield the same result.

Important Factoids

no

References

no

[RyanS-C]

Likewise, I have the same issue.

PS C:\Users\ryan.stanley\Downloads\Function> terraform version
Terraform v1.1.9
on windows_amd64
+ provider registry.terraform.io/aztfmod/azurecaf v2.0.0-preview-2
+ provider registry.terraform.io/hashicorp/azurerm v3.3.0
+ provider registry.terraform.io/hashicorp/local v2.2.2

Upon further investigation, I have found in the azure resource browser:
https://resources.azure.com/

The configuration config document has the following values when created using the azurerm_windows_function_app terraform resource:

        "netFrameworkVersion": "v4.0",
        "phpVersion": "",
        "pythonVersion": "",
        "nodeVersion": "",
        "powerShellVersion": "",
        "linuxFxVersion": "",
        "windowsFxVersion": "DotNet|6",

Upon creating the resource manually via the azure ui/portal:

        "netFrameworkVersion": "v6.0",
        "phpVersion": "",
        "pythonVersion": "",
        "nodeVersion": "",
        "powerShellVersion": "",
        "linuxFxVersion": "",
        "windowsFxVersion": null,

NOTE: the netFrameworkVersion and windowsFxVersion are different. I think that the later should be the correct values for this not the ones that are being created at present.

Upon manually updating the attributes via the eddittor the ~4 function version was available in the drop down.

UPDATE:
Further to this my workaround has been to run:

az functionapp config set --net-framework-version v6.0 -n $Function -g $resourceGroup

This setep is run within my automation during the software deployment phase as I use PowerShell to deploy the functions contents, therefore, this is the most logical I'm my instance.

[RyanS-C]

Guide/info here also.

[lrsvendsen]

I am experiencing the same problem with the azurerm_linux_function_app. Any updates on the triage?

[iskarconsulting]

A workaround is to use app_settings (rather than functions_extension_version).

app_settings = {
  "FUNCTIONS_EXTENSION_VERSION"         = "~4"
  "FUNCTIONS_WORKER_RUNTIME"            = "dotnet-isolated"
}

[irogers-tr]

A workaround is to use app_settings (rather than functions_extension_version).

app_settings = {
  "FUNCTIONS_EXTENSION_VERSION"         = "~4"
  "FUNCTIONS_WORKER_RUNTIME"            = "dotnet-isolated"
}

This didn't work for me, though the error messages has gone in the portal, when you check the resource its still got the wrong netFrameworkVersion

    "netFrameworkVersion": "v4.0",
    "phpVersion": "",
    "pythonVersion": "",
    "nodeVersion": "",
    "powerShellVersion": "",
    "linuxFxVersion": "",
    "windowsFxVersion": "DotNet-Isolated|6",

[evandeworp]

I think the Terraform logic that checks/sets the value of WindowsFxVersion for Windows Function Apps isn't right (I've seen LinuxFxVersion mentioned in the documentation but not WindowsFxVersion - is WindowsFxVersion relevant at all to Windows Function Apps?).

For example, I created windows function apps with 4 different runtimes using powershell with debug enabled and the following is what Microsoft command line sends to Azure ARM - none of these calls set WindowsFxVersion:

dotnet 6:
{ "kind": "functionapp", "properties": { "siteConfig": { "netFrameworkVersion": "v6.0", "appSettings": [ { "name": "FUNCTIONS_WORKER_RUNTIME", "value": "dotnet" }, { "name": "FUNCTIONS_EXTENSION_VERSION", "value": "~4" }, ], } } }

dotnet 3.1:
{ "kind": "functionapp", "properties": { "siteConfig": { "appSettings": [ { "name": "FUNCTIONS_WORKER_RUNTIME", "value": "dotnet" }, { "name": "FUNCTIONS_EXTENSION_VERSION", "value": "~3" }, ], } } }

java 11:
{ "kind": "functionapp", "properties": { "siteConfig": { "netFrameworkVersion": "v6.0", "appSettings": [ { "name": "FUNCTIONS_WORKER_RUNTIME", "value": "java" }, { "name": "FUNCTIONS_EXTENSION_VERSION", "value": "~4" }, ], "javaVersion": "11" } } }

node 14:
{ "kind": "functionapp", "properties": { "siteConfig": { "netFrameworkVersion": "v6.0", "appSettings": [ { "name": "FUNCTIONS_WORKER_RUNTIME", "value": "node" }, { "name": "WEBSITE_NODE_DEFAULT_VERSION", "value": "~14" }, { "name": "FUNCTIONS_EXTENSION_VERSION", "value": "~4" }, ], } } }

[neilmcalister]

There are numerous issues with this resource type over the old one - it also won't generate host keys either. #17750

I've switched back to the old resource azurerm_function_app - these new ones just don't work. The fact that this issue was raised in April and its now nearly August proves my point. I've no idea why these where introduced in this state.

[JoshWeepie]

Same issue here, also see this link https://docs.microsoft.com/en-us/answers/questions/835272/azure-functions-pinned-to-unsupported-dotnet-runti.html that says it's fixable in an ARM template by setting "netframeworkversion": {"type": "string","defaultValue":"v6.0"}, but I don't want to use an ARM template or the AZ CLI workaround to fix this.

To note though, even though there is a warning in the Azure portal, your .NET6 function may still be working fine, during the ~winter we upgraded our functions to .NET6 and changed our "FUNCTION_EXTENSION_VERSION" variables to "~4", and they are all working. Today is the 1st time I've seen the warning banner on the Function runtime settings page, since it's buried in the configuration tabs. Reading through the documentation it looks like we have some extra work to do to fully upgrade to .NET 6.

[xiaxyi]

Thanks guys for raising the issue. For the newly created windows functions, we will set the .NetFrameworkVersion to v6.0 if dotnet_version sets to 6 in the TF config, it should fix the issue custom ~4. As mentioned in our docs, function runtime 4.0 requires the underlying .Net version6, if the functions are created before, please aslo set the .net version to 6 when upgrading the function worker runtime to 4 and it should resolve custom ~4 situation.

[CRhodes1510]

@xiaxyi I'm creating a new Function as per your comment on the 24th Aug 2022, but still get the same warning and my netFrameworkVersion is still "v4.0"
Goolging around the area, I don't think there is anything wrong with my code
https://github.com/CRhodes1510/Terraform/blob/main/WindowsFunctionApp.tf

Is there anything that screams incorrect? Any help would be greatly appreicated
Thanks :)

[xiaxyi]

@CRhodes1510 the fix is in the mentioned pr. Can you try setting that property via api and see if its working?

[CRhodes1510]

@xiaxyi setting via Azure CLI, works a treat :)

[SPALLADI]

It's not working for me with AZ CLI commands. Just stuck with this issue.

[SPALLADI]

It's not working for me with AZ CLI commands. Just stuck with this issue.

@xiaxyi setting via Azure CLI, works a treat :)

It's not working for me with AZ CLI commands. Just stuck with this issue.

[SPALLADI]

Please someone help me with AZ CLI command. I can see ~4 is updated, but defaulted to custom field. Has anyone succeeded with the FUNCTIONS_EXTENSION_VERSION to ~4

[CRhodes1510]

Using the below Powershell code and executing as SPN in DevOps Azure CLI task, got rid of the warning for me

az functionapp config set --name $(FunctionAppName) --resource-group $(ResourceGroupName) --net-framework-version v6.0

[SSKLCP]

Is there any update on this? Ideally I just want to run the Terraform without needing the additional CLI step

[websolut]

We experience the same issue. It seems to be a pretty easy fix for TF azurerm to add another parameter similar to the app service resource. Thanks.

[kahawai-sre]

I'm using AzAPI provider to resolve any of these types of issues.

New deploy reference:

• https://learn.microsoft.com/en-us/azure/templates/Microsoft.Web/sites?pivots=deployment-language-terraform

Update existing example:

resource "azurerm_windows_function_app" "demoapp" {
  provider = azurerm.corpventure0002
  name                = "demoapp"
  resource_group_name = azurerm_resource_group.rg-function-app.name
  location            = var.region
  service_plan_id = azurerm_service_plan.appsp-ep.id
  storage_account_name = azurerm_storage_account.sa.name
  storage_account_access_key = azurerm_storage_account.sa.primary_access_key
  https_only = true
  virtual_network_subnet_id   = azurerm_subnet.appservice-vnet-integration-01.id
  site_config {
      pre_warmed_instance_count = 2
      vnet_route_all_enabled    = true
  }
  app_settings = {
    WEBSITE_CONTENTOVERVNET   = 1
    WEBSITE_CONTENTSHARE = azurerm_storage_share.sashare.name
    WEBSITE_CONTENTAZUREFILECONNECTIONSTRING = azurerm_storage_account.sa.primary_connection_string
    FUNCTIONS_WORKER_RUNTIME = "dotnet"
    FUNCTIONS_EXTENSION_VERSION = "~4"
  }
}

resource "azapi_update_resource" "this" {
  type = "Microsoft.Web/sites/config@2022-03-01"
  name = "web"
  #resource_id = azurerm_windows_function_app.fa-test-vnet-content2.id
  parent_id = azurerm_windows_function_app.demoapp.id
  body = jsonencode({
    properties = {
      netFrameworkVersion = "v6.0"
    }
  })
}

[xiaxyi]

@kahawai-sre @royjia , the issue should be fixed now, can you confirm if the app stack for windows dotnet function is set correctly? Thanks!

[rcskosir]

Thanks for taking the time to submit this issue. It looks like this has been resolved as of #19685. As such, I am going to mark this issue as closed.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.