绑定重定向被添加到每个 app.config
Binding Redirect being added to every app.config
我在一个解决方案文件中有 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
的 nuget 包然后必须有这个新的 bindingRedirect 而在我们安装 Package A Helper
之前已经满足了主要依赖?
当我在 nuget 包中指定 3.0.0.0-5.0.0.0 和 package.config
时,为什么它说 0.0.0.0-5.0.0.0
更新:
当我使用 Package A
版本 5.0.0.0 构建 Package A helper
时,所有 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
实际上解决了我的问题,但我不明白为什么。
I had originally built it with 3.0.0.0 because I figured it was best ...
这就是问题开始的地方。您的解决方案现在取决于两个 个不同版本的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 足够兼容,那么 可以 工作。或者不是,主版本号的两个增量通常会带来麻烦。你测试一下就知道了。
So setting Copy Local in the reference properties to False actually solved my issues
这并没有解决问题,您只是阻止了构建系统假设它应该为您解决这个问题。由于它不再需要复制 DLL,它猜测您将在 GAC 中安装程序集,以便两个版本可以共存。也许你做到了,在开发机器上这样做并不常见而且通常是非常不明智的。考虑到额外的安装步骤,您的老板和团队成员不太可能会喜欢这个解决方案。
所以您可以做两件基本的事情:
让构建系统解决这个问题。正如它所做的那样,它正确地解决了问题,您的解决方案将起作用。如果版本 5 与版本 3 足够兼容,那么 A-helper.dll 中的代码甚至可以正确执行。如果老板不喜欢,那你当然得把这个划掉然后做:
将 A-helper 项目中的引用更改为 A 版本 5.0.0.0。现在不再有任何不兼容,唯一的 A.dll 对所有代码都有好处。鉴于您的要求,这是您老板唯一喜欢的解决方案。
我在一个解决方案文件中有 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
的 nuget 包然后必须有这个新的 bindingRedirect 而在我们安装 Package A Helper
之前已经满足了主要依赖?
当我在 nuget 包中指定 3.0.0.0-5.0.0.0 和 package.config
时,为什么它说 0.0.0.0-5.0.0.0更新:
当我使用 Package A
版本 5.0.0.0 构建 Package A helper
时,所有 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
实际上解决了我的问题,但我不明白为什么。
I had originally built it with 3.0.0.0 because I figured it was best ...
这就是问题开始的地方。您的解决方案现在取决于两个 个不同版本的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 足够兼容,那么 可以 工作。或者不是,主版本号的两个增量通常会带来麻烦。你测试一下就知道了。
So setting Copy Local in the reference properties to False actually solved my issues
这并没有解决问题,您只是阻止了构建系统假设它应该为您解决这个问题。由于它不再需要复制 DLL,它猜测您将在 GAC 中安装程序集,以便两个版本可以共存。也许你做到了,在开发机器上这样做并不常见而且通常是非常不明智的。考虑到额外的安装步骤,您的老板和团队成员不太可能会喜欢这个解决方案。
所以您可以做两件基本的事情:
让构建系统解决这个问题。正如它所做的那样,它正确地解决了问题,您的解决方案将起作用。如果版本 5 与版本 3 足够兼容,那么 A-helper.dll 中的代码甚至可以正确执行。如果老板不喜欢,那你当然得把这个划掉然后做:
将 A-helper 项目中的引用更改为 A 版本 5.0.0.0。现在不再有任何不兼容,唯一的 A.dll 对所有代码都有好处。鉴于您的要求,这是您老板唯一喜欢的解决方案。