Not every time but quite frequently I get ##[error]The nuget command failed with exit code(1) and error(NU1102: Unable to find package MyPackage with version (>= 1.0.5)
in my Azure Pipelines builds (different packages and different versions):
The package definitely exists as it had just been built a couple of minutes ago and I can see it in the Artifact Feed:
Here is my pipeline:
The project consists of multiple packages so this is starting to get really inconvenient. If I try on different build agents I eventually get one to work but the pipelines are supposed to be more of a hands off process. As far as I can tell (or guess), Nuget is caching the index.json for the feed. The only other issues I can find related to this specifically happen in people's local environments. Is there some way to get Nuget to properly check if packages exist?
1.Not sure about the real cause of your issue, but if cleaning cache can help to resolve your issue, you only need to enable this option in Restore task.
2.Also, sometimes the package not found error could be related to feed permissions in Devops. Go Artifacts=>custom Feed=>Feed Settings in right corner:
Make sure your build service have access to that feed.
NuGet does cache what versions of a package are available on each feed for 30 minutes, so the package was published more recently than that, and that machine had already restored a different version of the package within the last 30 minutes, it will be a problem.
You could run dotnet nuget locals http-cache --clear or nuget.exe locals http-cache -clear before the restore, that will delete NuGet's HTTP cache.
Related
I'm trying to use the nuget install plugin for TeamCity but after running, it takes too long in restoring and installing all the packages in my solution.
Can someone help in nuget restore packages in TeamCity?
I was researching and solving the same problem. My solution took up to 20 minute(in bad times) to resolve all NuGet packages. Here is what I had found:
TeamCity doesn't use the nuget cache because they reassign the env variable for the directory where they keep resolved packages. The details about this you can find on here https://teamcity-support.jetbrains.com/hc/en-us/community/posts/115000160524/comments/360000087900
And here is the reason why they do it https://github.com/NuGet/Home/issues/4277
I'm not sure why but the version NuGet that provided by TeamCity v3.5, v4.6 proceed with restore operation slower than other versions.
What I did:
In my case I've added the override of the env.NUGET_PACKAGES to the home Agent directory (%teamcity.agent.home.dir%/nuget-cache) in my
TeamCity project. That made restore stable not more than 10 minutes. Be careful because the work and temp directory might be cleared by TeamCity Agent and your cache will not be stable.
I've added the latest stable version of the NuGet.exe file (v5.8.1 in my case) https://www.nuget.org/downloads. Then I'd chosen the Custom option for NuGet Install step in TeamCity (NuGet.exe select box) and set the path to my NuGet.exe file in the solution.
After both of these steps, NuGet restore takes up to 1.5 minutes for my solution and this is ok for me.
I have a private NuGet feed where I publish package A.
A has a version like 4.0.0.X (where X is the build number).
When I change code, the build number is incremented and the package is published.
In the csproj, I have referenced the package like this:
<PackageReference Include="A" Version="4.0.*" />
I want to get the newest version of A, which has no major changes (which would result in a bump the minor section...).
Unfortunately, if Nuget has downloaded a Version of A, it never attempts to check if there is a newer version.
I can check manually, but then Nuget automatically pins the version in the csproj, which I have to re-edit.
How can I fix this?
Fix means: I want a smooth dev experience for my CI workflow. Ideally, I have the newest package version on my dev computer without lots of manual work.
NuGet has caching strategies to avoid re-downloading packages/hitting the network all the time.
It dumps a little cache file in your obj that tells it whether you've changed your dependencies at all.
You will need to force NuGet to reevaluates the available packages from remote sources, by using the -force option. /p:RestoreForce=true, or --force in dotnet CLI.
In Visual Studio, currently a rebuild will do a force restore.
NuGet also has a http caching strategy that avoids hitting the remote feeds for 30 mins. To override that, use -NoCache from the commandline. Currently there's no option to override that in Visual Studio.
tl;dr;
NuGet caches a lot of things to improve performance and remote unnecessary remote calls.
Avoid that by calling restore with the --force/rebuilding.
I need to execute a command line utility from a package that is downloaded as part of nuget package restore in the TFS build process.
On my local computer that is stored in c:\users\me.nuget*
I've tried every permutation of that on TFS without success. I've also tried \mydir\packages with no success as well.
The biggest problem is that I have to run the package restore step before being able to see any sort of feedback from the log. That's some slow debugging.
Any ideas? Thanks ahead.
With the latest nuget/msbuild the packages folder is held under the active user's profile directory, so an appropriate Powershell command is
Get-ChildItem $(UserProfile)\.nuget\packages
This currently evaluates on the VSTS 2017 Hosted build agent to C:\Users\VssAdministrator\.nuget\packages but by using the variable you are insulated from any changes made.
Just an addition to #Paul Hatcher's answer:
I also faced the same problem in Azure DevOps build pipeline where a specific package and nuget packages directory could not be found.
It is a Xamarin.Forms app based on a .net standard library where no packages folder exists. I later noticed in build logs that the packages are restored to nuget folder under user's profile. However this particular case is not documented on https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=vsts#agent-variables.
That means #Paul Hatcher's answer is also valid if you try to reference nuget package folder directly from your build pipeline. This ($(UserProfile).nuget\packages) should actually be a (standard) predefined build variable.
The Nuget package cache folder is in C:\Users\buildguest.nuget\packages, but it will be cleaned after build if you are using Hosted build server.
The simple way to verify:
Add NuGet restore or .Net Core Restore build step to restore packages
Add PowerShell build step to list files in C:\Users\buildguest.nuget\packages
Code:
Get-ChildItem -Path C:\Users\buildguest\.nuget\packages
Queue build and check the PowerShell step log (the packages’ will be listed in the log)
Remove/disable NuGet restore or .Net Core Restore build step > Save build definition
Queue build
The build will be failed, because the path does not exist.
So, the packages need to be restored before build solution/project if aren’t existing. You can add packages to source control and map to build agent to deal with the issue of too long time takes to restore packages.
I've got a build running in VSTS which is restoring NuGet packages from both nuget.org and a custom feed in VSTS. The custom feed is in the solutions NuGet.config as a <packageSource>, along with the user name and password in <packageSourceCredentials>
The build, including the restore, is working Ok, but there is a warning ...
2016-10-12T16:18:57.6589001Z ##[warning]To connect to NuGet feeds
hosted in your Team Services account/TFS project collection with
NuGet 3.1 or below, edit your build definition to specify a path
to a NuGet.config containing the package sources you wish to use.
How can I remove this?
Based on my test, that warning remains even through using higher version of nugget (e.g. 3.3) or do not restore package from VSTS feed. (Hosted build agent has the same result).
You can’t remove it unless you custom a build task to restore package through command line.
I submit a issue here.
Update:
The issue has been updated.
I see the issue in the code coming from our transition from depending
on assets coming with the agent to being deployed with the task. You
can get around this for now until we get an official change out by
either (1) choosing to use the Nuget 3.5 version radio button in the
task config or (2) supplying a path to your nuget.config.
So, you can use Nuget 3.5 version or specify nuget.config file.
I have turned on TeamCity's NuGet Server and I want to push in common packages (i.e. from public sources such as NuGet.org) because the build server cannot see outside our company, so restoring packages on the build server from NuGet.org is not possible.
I cannot see how to push these packages on to our TeamCity server. I've seen various answers suggesting to use a package build still or some other means of publishing from within a build, but this is not appropriate for my use case.
If I try to publish from a command line it complains that it cannot find an API key (where do I get that from?) and it won't allow me to enter my credentials (I assume my team city login would be it) as it tells me "Cannot prompt for input in non-interactive mode." (I didn't set that mode and I can't see how to turn that off).
So, how do I push/publish an adhoc package that I obtained elsewhere into team city?
I believe that the nuget functionality provided by TeamCity is an API added on top of TeamCity's builtin artifact functionality.
There are a number of consequences of that:
When a build configuration is executed that produces any .nupkg files that are marked as artifacts, they will be available on the Teamcity nuget feed.
As with all other artifacts nupkgs published in TeamCity are subject to Teamcity's general artifact retention rules.
Access rules for nuget packages are the same as access to the TeamCity projects.
There is however as far as I know no implementation in the Teamcity Nuget API for pushing packages to it. The general practice for storing original or generated packages is to use a stand alone nuget server or service like a normal file share, a Nuget.Core based server, proget or myget.org.
Update:
If you end up with many packages of your own I've heard people reporting that Teamcity becomes quite slow when the clients are resolving the packages.
Update 2:
The last years I've adopted the notion of separating build artifact packages into the two categories library package and deployment package. A separate package repository can be used for both types but a repository such as the one available in for instance Octopus deploy should only be used for deployment packages.
Update 3:
Microsoft have a page for a number of nuget server options.