Question

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

大约一年前，我们添加了一个新的nuget包，我们称之为Package A版本5.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增加了太多的噪音，并且过分依赖于套餐A.

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

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

更新

当我使用Package A helper版本5.0.0.0的引用构建Package A时，所有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对所有代码都有好处。根据您的要求，这是您老板喜欢的唯一解决方案。

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

1 个答案: