绑定重定向被添加到每个app.config

Question

我在解决方案文件中有20个项目.其中1个项目是所有项目都参考的标准库项目.

大约一年前,我们添加了一个新的nuget包,我们称之为Package A5.0.0.0版.它有一堆文件,它们会在编译时全部转移,但我们最终处理它.我们将包添加到我们的标准库项目(另一个参考的那个).

我是Nuget的新手(所以也许我做错了)所以我做了一个新包作为帮助Package A.我已经设置了所有内容,以便帮助程序依赖于Package A版本3.0.0.0到5.0.0.0(因此它适用于版本低于我们的其他人).让我们称这个新包Package A helper

我安装Package A helper,一切正常.我去做拉取请求,现在我们的解决方案中的每个app.config都有

<runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
              <dependentAssembly>
                      <assemblyIdentity name="Package.A" publicKeyToken="8FC3CCAD86" culture="neutral"/>
                      <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0"/>
              </dependentAssembly>
      </assemblyBinding>
</runtime>

如果没有它,它将编译正常,但视觉工作室抱怨并发出警告.是什么赋予了？我的经理现在不会让我合并我的代码,因为它会给app.config增加太多噪音,并且过分依赖于Package A.

为什么Package A在我们安装之前已经满足主要依赖关系的时候添加依赖的nuget包必须拥有这个新的bindingRedirect Package A Helper？

当我在nuget包和package.config中指定3.0.0.0-5.0.0.0时,为什么会说0.0.0.0-5.0.0.0

更新:

当我Package A helper使用对Package A5.0.0.0版的引用构建时,所有bindingRedirects都不会在每个app.config中自动填充,而是生成警告.我最初用3.0.0.0构建它,因为我认为最好用最低的依赖构建它.问题仍然存在,因为visual studio仍然警告并建议创建bindingRedirects.

No way to resolve conflict between "Package A, Version=5.0.0.0, Culture=neutral, PublicKeyToken=83hfhsd33" and "Package A, Version=3.0.0.0, Culture=neutral, PublicKeyToken=83hfhsd33". Choosing "Package A, Version=5.0.0.0, Culture=neutral, PublicKeyToken=83hfhsd33" arbitrarily.
Consider app.config remapping of assembly "Package A, Culture=neutral, PublicKeyToken=83hfhsd33" from Version "3.0.0.0" [] to Version "5.0.0.0" [path to Package A dll] to solve conflict and get rid of warning.

解决方案只是将我的nuget包依赖从3.0.0.0改为5.0.0.0并且只允许5.0.0.0并摆脱我的allowedVersions="[3,6)"in me package.config ？我不想减少我的nuget包的有用性和向后兼容性,但同时我不希望我的主要解决方案需要警告或bindingRedirects.

更新2:因此设置Copy Local参考属性以False实际解决我的问题,但我不明白为什么.

Answer 1

我最初用 3.0.0.0 构建它，因为我认为它是最好的......

这就是问题开始的地方。您的解决方案现在取决于A.dll 的两个不同版本，一个将覆盖另一个。哪个版本的 A.dll 最终被复制到 bin\Debug 是随机的。无论最后建造什么项目。

这不能有好下场，解决方案注定无法执行。如果是 A-helper.dll 中的代码，当版本 5.0.0.0 最终被复制时，它将失败。或者它将是任何其他项目中使用 A.dll 的代码，当版本 3.0.0.0 被复制时它将失败。最终结果是解决方案总是失败。

所以你看到构建系统正在做一些事情。它注意到差异并选择其中一个版本获胜。它选择了 5.0.0.0，这是正确的选择。而且还修改的app.config，加入bindingRedirect所以要加载，要求为3.0.0.0版本代码实际上将获得5.0.0.0。如果您使版本 5 与版本 3 足够兼容，这可能会起作用。或者不，主要版本号的两个增量通常会带来麻烦。你考试的时候就知道了。

所以将参考属性中的 Copy Local 设置为 False 实际上解决了我的问题

这并没有解决问题，您只是阻止构建系统假设它应该为您解决这个问题。由于它不再需要复制 DLL，因此它猜测您将在 GAC 中安装程序集，以便两个版本可以共存。也许你这样做了，在开发机器上这样做并不常见，而且通常是非常不明智的。考虑到额外的安装步骤，您的老板和团队成员不太可能喜欢这个解决方案。

所以你可以做两件基本的事情：

• 让构建系统解决这个问题。正如它所做的那样，它正确地解决了问题，您的解决方案将起作用。如果版本 5 与版本 3 足够兼容，那么 A-helper.dll 中的代码甚至可以正确执行。如果老板不喜欢它，那么你当然必须从头开始做：

• 将 A-helper 项目中的引用更改为 A 版本 5.0.0.0。现在不再有任何不兼容，唯一的 A.dll 对所有代码都有好处。鉴于您的要求，这是您老板会喜欢的唯一解决方案。