This post was most recently updated on November 20th, 2019.Reading Time: 3 minutes.
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!
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’s the kind of a 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!
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 inside a 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: [email protected] - task: [email protected] inputs: restoreSolution: '$(solution)' packagesdirectory: '..\packages' - task: [email protected] 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: [email protected] inputs: PathtoPublish: '$(Build.ArtifactStagingDirectory)' ArtifactName: 'drop' publishLocation: 'Container'
These links below were helpful in my investigation – hopefully they’ll prove useful to you, too!
- Why you shouldn’t attach files from other channels in Microsoft Teams? - March 19, 2020
- Top Tips To Survive Working From Home! - March 10, 2020
- Adding new MVC/Razor items fails throwing an error about hostpolicy.dll - March 5, 2020