如何跨多个.NET项目管理常见DLL的版本控制？

Question

遵循SO线程显示Managing DLL references in multiple projects across different solutions。另外，我想知道如何管理这些依赖项DLL的版本控制？

每次代码更改发生时，是否应该提交DLL（发布到其他外部项目）？

Answer 1

Team Development with TFS Guide (Final Release)

本指南已被证明对我的团队非常宝贵。他们描述了几种情景以及每种情景的利弊。对于管理TFS环境的任何人来说，这是必读的。

关于来自外部项目的DLL。如果我们可以访问源代码，我们将在TFS中保留源代码的副本，并使用您的最佳判断。我们始终在源代码管理中保留DLL的副本。 DLL进入源代码旁边的“SharedBinaries”文件夹，以便它们可以分支在一起。

至关重要的是，您可以将这些DLL与源一起分支。它们在TFS中也很重要，这样您就可以在很少或没有构建机器配置的情况下进行自动构建。管理TFS时我自己的个人目标是为新开发人员加入团队做好准备，只需一次源代码就可以执行本地调试的成功构建。

编辑：不同的部门构建DLL

像所有优秀的IT答案一样，我必须从“它取决于”开始。如果其他部门真正与您的部门隔离，并且您很少或根本不知道他们正在做什么或何时将其工作。如果他们偶尔会告诉你他们已经完成了一些事情，你现在应该合并这些更改，那么每当消费它的部门想要更改它时，我会倾向于将DLL提交到存储库。

另一方面，如果我们真的只是在谈论同一部门的不同团队，那里有很多串扰和水冷却器沟通，那么我希望你可以用一些项目参考来制作别的东西。

听起来我觉得这是前者而不是你今天发现的后一种情况。我会尝试让创建共享代码的部门“释放”共享代码，如Microsoft发布.NET Framework。让他们只是构建API并给你一些DLL和一些文档。然后将那些DLL合并到那里的产品组可以将它们单独检查到自己控件的存储库中，并将自己与代码流失隔离开，而处理这些重用DLL的部门可以处理它们的下一个版本。

你应该把这一切都带上一粒盐。这只是一个人讨论什么可能是一个好主意。有许多方法可以解决这些问题，并且在不同情况下它们都是正确的。如果你问5个人，你得到5个不同的回答，我不会感到惊讶。