Hi Rick,

I also had this problem and spent a few hours resolving it.

This nuget command would've sorted it in no time. And, now I know how ;-)

Thanks for posting.

So why isn't this just automatically done? Is there any reason why you wouldn't want this?

@Clay - NuGet only works off a single package and updates redirects only for that single package, it doesn't look at all of the dependencies when it installs individual packages. This command looks at the whole project/solution and looks at all assembly references. I think the reason it doesn't happen on everything is that this can also potentially break stuff if you explicitly set assembly redirects or if you want to stick with a particular verions for a given assembly.

Is there a command line version of this?
I use this command to update packages in my solution, but found that binding redirects in web.config / app.config files are not updated as it would be when updating in VS Package Manager Console
"nuget update mySolution.sln"

To update all projects use an asterisk Add-BindingRedirect *

Echoing @bloumoord. Is there a way to do this outside the package manager console? It would fix a lot of issues for us if we could run this as part of our CI (Jenkins pipeline).

I actually love you Rick. Thank you for this. Still very handy in 2017 to fix the rats nest of dependency mess my web.config had built up.

Any way to add in assemblies to app.config that are not already present?

I'm guessing this only works for existing dependentAssembly elements in the runtime section of the web.config. The problem is: I have no idea how those dependentAssembly elements end up there as I've started a fresh MVC project, it has some already in there (presumably in the project type template) but then adding a new NuGet package which does have redirectability (e.g. iTextSharp) does nothing to the file, neither does "Restore NuGet Packages", neither does a complete rebuild and neither does this Package Manager script. Where on earth do these elements come from?

I was expecting to see this appear in the runtime section when installing iTextSharp and disappear when uninstalling it (or running the above script since that doesn't work).

<dependentAssembly>
	<assemblyIdentity name="itextsharp" publicKeyToken="8354ae6d2174ddca" culture="neutral" />
	<bindingRedirect oldVersion="0.0.0.0-5.5.9.0" newVersion="5.5.9.0" />
</dependentAssembly>

I've seen it in another project which has worked and no one in our team has written it.

I've reference this page and used this command a lot. Thanks so much for posting this and keep it up!

You know, I've probably stumbled on your site about 3 times over the last 10 years, and each time has been a huge value add.

Thank you for writing!

Running this gave me this error:

Add-BindingRedirect : Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401) At line:1 char:20

Get-Project -all | Add-BindingRedirect
CategoryInfo : NotSpecified: (:) [Add-BindingRedirect], FileLoadException
FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.AddBindingRedirectCommand

To solve this:

I was facing the same issue when attempting to run this command, but managed to run it by creating the DWORD variable LoaderOptimization with 1 for value under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework, then restarting Visual Studio and running the command in the Package Manager Console again.

source: https://stackoverflow.com/questions/76049195/add-bindingredirect-loading-this-assembly-would-produce-a-different-grant-set