Add-BindingRedirect, referencing strongly named assemblies, and NuGet docs

Topics: Ecosystem
Aug 11, 2012 at 9:10 PM


After giving my post that title, I'm sure only two other people in the world will be inclined to read this ;)

I was wondering what the current state of the art and recommendation is with regards to taking a dependency on packages that contain strongly signed dlls. I see a lot of confusion about this out there.

Note that this is esp. a problem for packages that use F#, as the F# runtime dll, FSharp.Core will get a new version (FSharp.Core 4.0 becomes 4.3 in VS2012). That means that any NuGet package that has a dependency on F# installed in VS2012 will most likely not work (as the project it is installed in references 4.3, but the installed package references 4.0). 

For a while now, NuGet has offered Add-BindingRedirect, which is great and fixes the problem.

However, there are a couple of issues.

1. says that Add-BindingRedirect, as of NuGet 1.2 is run automatically upon install. I can't reproduce this behavior with NuGet 2.0 in VS2012 RC.

2. By itself, this is not a big issue, as you can add the command in install.ps1 manually, e.g. as Daniel Mohl has done for FsUnit:

Does this work reliably, in particular if the project has not been built yet? The doc above again states that it looks at the output path, so I suspect it doesn't, although empirically it does seem to work. How? :)

3. Adding this manually to a package has a big downside: for it to really work, every package author that references strongly signed assemblies and every package author that produces strongly signed assemblies has to include this command in install.ps1. And example is a package I maintain, FsCheck.Xunit, which depends on XUnit. XUnit are strongly signed assemblies. Every time they are updated (which might happen any time after the install of the FsCheck.Xunit package), Add-BindingRedirect needs to be called. So it's not enough that I add this command to the install.ps1 of FsCheck.Xunit - the xunit folks would have to do the same. Clearly this doesn't scale. Any thoughts?



Aug 17, 2012 at 12:33 AM

Were you installing this package to a ClassLibrary? That's the only project type we do not add binding redirects to. They should be added on install otherwise. If you've a stable repro, feel free to create a work item for this.

Aug 17, 2012 at 2:22 AM

That's right. Test projects are an exception to the rule in that app.config files are picked up by most test runners, like, even though technically adding a bindingredirect to a dll makes no sense. Thanks for that - it makes sense. 

So what you're saying is that, since test projects are a special case, all test projects that are strongly signed or depend on strongly signed assemblies should run Add-BindingRedirect as part of their install.ps1, since NuGet won't do it automatically .