Azure DevOps build fails with "The nuget command failed with exit code(1) and error(Cannot determine the packages folder to restore NuGet packages."
-_PublishedWebSites
------ArtifactName
------bin,content,scripts,views.... folders and
------Web.config, Web.Debug.config and Web.Release.config
----ArtifactName.zip
----NugetPackagedll1
----NugetPackagedll2
----NugetPackagedll3
....
----NugetPackagedll_300
So, I am not sure why I am getting these many contents in the output?
My pipeline tasks:
- task: VSBuild@1
inputs:
solution: '$(solution)'
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true
/p:PackageLocation="$(build.artifactStagingDirectory)" /p:OutputPath=$(build.artifactstagingdirectory)'
#and(I tried to change these parameters in msbuildArgs) like below as well and
other combinations
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true
/p:PackageLocation="$(build.artifactStagingDirectory)" /p:publishUrl="$(build.artifactstagingdirectory)\\"
/p:DeployDefaultTarget=WebPublish /p:OutDir=$(build.artifactstagingdirectory) /p:OutputPath=$(build.artifactstagingdirectory) '
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
- task: PublishBuildArtifacts@1
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'SGOrdersTracker'
Any possible reasons causing lot of output files except only zip file?
Thnx
approved: true type: comment parent: '0' userId: '0'
id: '25821' author: Antti K. Koskela email: [email protected] url: https://www.koskila.net/antti-koskela/ ip: 109.240.47.74 date: '2020-03-10 23:04:58' content: >- Hi Sandip, and thanks for your comments!
That IS a lot files. I'm getting a few files per project - all related to deployment, essentially.
What contents does the ArtifactName.zip archive contain? approved: true type: comment parent: '25806' userId: '1'
id: '25822' author: Sandip email: [email protected] url: '' ip: 199.192.105.164 date: '2020-03-11 01:02:39' content: >- Thanks for your reply Antti.
I finally fixed it wout reducing projects, by making VSBuild args simpler it worked and I set the artifact name to 'drop' and it creates drop folder inside the build artifact named as per CI.
I was in wrong impression and thought that artifact is must to get CI output and then only we can start CD.
task: VSBuild@1 inputs: solution: '$(solution)' msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)" /p:OutputPath=bin\Release' platform: '$(buildPlatform)' configuration: '$(buildConfiguration)'
task: PublishBuildArtifacts@1 inputs: PathtoPublish: '$(Build.ArtifactStagingDirectory)' ArtifactName: 'drop'
using "/p:OutputPath=bin\Release" for one of MVC 6 site in the solution.
So, now the CI output with one zip and four extra files like:
CIName
--drop
----CIName.zip
----CIName - deploy.cmd, readme.txt, setparams.xml & srcmanifest.xml approved: true type: comment parent: '25821' userId: '0'
id: '26198' author: Ahmed email: [email protected] url: '' ip: 151.255.161.23 date: '2020-04-07 15:32:56' content: |- Thanks very much, that was helpful. approved: true type: comment parent: '0' userId: '0'
id: '26428' author: syed email: [email protected] url: '' ip: 50.233.52.98 date: '2020-04-20 00:42:19' content: Thank you ! approved: true type: comment parent: '0' userId: '0'
id: '26460' author: Antti K. Koskela email: [email protected] url: https://www.koskila.net/antti-koskela/ ip: 84.253.207.207 date: '2020-04-21 16:01:45' content: Happy to be of help! approved: true type: comment parent: '26198' userId: '1'
id: '26461' author: Antti K. Koskela email: [email protected] url: https://www.koskila.net/antti-koskela/ ip: 84.253.207.207 date: '2020-04-21 16:01:54' content: My pleasure :) approved: true type: comment parent: '26428' userId: '1'
id: '29418' author: binance referral bonus email: [email protected] url: '' ip: 240e:350:8003:1291:4ecc:6a8d:cef7:5ca9 date: '2025-04-28 17:57:56' content: Your article helped me a lot, is there any more related content? Thanks! approved: false type: comment parent: '0' userId: '0'
This was another peculiar one - something, that didn't bring up too many results on Google. Always fun trying to figure out those!
So, when configuring an Azure DevOps pipeline (build) for a .NET project, you might run into this annoying error:
##[error]The nuget command failed with exit code(1) and error(Cannot determine the packages folder to restore NuGet packages. Please specify either -PackagesDirectory or -SolutionDirectory.
Job: "The nuget command failed with exit code(1) and error(Cannot determine the packages folder to restore NuGet packages. Please specify either -PackagesDirectory or -SolutionDirectory. System.InvalidOperationException: Cannot determine the packages folder to restore NuGet packages. Please specify either -PackagesDirectory or -SolutionDirectory. at NuGet.CommandLine.RestoreCommand.GetPackagesFolder(PackageRestoreInputs ...
While your actual error might be something completely different, the biggest pointer comes from this message (or an internal error, if you had nested ones in the log):
Cannot determine the packages folder to restore NuGet packages. Please specify either -PackagesDirectory or -SolutionDirectory.
Okay - so NuGet doesn't know where to restore the packages to. Suppose we just need to specify that!
And for the record: This is what I had specified in my pipeline configuration for the NuGet task. And this should work most of the time - just in my case, it didn't!
- task: NuGetCommand@2
inputs:
restoreSolution: '$(solution)'
Solution
I hadn't seen this ever before and embarked upon furious googling. Very few results showed up, though, which is kinda weird with Azure DevOps - so many people are already sharing their experiences and best practices, that usually you can find someone who's solved all the issues you might run into!
However, in this particular case, I just ended up taking a few stabs in the dark and guessing what kind of value Azure DevOps might want for "packagesdirectory". While I don't know if it made a difference or not, the parameter name is in lowercase for me.
After a few different tries, this is how I fixed it. Hopefully, it works out for you as well!
- task: NuGetCommand@2
inputs:
restoreSolution: '$(solution)'
packagesdirectory: '..\packages'
This way, the NuGet packages are restored to the solution level. This might not always be what you want - but you can tweak it by changing the value for restoreSolution, and packagesdirectory if need be.
However, it is fine for my use case, as I'm actually building a single project with an inside solution with quite a few different projects. The $(solution) variable reference contains the name of a .csproj-file.
Finally, in case someone is interested, this is what my whole YAML for this very simple build pipeline looks like:
Example YAML for building ASP.NET Projects
# ASP.NET
# Build and test ASP.NET projects.
# Add steps that publish symbols, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/apps/aspnet/build-aspnet-4
trigger:
- master
# this particular agent was required to make the build run for .NET Framework
pool:
vmImage: 'VS2017-Win2016'
variables:
solution: '**/[projectname].csproj'
buildPlatform: 'AnyCPU'
buildConfiguration: 'Debug'
steps:
- task: NuGetToolInstaller@1
- task: NuGetCommand@2
inputs:
restoreSolution: '$(solution)'
packagesdirectory: '..\packages'
- task: VSBuild@1
inputs:
solution: '$(solution)'
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
- task: PublishBuildArtifacts@1
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'drop'
publishLocation: 'Container'
References
These links below were helpful in my investigation - hopefully they'll prove useful to you, too!
Comments