1

I'm trying to publish a small .NET Core 3.1 Web App on Azure App Service (Linux), and the app won't start.

No matter if I'm publishing using Visual Studio, or Azure DevOps, i'm getting the following error on my Linux Azure App Service (which, by the way, already contains two other apps):

2021-06-23T22:19:47.102376527Z   _____
2021-06-23T22:19:47.102415627Z   /  _  \ __________ _________   ____
2021-06-23T22:19:47.102422327Z  /  /_\  \___   /  |  \_  __ \_/ __ \
2021-06-23T22:19:47.102426627Z /    |    \/    /|  |  /|  | \/\  ___/
2021-06-23T22:19:47.102430627Z \____|__  /_____ \____/ |__|    \___  >
2021-06-23T22:19:47.102434927Z         \/      \/                  \/
2021-06-23T22:19:47.102438927Z A P P   S E R V I C E   O N   L I N U X
2021-06-23T22:19:47.102442827Z
2021-06-23T22:19:47.102446327Z Documentation: http://aka.ms/webapp-linux
2021-06-23T22:19:47.102449927Z Dotnet quickstart: https://aka.ms/dotnet-qs
2021-06-23T22:19:47.102453427Z ASP .NETCore Version: 3.1.13
2021-06-23T22:19:47.102457227Z Note: Any data outside '/home' is not persisted
2021-06-23T22:19:47.307988432Z Running oryx create-script -appPath /home/site/wwwroot -output /opt/startup/startup.sh -defaultAppFilePath /defaulthome/hostingstart/hostingstart.dll     -bindPort 8080 -userStartupCommand 'dotnet WebApplication1.dll'
2021-06-23T22:19:47.378242802Z Cound not find build manifest file at '/home/site/wwwroot/oryx-manifest.toml'
2021-06-23T22:19:47.382799606Z Could not find operation ID in manifest. Generating an operation id...
2021-06-23T22:19:47.382816206Z Build Operation ID: 7f48597c-0791-46e5-bffd-b0007d8b27b7
2021-06-23T22:19:49.335414280Z Writing output script to '/opt/startup/startup.sh'
2021-06-23T22:19:49.567879341Z Running user provided startup command...
2021-06-23T22:19:49.610748271Z A compatible installed .NET Core SDK for global.json version [3.1.409] from [/home/site/wwwroot/global.json] was not found
2021-06-23T22:19:49.610783071Z Install the [3.1.409] .NET Core SDK or update [/home/site/wwwroot/global.json] with an installed .NET Core SDK:
2021-06-23T22:19:49.610825071Z   It was not possible to find any installed .NET Core SDKs
2021-06-23T22:19:49.610829471Z   Did you mean to run .NET Core SDK commands? Install a .NET Core SDK from:
2021-06-23T22:19:49.610835971Z       https://aka.ms/dotnet-download
2021-06-23T22:19:50.944Z ERROR - Container procoding-me_0_8935305e for site procoding-me has exited, failing site start
2021-06-23T22:19:50.961Z ERROR - Container procoding-me_0_8935305e didn't respond to HTTP pings on port: 8080, failing site start. See container logs for debugging.
2021-06-23T22:19:50.978Z INFO  - Stopping site procoding-me because it failed during startup.```

I've tried to create the web app on azure again, and even tried to publish the same code of the other apps, and the same problem occurs.

Anybody has a hint of the cause of this problem?

  • It looks like the sdk isn't installed for whatever reason. So you can always publish as a self-contained build that will package the sdk targets with your application code. – David L Jun 23 '21 at 22:33
  • You need to download Core 3.1 from following. The left side is for the build machine and the right side is the runtime library. Read the notes on right column for additional libraries that may be needed. These notes are different depending on version and type of runtime library : https://dotnet.microsoft.com/download/dotnet/3.1 – jdweng Jun 23 '21 at 23:26
  • @DavidL: even as a self contained build the problem persists – Robson Rocha de Araujo Jun 24 '21 at 02:05
  • @jdweng: When you select a runtime it should be installed and available into the app service. It is not neccessary to install it on the app service. – Robson Rocha de Araujo Jun 24 '21 at 02:06
  • @RobsonRochadeAraujo : This is CORE, not NET. Core is a common library for Linux Severs, Mobile Devices, Mac, and Windows. There are an installed version the left column and a runtime library the right column which is used when you deploy and do not build. The OP is trying to deploy on a Linux machine and not intending to build. – jdweng Jun 24 '21 at 07:17
  • @RobsonRochadeAraujo, Review the port configured for container listening and if it matches how the application runs in the entrypoint or startup script in their Docker file. Host ASP.NET Core on Linux with Nginx -https://learn.microsoft.com/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-5.0 Also, add a startup file> compiled DLL name as dotnet .dll https://learn.microsoft.com/azure/app-service/faq-app-service-linux#what-are-the-expected-values-for-the-startup-file-section-when-i-configure-the-runtime-stack- – AjayKumar Jun 25 '21 at 08:16
  • @RobsonRochadeAraujo Just checking on this, have you tried the suggestions shared above? Please let us know it goes. – AjayKumar Jun 29 '21 at 11:15
  • @AjayKumar-MSFT, I was publishing CODE, not a container. AFAIK, App Services would then "wrap" the code in a container for it to run when using Linux. I was not creating the container by myself. So all those configurations were at their defaults. In the two other web apps contained in the app service this was working fine, but for the third, it was not working anymore. I've tried deleting one of my working web apps and creating it again, but then it began showing the same behavior. So I gave up and created a containerized app. Now everything works fine. But the original issue persists. – Robson Rocha de Araujo Jun 29 '21 at 23:26
  • I'm having the exact same issue but with .NET 5. However, I've managed to get the app running if publishing with Visual Studio 2022 PREVIEW. Have not tried with any other version of VS, since this it does not matter to me. I need to be able to deploy this with azure-pipelines.yaml. I'm using the AzureWebApp@1. – Kasper P Jul 05 '21 at 10:41
  • @KasperP, I've tested with .NET 5 and yes, it presents the same behavior. Using a container was the only way to make it work too. The issue seems to be with the default wrapper container that App Services uses. – Robson Rocha de Araujo Jul 05 '21 at 13:32
  • Apologies for the delay! Thanks for sharing the solution that works for you, @KasperP just to confirm, if azure/webapps-deploy@v2 action works fine. -azure/webapps-https://github.com/Azure/webapps-deploy – AjayKumar Jul 06 '21 at 19:41

1 Answers1

3

So, after a long day of trying to figure this thing out I managed to publish and app to an app service running linux. I'm using an App Service Plan (Linux, B1) that lives in a "shared" resource group since I want to run multiple apps on it. I'm also deploying the infrastructure using Bicep and the pipeline is yaml.

The issue was, as it seems, that when I was deploying the app through Azure DevOps, it was nesting the app archive in another zip-file. The app zip-file needs to be the root-folder in the app, not obvious unless you download the files that are being executed in the app service itself.

Yeah, also I'm using the self-contained version of deployment here. You can read more about it here. I had no success doing it with the framework-dependent way unless I published the app from Visual Studio 2022.

So, in the end, here are the snippets that made the thing work for me:

azure-pipelines.yaml - Build stage

- task: DotNetCoreCLI@2
    inputs:
      command: 'publish'
      projects: '**/*Api.csproj'
      arguments: '--configuration $(buildConfiguration) -r linux-x64 --self-contained true --output $(Build.ArtifactStagingDirectory)'
      modifyOutputPath: false
      publishWebProjects: false
      zipAfterPublish: true
    displayName: 'Dotnet Publish'

  - task: PublishBuildArtifacts@1
    inputs:
      targetPath: '$(Build.ArtifactStagingDirectory)' 
      ArtifactName: drop

azure-pipelines.yaml - Deploy stage

- task: AzureRmWebAppDeployment@4
              inputs:
                azureSubscription: '$(azureSubscription)'
                appType: webAppLinux
                WebAppName: '$(output_appServiceName)'
                packageForLinux: '$(Pipeline.Workspace)/**/a.zip' #Since we are not specifying the folder name in the steps prior, the folder will be called just a.zip, this is fine since the deployment is going to rename it any way in the app service file system anyway(in Kudu)

The app service resource in Bicep

 resource appService 'Microsoft.Web/sites@2021-01-01' = {
  name: '${serviceName}-${environment}-app'
  location: resourceGroup().location
  kind: 'app'
  properties: {
    serverFarmId: planId
    
    siteConfig: {
      alwaysOn: true
      http20Enabled: true
      linuxFxVersion: 'DOTNETCORE|5.0'
      appSettings: [
        {
          name: 'WEBSITE_RUN_FROM_PACKAGE'
          value: '1'
        }
      ]
    }
  }
}

Hope this helps.

P.S. Having "corrupted" zip-files in the app service (Kudu) can cause the app to fail. I suggest anyone having this issue to either delete all files from wwwroot or simply delete the app service resource and deploy it from scratch to make sure it can start properly.

Kasper P
  • 710
  • 2
  • 9
  • 14
  • Thanks again for sharing the solution that helped you with the community. Just to highlight on a similar note with B1 plan, “Web Sockets are not currently supported for Linux apps on Free App Service Plans." Users have fixed Web Socket Handshake Error 503, fixed it by switching the plan -B1 -> B2 -> B1. https://learn.microsoft.com/azure/app-service/faq-app-service-linux#web-sockets Also, you may overwrite the environmental variable before .NET core app starts. E.g. In the init.sh script: export ASPNETCORE_URLS={Your value} – AjayKumar Jul 06 '21 at 19:45