Try our conversational search powered by Generative AI!
AI OnAI Off
Binding redirect overwiriting on installing nuget package
if I understand you correctly.. usually there is a reason why nuget package authors are setting min version for the dependencies packages. for me it looks like package requires "11.11.0.0" version of the framework, but your project is using only "11.10.5.0". am I correct? if it's so then I would recommend to upgrade your project to "11.11.0.0" if you really need to use that package.
Jan 12, 2019 22:03
"for me it looks like package requires "11.11.0.0" version of the framework, but your project is using only "11.10.5.0". am I correct?"
That is indeed the case.
Should the content of the global Web.config change after package import? Because that's happening now, when I import the package.
Original package content:
<dependentAssembly><assemblyIdentity name="EPiServer.Framework" publicKeyToken="8fe83dea738b45b7" culture="neutral" /><bindingRedirect oldVersion="0.0.0.0-12.0.0.0" newVersion="11.11.0.0" /></dependentAssembly>
changes automatically after package import to:
<dependentAssembly><assemblyIdentity name="EPiServer.Framework" publicKeyToken="8fe83dea738b45b7" culture="neutral" /><bindingRedirect oldVersion="0.0.0.0-11.10.5.0" newVersion="11.10.5.0" /></dependentAssembly>
So every time I import the package, I have to change this binging back to 0.0.0.0-12.0.0.0
I don't think this is the correct behavior. Or maybe it is?
Jan 14, 2019 11:40
for me it looks like package behaves exactly as it should. if you install 11.10.5.0 version -> it will make binding redirects from any version up to 11.10.5.0 to use exactly this version which is being installed - 11.10.5.0.
where did you get 0.0.0.0 - 12.0.0.0 binding? are you sure that on v12 release - Episerver will be able to fallback to 11.10.5.0?
for me - it just looks that your web.config is wrong.
Jan 14, 2019 12:04
The Package has dependancy set to 11.11.0.0.
I have the same dependancy installed in the main project, version 11.10.5.0. I manually set the range in bindings to 12.0.0.0 to include the dependancy from the package. All is well. I know for a fact, that the package will work with that version of the dependancy.
And I nave to set this every time I install the package.
Can I turn this manual bindings rewrite off? MSDN says that the automatic bindings redirect is not set in ASP projects. And somehow it is.
Jan 14, 2019 13:37
still I would say that package behaves by design and mix-match various version is left on your own risk :)
anyway - assembly redirect is part of the package and is executed during the install just to ensure that configuration is correct. check packages\EPiServer.Framework.AspNet.xxx\tools\AssemblyRedirects.ps1
Jan 14, 2019 14:39
I cannot share the code right now. But i am gratefull for your help.
I will try to post an update in case of a solution to this problem.
Jan 16, 2019 12:41
Hi All!
I am having a problem with automatic bindingRedirect overwriting, when installing nuget packages.
In most cases that behavior is expected, but in my case the problem is that the max value of the version range is decreased.
My main project has the following binding redirect:
<assemblyIdentity name="EPiServer.Framework" publicKeyToken="8fe83dea738b45b7" culture="neutral"/><bindingRedirect oldVersion="0.0.0.0-11.10.5.0" newVersion="11.10.5.0"/>And the nuget package i am installing has the following:
<assemblyIdentity name="EPiServer.Framework" publicKeyToken="8fe83dea738b45b7" culture="neutral" /><bindingRedirect oldVersion="0.0.0.0-11.11.0.0" newVersion="11.11.0.0" />As you can see the problem is that the minor version in the package is higher than the version in the consuming package, therefore it is out of the version range in that particular binding. That creates an error when starting the base project, about missing assemblies.
A fix for this is to correct the range of the versions in the binding in the consuming project after the nuget package installs. But that is cumbersome and I would not want to push that responsibility on the people that would use the nuget package.
So is there any way to mitigate this problem, without manually parsing the packages.config file in the nuget a1 script file?