我有一些不同的应用程序，我需要在它们之间共享代码以减少维护。我试图在stackoverflow和web上阅读很多，这是一个相当普遍的问题;我没有找到自己喜欢的答案。
我们的TFS分支结构是这样的。我们有三个分支开发，主要和生产。在开发分支上完成所有活动开发，当我们完成开发新功能时，我们将其与Main合并，然后再合并到生产中。生产分支始终是服务器上运行的代码。如果我们检测到在下一次迭代之前必须修复的错误。更改在main中完成，并在部署时与Production合并。需要共享代码的应用程序不共享共同的分支层次结构或共同的迭代计划。实际上，其中一个应用程序每年只进行一次1次迭代。 （我知道这与传统的做法略有不同。
在我的研究期间，我找到了一些不同的解决方案，但我遇到了所有问题。
二进制共享：我发现的一种常见方法是将已编译的二进制文件分支到开发分支下的文件夹中。我的问题是，如果我们在哪里检测必须快速修复的共享代码中的错误，则编译所讨论的代码。如果我们在哪里修复错误，我们将完成对共享代码库的所有更改。
项目共享：我的主要问题是如何以可接受的方式完成。我最初的想法是当新的迭代开始时，将主分支的更改与共享代码合并以更新它。将main与开发分支合并，以便通过错误修正更新开发分支。并将分享新的更新版本的共享代码放入开发分支。但据我所知，TFS不支持这一点，因为我会创建嵌套分支。
我的问题是：我如何在解决方案之间共享一些常见项目，同时保持它们孤立并能够修复主分支上的错误，而不必担心常见项目已经发生变化，从而引入新的错误。但仍然能够修复公共项目中的错误并将这些修复程序合并回共享的公共项目中。
我所做的是你所谓的'二进制共享'的版本。如果您可以将共享代码视为第三方项目，那么您可以应用与运行良好的第三方项目相同的开发规则。这意味着您应该专门对共享代码进行版本化（使用semVer或类似的东西），并尽可能保持向后兼容性。
是的，您是对的，这意味着如果您在共享代码中发现错误，则需要发布另一个版本，然后重新编译依赖于此代码的项目。
但是，这也意味着如果依赖于共享代码的两个项目中只有一个需要修复错误，那么只有该项目需要采用新版本。
另一个好处是，何时进行更新取决于项目。因此，您可以更自信地管理错误修复过程。
所以，要明确的是，我的建议是为共享代码创建一个新的TFS项目，给予你对第三方项目（它自己的构建，NuGet等）展示的所有爱，然后进行构建程序集到想要使用它的项目的库文件夹中。
希望这可以帮助。
虽然问题不尽相同，但我认为答案可能和this one一样。
感谢大家的帮助，因为有些人为我的最终解决方案做出了贡献，我选择发布我最终在这里做的事情。
我最终做的是二进制共享和代码共享
对于经常更新且迭代速度相对较快的项目，我引用了我需要的共享项目并创建了项目指南，以确保代码在特定时间内向后兼容。
对于更新频率较低的项目，我在已编译的二进制文件中分支。我还创建了共享项目的版本并创建了指南，以确保任何向后兼容性冲突的代码导致版本号的主要组件的增量。