Update-Package -reinstall -ProjectName <project> does not work for PR

[karann-msft]

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

[rrelyea]

@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?

[karann-msft]

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

[mishra14]

@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.

[karann-msft]

@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.

[mishra14]

@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?

[karann-msft]

Take a look at the switch it's being run with.
What do you think is the meaning of reinstall?

[rrelyea]

We need to determine what is the appropriate behavior for reinstall is in PR.

[nkolev92]

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.

[bchavez]

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.

[nkolev92]

@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.

[anangaur]

I need an option to re-download the package into Global packages directory. I am just thinking may be -Reinstall does that?

[nkolev92]

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.

[MichelZ]

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.

[joshmouch]

I'd like to use -Reinstall in order to automatically update the AssemblyBindings section of my app.config.

[nkolev92]

@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.

[joshmouch]

@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.

[nkolev92]

@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:
dotnet/announcements#31
https://stackoverflow.com/questions/46111749/adding-a-bindingredirect-to-a-net-standard-library

[joshmouch]

Unfortunately, the automatic binding is buggy and doesn't work on large projects.

[Bartolomeus-649]

@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....

[d4e666]

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.

[nkolev92]

@d4e666

What you are articulating sounds like it is related to packages.config.
This issue is talking about PackageReference.

[d4e666]

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.

[nkolev92]

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.

[dkattan]

This is extremely frustrating. I'm trying to get copies of certain DLLs into my output folder and this thread is the only documentation I can find that indicates Update-Package -reinstall doesn't work on .net core projects. The

I got here because this thread on StackOverflow states that it will copy the DLLs into the output folder, but it does not:

[nkolev92]

@dkattan PackageReference works differently from packages.config.

PackageReference is .NET Core projects is integrated with the build, and the files necessary will be copied to the output directory at build time.
You shouldn't need any other command.

If there are files that are not getting copied to the output, it's likely a different issue, or just how the package itself was authored.

[dkattan]

@dkattan PackageReference works differently from packages.config.

PackageReference is .NET Core projects is integrated with the build, and the files necessary will be copied to the output window at build time.
You shouldn't need any other command.

If there are files that are not getting copied to the output, it's likely a different issue, or just how the package itself was authored.

You are correct. Turns out the project I was loading had overloaded the Assembly.Load event and was doing some hacky stuff at runtime.

[nkolev92]

Please refer to #6088 (comment) and NuGet/docs.microsoft.com-nuget#2520