Tfs 在大型团队中共享公共库&；跟踪正在使用的库的版本

我属于使用TFS的.NET商店。在过去一年左右的时间里，我们一直在尝试在我们的团队（一些是本地的，一些是在完全不同的地区）之间分享和交流

到目前为止，我们已经将共享代码作为项目引用。随着对共享代码依赖性的增长，我们遇到了越来越多的问题（人们修改破坏其他应用程序的代码，将project更新为Visual Studio的新版本，等等）。因此，我倾向于让人们将代码作为编译二进制文件（DLL）引用。代码本身将由指定的团队进行维护和定期更新。源代码将以只读形式提供，以便人们可以进行更改/修补，并将其提交给所属团队进行审查和重新分发。你觉得这个计划怎么样？有更好的办法吗

我觉得这个计划的缺点是，我把一系列令人头痛的事情换成了另一系列。如果我有一个库的许多不同版本，我如何确定哪些版本正在使用，哪些版本没有？有没有办法通过TFS做到这一点？我相信，如果我们确切地知道正在使用什么版本，我们就可以知道我们在多大程度上需要担心向后兼容性，如果我们有问题，应该联系谁，等等

你们这些大团队的人是如何处理这件事的

将代码作为编译的二进制文件（DLL）引用

这是个好主意。在短期内，共享项目引用会让人感觉更容易，但这会让事情变得更困难，除非你有好的回归测试。即使如此，还是最好考虑共享库中的项目/产品。有一个专门用于可交付成果的积压工作和团队项目

我能确定哪些版本正在使用，哪些没有使用吗

我的第一个问题是，你为什么在乎？允许那些依赖共享库的用户在其特定时间和带宽允许的情况下升级和采用新版本。您可能需要使用项目/产品进行升级的主要原因是处理折旧的功能或规则。例如，您可能正在部署一个通用的崩溃报告库，该库降低了发送崩溃报告的机制，因为您现在需要HTTPS。旧版本将不再有效。在这种情况下，通信将是您的最佳选择，但您可以在TFS中找到的所有程序集上运行脚本以查看程序集版本。

如何确定正在使用哪些版本

有几件事：

• 在应用程序代码和库之间尽可能保持隔离。使用漂亮稳定的界面

• 让开发人员在进行本地工作/编译之前负责获取库的最新版本。个人责任是一件好事

• 在构建过程中担心接口。确保您的生成在生成之前获得库的最新版本。如果您的开发人员犯了一个错误，这一点在这里将变得显而易见

• 仅使用官方版本进行测试和发布。本地构建可以用于某些单元测试，但一旦您进行了集成，就应该只接受正式构建

---

我们在不同的团队中分发组件。如果必须在特定版本中更改方法或重载，我们将旧方法保留为

[过时（“消息”）]

，添加新方法，然后在下一个版本中删除不推荐的方法。这样，开发人员就有足够的时间使用新版本。

可能重复[在解决方案树之间共享项目的最佳实践（MSVS 2008和MSVS 2010）]（）问题的第二部分如何。。。跟踪使用了哪些版本的库？这是一个公平的问题。我已经把我的想法贴在下面了。回答得很好。我想你在最后两句话中说了“我为什么在乎”。。。真的只是为了方便沟通。如果我修复了库中的一个bug，我希望那些使用旧版本的人知道他们确实需要升级。正如我所说的，如果我知道某些功能没有被使用，我知道我可以完全删除它（而不是将其标记为过时，在这种情况下，这将是不必要的混乱）。是的，使用过时绝对是保持兼容的好方法。尽管如此，我觉得知道哪些项目正在使用什么库（以及什么版本）很重要，因为这将允许我们（更好地）提醒团队应该更新到包含重要修复的新库。另外，如果我们知道没有项目在使用某个方法，我们可以简单地删除它，而不是随着时间的推移而弃用它。@Giovanni Galbo，我们也有同样的问题。一些同事认为，我们应该维护一个程序集用户的纸质/excel列表。使用特定程序集的每个团队都应该在那里注册。通过这种方式，我们可以说哪些团队正在使用每个组件。这里也提出了相同的建议。但它似乎太过时了。。。我们是程序员，我们的整个人生目标就是自动化一切：）编写一个自动化脚本来运行每个TFS项目，以反映所有DLL，并在遇到共享库时记录一个版本号，这可能不会太糟糕。有人碰到过这样的事情吗？