Home: Add support for Removing BindingRedirects

[holytshirt]

Currently from the Package Manager Console you can run Add-BindingRedirect to add missing bindings. The management of bindings is a bit rubbish, as is only adds and sometimes updates, never seems to delete. This is fine for small projects, I find in large solutions my workflow ends up like this.

1. Update nuget packages
2. Manually delete all assembly bindings sections from all app.configs and web.configs. (I have a script now)
3. Run Get-Project –All | Add-BindingRedirect via the Package Manager Console.

Would be great to have Remove-BindingRedirect available then I could just do this

Get-Project –All | Remove-BindingRedirect
Get-Project –All | Add-BindingRedirect

Thanks
Toby

[nkolev92]

@holytshirt
Is there a scenario where update gets the binding redirects wrong?

Why do you need to remove all binding redirects first and then add them again?

[StingyJack]

It leaves them around even when packages are removed. It's another _thing to manage_.

[holytshirt]

When some packages are remove, the redirects are not removed and you have
to manually remove them. In large solutions with many projects it is a pain.

On 15 Nov 2017 16:31, "Nikolche Kolev" [e-mail] wrote:

@holytshirt https://github.com/holytshirt
Is there a scenario where update gets the binding redirects wrong?

Why do you need to remove all binding redirects?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NuGet/Home/issues/6187#issuecomment-344775772, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAFgFM4FkCUB7D-ARSlB7SnbBbM3wE_dks5s24JwgaJpZM4Qe0aL
.

[begrs]

We have the same issue in our large solution system. Here is our process in probably more detail than necessary, but its otherwise hard to get a picture why we run into this issue frequently.

We use an internal nuget package repository and have built our Process like this: A -> B -> C,D where C and D are Web Projects(front-end) which are not nuget packages themselves. (Note: C and D also reference A nugets directly).
There are also several really small nuget packages beside A that are also referenced by B, lets call them X.
The small projects X are updated infrequently but A and B contain core functionallity and are updated daily.
Scenario:
Some project of X is modified - e.g. some project containing utiltiy functionallity. It is referenced in A, B, C and D.
Now if we update the version just in the front-ends C and D (e.g. because we need the new functionallity right now) we get binding-redirects since nuget detects that they are necessary -> great!
However, at the end of the day some code changes in A and/or B. Now we update the packages A and B in the projects C and D.
Result: the binding redirects are not needed anymore so nuget wont update their version in the app.config/Web.config files. Sadly, nuget wont delete the old bindings either, as @holytshirt described it.
This leaves those bindings as "corpses" until the project of X gets updated independently of A and B again. Until that happens it will always bind to the old version - the compiler will not use it so there is no actual exception, but it generates a Warning. (Big solution so possibly alot of unnecessary warnings which fog the build log for important errors/warnings a developer should not overlook)

(In addition, if this happens to a lot of projects in X our app.config/web.config files get really confusing to read as any one of those solutions possibly contain more than one project and thus deploy more than one nuget package with the same version. Spotting actual errors in assembly bindings - e.g. some of the manually added once - becomes very confusing and time-consuming.)

It would be nice if nuget could track which binding redirects were generated automatically so it can remove them once they are no longer needed.
If that is not possible the proposed Remove-BindingRedirect would be a great help in automating the clean up of the old bindings.

[Hambo67]

Waiting for this exact functionality for some time. I am keen to see this added.

[StingyJack]

@heng-liu what does pipeline:icebox mean?

Hopefully it means it's so cool it's got to be next.

[nkolev92]

@StingyJack

The link I am providing is a design (so the implementation differed a bit), but it has the right gist.
https://github.com/NuGet/Home/blob/dev/designs/ClientDevProcess.md#icebox