我创建了一个依赖于其他第三方程序集的程序集,这些程序集在添加程序集时可能会也可能不在项目引用中。因为我的程序集最初是使用可能比当前项目中的旧版本更旧的第三方依赖项构建的,所以我需要将bindingRedirects添加到app.config文件中。 Stack Overflow的一个伙伴(回答我的一个问题,关于是否有可能以某种方式自动化app.config文件所需的修改)建议我看看通过NuGet分发我的程序集。这结果是一个很好的建议,但我注意到一个奇怪的效果,我不知道如何纠正它,如果有的话。
在我的NuGet包的内容文件夹中,我有一个app.config.transform文件,表面上是这样的:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="C1.Win.C1Ribbon.2" culture="neutral" publicKeyToken="79882d576c6336da"/>
<bindingRedirect oldVersion="2.0.20141.567" newVersion="Add New Value Here"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
还有其他重定向,但这应该足以让你获得要点。
当我将NuGet包添加到项目中时,它会加载我的程序集并改变app.config文件,这是一个结果,但通常情况下,编程事情似乎从未进行过规划。
如果项目中已经存在我提供重定向的其中一个程序集,那么对我在NuGet程序包中提供的原始xml进行一些细微的更改:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="C1.Win.C1Ribbon.2" culture="neutral" publicKeyToken="79882d576c6336da" />
<bindingRedirect oldVersion="0.0.0.0-2.0.20142.582" newVersion="2.0.20142.582" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
您会注意到oldVersion已完全更改,newVersion已经过修改,以反映项目引用中程序集的当前版本。从我的观点来看,自动更改为newVersion是额外的奖励,因为它是最终用户不需要做的事情,但是对于旧版本的改变是完全的灾难,因为项目现在将编译时抛出错误。
如果在将nuget软件包添加到项目中时组件恰好存在,如何防止覆盖oldVersion详细信息?
答案 0 :(得分:2)
你真的在这里错误的轨道,那是&#34; oldVersion&#34;属性不是你问题的根源。你开始依赖别人的图书馆来解决麻烦。图书馆改变,这是不可避免的。而这样的改变可以并且迟早会打破你的程序。在这种情况下更快。
图书馆作者确实使用了很差的做法。版本号如&#34; 2.0.20142.582&#34;毫无意义。它是自动生成的版本号。您可以查看这样的数字,并且完全不知道库中的更改可能会有多大影响。关于版本号的常见抱怨和许多图书馆作者已经切换到语义版本控制。更简单的版本号:x.y.z。如果z的增量只是一个您不必担心的小维护增量。 y的增量使您注意,您阅读发行说明以了解是否需要修改或改进您自己的代码。 x的增量会带来很多麻烦。
Nuget软件包修补<bindingRedirect>
以尝试更改版本号而不会破坏您的程序。有些不可避免地,因为作者使用了这样一个糟糕的版本编号方案,他的bindingRedirect是没有意义的。他声称他的新库与所有以前版本的库兼容。你发现了一个完整的谎言。
您必须选择是否跳过此库更新。如果您没有,那么 来修复新版本导致的编译错误。关于它没有两种方法。 &#34; oldVersion&#34;属性无关紧要,您使程序与当前版本兼容。你也可以完全删除bindingRedirect,它没有意义。