1

我有：

  • 共享功能库 [A]
  • 另一个引用 A [A1] 的 v1 的库 [B]

我当前的 Visual Studio 解决方案有：

  • A dll [L]，（文件）引用 B
  • 一个 WindowsService [S]，它（项目）引用 L 并且还具有对 A 的更新但向后兼容的版本 [A2] 的文件引用。

当我在 Visual Studio 中构建解决方案时，一切正常。S 的 bin 文件夹包含 L、B 和 A2（与 B 兼容，因此效果很好）。

但是，如果我使用 MSBuild（通过 TeamBuild）进行构建，最终的构建文件夹会以 L、B 和 A1 结尾。A1 没有 S 需要的库 A 的新特性，所以当你尝试运行它时，S 会掉下来。

我已经阅读了一些内容，表明这与被 MSBuild 忽略的 .sln 的构建顺序有关。

正如我所料，我发现 L 的 bin 目录包含 B 和 A1，因为其中没有任何对 A2 的引用。因此，大概当 MSBuild 构建了 L（本地拉入 B 和 A1）和 S（拉入 L 和 A2）时，它必须将所有二进制文件合并到构建的最终输出中。我不明白是什么让它选择A1（来自L bin）而不是A2（来自S bin）？

我很感激没有什么可以说它应该是相反的，但我只是不知道 MSBuild 使用什么标准来进行这个调用。

任何人都可以对此有所了解吗？

4

1 回答 1

0

汤姆teambuild中msbuild的工作方式是所有项目的所有输出dll都放在输出目录中。此输出目录为解决方案中的所有项目共享。因此，如果您有相同 dll 的不同版本，它们将相互覆盖。

解决此问题的方法是使用此类项目的子目录 $(Outdir)\SpecificDir 或使用版本标记重命名 dll，即 A.1.0.dll 和 A.dll

于 2013-02-05T10:15:58.707 回答