管理内部第三方依赖关系

Question

我们有很多不同的解决方案/项目，由不同的团队管理。我们的解决方案需要参考另一个团队拥有的几个项目。我们不希望将这些依赖项添加为项目引用，因为我们不打算修改该代码，我们只想使用它。此外，我们的解决方案中已经有相当多的项目，并且不想添加更多项目，因为它会降低Visual Studio的速度。因此，我们将在单独的解决方案中构建这些项目，并将它们作为文件引用添加到我们的解决方案中。

我的问题是，人们如何管理这些类型的依赖关系？我是否应该只有一些自动化流程来查找这些项目的更改，构建它们并将dll检查到我们的源代码控制中，之后我们将它们视为其他第三方依赖项？有推荐的方法吗？

Answer 1

（^{不是完整的答案，但仍然是：}）
任何交付都最好存储在文件/二进制存储库中，而不是用于管理源历史记录的VCS。

我们更喜欢在 Nexus 等回购中管理这些投放，我们正在使用 maven 来恢复正确的依赖关系。 /> 即使这些工具可以更加面向Java，Nexus也可以存储任何内容，而maven只是在那里读取每个工件的pom.xml并计算正确的依赖关系。

Answer 2

一种解决方案，虽然它可能不一定是您正在寻找的，但是让每个从属子系统执行发布。此版本可以是MSI安装的形式，也可以是组件的网络共享。当进行重大更改时，该团队可以通知您，您可以运行安装或脚本来复制文件。

获得发布后，您可以将它们放入GAC，这样您就不必担心将它们复制到项目bin文件夹中。

假设您正在使用构建服务器或某种类型的持续集成，另一种解决方案是在文件的后期构建步骤或流程阶段。在任何特定时刻，其他团队的开发人员都可以获取新文件，或者让脚本或bat文件在本地拉下来。

编辑 - 另一种解决方案 最好问一下为什么你有这些依赖？在构建应用程序的一部分时，您是否真的需要它们？你能模拟解决方案中的依赖关系，允许你编码，构建和运行单元测试吗？实际的应用程序会将它们连接到您的DEV / Test / Prod环境中。保持解决方案解耦和依赖免费可能是个人团队的更好解决方案。当应用程序在实际设置中运行时，保留集成和耦合。