This project is read-only.


Enabling Nuget Package Restore doesn't always work


  1. Create a project.
  2. Install a package e.g. EntityFramework
  3. (close solution) Delete "packages" folder
  4. (reopen solution) Enable Nuget Package Restore
  5. Build solution.
no attempt to restore package.

error :
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,9): warning MSB3245: Could not resolve this reference. Could not locate the assembly "EntityFramework". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
Closed Sep 20, 2012 at 10:44 PM by deepakverma
verified, it builds fine after enable nuget is set.


JeffHandley wrote Mar 16, 2012 at 8:11 PM

It looks like steps 3 and 4 are in the wrong order. But it would be good to understand why enabling package restore requires the packages folder to be in place.

el_tone wrote May 1, 2012 at 1:08 PM

it seems like the <RestorePackages>true</RestorePackages> line is not being added to the csproj in this case.
This happened to me after trying to enable package restore after a clean source control checkout.

JeffHandley wrote May 15, 2012 at 9:36 PM

@aldion this behavior might be different in 1.8. Please verify.

aldion wrote May 15, 2012 at 11:53 PM

This still repro with latest 1.8/2.0

JeffHandley wrote May 17, 2012 at 10:12 PM

@anurse please investigate this to understand why we need the packages folder to exist when enabling package restore.

We should expect users to fall into this situation where they choose to not check in their packages folder but they forget (or don't know) to enable package restore first.

shtreber wrote Jun 7, 2012 at 12:06 AM

confirming this still DOESN'T work with latest nuget version (1.8.0)

aldion wrote Jun 28, 2012 at 11:52 PM

@anurse This is why it happens, there's a check looking for packages before enabling package restore (the fix could be on packages.config instead ?) :
    private void EnablePackageRestore(Project project, IVsPackageManager packageManager)
        var projectManager = packageManager.GetProjectManager(project);
        if (projectManager.LocalRepository.GetPackages().IsEmpty())
            // don't enable package restore for the project if it doesn't have at least one 
            // nuget package installed


shailendrab wrote Jul 3, 2012 at 10:15 AM

Package restore test on VS2010

To explore package restore feature, I followed the official Nuget website help from the link

Executed following steps to try using the package restore feature :
  1. Created a new class library project.
  2. Installed the target package.
  3. Add a reference and used a public method from the package installed.
  4. Build the project successfully.
  5. Clean and close the solution.
  6. Delete the packages folder.
  7. Reopen the solution.
  8. Enable the package restore as suggested in link. I observed although it is expected to modify the project csproj file, surprisingly it did not.
  9. Try building the solution and it will fail (as I observed). No attempt to get the package.
  10. I tried following to get it to work:
a. Add this line in the csproj file

<Import Project="$(SolutionDir).nuget\nuget.targets" />

This is required as this is the script that loads the packages (through running build tasks). Reopen solution. Try building the solution and it fails. No attempt to get the package.

b. Ensure the packages.config file is present in the project folder and has the correct package added. This is required as this file is referred by the nuget.targets file in the project directory.

Close the solution and open it again. Try build the solution and it fails. Still no attempt to get the package.

c. Enable the restorePackages option.

<RestorePackages Condition=" '$(RestorePackages)' == '' ">true</RestorePackages>
Close the solution and open it again. Try build the solution and this time it will successfully downloaded the package from store and solution is build successfully. Surprised as this should have been
done by Nuget.
--- Optional step ---
d. Add package source path in nuget.targets file similar to:

<PackageSource Include="\NetworkShare\Builds\MyPackages" />

So if you do not add a PackageSource in nuget.targets file, how did it find out the package location? Well, by default it will use the registered sources under %APPDATA%\NuGet\NuGet.Config.

Am I missing something (doing it incorrectly). My Question is, while the feature is cool can not we make it easy to use or enable at first instance without going through these (try and cross you figure) steps???

pmoutzo wrote Jul 11, 2012 at 4:53 PM

I have run into this in two different scenarios. First, following your example shailenrab on my local dev box. I clean the solution, close it, delete the packages folder and go to the command line to execute MSBUILD on my own. It fails completely with references missing for the cproj file inside the sln. The build server fails with the same errors. I cut and pasted the nuget.exe -install command from the build script and run that in a console window, and I get the message "All packages listed in packages.config are already installed". But they aren't. I deleted the packages folder! I give up and open the sln in VS2010 and the Package Console gives me a quick warning that packages are missing in this solution and offers an Enable button for me to restore them. Click the button and everything is back to normal. So it seems Package Restore only works in VS...msbuild fails if you get latest from TFS and attempt a build via a script or command line, and as a result so does my CI build on the build server. This means that I'm dead in the water. Unless someone has a work around that doesn't involve checking in the packages into TFS?

eddiegroves wrote Aug 8, 2012 at 7:29 AM

I've had this bug a few times when trying to enable package restore after I have used nuget and then deleted the packages folder.

The part that fails is modifying the csproj files.

The fix has been to manually create the packages folder and pull down the missing packages first (e.g using the command line), then use the GUI to 'Enable Package Restore'.

This is on a per project case as well.

AnthonySteele wrote Aug 22, 2012 at 1:32 PM

This, in my recent experience is a pretty common case which gives a disfunctional first impression of nuget.

i.e. Someone gets the source to a project and builds it. Build fails due to missing packages. nuget's "package restore" feature then fails even after setting the right options.

What worked finally was to
  • check Tools|Options|package manager|Package restore
  • right-click the solution and "enable package restore"
  • right-click a project in the solution and "Manage nuget packages".
Then you will finally get a bar across the top of this UI with a message that some packages are missing, click to get them. Clicking this button gets the packages.

JeffHandley wrote Sep 5, 2012 at 5:43 PM

@dotnetjunky - let's see if this can be addressed in NuGet 2.1. Please let us know your risk assessment on it though if you think it needs extra bake time (NuGet 2.2).

dotnetjunky wrote Sep 6, 2012 at 10:16 PM

The fix for this bug is low risk.

dotnetjunky wrote Sep 6, 2012 at 11:58 PM

Fixed in changeset 32790bbc42a7

esaulsberry wrote Nov 26, 2012 at 9:27 PM

I hate to say this but it sure doesn't look fixed here.
My NuGet version is 2.1.31002.9028, (VS 2012)
The packages are in a private package source.

Enable package restore is turned on for the solution.
Allow NuGet to restore packages during build is enabled.

<add key="enabled" value="True" />
<add key="NuGet official package source" value="" />
<add key="MyPrivateServer" value="\\MyPrivateNuGetServer\NUGET" />

1) Add the required packages for the assembly
2) build - all is well
3) Check in to TFS
4) Close VS
5) Delete local directory (Simulating another dev getting the solution on a clean machine)
6) Fire up VS, get solution
7) Build - No packages are restored. Build fails.
1> All packages listed in packages.config are already installed.
1>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1578,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "cognosdotnet_2_0". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.

hannespreishuber wrote Feb 5, 2013 at 7:22 PM

have exact same behavior .-STILL

Version 2.2.31210.9045

btw it's lame that there i have to type the infos from the visual Studio Dialog and can not copy

dotnetjunky wrote Feb 6, 2013 at 6:04 PM

Can you download the latest nightly build VSIX and try to see if it still fails?

Btw, you can press Control+C on the error dialog to copy the whole content.

SenthilGandhi wrote Feb 7, 2013 at 2:07 PM

i used the below command to fix the issue at the solution level
PM> Update-Package -Reinstall
  • this will uninstall and install all the packages again and most importantly reconfigures your .csproj to point to appropriate package location
Then you can check-in again to TFS

To fix the issue at the project level use
PM> Update-Package -Reinstall -ProjectName <foo>

barnarddale wrote May 2, 2013 at 3:37 PM

Thank you, @SenthilGandhi. This did indeed update the project files and get it to build. I was having this issue in Nuget 2.5.40416.9020.

andrewmyhre wrote Oct 21, 2013 at 3:59 PM

Just a note for people looking for a solution, the update-package command above can be problematic if Nuget fails to re-install a package. Instead of retrying it will just delete the entry from packages.config and move on. Any failures need to be reinstalled using the install-package command and specifying the appropriate version.

andrewmyhre wrote Oct 21, 2013 at 3:59 PM

Also, in my case this was due to packages.config files not being included in my VS projects as well as the bug reported on this page.

Raz0rbBlack wrote Feb 28, 2014 at 2:02 PM

I ran into the same error in VS 2012 with NuGet 2.8.50123.400. I found that changing the NuGet.config file key under activePackageSource to the private feed URL enables the private package to download correctly:
    <add key="" value="" />
Setting it back to nuget makes the build fail.
Seems a lot like the message for the way 'Manage NuGet Packages' dialog seems to work (fail once, probably on feed, work the second time).

Seeing no way to fix this with the current NuGet version, but needing a solution to use inside my CI environment, I tested the usage of the nuget.exe restore path/to/solution.sln command and found it working.

  1. this bug is not fixed
  2. work around available for manual updates (using the 'Manage NuGet Packages' inside VS and ignoring the first fail message)
  3. work around inside CI environments: use the nuget.exe restore command

Rziedreo145 wrote Mar 5, 2014 at 7:39 PM

I've encountered this same bug and found that it completely defeats the intent of not committing packages into source control. My team needs to be able to pull down source from source control and build successfully without any intermediate steps.

Only solution I see for now is to include packages in source control, which is far from ideal.

Is there a way to re-open this work item?

shkup wrote May 15, 2014 at 9:29 AM

I have this issue with version 2.8.50126.400.
I have NuGet.config with my offline repostiry activated and the rest of the repositories disabled (No internet access over here).
I also tried to copy nuget.config in c:\, C:\ProgramData\NuGet\Config, atc. to no avail.
Regular packages browsing and installing packages via the the console or add on dialog works.
The restore fails (on the same packages that have been successfully installed) with the error message of "an error occurred while trying to restore packages: Unable to find version *** of package ***".

epang wrote Aug 5, 2014 at 12:17 PM

I also get this in version 2.8.50313.31
In order to resolve, I had to explicitly click on the Restore button in the Package Manager Console.
This restores the missing packages that are NOT in the local cache. I think this is an issue with NuGet.

danliu wrote Aug 5, 2014 at 6:11 PM

@epang, can you please provide more details? such as which package sources that you have, and which packages are left from being restored.

Also if you start visual studio by calling devenv.exe /log, the activitylog.xml under %APPDATA%\Microsoft\VisualStudio\Version\ActivityLog.xml may give some exception details. Please share with us the activitylog.xml, thanks.

mrnaveedbutt wrote Nov 24, 2014 at 4:31 AM

I had the same issue.

In my case.

Someone wrongly checked-in some packages inside the packages folder into the TFS. So make sure, that there are no packages in the "Packages" folder for the solution.

The only thing there should be repositories.config and "Enable Nuget Package Restore" should be clicked for solution.

nbharali wrote Dec 4, 2014 at 5:51 PM

Thanks @mrnaveedbutt. Package folders were the problem in my case.