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

Question

我们有大量MSVS解决方案(解决方案"A“、"B”、"C“、.)在程序集中共享称为"Common.dll“的基本功能。

有3-5个主动解决方案(正在开发中)，而另一些则是被动的，几乎无法重建。

Common.dll一直处于开发阶段。有几种选择，如何保留我的解决方案代码，你会建议什么，为什么？

a)。将common.dll源代码应用于每个解决方案()。优点:它将有助于主动解决方案与common.dll并排增长，而被动解决方案将是可编译的。缺点:很难在活动解决方案之间同步active common.dll代码

b)。将common.dll二进制代码放入每个解决方案()。优点:所有项目都是可编译的，而common.dll代码则是集中的。缺点:很难将活跃的解决方案与common.dll并行增长。

c)。将每个项目引用到最后一个common.dll二进制文件中，看起来类似于B，但是如果common.dll增长并改变它的接口(一些人可能会说接口应该始终保持不变)，那么它会给被动解决方案带来问题。

d)。？

提前谢谢你！

Answer 1

我们练习的东西大多类似于B。

CI服务器确保公共库始终是最新的(即使它们使用其他公共库主题)。每个使用公共库的解决方案都有一个"Lib“文件夹，我们在其中放置构建人工制品，但它们并不在源代码管理之下(与通过NuGet导入的外部构件不同)。

因此，在开发过程中，您不会因为打破常规库中的更改而遇到问题，并且开发人员选择了升级的时间点(但在提交到中央回购之前，他总是必须这样做)。

CI服务器将始终将最新的公共库复制到正在构建的解决方案的"Lib“中，以便集成最新的公共库。如果我们需要用旧库创建一个构建(特定的修复版本--非常罕见)，我们可以始终使用带有匹配日期的构建人工制品。不过，正常的补丁/修复版本通常也会升级到最新的公共库。

Answer 2

还有其他选择，还有：

D)将所有项目放在同一个SVN (或其他CVS)根中.

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

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

它的好处是，您肯定会在您创建的每个分支中获得Common.dll源代码的快照。

E)使用SVN外部

如果使用Subversion，则可以使用SVN外部 (将本地子文件夹映射到版本化资源的url )。GIT也支持类似的东西，但是如果您想要向外部repos提交更改，它就有点复杂了。

Answer 3

我会马上说折扣(A)，因为你会扼杀你所有的可维护性的能力！

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

我们在类似设置上的当前解决方案是有一个独立的“公共”项目，二进制文件被复制到每个引用公共项目的“Libs”文件夹中。这样做的原因是我们能够将common.dll的显式版本部署到每个项目。Libs文件夹通过TFS维护。因此，虽然父项目不需要重新编译，TFS将看到一个新的签入，并可以采取相应的行动。

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