在.NET中的解决方案之间共享公共库的最佳实践

Question

我们有一组MSVS解决方案（解决方案“A”，“B”，“C”，......），它们在程序集中共享基本功能，称为“Common.dll”。

有3-5种活跃的解决方案（正处于开发阶段），而其他解决方案则是被动的，几乎不会被重建。

Common.dll始终处于开发阶段。如何保存我的解决方案代码有多种选择，您会建议什么以及为什么？

A）。 将common.dll源代码放入每个解决方案。优点：它将帮助主动解决方案与common.dll并排增长，而被动解决方案将可编译。缺点：在活动解决方案之间同步活动的common.dll代码很难

B）。 将common.dll二进制代码放入每个解决方案。优点：所有项目都可以编译，而common.dll代码将集中。缺点：很难与common.dll并行增加活动解决方案

C）。 引用每个项目到上一个common.dll二进制文件看起来像B.但是如果common.dll会增长并改变它的接口（有些人可能会说接口应该始终保持不变），它会带来被动解决方案的问题< / p>

d）。 ？

提前谢谢！

Answer 1

还有其他选择：

D）将所有项目放在同一个SVN（或其他CVS）根目录中。

这允许分支和标记，同时确保每个项目都具有一致的Common分支版本。这样，您只需根据需要在每个解决方案中包含项目。

问题是，当然，所有项目都在同一个SVN中。 ：）

有什么好处是你肯定会在你创建的每个分支中获得Common.dll源代码的快照。

E）使用SVN外部

如果您正在使用Subversion，则可以使用SVN Externals（将本地子文件夹映射到版本化资源的URL）。 GIT也支持something similar，但如果您想要对外部回购提交更改，则会有点复杂。

Answer 2

我们实践的主要是像B。

CI服务器确保公共库始终是最新的（即使它们使用其他公共库）。每个使用公共库的解决方案都有一个“Lib”文件夹，我们放置构建工件，但这些不受源代码控制（与外部工件相反，例如通过NuGet导入的工件）。

因此，在开发过程中，您不会因为常见库中的更改而出现问题，并且开发人员选择升级时的时间点（但他总是必须在他提交到中央存储库之前执行此操作）。

CI服务器将始终将最新的公共库复制到正在构建的解决方案的“Lib”中，以便集成最新的公共库。如果我们需要使用旧库（特定的修补程序版本 - 非常罕见）创建构建，我们总是可以使用具有匹配日期的构建工件。正常的补丁/修复版本通常也会升级到最新的通用库。

Answer 3

我会马上说折扣（A），因为你会杀死任何可维护性的能力！

实际上，它确实取决于这些代码库的变化频率。

我正在研究的类似设置上的解决方案是创建一个单独的“Common”项目，并将二进制文件复制到引用Common文件的每个Project的'Libs'文件夹中。这样做的原因是我们有能力为每个项目部署common.dll的显式版本。 Libs文件夹通过TFS维护。因此，虽然父项目不需要重新编译，但TFS会看到新的签到并且可以采取相应的行动。

我考虑的另一个选择是根据this link的解决方案之一“原位”引用共同项目。请注意，这会限制您引用不同版本的公共版本的能力，除非您为每个物理版本创建单独的项目版本，这是不可能的，也是不可取的，这也是由于可维护性。