vor*_*rou 13 .net msbuild nuget
项目A使用log4net 1.2.13.0,并依赖于库B,它使用log4net 1.2.11.0.如果我这样做Package Manager Console> Add-BindingRedirect,我得到一个正确的绑定重定向app.config:
<dependentAssembly>
<assemblyIdentity name="log4net" publicKeyToken="669e0ddf0bb1aa2a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-1.2.13.0" newVersion="1.2.13.0" />
</dependentAssembly>
Run Code Online (Sandbox Code Playgroud)
我认为这个是必需的,以便完成构建.但是构建成功也没有重定向.这是我在构建日志中看到的(详细程度设置为详细):
统一主要参考"log4net,Version = 1.2.13.0,Culture = neutral,PublicKeyToken = 669e0ddf0bb1aa2a".在"C:\ Users\vorou\code\ConsoleApplication1\packages\LibraryB.dll"中使用此版本而不是原始版本"1.2.11.0",因为AutoUnify为"true".
什么是AutoUnify的全部?哪个更好,即在.config中有明确的重定向是否有任何优势?
此外,我记得,在某些情况下,您需要添加绑定重定向.否则应用程序将在运行时爆炸.这些案件是什么以及为什么这种AutoUnify魔法对他们不起作用?
UPD这是MSDN关于以下内容的摘录AutoUnify:
此参数用于构建程序集,例如DLL,它们不能具有正常的App.Config文件.如果为true,则会自动将生成的依赖关系图视为传递给AppConfigFile参数的App.Config文件.此虚拟App.Config文件具有每个冲突的程序集集的bindingRedirect条目,以便选择最高版本程序集.这样做的结果是永远不会有关于冲突组件的警告,因为每个冲突都将得到解决.
看起来.config中的重定向在我的情况下不起任何作用.问题是库B无法满足它的依赖性,并AutoUnify通过"假装有绑定重定向"规则来解决它.
Han*_*ant 26
版本控制是一个很大的话题,不能在单个SO帖子中做到公正.所以突破速度:
当您使用多个Nuget包并且它们具有共同的依赖关系时,这些类型的恶作剧是必需的.像log4net或NewtonSoft.Json一样,非常常见的库没有将程序集放在GAC中的安装程序.
问题是,每个Nuget包很可能使用这些核心支持库的不同版本构建.而且这样的软件包不太可能得到足够的更新来保持当前的最新版本,软件包作者喜欢他测试代码的版本.所以你很容易在你的构建目录中找到一个程序集,要求1.2.11.0和另一个要求1.2.13.0的程序集
那不行.CLR在加载程序集时坚持确切的版本匹配.并且必须从构建目录加载它,并且不能依赖GAC来提供它们.只能有一个DLL副本,其中一个软件包库不可避免地会出错版本,程序将崩溃.不好,你有一个问题,如果没有重建Nuget包,你无法解决.
这就是绑定重定向解决的问题.它只在运行时产生影响,而不是构建时间.它告诉CLR,"如果它要求1.2.11.0然后只是加载1.2.13.0.或者更普遍的是这个特定的绑定重定向:"如果它要求任何小于1.2.13.0的版本".问题解决了,不再崩溃了手指越过那个包仍然适用于那个更新的版本.当只有版本号不同时,它们通常都会这样做.但是没有硬保证.
另一件需要决定的事情是,这是在构建时发生的,应该选择哪个特定版本的库.你想要1.2.11.0还是1.2.13.0?这就是AutoUnify所做的.没有什么比这更复杂,它选择更高版本.
| 归档时间: |
|
| 查看次数: |
3236 次 |
| 最近记录: |