我们公司有很多解决方案。他们中的大多数都使用一组用于不同功能（日志记录、缓存、数据访问）的通用库。
我的问题是，您将如何确保它们得到妥善管理？
直接从 windows app1 引用跟踪项目
优点：您不必合并和分支。
缺点：重新编译代码时可能会在系统中引入问题。因为现在它正在用最新版本编译。
对每个项目进行分支跟踪并每隔一段时间合并它们 利弊与第一种选择完全相反。
我可能完全不理解这些想法，但我相信一定有更好的方法。
【问题讨论】：
标签： visual-studio-2008 tfs version-control
我们在这里所做的只是不断更新和改进我们的公共库，然后当我们对它感到满意并且需要在应用程序中使用它时，我们会根据主要或次要版本关于更改的数量，为其构建安装程序，并在源代码管理中对其进行标记。
当我们需要对旧应用程序进行更改时，我们只需将它们升级到最新版本即可处理旧应用程序。
我为公共库构建了一个 SDK 和 Redistributable 安装程序。 SDK 提供给所有开发人员，包括源代码、模板、文档，将 DLL 放在他们的驱动器上，并将 DLL 放在他们的 GAC 中。 Redistributable 只是将 DLL 放在 GAC 中。我们在服务器上安装可再发行组件。
我们很快将采用一种不产生可再发行产品的方法。我们将只生成一个 SDK，并且在该 SDK 中将是公共库的合并模块。当开发人员使用该库并准备将其应用程序投入生产时，他们将为它构建一个安装程序并将合并模块包含在该安装程序中，这样应用程序的部署始终具有正确版本的公共库，我们不必担心先在服务器上安装它。
我对你的环境一无所知，所以我不知道这些技术对你有什么作用，但它现在对我们来说效果很好。
【讨论】：
一个重要的区别是服务器上的两个子项目是否运行不同版本的“共享”代码是否重要。图书馆，你可能没问题。共享服务？可能不是。如果是后者，那么分支就会成为一个更大的问题，因为每个人都很容易不同步。如果你能负担得起并排运行不同的版本，那么我会选择分支方法，因为它让每个项目/区域可以更好地控制何时接受更改。
您没有提到的一个选项是将常见项目的二进制文件存储在源代码管理中，并使用二进制引用。这与您的第二个选项（分支）具有相似的属性。与直接项目参考相比，您遇到的问题更少，因为只有已知良好（或至少可编译）的版本可用。这样做的一个缺点是，在使用共享项目的同时编辑共享项目可能会有点痛苦。
这也有助于避免大型解决方案的混乱。
您还可以使用此设置做一些巧妙的事情，例如在共享项目上设置 CI 构建，并使用自定义构建后任务来签入新的二进制文件。
【讨论】：