【问题标题】:Managing shared binary dependencies for multiple solutions管理多个解决方案的共享二进制依赖项
【发布时间】:2010-11-22 23:21:20
【问题描述】:

好的,我们有很多解决方案,都有很多共享的二进制文件:

我们要做的是以下。

在共享驱动器中,我们有以下布局,其中每个二进制依赖项都有一个目录,每个版本都有一个子目录

BinaryDep1
------------挥发性
------------1.0
------------1.1
------------1.2

BinaryDep3
------------挥发性
------------1.0
------------1.1
------------2.2

BinaryDep3
------------挥发性
------------1.0
------------1.1
------------1.2

在我们的解决方案中,我们有一个 XML 文件,其中列出了所有依赖项和版本。我们有一个脚本,然后它会转到共享驱动器并将依赖项下载到名为 /ext 的解决方案的子文件夹中

这很好用,但有一些我们正在寻求改进的缺陷,我想得到人们的反馈。

  1. 我们有许多解决方案,因此如果它们都依赖于相同版本的二进制依赖项,那么我们每个解决方案都会获得一份副本(因为它应该是自包含的)。因此,如果我有 5 个都依赖于 Syncfusion 的解决方案,我会在我的桌面上获得 5 个 syncfusion 副本。这里的两个问题是 1) 下载时间慢(比我需要的多 5 倍)并且占用大量磁盘空间。

我们喜欢每个解决方案都有一个带有 /ext 的本地子目录的模型,因此我们永远不必更改项目引用,但这些似乎是相互竞争的力量。

关于如何规范下载的任何想法,因此我们无需下载 5 倍的数据和相同的磁盘大小,而无需手动更新项目引用,我必须在每次版本升级时更改 VS 中的引用。

【问题讨论】:

    标签: c# winforms dependencies


    【解决方案1】:

    所有开发人员机器中的相同结构怎么样?

    喜欢:

    d:/项目
    d:/projects/ext(这里需要的共享库)
    d:/projects/project1
    d:/projects/project2
    d:/projects/project3
    d:/projects/project4
    ...

    ps:我喜欢惯例。

    【讨论】:

      【解决方案2】:

      您可能想看看DEVPATH

      其他 * 参考:Support for DEVPATH

      【讨论】:

        【解决方案3】:

        是否有任何reason 不将共享程序集放入GAC

        【讨论】:

        • 我总是被告知要不惜一切代价避开 GAC