We are NuGet enthusiasts for both built-in and third-party packages.
We recently turned on the NuGet package restore feature in some of our build projects to reduce the number of binary files that we pass to the source control, but we are facing a problem.
We see that Visual Studio takes a very long time to start, and as soon as it starts (which may take more than half an hour), subsequent assembly will be laborious at the same time. While this is happening, you can see many NuGet child processes that appear and die in the process explorer.
We found that if the version of the package referenced by the package.config file is not available from any of the configured package sources (perhaps this is an old version of the internal package, and someone useful, we clear our local repo), it seems that NuGet and Visual Studio end up in some kind of endless (or at least long term) retry loop.
If we run the NuGet installation command from the command line, we will return an error
>.nuget\NuGet.exe install project\packages.config -o packages
Unable to find version '1.0.0.1' of package 'my.internal.package'.
but it looks like Visual Studio / NuGet is not being consumed correctly.
- Does NuGet record its activities anywhere?
- Can we limit NuGet retries or timeouts (possibly in a file
nuget.targets?) - It seems that NuGet semantic notion is not used, because in our above scenario 1.0.0.2 is available from the repo, can this be turned on?