管理多个解决方案的共享二进制依赖项

时间:2008-12-10 22:00:50

标签: c# winforms dependencies

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

我们的工作如下。

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

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倍)并占用大量磁盘空间。
  2. 我们喜欢这样的模型,其中每个解决方案都带有/ ext的本地子目录,所以我们永远不必更改项目引用,但这些似乎是竞争力。

    关于如何规范化下载的任何想法,所以我们不下载5倍的数据和相同的磁盘大小,而不必去手动更新项目引用,我必须在VS中为每个版本升级更改引用。

3 个答案:

答案 0 :(得分:1)

所有开发者机器中的结构如何?

像:

d:/项目
d:/ projects / ext(这里需要的共享库)
d:/项目/ PROJECT1
d:/项目/项目2
d:/项目/项目3
d:/项目/ project4
...

ps:我喜欢惯例。

答案 1 :(得分:1)

您可能需要查看DEVPATH

其他StackOverflow参考:Support for DEVPATH

答案 2 :(得分:0)

是否有reason未将共享程序集放入GAC