我们公司有很多解决方案。他们中的大多数都使用一组公共库来实现不同的功能（日志记录，缓存，数据访问）。
我的问题是你如何确保他们得到妥善管理？
直接从Windows app1
引用跟踪项目优点：您不必合并和分支。
缺点：重新编译代码时，可能会在系统中引入问题。从现在开始编译最新版本。
对每个项目进行分支跟踪并偶尔合并它们 优点和缺点与第一选择完全相反。
我可能完全偏离这些想法，但我确信必须有更好的方法。
答案 0 :(得分：1)
我们在这里做的只是不断更新和改进我们的公共库，然后当我们达到一个我们对它感到满意并且需要在应用程序中使用时，我们依赖于主要或次要版本在更改次数上，为其构建安装程序，并在源代码管理中标记它。
当我们需要对该应用程序进行更改时，我们只需将它们升级到最新版本即可处理旧应用程序。
我为公共库构建了SDK和Redistributable安装程序。 SDK发送给所有开发人员，包括源代码，模板，文档，将DLL放在他们的驱动器上，并将DLL放入他们的GAC中。 Redistributable只是将DLL放在GAC中。我们在服务器上安装可再发行组件。
我们很快就会找到一种不会产生可再发行的方法。我们只会生成一个SDK，并且该SDK将是公共库的合并模块。当开发人员使用该库并准备将其应用程序转移到生产环境时，他们将为其构建安装程序并在该安装程序中包含合并模块，这样，应用程序的部署始终具有正确的公共库版本，我们不必担心首先在服务器上安装它。
我对你的环境一无所知，所以我不知道这些技术对你有什么用处，但它现在对我们来说非常好。
答案 1 :(得分：0)
要做的一个重要区别是，服务器上的两个子项目是否运行不同版本的“共享”代码是否重要。图书馆，你可能还可以。共享服务？可能不是。如果是后者，则分支变得更加困难，因为每个人都很容易失去同步。如果您可以并排运行不同的版本，那么我会选择分支方法，因为它可以让每个项目/区域更好地控制何时接受更改。
您未提及的一个选项是在源代码管理中存储公共项目的二进制文件，并使用二进制引用。这与您的第二个选项（分支）具有相似的属性。与直接项目引用相比，您将遇到的问题更少，因为只有已知良好（或至少可编译）的版本可用。这样做的一个缺点是，与使用它的东西并行编辑共享项目可能会有点痛苦。
这也有助于防止杂乱无章的解决方案。
您还可以使用此设置执行一些聪明的操作，例如使用自定义的构建后任务在共享项目上设置CI构建以检入新的二进制文件。