好的，我们有很多解决方案，都有很多共享的二进制文件：
我们要做的是以下。
在共享驱动器中，我们有以下布局，其中每个二进制依赖项都有一个目录，每个版本都有一个子目录
BinaryDep1
-----------易失性
-----------1.0
-----------1.1
-----------1.2
BinaryDep3
-----------易失性
-----------1.0
-----------1.1
-----------2.2
BinaryDep3
-----------易失性
-----------1.0
-----------1.1
-----------1.2
在我们的解决方案中，我们有一个 XML 文件，其中列出了所有依赖项和版本。我们有一个脚本，然后会转到共享驱动器并将依赖项下载到名为 /ext 的解决方案的子文件夹中
这工作得很好，但有一些我们正在寻求改进的缺陷，我想得到人们的反馈。
- 我们有很多解决方案，所以如果它们都依赖于相同版本的二进制依赖项，那么我们每个解决方案都会得到一个副本（因为它应该是自包含的）。因此，如果我有 5 个都依赖于 Syncfusion 的解决方案，我会在我的桌面上获得 5 个 syncfusion 副本。这里的两个问题是 1) 下载时间慢（比我需要的多 5 倍）并占用大量磁盘空间。
我们喜欢每个解决方案都有一个带有 /ext 的本地子目录的模型，因此我们永远不必更改项目引用，但这些似乎是相互竞争的力量。
关于如何规范下载的任何想法，因此我们无需下载 5 倍的数据和相同的磁盘大小，而无需手动更新项目引用，我必须在每次版本升级时更改 VS 中的引用。