I posted this in response to a question on Stackoverflow as well. The version of Stackoverflow is better formatted:
http://stackoverflow.com/questions/7253763/nuget-update-package-doesnt-recognize-installed-package-update-failed/9582694#9582694
I am working on the same project as Tomas and I have tried to figure out when this problem occurs and why. It seems this happens when we have one or more old versions of a package in the packages folder and try to issue the 'update-package' command.
Before issuing the command our packages folder and config looks like this:
Packages folder:
Common.WebApi.1.0.0.109
Common.WebApi.1.0.0.110
Packages config:
<packages>
<package id="Common.WebApi" version="1.0.0.110" />
<package id="System.Json" version="4.0.20126.16343" />
<package id="System.Net.Http" version="2.0.20126.16343" />
</packages>
Now, when issuing 'update-package Common.WebApi' we get the error:
Update-Package : 'OPF.Common.WebApi' was not installed in any project. Update failed.
To fix it I delete the old package 'Common.WebApi.1.0.0.109' from the packages folder and rerun the command which then works.
The obvious question is: Why do I have an old package in my packages folder? This happens to us because we do not committ our own packages to source control. Instead, we use the approach which is described here: http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages
The 'old package problem' occurs in this situation:
1. Developer A updates a package and commits the package.config to source control
2. Developer B gets the latest version from source control and receives the updated package.config
3. Developer B builds the project and the new package is created in his packages folder
4. Nuget does not delete developer B's old package from his packages folder so Developer B now has both the old package and the new package in his packages folder, but only a reference in the package.config to the new version.
To me, it seems that Nuget does not expect there to be more than one version of a package in the packages folder and becomes confused when you to try to update a package that has multiple versions [in the packages folder] even though you only reference a single package from the package.config.
Comments: Fixed with changeset aaa1e9fc8b501cbf5fdbc4da45e769c7d686f462
http://stackoverflow.com/questions/7253763/nuget-update-package-doesnt-recognize-installed-package-update-failed/9582694#9582694
I am working on the same project as Tomas and I have tried to figure out when this problem occurs and why. It seems this happens when we have one or more old versions of a package in the packages folder and try to issue the 'update-package' command.
Before issuing the command our packages folder and config looks like this:
Packages folder:
Common.WebApi.1.0.0.109
Common.WebApi.1.0.0.110
Packages config:
<packages>
<package id="Common.WebApi" version="1.0.0.110" />
<package id="System.Json" version="4.0.20126.16343" />
<package id="System.Net.Http" version="2.0.20126.16343" />
</packages>
Now, when issuing 'update-package Common.WebApi' we get the error:
Update-Package : 'OPF.Common.WebApi' was not installed in any project. Update failed.
To fix it I delete the old package 'Common.WebApi.1.0.0.109' from the packages folder and rerun the command which then works.
The obvious question is: Why do I have an old package in my packages folder? This happens to us because we do not committ our own packages to source control. Instead, we use the approach which is described here: http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages
The 'old package problem' occurs in this situation:
1. Developer A updates a package and commits the package.config to source control
2. Developer B gets the latest version from source control and receives the updated package.config
3. Developer B builds the project and the new package is created in his packages folder
4. Nuget does not delete developer B's old package from his packages folder so Developer B now has both the old package and the new package in his packages folder, but only a reference in the package.config to the new version.
To me, it seems that Nuget does not expect there to be more than one version of a package in the packages folder and becomes confused when you to try to update a package that has multiple versions [in the packages folder] even though you only reference a single package from the package.config.
Comments: Fixed with changeset aaa1e9fc8b501cbf5fdbc4da45e769c7d686f462