管理内部第 3 方依赖项
我们有很多不同的解决方案/项目，由不同的团队管理。我们的解决方案需要引用另一个团队拥有的几个项目。我们不想将这些依赖项添加为项目引用，因为我们不打算修改该代码，我们只是想使用它。此外，我们的解决方案中已经有相当多的项目，并且不想添加更多项目，因为它会减慢 Visual Studio 的速度。因此，我们在单独的解决方案中构建这些项目，并将它们作为文件引用添加到我们的解决方案中。
我的问题是，人们如何管理这些类型的依赖关系？我是否应该有一些自动化流程来查找这些项目的更改，构建它们并将 dll 检查到我们的源代码管理中，然后我们像其他第 3 方依赖项一样对待它们？有推荐的方法吗？
We have a lot of different solutions/projects which are managed by different teams. Our solution needs to reference several projects that another team owns. We don't want to add these dependencies as project references because we do not intend on modifying that code, we just want to use it. Also we already have quite a bit of projects in our solution and don't want to add a bunch more since it will slow down Visual Studio. So we are building these projects in a separate solution and adding them as file references to our solution.
My question is, how do people manage these types of dependencies? Should I just have some automated process what looks for changes to those projects, builds them and checks the dlls into our source control, after which we treat them like other 3rd party dependencies? Is there a recommended way of doing this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一种解决方案（尽管不一定是您正在寻找的解决方案）是让每个依赖的子系统执行发布。此版本可以采用 MSI 安装的形式，或者只是程序集的网络共享。当进行重大更改时，该团队可能会通知您，并且您可以运行安装或脚本来复制文件。
获得版本后，您可以将它们放入 GAC 中，这样您就不必担心将它们复制到项目 bin 文件夹中。
假设您正在使用构建服务器或某种持续集成，另一种解决方案是进行构建后步骤或处理文件。在任何特定时刻，其他团队的开发人员都可以获取新文件，或者使用脚本或 bat 文件将它们拉到本地。
编辑-另一个解决方案
最好问一下为什么会有这些依赖关系？在构建您的应用程序部分时，您真的需要在本地使用它们吗？您能否模拟解决方案中的依赖关系，从而允许您编码、构建和运行单元测试？实际应用程序会将这些连接到您的开发/测试/生产环境中。对于单个团队来说，保持解决方案解耦且无依赖可能是更好的解决方案。当应用程序在实际环境中运行时，保留集成和耦合。
One solution, although it may not necessarily be what you are looking for, is to have each dependent sub-system perform a release. This release could be in the form of a MSI install, or just a network share of assemblies. When a significant change is made, that team could let you know, and you could run the install or a script to copy the files.
Once you got the release, you could put them into the GAC, that way you would not have to worry about copying them to your project bin folders.
Another solution, assuming you are using a build server or continuous integration of some kind, is to have a post build step or process stage the files. Than at any given moment, the developers of the other teams could grab the new files , or have a script or bat file pull them down locally.
EDIT - ANOTHER SOLUTION
It might be best to ask why do you have these dependencies? Do you really need them locally when building your part of the application? Could you mock out the dependencies in your solution, allowing you to code, build, and run unit tests? The the actual application would wire these up in your DEV/Test/Prod environments. Keeping your solution decoupled and dependent free may be a better solution for the individual team. Leave the integration and coupling when the application runs in a real setting.
（不是一个完整答案，但仍然是：）
任何交付都最好存储在文件/二进制存储库中，而不是用于管理源历史记录的 VCS。
我们更喜欢在 Nexus 这样的存储库中管理这些交付，并且我们使用 < strong>maven 获取正确的依赖项。
即使这些工具可以更加面向 Java，Nexus 也可以存储任何内容，而 maven 仅用于读取每个工件的 pom.xml 并计算正确的依赖关系。
(Not a complete answer, but still:)
Any delivery is better stored in a file/binary repository, as opposed to a VCS used to manage sources history.
We prefer managing those deliveries in a repo like Nexus, and we are using maven to get back the right dependencies.
Even if those tools can be more Java-oriented, Nexus can store anything, and maven is only there to read the
pom.xmlof each artifact and compute the right dependencies.