packages. config: The targetframework attribute of a dependency specifies the variant of a package to install.
Put simply, a NuGet package is a single ZIP file with the . nupkg extension that contains compiled code (DLLs), other files related to that code, and a descriptive manifest that includes information like the package's version number.
NuGet 2.1 offers a feature that makes this a lot simpler: just do update-package -reinstall -ignoreDependencies
from the Package Manager Console.
NuGet 2.0 doesn't handle re-targeting your applications very well. In order to change your packages' target frameworks, you must uninstall and reinstall the packages (taking note of the packages you had installed so that you can reinstall each of them).
The reason packages must be uninstalled and reinstalled is:
For those who had problems with update-package -reinstall <packagename>
command, consider running it with -ignoreDependencies
flag, like this:
update-package -reinstall <packagename> -ignoreDependencies
This flag will leave your package dependencies alone, otherwise they might got updated even if the package you originally wanted reinstall still keeps it's version in same.
More info here.
After trying the accepted answer unsuccessfully I would like to suggest a less risky command:
Update-Package <PackageName> -ProjectName <ProjectName> -Reinstall -IgnoreDependencies
For more info: http://blog.nuget.org/20121231/a-quick-tutorial-on-update-package-command.html
Whilst attempting to reinstall packages solution wide, I encountered a dependency error (in spite of using the -ignoreDependencies
flag), and all the packages.config files for every project had been deleted. In VS2013, it seems that packages.config does not get flushed back to disk and re-added until all the upgraded dependencies/references are re-attached to the project.
In my case what worked was to upgrade each project one-at-a-time by adding the -ProjectName
projectname to the update-package
command. In this case the packages.config is updated as each project is upgraded.
May not be practical for very large solutions but it seems a reasonable compromise to still take advantage of the automated upgrade for as many projects as possible and isolate the problematic ones without having every packages.config in your solution deleted on failure.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With