Function App application stack setting dotnet_version does not control dotnet version of the Function App

[SteveKurutz]

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

AzureRM Provider Version

3.7.0

Affected Resource(s)/Data Source(s)

azurerm_windows_function_app

Terraform Configuration Files

resource "azurerm_windows_function_app" "primary" {
  name                          = (doesn't matter)
  location                      = (doesn't matter)
  resource_group_name           = (doesn't matter)
  service_plan_id               = (doesn't matter)
  storage_account_name          = (doesn't matter)
  storage_uses_managed_identity = true
  functions_extension_version   = "~4"
  https_only                    = "false"
  app_settings                  = (doesn't matter)

  identity {
    type = "SystemAssigned"
  }

  site_config {
    ftps_state          = "Disabled"
    http2_enabled       = "false"
    use_32_bit_worker   = "true"
    websockets_enabled  = "false"
    minimum_tls_version = "1.2"

    application_stack {
      dotnet_version = "6"
    }
  }
}

Debug Output/Panic Output

Azure console reports a mismatch between function app and dotnet runtimes on Configuration blade, Function runtime settings tab:
Your app is pinned to an unsupported runtime version for 'dotnet'. For better performance, we recommend using one of our supported versions instead: ~3.

See also pasted content in "actual behavior"

Expected Behaviour

using azurerm 2.7 function app code with site_config dotnet_framework_version = "v6.0", I get:

"netFrameworkVersion": "v6.0",
... and there's no mention of windowsFxVersion.

Actual Behaviour

Resulting Function app gets this configuration (ARM exported because UI hides this):
"netFrameworkVersion": "v4.0",

If I go against what documentation says and include the FUNCTIONS_WORKER_RUNTIME app setting, then I also get the following, which doesn't appear to help.
"windowsFxVersion": "DotNet|6",

Steps to Reproduce

1. Make a function app using azurerm 3.7, with runtime ~4 and dotnet 6
2. Observe outcomes in Azure.

Important Factoids

Trying to deploy new resources using 3.x to avoid resource types that will be deprecated in 4.x.

References

Documentation at https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/windows_function_app states about the application_stack block: "If this is set, there must not be an application setting FUNCTIONS_WORKER_RUNTIME.". This problem occurs both with and without the FUNCTIONS_WORKER_RUNTIME app setting present. Even when I deploy without FUNCTIONS_WORKER_RUNTIME in my code, Azure adds it to the settings automatically.

[SteveKurutz]

Additional info: running "az functionapp config set --net-framework-version "v6.0" --name --resource-group " post-deployment fixed my problem, and ib subsequent plan/apply this goes untouched.

[ASPCKenneth]

I confirm this, also tested it with azurerm 3.6 and eventually 3.1 with same result as described above
Guess it is more related to the new resource type (azurerm_windows_function_app) and not so much the provider version?

[SteveKurutz]

@ASPCKenneth - yes and no . . . Yes because that is true, and no because the azurerm_function_app is deprecated and won't be supported in 4.0, so I'm assuming that azurerm_windows_function_app and azurerm_linux_function_app are its replacements that should have feature parity.

[xiaxyi]

@SteveKurutz The function v4.0 requires .NET6.0 runtime. I will check the relevant properties to see if there is a better way to implement the feature.

[SteveKurutz]

Thanks @xiaxyi . This looks on the surface like wires got crossed in the new resource type. The desired outcome is to be able to set .NET to 6. However that gets done in AzureRM is fine by me.

[ASPCKenneth]

FYI
as a temp workaround I fixed it like this:

`resource "null_resource" "netfx" {
count = var.FUNCTION_COUNT

provisioner "local-exec" {
command = <<EOT
$subscriptionId = $env:ARM_SUBSCRIPTION_ID;
$tenantId = $env:ARM_TENANT_ID;
$clientId = $env:ARM_CLIENT_ID;
$secret = $env:ARM_CLIENT_SECRET;
az login --service-principal --username $clientId --password $secret --tenant $tenantId --output none;
az account set --subscription $subscriptionId;
az functionapp config set --net-framework-version v6.0 -g '${var.FUNCTION_RESOURCEGROUP_NAME}' -n '${azurerm_windows_function_app.func[count.index].name}';
EOT
interpreter = ["pwsh", "-Command"]
}
}`

[evandeworp]

This looks like a duplicate of 16417.

[boukeversteegh]

#16417

[xiaxyi]

@SteveKurutz The issue should be fixed now, can you confirm if the app stack is set correcly for your windows dotnet function app now?

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