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

Question

我在一个解决方案文件中有 20 个项目。其中 1 个项目是所有项目都引用的标准库项目。

大约一年前，我们添加了一个新的 nuget 包，我们将其命名为 Package A 版本 5.0.0.0。它有一堆文件，当我们编译时它会到处传输，但我们最终处理了它。我们将包添加到我们的标准库项目中（其他 19 个参考）。

我是 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>

没有它它会编译得很好，但 Visual Studio 会抱怨并给出警告。是什么赋予了？我的经理现在不让我合并我的代码，因为它在 app.config 中添加了太多的噪音并且过于依赖包 A。

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

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

更新：

当我构建 Package A helper 并引用 Package A 版本 5.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 并在我的 packages.config 中摆脱我的allowedVersions="[3,6)"？我不想降低我的 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 对所有代码都有好处。鉴于您的要求，这是您的老板会喜欢的唯一解决方案。