我们拥有共享基本功能的MSVS解决方案（解决方案“A”，“B”，“C”，...）池，名为“Common.dll” 。在.NET解决方案之间共享通用库的最佳实践
有3-5个积极的解决方案（正在开发中），而另一些是被动的，几乎没有重建。
Common.dll始终在开发中。有几个选择如何保持我的解决方案代码，你会建议什么，为什么？ A）
A）。 将common.dll源代码放入每个解决方案。优点：它可以帮助积极的解决方案与common.dll并行发展，而被动解决方案可以编译。缺点：很难在活动解决方案之间同步活动common.dll代码。 将common.dll二进制代码添加到每个解决方案。优点：所有项目都是可编译的，而common.dll代码将被集中。缺点：很难与common.dll并行增长主动解决方案。 参考每个项目将持续common.dll二进制看起来像B.但它会带来被动解决问题，如果common.dll会不断地改变它的接口（有些人可能会说接口应始终保持不变）
d） 。 ？
预先感谢您！
我们练的东西大多喜欢B.
CI服务器可以确保公用库始终保持最新的（即使他们使用其他公共库themselfes）。每个使用公共库的解决方案都有一个“Lib”文件夹，我们在其中放置构建工件，但这些文件不受源代码控制（与外部文物相比，例如通过NuGet导入的文物）。
因此，尽管开发者不会因为常见库的变化而出现问题，开发人员会选择升级时的时间点（但在他承诺进行中央回购前，他必须这样做）。
CI服务器将始终将最新的通用库复制到正在构建的解决方案的“Lib”中，以便集成最新的通用库。如果我们需要使用旧库（特定的修补程序版本 - 非常少见）创建构建版本，则始终可以使用具有匹配日期的构建文物。正常的修补程序/修补程序版本通常也会升级到最新的通用库。
我会说直接打折（A），因为你会杀死任何你有可维护性的功能！
实际上，它的确会降低这些代码库的变化频率。
对于我正在处理的类似设置，我们的解决方案是有一个单独的'Common'项目，并将二进制文件复制到每个引用Common的项目的'Libs'文件夹。原因是我们有能力为每个项目部署common.dll的显式版本。 Libs文件夹通过TFS进行维护。因此，虽然父项目不需要重新编译，但TFS将会看到新的签入并可以采取相应的行动。
我认为您的其他选择是参照this link的解决方案之一的“原位”共同项目。但请注意，这会限制您引用不同版本通用的能力，除非您为每个物理版本创建单独的项目版本，而这又因可维护性而不太可能且不可取。
还有其他的选择，也：
d）将同SVN（或其他CVS）根内的所有项目。
这允许分支和标记，同时确保您有一个与每个项目共同分支的一致版本。这样您可以根据需要简单地将项目包含在每个解决方案中。
问题是，当然，所有的项目都在同一个SVN中。 :)
它的好处是，您一定要在您创建的每个分支中获得Common.dll源代码的快照。
E）使用SVN的外部对象
如果你使用Subversion，你可以使用SVN Externals（映射本地子文件夹到一个版本资源的URL）。 GIT也支持something similar，但如果您想要对外部回购提交更改，这有点复杂。
您的解决方案需要引用common.dll的不同版本吗？ – Nick 2012-01-16 11:15:57
谁知道。使用common.dll的精确版本来冻结被动解决方案将更容易，然后在common.dll更改时保持所有解决方案都是最新的。 – 2012-01-16 11:18:13
我会考虑为此设置自己的公司端nuget feed http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds - 它使它更容易管理卫星项目参考需求（包中可以编码最大版本以及最小版本）。我们刚刚做到了这一点，而且它很摇滚。 – 2012-01-16 11:26:02