Home: Users should be able to specify CopyLocal property for the references

[feiling]

Currently, when NuGet adds the reference to a dll in a package, it always sets the CopyLocal property of the reference to true. There are cases when users want to set CopyLocal to false for certain references. The only they can do this today is thru install.ps1.

We need to support this natively. A user should be able to specify the CopyLocal property for any references that will be added by NuGet.

[yishaigalatzer]

min version 2.8.6 and 3.0 support as well.

[yishaigalatzer]

CC @davidfowl

Moving out from the current releases for now, until we get a strong need for this feature

[jainaashish]

There is not much attraction from community for this feature besides our focus has been on other stuffs like performance, Integration in MSBuild with PackageReference, etc... so we don't see getting to this in near future.

[rhyous]

I see that #6553 is very similar to this one.

However, I am not sure they are the same. The ability to choose the value on install would be a nice feature enhancement. Erasing an already chosen value on upgrade is a bug and an unexpected change.

The problem is that values we've chosen are being removed by what the UI is stating is an Update. It is quite ubiquitous in the industry to persist settings on upgrade.

Choosing the feature on install requires adding new parameters to NuGet.exe, etc, and setting the value after install. Testing those parameters, etc. Yes, choosing the value would help. But that is not what bug #6553 is asking for. We have already chosen the values on our projects. So even the solution for these two bugs require different work loads.

This may not change the priority, and this bug still might not get worked on, but I would appreciate it if I could share my observations.

Observation 1 - Upgrade is not an Upgrade

I have detected a fundamental flaw in the NuGet.exe update design and fixing that flaw might be more desired.

The problem is actually how NuGet.exe upgrades the .csproj file. The "upgrade" isn't actually and upgrade. NuGet.exe uninstalls the dependency first, then it installs the new dependency as if the old version were never installed. A complete uninstall and then a new install is not an upgrade.

Now there is a user experience bug, because both the NuGet.exe update parameter and the VS UI claim that NuGet.exe supports upgrade. Which it does not. Update is a tenuous claim at best.

So perhaps NuGet.exe should only replace the Xml attributes.

    <Reference Include="Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
      <HintPath>..\..\packages\Newtonsoft.Json.10.0.3\lib\net45\Newtonsoft.Json.dll</HintPath>
      <Private>False</Private>
    </Reference>

Perhaps, instead of removing the reference altogether, and update should only do the following:

• Replace the include in the Reference element.
• Replace the element.

Of course, I trust the method the NuGet team decides to solve this. It doesn't have to be the suggested solution I mention above.

Observation 2 - This effects EmbedInteropTypes and custom HintPaths as well

NuGet.exe also has this issue with EmbedInteropTypes and additional HintPath settings as well.

So two additional settings are also lost on upgrade. There are users that use those two setting as well, so that should increase the priority.

Observation 3 - The uninstall and reinstall is a performance issue

I have to wait some significant time when I update a NuGet package that is installed on 100+ projects.
It is actually faster for me to find all *.csproj files. Select All. Then deselect one by one the ones that shouldn't have copy local set to false. Then open the selected ones in Notepad++. Run Find and replace on the Xml element in All open files. Then do the same for the packages.config.

It was actually while doing a manual NuGet package upgrade for the dozenth time that I thought I'd submit this bug.

Observation 4 - The previous three observations are solved by a true upgrade

Uninstall and Install were implemented in NuGet.exe. Upgrade appears to have been implement by doing what to any novice install builder would do: Calling Uninstall. Then calling Install. Understanding that upgrade needs a separate implementation is something all installers come to realize as they mature. And NuGet.exe is very mature in most other areas. It is probably time for it to mature in Upgrade as well.

So now that we have established that NuGet.exe doesn't have a true update even though it claims it does, we can see that these bugs are actually side effects of this architectural design choice.

• Why are a dll reference's property settings not not persisted? Because of the NuGet.exe upgrade implementation.
• Why is there a performance issue on upgrade? Because of the NuGet.exe upgrade implementation. It takes much longer to uninstall and reinstall.

Would you like me to submit bugs on the lack of a true upgrade? On the upgrade performance issue?

Thank you

Thank you for taking time to read my observations. Also, thank you for NuGet.exe. I know NuGet.exe is an open source project and is a feature I am not paying for. Yet, I get extreme benefit from NuGet.exe. I know that most of what is heard here are problems. But NuGet.exe is working in most areas quite well and is one of the best things to happen to .Net programming ever.

[StingyJack]

A complete uninstall and then a new install is not an upgrade. - @rhyous

This is arguable for most cases...

• Upgrading a CPU from a Pentium 133 to a 233.
• Upgrading from Windows 7 to Windows 10
• Upgrading your auto from a BMW to a Toyota
• Upgrading MSI packages that involve changes to the Major or Minor version

... but I agree that settings and changes made after the first installation should be preserved when possible.