4

Closed

Add ability to force adding assembly binding redirects for select assemblies in package

description

Currently when a package gets installed assembly binding redirects get added to config only if there are other assemblies in the application that were bound against an earlier version of the assembly in my package. However, an application using my package could be referencing my assembly's identity in other ways, most notably from config (e.g. registering custom config sections, specifying custom types, etc).

This request is about allowing me as the package author to specify a list of assemblies should always have assembly binding redirects added (either in the nuspec file or maybe via some other manifest file).

For example, say there's an MVC 3 application that has a ~/Views/web.config file that registers a RazorHost config section. I use NuGet to install MVC 4 into my application, which adds the latest versions of the assemblies into bin. However, my application doesn't work because at runtime it's trying to load the 3.0 section (as specified in config) but the loaded assembly is 4.0.
The easiest solution is to add an assembly binding redirect in the root web.config. It would be nice if NuGet would do that automatically.

Note 1: It would be impractical to scan the entire application (at least a Web Application) to try to smartly determine if there are any web.configs that are referencing assemblies in my package because there could be a large number of those config files to scan. Using a list would be a lot more efficient.

Note 2: For assemblies in my package that are not on my list we probably would still want NuGet to do the reference scanning just in case something is referencing that assembly.
Closed Jun 26, 2013 at 10:35 PM by dotnetjunky

comments

Haacked wrote Oct 25, 2011 at 10:36 PM

How impractical is #1 really? It would be nice if we could scan for config files with the <assemblies> node and treat those as assembly references when computing binding redirects. Maybe we only look in a set of common places that covers the 99% case?

If we add this as a nuspec metadata, could it be a single field that simply applies to all assemblies in the package. Such as "<includeBindingRedirects>true</includeBindingRedirects>.

Fowler, any thoughts on this?

marcind wrote Oct 25, 2011 at 11:49 PM

For #1 you'd have to essentially do a regex match search (and you got to make sure it's the correct regex) for every assembly in a package times every *.config file in the application (scannfing folders recursively to find them). You could be slightly quicker by only scanning well known locations, but that just means that config in other locations would still be broken.

Letting the package author specify the required bindings would help avoid the scans. Of course there's still the problem of the package author not knowing which of their assemblies might get referenced in config, but hopefullythey know their customers well enough to be able to list the most likely ones. In the edge case they could just list all of them.

Haacked wrote Oct 26, 2011 at 1:39 AM

Yeah, in talking it over we realized that it's not just <assemblies> sections, but custom config settings, etc. So do you have a proposal for the exact format? Should it be in nuspec or an additional file? I'd prefer to keep things in NuSpec so it's the one source of truth.

marcind wrote Oct 26, 2011 at 6:09 AM

Fowler seemed to prefer a new file (maybe to avoid confusing existing nuspec file parsers?). I don't care either way, though appending nuspec does seem to make sense. No ideas for a file format just yet.

JeffHandley wrote May 17, 2012 at 10:47 PM

Triage: Moving out of 2.0 into Soonish

davkean wrote Sep 19, 2012 at 11:59 PM

We (CLR team) would also like this feature for a package that we're working on where we are mixing versions within the package itself (not just package version to package version). It becomes more prevalent when you start seeing desktop referencing portable projects that maybe referencing an "older" version ofg the same binary that desktop is referencing. In this case, we always want binding redirects added.

This has become more an issue due to a bug that was introduced in VS2012 due to the out-of-proc MSBuild design changes. This bug prevents MSB3247 from being output to the Error List (it's display in the output log, but just never in the Error List). This was the warning that tells the user when they have assembly versions that conflict, and you could double-click it to auto-add binding redirects.

dotnetjunky wrote Mar 19, 2013 at 6:37 PM

There's an easy workaround for this: create a web.config.transform or app.config.transform which includes the binding redirect snippets that you want to add.

davkean wrote Mar 19, 2013 at 6:53 PM

That leads to other bugs; now NuGet binding redirects and the transforms are fighting each other.

NuGet's transform logic is also extremely limited, so you need to play tricks with fake namespaces to get them to insert the binding redirects correctly.

We originally went down this route of using transforms; but it led to so many problems that we've now moving away from this. Feel free to contact me offline with all the issues we encountered.

dotnetjunky wrote Mar 20, 2013 at 5:59 AM

Yes, I'm aware of the bugs with the transform engine where multiple elements in different parent elements are lumped into one parent element after the transform. I'll fix it.

Good point about the transform and binding redirect fighting each other :) I'll put this bug on 2.4 release.