Allow generating Assembly Binding Redirects into specific project's app.config

[megafinz]

Description

I have a WPF Desktop Application which uses Prism and Ninject. There is main executable project and a bunch of class libraries that are loaded dynamically upon start (Ninject Modules).

One of those projects has a reference on Ninject.Extensions.Factory package, which has a reference on Castle.Core 3.2.0. I'd like to use the latest 3.x.x version, which is 3.3.3.

Obvious solution is to use assembly binding redirects. I can add them manually, but it appears that Paket can also deal with them.

Here's the problem. I might not be understanding binding redirection correctly, but anyway. CLR seems to process only those binding redirects that are specified in the main executable's app.config (which becomes AppName.exe.config upon build). Paket adds redirects to config files of the assemblies that use those specific packages that need redirection, and unfortunately those redirects are completely ignored by the runtime.

Repro steps

Here's small project that demonstrates the issue. Both projects are built into the same folder, and Ninject dynamically loads Ninject.Extensions.Factory.dll which is referenced by the second project. Binding redirection is turned on in the paket.dependencies, but it doesn't help. Manually adding binding redirect to main project's app.config fixes the issue.

BindingRedirectTest.zip

Expected behavior

I'd like Paket to be able to generate assembly binding redirects in a single specified project (which produces the main executable and whose app.config is used by CLR to process binding redirects). Or even in a list of specified projects in case solution has many executable-website-whatever projects.

Actual behavior

Paket generates assembly binding redirects in app.config's of all projects that reference the redirectable package directly or indirectly. In my case these binding redirects are useless since they are absent from the app.config of the executable.

Also Paket removes binding redirects that I added manually.

Known workarounds

Don't use redirect's in paket.dependencies at all and manually add them to app.config of the main executable.

[forki]

/cc @isaacabraham ?

[isaacabraham]

I think I've pointed this out in a previous issue. BRs only seem to get generated for projects that are directly referenced by the host app, not across the whole solution. The original implementation didn't have this problem IIRC because it just spat out redirects for everything, but the changes that were put in later (much smarter and more efficient) probably don't cater for this. @mrinaldi can you comment on this?

[mrinaldi]

@isaacabraham is right. It'll only generate BRs for referenced projects. This is the same behavior as the nuget client.
The workaround is to either reference the project/library or add the BR manually.

@megafinz you mentioned that Paket is removing the BR that was added manually, but my guess is that you just copied and pasted the BR from the other project.
You can do that, however, you must remove the <Paket>True</Paket> tag, otherwise Paket will indeed remove the BR.

[megafinz]

@mrinaldi Yes, you are right, I was copying BR as is, wasn't aware of the Paket tag effect. Without that tag BRs stay in App.config after running paket install, which is acceptable.

[isaacabraham]

@mrinaldi do you think it would be feasible for someone to have it walk the whole project dependency chain across projects to build a more complete list of BRs?

[mrinaldi]

IMHO, we shouldn't do that. I think we get a lot of noise putting the whole dependency chain in App.config, besides growing potential merge conflicts. Because it's not just the main executable that need the BRs, but also the unit test projects.
Since I believe @megafinz's scenario is uncommon, I think we should stick with manual BRs for dynamically loaded libs by default.
One feature that might be useful, though, is to have the option to turn that behavior on. Maybe a redirects: all flag to tell Paket to dump the whole dependency chain to App.config.
What are your thoughts?

[isaacabraham]

I think that'd be welcome, although your point about unit tests is interesting - that shouldn't impact on e.g. exe.config since the dependencies in the test projects wouldn't cross into the exe's tree?

[mrinaldi]

In fact, it does impact. How do you know which dependencies will go to exe.config and which won't, since everything can be dynamically loaded?

[isaacabraham]

Can't you know from understanding which projects are referenced by the "root" e.g. exe - and then looking at the paket.references?

[mrinaldi]

That's exactly the current behavior.
The scenario @megafinz described, the lib is dynamically loaded, rather than the root referencing the lib.

[isaacabraham]

Ahhhh. I misunderstood. In which case, yes - some explicit opt-in flag would be a nice-to-have IMHO.