How to resolve target-issues in Azure Devops Pipeline when creating Self-contained deployments

Question

Because Azure AppServices doesn't (anymore) support .NET Core 2.1 on x64 with framework-dependent deployments, we are currently publishing self-contained win-x64 versions of our .NET Core 2.1 Web API.

I'm trying to setup an Azure Pipeline in Yaml for CI/CD purposes and deploy it to Azure App Service deployment slot.

The issue I'm trying to resolve is this error-message: project.assets.json' doesn't have a target for 'netcoreapp2.1/win10-x64'

/usr/bin/dotnet publish /home/vsts/work/1/s/MyApp.WebApi/MyApp.WebApi.csproj --configuration Release -f netcoreapp2.1 -r win10-x64 --self-contained true --no-restore --output /home/vsts/work/1/a/MyApp.WebApi

Microsoft (R) Build Engine version 16.8.3+39993bd9d for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

/usr/share/dotnet/sdk/5.0.102/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(241,5): error NETSDK1047: Assets file '/home/vsts/work/1/s/MyApp.WebApi/obj/project.assets.json' doesn't have a target for 'netcoreapp2.1/win10-x64'. Ensure that restore has run and that you have included 'netcoreapp2.1' in the TargetFrameworks for your project. You may also need to include 'win10-x64' in your project's RuntimeIdentifiers. [/home/vsts/work/1/s/MyApp.WebApi/MyApp.WebApi.csproj]
##[error]Error: The process '/usr/bin/dotnet' failed with exit code 1

This is my yaml file:

# ASP.NET Core
# Build and test ASP.NET Core projects targeting .NET Core.
# Add steps that run tests, create a NuGet package, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core

trigger:
- develop

pool:
  vmImage: 'ubuntu-20.04'

variables:
  buildConfiguration: 'Release'
  buildPlatform: x64

steps:
- task: DotNetCoreCLI@2
  displayName: dotnet restore
  inputs:
    command: 'restore'
    projects: '**/*.csproj'
    feedsToUse: 'config'
    nugetConfigPath: './NuGet.config'
    externalFeedCredentials: 'Hangfire Pro'

- task: DotNetCoreCLI@2
  displayName: dotnet publish
  inputs:
    command: 'publish'
    publishWebProjects: true
    feedsToUse: 'config'
    nugetConfigPath: './NuGet.config'
    externalFeedCredentials: 'Hangfire Pro'
    arguments: '--configuration $(BuildConfiguration) -f netcoreapp2.1 -r win10-x64 --self-contained true --no-restore --output $(build.artifactstagingdirectory)'

# this code takes all the files in $(Build.ArtifactStagingDirectory) and uploads them as an artifact of your build.
- task: PublishBuildArtifacts@1
  inputs:
    pathtoPublish: '$(Build.ArtifactStagingDirectory)' 
    artifactName: 'MyAppWebApi'

I tried modifying the CSPROJ file by adding these:

<PropertyGroup>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    **<RuntimeIdentifiers>win10-x64;win-x64</RuntimeIdentifiers>**

and

<PlatformTarget>x64</PlatformTarget>

Answer 1

Please delete the obj and bin folders from your project. Also the <TargetFramework> in your .csproj file was singular. Please try to add an "s" and it become "TargetFrameworks" to see if it works.

  <PropertyGroup>
    <TargetFrameworks>netcoreapp2.1</TargetFrameworks>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
  </PropertyGroup>

You could refer to this thread for more possible solutions.

BTW, there are different build environment between Microsoft-hosted Windows-2019 agents(which install Visual Studio Enterprise 2019) and your local machine, you could try to use self-hosted Windows agents to build your project without additional environment preparation steps.

Answer 2

A few things went wrong during my work. The most important one is that all the changes I've tried to make were pushed to the Develop-branch while the Pipeline was running on a different branch. My inexperience with Pipelines (and also Git) mainly caused this. I was under the impression that the trigger line in YAML pointed to the repository to restore and publish.

I finally got it working with the following steps. Like Edward Han mentioned, I tried to restore and publish by command line on my local machine. These also gave me some errors I needed to fix. Like adding this line to all (30+) referenced csproj files:

<TargetLatestRuntimePatch>true</TargetLatestRuntimePatch>

Then add this configuration to the webproject csproj:

<RuntimeIdentifiers>win-x64</RuntimeIdentifiers>

Then my final YAML file is this:

trigger:
- develop

pool:
  vmImage: 'windows-2019'

variables:
  buildConfiguration: 'Release'
  buildPlatform: x64

steps:
- task: UseDotNet@2
  displayName: 'Use .Net Core sdk 2.1.x'
  inputs:
    version: 2.1.x

- task: DotNetCoreCLI@2
  displayName: dotnet restore
  inputs:
    command: 'restore'
    projects: '**/*.csproj'
    arguments: '-r win-x64'
    feedsToUse: 'config'
    nugetConfigPath: './NuGet.config'
    externalFeedCredentials: 'Hangfire Pro'

- task: DotNetCoreCLI@2
  displayName: dotnet test
  inputs:
   command: 'test'
   projects: '**/*[Tt]ests/*.csproj'
   arguments: '--configuration $(BuildConfiguration)'
   testRunTitle: 'dotnet test 2'

- task: DotNetCoreCLI@2
  displayName: dotnet publish
  inputs:
    command: 'publish'
    publishWebProjects: true
    arguments: '--configuration $(BuildConfiguration) -r win-x64 --self-contained true --no-restore --output $(build.artifactstagingdirectory)'

# this code takes all the files in $(Build.ArtifactStagingDirectory) and uploads them as an artifact of your build.
- task: PublishBuildArtifacts@1
  inputs:
    pathtoPublish: '$(Build.ArtifactStagingDirectory)' 
    artifactName: 'MyAppWebApi'

Few important things I changed/added:

• Explicitly tell to use .NET Core 2.1.*
• Add -runtime parameter to the RESTORE command

Conslusion

Although I studied some Pluralsight courses, YouTube video's and blogs, I still ended up reading the Microsoft Docs/MSDN. Being used to use publishing by the Visual Studio User Interface, switching to command-line really was a big difference. A lot more depencenies are needed to be looked at. Tip: really read the urls these error messages provide, they do contain enough information to resolve your issue. At least, that's what I learned.