Microsoft.Web/Sites about bicep-types-az

[seligj95]

Opened up a GH issue (see mentioned issue above) with the team that should be able to help with this.

[erionpc]

I was given a solution for this on stackoverflow
https://stackoverflow.com/questions/69897663/setting-azure-app-service-server-stack-on-a-bicep-template?noredirect=1#comment123566981_69897663

The trick is using linuxFxVersion: 'DOTNETCORE|3.1'

resource appServicePlan 'Microsoft.Web/serverfarms@2021-02-01' = {
  name: 'MyAppService'
  location: resourceGroup().location
  properties: {
    reserved: true
  }
  sku: {
    name: 'P1v2'
  }
  kind: 'linux'
}
resource appService 'Microsoft.Web/sites@2021-02-01' = {
  name: 'MyApp'
  location: resourceGroup().location
  identity: {
    type: 'SystemAssigned'
  }
  kind: 'app'
  properties: {
    enabled: true
    serverFarmId: appServicePlan.id
    siteConfig: {
      linuxFxVersion: 'DOTNETCORE|3.1'
      appCommandLine: 'dotnet MyApp.dll'
    }
  }
}

[seligj95]

I was given a solution for this on stackoverflow https://stackoverflow.com/questions/69897663/setting-azure-app-service-server-stack-on-a-bicep-template?noredirect=1#comment123566981_69897663

The trick is using linuxFxVersion: 'DOTNETCORE|3.1'

resource appServicePlan 'Microsoft.Web/serverfarms@2021-02-01' = {
  name: 'MyAppService'
  location: resourceGroup().location
  properties: {
    reserved: true
  }
  sku: {
    name: 'P1v2'
  }
  kind: 'linux'
}
resource appService 'Microsoft.Web/sites@2021-02-01' = {
  name: 'MyApp'
  location: resourceGroup().location
  identity: {
    type: 'SystemAssigned'
  }
  kind: 'app'
  properties: {
    enabled: true
    serverFarmId: appServicePlan.id
    siteConfig: {
      linuxFxVersion: 'DOTNETCORE|3.1'
      appCommandLine: 'dotnet MyApp.dll'
    }
  }
}

Apologies, didn't see this yesterday. For reference, you can use az webapp list-runtimes --linux to see the supported runtimes/linuxFxVersions. As you found out, dotnet|3.1 is not supported while dotnetcore|3.1 is.

[alex-frankel]

Do you happen to know how/where that metadata array is consumed? It looks like the web/sites resource type understands what to do with that.

You are getting this warning because this property is not declared in this resource type's swagger, so I'm wondering if it should be or if this is arbitrary metadata.

[Plork]

that last part I figured out thnx.

but it looks like web/sites or web/sites/config. but its not very clear to me either. We were looking for a way to specify dotnetcore on a windows app service. Not much is documented about this.

MicrosoftDocs/azure-docs#43963

[alex-frankel]

Were you able to verify that the website is in fact running dotnet core? I'm worried it may be silently failing.

If it is working, then it looks like the right fix is to add it to the swagger spec.

[ErwinWiegmanTest]

Hi Alex, i can confirm that setting the metadata stack, changes the stack to dotnetcore and back to framework (tested on existing deployment). Also the stack option is generated in the azure portal, when deploying a new webapp and choosing the Download a template for automation option.

@Plork: Thanks for this snippet, i waisted a day figuring this out ;)

[bminisi]

Hi @alex-frankel , Any update on this. In Azure Pipelines, it is being surfaced as a warning and the build shows as partially succeeded. It compiles correctly and the corresponding ARM template deploys correctly. Need to remove the warning.

[alex-frankel]

No update on resolution of the issue unfortunately. It is part of a larger list of swagger fixes that I hope the team will be able to resolve soon. cc @seligj95

[erionpc]

This doesn't work. Here's my template for a .NET Core 3.1 web app.

resource appServicePlan 'Microsoft.Web/serverfarms@2021-02-01' = {
  name: 'MyAppServicePlan'
  location: resourceGroup().location
  properties: {
    reserved: true
  }
  sku: {
    name: 'P1v2'
  }
  kind: 'linux'
}

resource appService 'Microsoft.Web/sites@2021-02-01' = {
  name: 'MyApp'
  location: resourceGroup().location
  kind: 'app,linux'
  identity: {
    type: 'SystemAssigned'
  }
  properties: {
    enabled: true
    serverFarmId: appServicePlan.id
    siteConfig: {
      linuxFxVersion: 'dotnet|3.1'
      appCommandLine: 'dotnet MyUI.dll'
      netFrameworkVersion: 'v4.0'
      metadata: [
        {
          name: 'CURRENT_STACK'
          value: 'dotnetcore'
        }
      ]
    }
  }
}

When it gets deployed it gives the warning mentioned above and the app service is set up with an empty server stack.

[alex-frankel]

@seligj95 -- is there a possibility to validate when the linuxFxVersion is not valid? I know this is not a strict list of enum values, so it may not be feasible, but presumably the property value could be compared w/ what is returned by the list-runtimes command?

[cpdohert]

The core issue is that the metadata property is one - but not the only - way to set the Stack Settings (from the Azure Portal) programmatically:

For different stacks an app setting/environment variable is used.

I don't know if it's the ARM team or the App Service team that adamantly refuses to document this, but it's been going on for years and there are dozens of StackOverflow questions about it. The closest thing to a Microsoft official answer is "manually create what you want in the portal, then dump the ARM template before actually initiating the deploy", which is pretty much the definition of half-assing it.

This is complicated by the fact that apparently it isn't necessary to configure Stack Settings at all for any version of .NET Core/Framework running on a Windows App Service Plan because all the runtimes are just there and magically work, but that's not documented clearly anywhere either.

[alex-frankel]

@cpdohert -- have you seen this reference before? Wondering if it is helpful at all, or if we need to edit/expand it:
https://docs.microsoft.com/azure/app-service/reference-app-settings?tabs=kudu%2Cdotnet

[naveedaz]

Please use the metadata APIs instead.

https://learn.microsoft.com/en-us/rest/api/appservice/web-apps/list-metadata
https://learn.microsoft.com/en-us/rest/api/appservice/web-apps/update-metadata