What Exactly are Binding Redirects?
Binding Redirects are there to solve the issues of two libraries requiring different versions of the same assembly, as only one can be loaded. For example:
- Library A depends on v1.1 of Library C
- Library B depends on Library A
- Library B depends on v1.2 of Library C
So in this case, Library B wants to use v1.2 of Library C, but its dependency Library A expects v1.1. So NuGet will install v2 of Library C, and in order to reassure Library A that we can satisfy its dependency of Library C it adds a Binding Redirect to say “sorry we don’t have v1.1 of Library C, but we have v1.2 and that should be fine, and you should be good to use it in its place.”
The following binding redirect specifies this:
<dependentAssembly>
<assemblyIdentity name="LibraryC" … >
<bindingRedirect oldVersion="1.1.0.0" newVersion="1.2.0.0" />
</assemblyIdentity>
</dependentAssembly>
Of course, there is a risk here that v1.2 of Library C won’t be compatible with Library A, leading to errors at runtime, and that is something only the app developer can verify using all of those integration tests they remembered to write.
Keeping your binding redirects in order
Maintaining all of these binding redirects can become a bit of a problem if you have a large number of projects in your solution. Old redirects will stick around, as NuGet won’t automatically remove them due to the risk of those runtime errors that only testing can confirm.
I’ve found that they can cause headaches with source code merges if your team is maintaining multiple branches.
The NuGet package manager provides a cmdlet Add-BindingRedirect that will add all of the necessary binding redirects to a project, however, it won’t remove the old binding redirects that no longer apply.
The following PowerShell run in the Package Manager console will apply this:
PM> Get-Project -All | Add-BindingRedirect
No comments:
Post a Comment