Azure DevOps release of ASP.NET Core API to App Service fails to start

Question

This is a plain-vanilla ASP.NET Core (.NET 6.0) API project with a single controller/action. Publishing it directly from Visual Studio 2022 to a Linux based App Service on Azure works fine. The exact same code deployed from Azure DevOps fails (the app service fails on startup).

Here's the error from the Log Stream:

The application 'project-name.dll' does not exist.
You intended to execute a .NET SDK command:
No .NET SDKs were found

(that's essentially the docker error from the app service)

Here's the azure-pipelines.yml file used by the DevOps Pipeline.

trigger:
- main

pool:
  vmImage: 'windows-latest'

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

steps:
- task: NuGetToolInstaller@1

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

- task: VSBuild@1
  inputs:
    solution: '$(solution)'
    msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactStagingDirectory)\WebApp.zip" /p:DeployIisAppPath="Default Web Site"'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: VSTest@2
  inputs:
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

- task: PublishBuildArtifacts@1
  displayName: 'publish artifacts'

The Pipeline builds fine - no errors. The release then runs fine - no errors. What is different about the DevOps CICD flow compared to the VS 2022 direct publish? What step am I missing here?

Thank you for any help.

More Info:

So, I've noticed this difference now by bash-ing into the app service.

When I publish from VS 2022 - all the files from the deployment including the project-name.dll are in ~/site/wwwroot.

When Azure DevOps does the deploy, the file structure is not the same. I think that's the root of the problem. There, wwwroot has a Content directory and inside that, there is a convoluted folder structure that goes D_C/a/1/s/project-name/obj/Release/net6.0/PubTemp/Out. And inside Out are the files needed to run including project-name.dll.

No wonder it's not running. Anyone has any idea why Azure DevOps is doing this

Answer 1

Windows by default doesn't typically have certian version of .NET

I did see this
https://github.com/dotnet/core/issues/6907

Have you tried adding the step

- task: UseDotNet@2
  displayName: Use .NET 6.0
  inputs:
    packageType: 'sdk'
    version: '6.0.x'

Answer 2

Hi @joshguy2023

Have a look at the Azure Web App task. One thing that's missing from your yaml is the actual deployment artifact. I'm not sure if your snippet omitted it but your PublishBuildArtifacts@1 is missing your publish artifact. If not, then that would be the reason you're getting the project-name.dll doesn't exist. For example, it should be configured as such,

- task: PublishBuildArtifacts@1
  inputs:
    pathToPublish: $(Build.ArtifactStagingDirectory)
    artifactName: MyBuildOutputs

But all this task does is take the output of your VSBuild@1 copies it to a location that can be pickup in the deployment phase of your pipeline. You really don't necessarily need this step and can utilize AzureWebApp@1 in the following manner,

- task: AzureWebApp@1
  inputs:
    azureSubscription: '<Azure service connection>'
    appName: '<Name of web app>'
    package: $(System.DefaultWorkingDirectory)/**/*.zip

If you still wanted to utilize PublishBuildArtifacts@1 step, then you package would be set to '$(Build.ArtifactStagingDirectory)/**/*.zip in AzureWebApp@1.