CODEWITHSUNDEEP
visual-studio-2010nugetnuget-package
Unsliced
Unsliced

Reputation: 10552

Missing package causes NuGet package restore to fail

We are enthusiastic users of NuGet, both for internally built as well as 3rd party packages.

We've recently started to enable the NuGet Package Restore option in some of our build projects to reduce the amount of binary files we commit to source control, but we're coming up against a problem.

We're seeing Visual Studio taking a really long time to start up and, once it has started (which could take over half an hour), the subsequent build is then equally time-consuming. While this is happening, you can see many child NuGet processes appearing and dying in process explorer.

We have found that if the version of the package that is referenced in the packages.config file is not available from any of the configured package sources (perhaps it's an old version of an internal package and someone helpful has been cleaning up our local repo), it seems as though NuGet and Visual Studio get into some sort of infinite (or at the very least long-running) retry loop.

If we run the NuGet install command from the command line we get back the 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 as though this isn't being consumed correctly by Visual Studio/NuGet.

Upvotes: 5

Views: 2420

Answers (2)

allen
allen

Reputation: 4647

Firstly your versioning does not conform to what nuget recommends ie 1.2.3. So you should try bumping up your version as 1.0.1 to see if that resolves the issue.

  • Does NuGet log its actions anywhere?

You can use the -verbosity flag with your command line "nuget install" to get additional information. Details are also available in the output window. Select "package manager" from the dropdown. For more use devenv /log

  • Can we limit the NuGet restore retries or time outs (perhaps in the nuget.targets file?)

Dont know of any way here.

  • It looks as though NuGet's semantic versioning isn't being used, because in our above scenario 1.0.0.2 is available from the repo, can this be enabled?

This can be acheived by checking the "automatically check for upgrades" in the tools->options-> package manager? See if your packages.config is limiting the version to 1.0.0.1

Upvotes: 0

Deepak
Deepak

Reputation: 2233

This seems to similar to this issue http://nuget.codeplex.com/workitem/2970 temporary workaround worked for me is to open nuget.targets and replace
<!-- We need to ensure packages are restored prior to assembly resolve -->
<ResolveReferencesDependsOn Condition="$(RestorePackages) == 'true'">
RestorePackages;
$(ResolveReferencesDependsOn);
</ResolveReferencesDependsOn>
with

<BuildDependsOn Condition="$( RestorePackages) == 'true'">
RestorePackages;
$(BuildDependsOn);
</BuildDependsOn>

Close and reload solution in VS. this would make the build depend on restore packages instead of assembly resolve which seems to solve the issue.

hope this helps.

Upvotes: 2

Related Questions