Repository navigation
Binding redirects filtering #1042
Description
Some of our projects reference Microsoft BCL Portability Pack NuGet (Indirectly but that's not the point) the problem is in the generation of the binding redirects.
redirects: on
Any project referencing this package will have this redirect generated :
<dependentAssembly>
<assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-999.999.999.999" newVersion="2.6.10.0" />
</dependentAssembly>Version 2.6.10.0 is the current version in silverlight and a few other platforms but our projects are all net40 or net45 and in theses there correct version is of a higher version number (The NuGet package contains no file at all in the corresponding folders)
So I think that Paket is either missing a way to disable redirects for one package or some way to tell it that he should trust the framework in the .csproj file (So he could generate only the required Reference and only the required redirects)
Activity
forki commentedon Sep 3, 2015
@isaac_abraham
isaacabraham commentedon Sep 3, 2015
I think that this is an outstanding issue that centers around basically we can't do binding redirects for different frameworks. The redirects code finds all strong-named assemblies in the nuget package, assumes that all framework version uses them, and that any assembly in the package is the same version across all frameworks.
Perhaps a (somewhat crude?) workaround would be the ability in the dependencies file to specify a redirect at a package level e.g.
An ever better solution would be to specify redirects per assembly but I don't think that that's quite a good fit for the dependencies file.
Krzysztof-Cieslak commentedon Sep 3, 2015
Use Group feature from
2.0and specify redirects per group?vbfox commentedon Sep 3, 2015
@isaacabraham :
Any feature allowing to disable redirects for one package only would be enough.
I wouldn't solve the problem but it would allow for an easy workaround.
For now I reverted the process, removing all bindings and generating the needed ones either by msbuild using
And doing it manually in the projects where it doesn't work (I don't know why sometimes it's ignored)
@Krzysztof-Cieslak :
if it's available at this level it would be another possible workaround (And could even work when both a SL and a net40 project reference this package by including them in different groups)
isaacabraham commentedon Sep 3, 2015
@Krzysztof-Cieslak That puts all the work on the user though. Definitely useful for targeting multiple versions but if I'm e.g. writing something that only targets a single framework I shouldn't need to create a group just for that.
forki commentedon Sep 17, 2015
http://fsprojects.github.io/Paket/nuget-dependencies.html#redirects-settings Paket 2.2.1 allows you to activate or deactive redirects per package.
vbfox commentedon Sep 17, 2015
Oh nice, it's a cleaner workaround than doing everything by hand, still not automatic but at least I won't need to author redirects by hand anymore, thanks.