我们有很多不同的解决方案/项目，由不同的团队管理。我们的解决方案需要引用另一个团队拥有的几个项目。我们不想将这些依赖项添加为项目引用，因为我们不打算修改该代码，我们只想使用它。此外，我们的解决方案中已经有相当多的项目，并且不想添加更多项目，因为它会减慢 Visual Studio。因此，我们在单独的解决方案中构建这些项目，并将它们作为文件引用添加到我们的解决方案中。
我的问题是，人们如何管理这些类型的依赖关系？我是否应该有一些自动化过程来查找对这些项目的更改，构建它们并将 dll 检查到我们的源代码控制中，然后我们将它们视为其他 3rd 方依赖项？有推荐的方法吗？
一种解决方案，虽然它可能不一定是您正在寻找的，是让每个相关的子系统执行一个发布。此版本可以采用 MSI 安装的形式，或者只是程序集的网络共享。当进行重大更改时，该团队可以通知您，您可以运行安装或脚本来复制文件。
获得版本后，您可以将它们放入 GAC，这样您就不必担心将它们复制到您的项目 bin 文件夹中。
另一个解决方案，假设您正在使用构建服务器或某种持续集成，是对文件进行后期构建步骤或处理阶段。与任何时候相比，其他团队的开发人员可以抓取新文件，或者让脚本或 bat 文件在本地下载它们。
编辑-另一种解决方案最好问一下为什么会有这些依赖项？在构建应用程序的一部分时，您真的需要它们吗？你能模拟出解决方案中的依赖关系，允许你编写代码、构建和运行单元测试吗？实际的应用程序会将这些连接到您的 DEV/Test/Prod 环境中。使您的解决方案保持解耦和无依赖可能是单个团队更好的解决方案。当应用程序在真实环境中运行时，留下集成和耦合。