Azure 管道 Nuget 恢复失败 MSB4226

Question

I am trying to set up an Azure pipeline for a project but I am getting a failure on the nuget restore command in my yml. Below is the full error:

[error]The nuget command failed with exit code(1) and error(D:\a\1\s\UDesign\Backup\UDesign\UDesign.csproj(190,11): error MSB4226: The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Also, tried to find "Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" in the fallback search path(s) for $(MSBuildExtensionsPath32) - "C:\Program Files (x86)\MSBuild". These search paths are defined in "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\msbuild.exe.Config". Confirm that the path in the declaration is correct, and that the file exists on disk in one of the search paths.) ##[error]Packages failed to restore

Pretty much every post on this error is on the Build command in the YML but this is failing on the Nuget Restore:

Pipelines failure image

YML below:

# .NET Desktop
# Build and run tests for .NET Desktop or Windows classic desktop solutions.
# Add steps that publish symbols, save build artifacts, and more:
# https://docs.microsoft.com/azure/devops/pipelines/apps/windows/dot-net

trigger:
- master

pool:
  vmImage: 'windows-latest'

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

steps:
- task: NuGetToolInstaller@1

- task: NuGetCommand@2
  inputs:
    command: 'restore'
    restoreSolution: '$(solution)'
    feedsToUse: 'select'
    vstsFeed: 'MyFeed'

- task: VSBuild@1
  inputs:
    solution: '$(solution)'
    msbuildArgs: '/p:OutputPath="$(Build.BinariesDirectory)\$(Build.BuildID)"'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'
    restoreNugetPackages: true
    msbuildArchitecture: 'x64'

- task: ArchiveFiles@2
  inputs:
    rootFolderOrFile: '$(Build.BinariesDirectory)\$(Build.BuildId)'
    includeRootFolder: false
    archiveType: 'zip'
    archiveFile: '$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip'
    replaceExistingArchive: true

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

I am not sure if the issue is with the config somehow or my NuGet packages, I can't find much on this issue.

Answer 1

Could you please try this

Note: You need to replace the source and target paths according to your project.

variables:
- name: BuildParameters.RestoreBuildProjects
  value: '**/*.csproj'
- name: BuildParameters.TestProjects
  value: '**/*[Tt]ests/*.csproj'
trigger:
  branches:
    include:
    - refs/heads/master
name: $(date:yyyyMMdd)$(rev:.r)
jobs:
- job: Job_1
  displayName: Agent job 1
  pool:
    vmImage: windows-2019
  steps:
  - checkout: self
  - task: DotNetCoreCLI@2
    displayName: Restore
    inputs:
      command: restore
      projects: $(BuildParameters.RestoreBuildProjects)
  - task: DotNetCoreCLI@2
    displayName: Build
    inputs:
      projects: $(BuildParameters.RestoreBuildProjects)
      arguments: --configuration $(BuildConfiguration)
  - task: DotNetCoreCLI@2
    displayName: Test
    enabled: False
    inputs:
      command: test
      projects: $(BuildParameters.TestProjects)
      arguments: --configuration $(BuildConfiguration)
  - task: DotNetCoreCLI@2
    displayName: Publish
    inputs:
      command: publish
      publishWebProjects: True
      projects: $(BuildParameters.RestoreBuildProjects)
      arguments: --configuration $(BuildConfiguration) --output $(build.artifactstagingdirectory)
      zipAfterPublish: True
  - task: PublishBuildArtifacts@1
    displayName: Publish Artifact
    condition: succeededOrFailed()
    inputs:
      PathtoPublish: $(build.artifactstagingdirectory)
      TargetPath: '\\my\share\$(Build.DefinitionName)\$(Build.BuildNumber)'
...

Answer 2

Actual issue

The problem is actually unrelated to NuGet, it's just that NuGet is the first thing in your pipeline that tries to evaluate MSBuild files. If you look carefully at the error:

error MSB4226: The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found.

You can see that the error is that MSBuild can't find Microsoft.WebApplication.targets . What does this mean? I'm not 100% confident, but I do have high confidence that this means you're using a "self hosted" CI agent, not a Microsoft hosted agent , and whoever set up the machine installed Visual Studio 2019 without installing the ASP.NET workload. Therefore, whoever sets up your CI agents should install the "ASP.NET and web development" workload.

Suggestion 1: CI agent should use BuildTools SKU

If you look at VS's release and build history , you see for every version, under "Links to Installer", there's a "BuildTools" link. This is a subset of Visual Studio without all the GUI stuff, meant for CI agents specifically. I don't think the BuildTools SKU has workload options, it just installs all the build tools necessary for all workloads.

Only in rare circumstances is the "full" Visual Studio required on a CI agent, so unless you know you're in that circumstance, I suggest installing the BuildTools on your CI agent instead of Enterprise or Professional.

Suggestion 2: Don't use NuGetCommand

There's two reasons. Firstly, NuGetCommand is a task that uses NuGet.exe. The problem with NuGet.exe is that when you're using PackageReference , rather than packages.config , is that there are times when NuGet and the build tools (msbuild's props/targets) change file format for the temporary files. If you don't keep the version of NuGet.exe aligned with the version of MSBuild/Visual Studio, you might get build errors. So, it's much better to use dotnet restore , or if you can't use the dotnet cli, then use msbuild -t:restore . This way you're always using the exact version of NuGet that is designed for the version of dotnet/msbuild installed, and you'll never have to think about NuGet-MSBuild version problems again.

Secondly, someone from the Azure DevOps team told my team that they want to deprecate these "heavy" tasks, and suggest customers call commands directly in a script task . In particular, the way they implemented these features will break NuGet's new Package Source Mapping feature.

If your solution contains only SDK style projects, then I suggest you use:

- task: NuGetAuthenticate
  displayName: Set up NuGet authentication
- script: dotnet restore $(solution)
  displayName: Restore

If your solution contains any "legacy" (non-SDK style) projects, then instead of using the dotnet CLI, use - script: msbuild -t:restore $(solution) .

Suggestion 3: Don't use VSBuild

You're using the task VSBuild to run your build. This is a task that uses devenv.com to build the project. While devenv does have command line parameters to build from the command line, msbuild.exe is the "official" tool to do command line builds. Again, unless you know you're in a special circumstance that really needs to be built via devenv /build , I suggest you use the dotnet CLI or MSBuild instead. As previously mentioned, the Azure DevOps team apparently want to deprecate the "heavy" tasks, so I suggest you use a script and call dotnet or msbuild directly.

- script: msbuild -t:build $(solution)
  displayName: Build solution