NuGet downgrade issue

[GanesanRengasamy]

Hi Everyone,

I have installed the third party NuGet packages with the latest version and all the dependent NuGet packages are installed successfully and I have faced some issues in my project.

So, I have decided to downgrade the packages to the lowest version. I have tried to downgrade the packages to the lowest version in my WPF application. But the dependent packages are not downgrade to the lowest version. I think this is the NuGet package downgrade behavior (Please confirm is this behavior) and also, latest version dependent assemblies are binding in the App.Config file.

Then, I have downgrade the each dependent packages to the lowest version.

But in App.Config file the assembly binding redirection is not removed and not updated to the lowest version.

Is this right behavior in NuGet installation?
Is this issue from your side?
Could you please suggest me to resolve this since some of our customer based this issue?

Thanks,
Ganesan R.

[GanesanRengasamy]

Hi Everyone,

Could you please update the details regarding this ASAP.

[GanesanRengasamy]

Hi Everyone,

Could you please update the details regarding this ASAP.

[PatoBeltran]

Hey @GanesanRengasamy, if you are using the package manager UI in Visual Studio, you should be able to install an earlier version of a package and this should uninstall the previous one and install the new one.

As for the binding redirects, we currently have issues with the way we manage the lifecycle of the binding redirects (see #6870)... You should be able to remove the old binding redirects and when you install the new ones we should set the right ones if needed.

Let me know if this information helps solve your issues!

[GanesanRengasamy]

Hi @PatoBeltran,

Thanks for your response.

Yes I have tried to downgrade the packages to the lowest version from package manager UI. But, only the parent package downgraded and the dependent packages are not downgraded. I didn't understand why the dependent packages are not installed when downgraded and installed when update the packages to the latest version.

[zivkan]

@GanesanRengasamy sorry about the very late reply. If this is still an issue for you, can you please give more details, or a sample solution if possible. I don't understand what you mean, in particular the last sentence of your last comment.

[GanesanRengasamy]

Hi @zivkan

I am trying to downgrade the sample NuGet package from latest version to lowest (Previous) version. My sample package have the dependent NuGet packages with the same version of root NuGet package.

But my root package only downgraded to lowest version and the dependent packages are not downgraded to the lowest version. But as I have mentioned in screenshot dependent NuGet packages are binding in the App.Config file with the latest version.

For Ex:

Sample.2.1.1.nupkg (root NuGet) - This package has been downgraded to 1.1.1 version
Dependent1.2.1.1.nupkg
Depemdent2.2.1.1.nupkg
Dependent3.2.1.1.nupkg - These three packages not downgrade to 1.1.1 version. But binding in app.config file with the 2.1.1 version

Is this NuGet packages downgrade behavior?, please confirm me.

Then I have tried to downgrade the each dependent NuGet packages to lowest version (1.1.1) separately. All the dependent packages downgraded but, in app.config file the assembly version (2.1.1) is not changed to lowest version (1.1.1).

Is this right behavior in NuGet installation?
Is this issue from your side?
Could you please suggest me to resolve this since some of our customer based this issue?

Regards,
Ganesan R.

[StingyJack]

@GanesanRengasamy - what you are seeing is how NuGet always has behaved. While it does do a check to see if the package you are removing or any of its dependencies are needed by other packages, it does not remove dependencies when the only package that references those is removed (unless you check the box in the UI options).

This is probably your best option, as after you remove the 2.1.1 package with that box checked it will remove the dependencies. Then when you install the older version of the primary package (1.1.1), it should install the lower version dependencies along with it.

[zivkan]

@GanesanRengasamy, @StingyJack's answer is correct, this is how packages.config has always behaved and is therefore expected behaviour. The reason is that packages.config projects don't have the concept of direct vs transient dependencies. All NuGet dependencies are listed in a flat list.

Imagine one of your dependencies has a security vulnerability, so you update it to a fixed version. But later you downgrade a different package which also has a dependency on that first package. You don't want the package to be downgraded to the version with the security issue. Or if you directly use an API in a package that doesn't exist in older versions of the package, which is also a dependency of second package. If you downgrade the second package which lists the first as a dependency, your project will no longer compile if the downgrade also downgrades the first package.

In addition to the suggestion of using the "remove dependencies" option, if you're able to migrate to PackageReference, then you can add only your direct dependencies, and NuGet will automatically bring in transient dependencies. Therefore allowing you to downgrade your direct dependency and your transient dependencies will change version automatically. Since PackageReferences are in MSBuild, it also allows the possibility of defining a MSBuild property that has the value of the package version, so if you have a set of PackageReferences that should all use the same version of a package, they can all use the same MSBuild property in the version field, and then you change a single value to change the version of all packages using that property.

It should also reduce the binding redirect issues. With packages.config projects, NuGet modifies the app.config file with binding redirects on package install, or upgrade,. But there are issues when project references have different versions of the same nuget dependency. With PackageReference, binding redirects are calculated at build time, based on all the assemblies available after compilation, so that it can more accurately use the correct values.

As long as you're not affected by the limitations of package compatibility issues, I recommend migrating to PackageReference. It's also the only way to reference packages with SDK style projects.