We saw this error when trying to reinstall nuget packages on one application:

Successfully uninstalled ‘Microsoft.AspNet.WebApi.Client 5.0.0’.
Install failed. Rolling back…
update-package : Could not install package ‘Microsoft.AspNet.WebApi.Client 5.0.0’. You are trying to
install this package into a project that targets ‘.NETFramework,Version=v4.0’, but the package does not
contain any assembly references or content files that are compatible with that framework. For more
information, contact the package author.
At line:1 char:1
+ update-package -project Walshgroup.Web.CorporateExperience.vbproj -reinstall
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Update-Package], InvalidOperationException
    + FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PowerShell.Commands.UpdatePackageCommand

This was caused by us installing this nuget package initially when the project was targeting .net 4.5, and then later it was changed to target .net 4.0. 

I just wrote about the switch from the MSBuild based “Enable Nuget Package Restore” option to the new and recommended “Automatic Package Restore.”

https://chrismay.org/2015/01/07/nuget-switching-from-enable-package-restore-to-automatic-package-restore/

Not only did this not solve our problems, but it seems the solution involves returning to the “wrong” way at least based on pretty much everything I read on the topic:

http://docs.nuget.org/docs/workflows/migrating-to-automatic-package-restore

http://www.xavierdecoster.com/migrate-away-from-msbuild-based-nuget-package-restore

http://blog.davidebbo.com/2014/01/the-right-way-to-restore-nuget-packages.html

Our problem lies in the use of common projects in multiple solutions.  Lets say you have SolutionA that contains AppA, ProjectX, ProjectY, and ProjectZ.  SolutionB contains AppB, along with ProjectX, Y and Z as well.  If you are working in SolutionA and you add a new Nuget package to ProjectX, then that package is downloaded to SolutionA/Packages/MyNewNugetPackage1.0/…/…/x.dll and ProjectX is given a hint path to search for that DLL reference at that file path.

Now what happens when your build server tries to build SolutionB (not SolutionA)?  Nuget restore downloads all the necessary nuget packages into the SolutionB packages folder, but ProjectX fails to build because it expected to find x.DLL in the SolutionA packages folder, but that folder is empty (the SolutionB packages folder was the one that was just populated with nuget packages).  So the build fails.

Because of the nature of how we store our projects in source control, if we could control the location of the packages folder it would solve our problem because we could use a common packages folder across all solutions. 

What would this mean?

It means that all solutions in this source control repo would all end up downloading their nuget packages, and looking for their nuget references, in the same folder.  This means that when SolutionA downloads it’s nuget packages, it the same spot where SolutionB would download it’s packages, so ProjectX will find what it needs not matter if it’s in SolutionA or SolutionB.

To make this work here is what I had to do.  First I needed to return the solutions to the “wrong” way of doing package restore.  This means right clicking on the solution in VS.Net and picking “Enable Nuget Package Restore”.  This will create a .nuget folder under the solution which will contain a Nuget.config file.  In this file you need to add the <config> node shown below.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <solution>
    <add key="disableSourceControlIntegration" value="true" />
  </solution>
   <config>
      <add key="repositoryPath" value="..\..\..\..\..\..\CommonPackages" />
    </config>
</configuration>

Any change to Nuget.config requires a VS.Net restart to take effect.  Once you restart VS.Net nuget will be looking in this new “CommonPackages” folder for it’s nuget packages.  But your projects aren’t looking for their DLLs there.  The easy way to solve this is to just run the Package Manager Console and issue the command:

update-package -reinstall

This will not only download all the nuget packages your solution references, but it will reassign those references so that they are now pointing to the new location, “CommonPackages” in this case.

I was not able to find a way to do anything equivalent using the nuget.exe program from outside visual studio.  If that WERE possible, then I think this would have been a possible solution to my original problem, because unlike running “nuget.exe restore”, this command actually DOES change where the solution’s projects look for their DLLs. 

So it seems that starting with Nuget 2.7 and Visual Studio 2013, it’s no longer advised to use the “Enable NuGet Package Restore” feature (see image below). 

Why?  Well now there is “Automatic Package Restore”, which is a feature that allows VS 2013 to automatically download missing packages as part of the build.  Again, see the image below.

But… there are a few catches.

First, this means that any build servers that use MSBuild will no longer automatically download missing packages.  You’ll need to script that out using “nuget.exe restore”.  (The positive side of this is that in some situations, like ours, the Enable Package Restore option was causing conflicts in our build server.  I won’t go into details but it had to do with multiple solutions referencing the same projects and bad HintPath values getting set.

Second, you need to go through some pains to extricate yourself from “Enable Package Restore” before you can successfully work with “Automatic Package Restore”.

What pains you ask?

Well first in your solution you should delete the .nuget/Nuget.exe and .nuget/Nuget.targets files.

Second, your project files (vbproj, csproj etc) you should remove these lines:

<RestorePackages>true</RestorePackages>

AND

<Import Project="$(SolutionDir)\.nuget\NuGet.targets" Condition="Exists('$(SolutionDir)\.nuget\NuGet.targets')" />

<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">  
    <PropertyGroup>    
        <ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>  
    </PropertyGroup>  
    <Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
</Target>

.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, “Courier New”, courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }

Actually I’m not sure if the first part dealing with the RestorePackages element needs to be removed.  I had found a few people saying you should remove it, but leaving it seems to not cause any problems (for me).

If you are doing a build and you get seeing errors like this:

Error    2    This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is C:\Data\Whatever\\.nuget\NuGet.targets.   

Then it means that you have some of the stuff in the project file still and you need to remove it before you can try building.

After doing this, if you then delete your solutions Packages folder and do a rebuild you should see Visual Studio automatically downloading the missing packages:

There have been a couple times where it seemed after making these changes I needed to close Visual Studio and reopen it.  But after that everything worked.