Home: Update-Package -reinstall -ProjectName <project> does not work for PR
PM> get-package -projectname ClassLibrary1
Id Versions ProjectName
-- -------- -----------
newtonsoft.json {10.0.3} ClassLibrary1
NETStandard.Library {2.0.0} ClassLibrary1
PM> Update-Package -reinstall -projectname ClassLibrary1
No package updates are available from the current package source for project 'ClassLibrary1'.
Executing nuget actions took 0 ms
Time Elapsed: 00:00:00.2839360
karann-msft
All 23 comments
@karann-msft - what is your expected behavior? (what versions of which packages should be upgraded to?)
does it work if you remove "-reinstall"
What TFM is your ClassLibrary project?
What version of VS are you using?
rrelyea
on 24 Oct 2017
the expected behavior is the same as what you you would see if you ran that command for a PC based project. Uninstall and then install all packages.
PM> Update-Package -reinstall -ProjectName WebApplication1
Attempting to gather dependency information for multiple packages with respect to project 'WebApplication1', targeting '.NETFramework,Version=v4.6.1'
Gathering dependency information took 18.29 sec
Attempting to resolve dependencies for multiple packages.
Resolving dependency information took 0 ms
Resolving actions install multiple packages
Found package 'ClassLibrary1 1.0.0' in 'C:\Users\karann\Source\Repos\WebApplication1\packages'.
Retrieving package 'CodicePlastico 1.0.0' from 'nuget.org'.
Retrieving package 'EFCodeFirst 0.8.0' from 'nuget.org'.
Retrieving package 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.8' from 'nuget.org'.
Retrieving package 'Microsoft.Net.Compilers 2.4.0' from 'nuget.org'.
Removed package 'ClassLibrary1 1.0.0' from 'packages.config'
Successfully uninstalled 'ClassLibrary1 1.0.0' from WebApplication1
Executing script file 'C:\Users\karann\Source\Repos\WebApplication1\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8\tools\net45\uninstall.ps1'
Removed package 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.8' from 'packages.config'
Successfully uninstalled 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.8' from WebApplication1
Removed package 'Microsoft.Net.Compilers 2.4.0' from 'packages.config'
Successfully uninstalled 'Microsoft.Net.Compilers 2.4.0' from WebApplication1
Removed package 'EFCodeFirst 0.8' from 'packages.config'
Successfully uninstalled 'EFCodeFirst 0.8' from WebApplication1
Removed package 'CodicePlastico 1.0.0.0' from 'packages.config'
Successfully uninstalled 'CodicePlastico 1.0.0.0' from WebApplication1
Package 'CodicePlastico.1.0.0' already exists in folder 'C:\Users\karann\Source\Repos\WebApplication1\packages'
Added package 'CodicePlastico.1.0.0' to 'packages.config'
Successfully installed 'CodicePlastico 1.0.0' to WebApplication1
Package 'ClassLibrary1.1.0.0' already exists in folder 'C:\Users\karann\Source\Repos\WebApplication1\packages'
Added package 'ClassLibrary1.1.0.0' to 'packages.config'
Successfully installed 'ClassLibrary1 1.0.0' to WebApplication1
Package 'EFCodeFirst.0.8.0' already exists in folder 'C:\Users\karann\Source\Repos\WebApplication1\packages'
Added package 'EFCodeFirst.0.8.0' to 'packages.config'
Successfully installed 'EFCodeFirst 0.8.0' to WebApplication1
Package 'Microsoft.Net.Compilers.2.4.0' already exists in folder 'C:\Users\karann\Source\Repos\WebApplication1\packages'
Added package 'Microsoft.Net.Compilers.2.4.0' to 'packages.config'
Successfully installed 'Microsoft.Net.Compilers 2.4.0' to WebApplication1
Package 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8' already exists in folder 'C:\Users\karann\Source\Repos\WebApplication1\packages'
Added package 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8' to 'packages.config'
Executing script file 'C:\Users\karann\Source\Repos\WebApplication1\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8\tools\net45\install.ps1'
Successfully installed 'Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.8' to WebApplication1
Executing nuget actions took 3.6 sec
Time Elapsed: 00:00:22.0793482
Why would I remove "-reinstall" ? I WANT to reinstall. I don't want to upgrade and hence don't care if one is available. The reason I did get-package was to show that the project did have packages installed.
Its a netstandard 2.0 class library.
27019.1.d15rel
karann-msft
on 25 Oct 2017
@karann-msft after reading some docs around the reinstall flag, I feel that this behavior is correct. Since PR has packages in global packages folder there is nothing to reinstall. Why dont you try deleting one of the packages from the global packages folder and then try reinstall. It should redownload the package.
mishra14
on 26 Oct 2017
@mishra14
When I run that command for a PR project that has packages installed, this message "No package updates are available from the current package source for project 'ClassLibrary1'." is plain wrong. The user is running a reinstall and NOT update.
There are only two options here - fix that message to state that resinstall is not supported for PR (and the docs to call out that this only supported in PC), or it should do exactly what it does for PC.
karann-msft
on 26 Oct 2017
@karann-msft
When I run that command for a PR project that has packages installed, this message "No package updates are available from the current package source for project 'ClassLibrary1'." is plain wrong. The user is running a reinstall and NOT update.
You are running an update-package command. What do you think it does?
mishra14
on 27 Oct 2017
Take a look at the switch it's being run with.
What do you think is the meaning of reinstall?
karann-msft
on 28 Oct 2017
We need to determine what is the appropriate behavior for reinstall is in PR.
rrelyea
on 30 Oct 2017
There was another customer report here.
The "reinstall" flag is only there because of all the issues people ran into when running installs.
Scripts execution/dll analysis, binding redirects application, could all lead to a broken state.
In Package Reference that's not the case.
The need for this feature is simply not there.
The concept of reinstall is not there, because the installs and restores do the exact same thing.
So it can't really do the same thing as PC, because even in PC, you don't delete the packages from the global packages folder.
Since the concept does not exist, I think the other option is the best.
- Clarify the docs
- Add a warning when someone tries to run it on a package reference project, and probably no-op when people run that.
nkolev92
on 2 Mar 2018
For what it's worth I'm with totally with @karann-msft on this one.
Make it explicit that -Reinstall doesn't work for a PR project and have the user do something else or make it work like it did before. IE: in a PR project, -Reinstall would blow out all the obj\*g.props/targets and obj\project.*.json and rewire the package references from the global packages folder and download them if they're not available.
There are common cases like zipping up a project folder, moving it to a different machine, where references on the new machine can be all out of whack. Most devs would think -Reinstall should work as they've been using it for years to deal with problems like this.
Also, I'd recommend NOT updating version numbers if -Reinstall does stay for PR projects. See #6611.
bchavez
on 2 Mar 2018
@bchavez The not updating a version number if -Reinstall is passed is a hole because the -Reinstall flag is completely ignored.
As I mentioned in my previous comment.
What you're articulating is literally just a restore.
Restore will blow out the assets file if it needs changed.
The zipping up a project, and extracting in a different directory scenario, whenever you run restore again, that'll update the assets file and msbuild props/targets.
The idea there is that once you extract that file, you run a rebuild, and it just works.
Doing a clean/build in VS also works.
Basically there's no point in anyone ever doing -Reinstall here. PackageReference is smart enough to do that in simple restore.
I'd say no-oping if someone does attempt that for package reference with a clear message would be the way to go.
We have designed a more streamlined workflow and we want people to be using that workflow.
Running PMC goo introduces needless friction.
nkolev92
on 2 Mar 2018
I need an option to re-download the package into Global packages directory. I am just thinking may be -Reinstall does that?
anangaur
on 2 Mar 2018
I think the question there is "why" do you need to do that.
I'd say we want to design for thescenario (local package dev testing would is restricted on the "refreshing" of global packages folder, even there though we'd look for a way to not re-download everything).
The Update-Package -reinstall is very much a "this project" command.
It was a big hammer to hide all the flaws with the design, not a scenario by any means.
tl;dr
I'd say don't change the meaning of reinstall for a new feature.
And let it die because it's not relevant to the new world.
nkolev92
on 2 Mar 2018
My scenario is that I have an existing project where I want to use VSTS Package Management. We want to leverage the "upstream" capabilities of it, so that we can specify a single feed in our Project, and VSTS takes care of aquiring the package from the right stream.
Now, to be able to do this, you have to execute an "Install" action on the packages that are already installed. A -Reinstall would have been good in this case.
MichelZ
on 26 Jun 2018
I'd like to use -Reinstall in order to automatically update the AssemblyBindings section of my app.config.
joshmouch
on 23 Oct 2018
@joshmouch
In PackageReference you cannot edit the content in the project directory.
You can only do that at build time and only in the output.
@MichelZ
That goes a step further than reinstall ever did.
In PackageReference the only copy on your machine of a package right now is in the global packages folder.
The global packages folder is shared among projects.
You cannot "comfortably" delete that, as you simply do not have the information.
nkolev92
on 23 Oct 2018
@nkolev92
By that, do you mean nuget is not capable of modifying app.config anymore? I've spent the last three days getting package conflicts to resolve, and I don't feel like I'm any closer to getting these dependencies sorted out. It feels like we're back in DLL hell.
joshmouch
on 24 Oct 2018
@joshmouch
In Package Reference NuGet does not deal with binding redirects.
They are automatically generated by the build.
See https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/how-to-enable-and-disable-automatic-binding-redirection.
For more references, please look at:
https://github.com/dotnet/announcements/issues/31
https://stackoverflow.com/questions/46111749/adding-a-bindingredirect-to-a-net-standard-library
nkolev92
on 24 Oct 2018
Unfortunately, the automatic binding is buggy and doesn't work on large projects.
joshmouch
on 24 Oct 2018
@nkolev92 The world is so much more complicated than you can imagine, and on top of that we have Murphy!
The need for this feature is simply not there.
It's a bold and brave statement to make, to have such confidence and be so sure of yourself, that a situation can not occur where you would need to reinstall the nuget packages for a project, no matter what other software is installed, what hardware that might have crashed and rendered who knows what corrupt, or what creative and ingenious modifications a user might have done to files, settings, registry, configurations or anywhere else, respect!
Myself, i'm a bit more humble, but then I've only been a consultant and a developer since the early 90ies. And I totally agree with what Einstein said about "human stupidity", and can personally add that it holds true for human creativity and ingenuity as well, when it comes to unorthodox and interesting ways of using computers and software. I can't think of one single thing where computers and software is involved, where I feel comfortable making a statement like "you will never need to do this"....I'm just thinking of the NTFS-Guys, who said "no need to run defrag on NTFS", but now it's built into windows, and runs automatically....
Bartolomeus-649
on 29 Apr 2019
I have the same issue. When I remove a reference using a tool, this can remove the file reference, but leave the reference in packages.config (or something went wrong with the install scripts added to the nuget). This would then REPAIR the package to it's original state instead of doing an update.
d4e666
on 2 Jul 2020
@d4e666
What you are articulating sounds like it is related to packages.config.
This issue is talking about PackageReference.
nkolev92
on 2 Jul 2020
Does it matter if it is for Niger cobfig or package reference. Fact is that links can get corrupted and because of dependencies simple remove and install doesn't cut it either way.
d4e666
on 3 Jul 2020
Does it matter if it is for Niger cobfig or package reference. Fact is that links can get corrupted and because of dependencies simple remove and install doesn't cut it either way.
@d4e666
It does. In packages.config the installation is 2 part, the packages.config file and the references in the project file (.csproj). The references in the project file hard code a relative path to the assets chosen (like the dll).
In PackageReference, the installation is simply the package id and package version.
Everything else is automatic!
This makes things like re-targeting a project super simple and doesn't require any special gestures such as Update-Package -reinstall to fix up references because the references were never broken.
The title and body of this issue talk about the Update-Package -reinstall command and it's behavior for the PackageReference project format.
Your scenario looks different from the one being discussed in this issue. Please file a different issue for the problems you are running into.
nkolev92
on 6 Jul 2020
Related issues
sylvainlavoie
路
3Comments
p-kaczynski
路
3Comments
livarcocc
路
3Comments
rrelyea
路
3Comments
skofman1
路
3Comments
Most helpful comment
Take a look at the switch it's being run with.
What do you think is the meaning of reinstall?