Why is my Azure DevOps pipeline failing to deploy my .NET 8 web app to App Service?

Below are a few areas to review and adjust in your pipeline and app service setup:

---

1. Verify Your Package Location

The Azure Web App task is looking for a ZIP using the pattern:

YAMLCopied
package: '$(System.DefaultWorkingDirectory)/**/*.zip'

• Confirm that your publish task (or your build task if packaging from VSBuild) is actually creating a ZIP file in the expected folder.
• You can add a temporary command-line or PowerShell task to check the contents of $(Build.ArtifactStagingDirectory) or $(System.DefaultWorkingDirectory) to ensure a single ZIP exists.

---

2. Consistency Between Build and Publish Steps

Your YAML currently performs both a VSBuild (which packages via MSBuild using WebPublishMethod=Package) and a DotNetCoreCLI publish task with zipAfterPublish set to true. Sometimes producing two ZIPs can cause confusion or even lead to an ambiguous file path. Consider one of these options:

• Option 1: Rely solely on the VSBuild packaging (and remove the DotNetCoreCLI publish step).

• Option 2: Remove the VSBuild packaging and just use the DotNetCoreCLI publish so that only one expected ZIP is produced.

This ensures that AzureWebApp task picks up exactly one deployment package.

---

3. Deployment Slot/ASE Settings

In your new pipeline YAML, you’re using “deployToSlotOrASE: true” with "slotName: 'production'". Note that by default the production slot is used when you do not set slot parameters. Double-check that your App Service actually has a slot named “production” or remove these settings if you mean to deploy directly into production. In many cases, simply using the default without specifying a slot can avoid configuration mismatches.

---

4. Application Settings and .NET 8 Compatibility

Since you’re using .NET 8, make sure that:

• Your App Service is configured to run .NET 8 (especially if it’s still in preview, the platform settings need to match, or you may need to configure a custom container).
• The app setting "-WEBSITE_RUN_FROM_PACKAGE 1" is applied correctly. This setting tells the runtime to run from a ZIP package.

It’s unlikely that Azure SQL DB, Key Vault, or Blob Storage settings would affect the deployment itself. However, they might affect the application startup if connection strings or permissions aren’t configured. So, checking the App Service logs (via Kudu) for runtime errors after a successful deployment is recommended.

---

5. Investigate Detailed Logs

The error message coming from Kudu with a 500 could be a symptom of a corrupt or unexpected deployment package. Look into the detailed Kudu logs (navigate to the LogFiles/kudu/trace folder) to get a clearer picture of what is failing during the deployment process. Sometimes, these logs reveal if a file is missing or if there’s an issue with the deployment script.

---

Sample Revision of YAML

Below is a sample YAML revision assuming you want to rely solely on the DotNetCoreCLI publish:

YAMLCopied
trigger:
- development

pool:
  vmImage: 'windows-latest'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

steps:
- task: NuGetToolInstaller@1

- task: NuGetCommand@2
  inputs:
    restoreSolution: '$(solution)'

# Option: Omit VSBuild packaging if DotNetCoreCLI is used for publishing
- task: DotNetCoreCLI@2
  inputs:
    command: 'publish'
    publishWebProjects: true
    arguments: '--configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)'
    zipAfterPublish: true

- task: AzureWebApp@1
  inputs:
    azureSubscription: '<My service Connection>'
    appType: 'webApp'
    appName: '<App-Name>'
    deployToSlotOrASE: false   # Remove slot settings if not using a staging slot
    package: '$(Build.ArtifactStagingDirectory)/**/*.zip'
    appSettings: '-WEBSITE_RUN_FROM_PACKAGE 1'
    deploymentMethod: 'auto'

This version:

• Uses DotNetCoreCLI to publish and specify an output path.
• Clears the slot settings so that production is used by default (or adjust accordingly based on your setup).

---

Final Steps

1. Confirm that the ZIP is created and available in the artifact directory.
2. Check that your Azure Web App (or slot) is set up to run .NET 8.
3. Enable diagnostics or review Kudu logs to get more context on the 500 error.

By checking each of these areas, you should be able to isolate whether the issue is with the packaging, the deployment method/slot definition, or runtime misconfiguration.

Let me know if you have further questions!