多目标.NET库的最佳实践

Question

我打算发布一个开源（MIT）.NET库，但也包括DLL以方便人们，这样他们就不必自己编译所有东西。

我的库在它引用的类型中非常简单，唯一真正的依赖似乎是.NET 3.0或更高版本（因为它指的是Func<T>等）。 （包括.NET 4.0服务器，.NET 3.5服务器，Windows Phone 7 Silverlight，普通Silverlight，XNA（电话），XNA（Windows）和XNA（XBox 360）等多个目标都可以使用该库。 。

我确保不要使用目标平台上不可用的任何类型，例如Windows Phone 7不支持HashSet<T>，所以我没有使用它。

我是否需要为这些目标中的每一个制作不同的项目以及多个DLL，还是有一些方法可以为它们生成一个通用的DLL？

Answer 1

有在PDC今年约做这样的东西谈话：

This is the video和these are the slides。

Answer 2

我会建议每个平台的图书馆。让我解释。

比方说，完整的.NET Framework包含一系列功能，而不是.NET Compact Framework的一部分，您可以通过Windows CE和智能手机找到该功能。因此，为了充分利用每个平台的全部可能性，我将利用一个通用的库来提供大量的接口，然后在.NET Framework platform specific类库中实现这些接口，这将允许您充分利用所提供的功能在特定的平台上。另一方面，如果通用的代码重用，并为了可维护性，您可能更喜欢使用单一的“全部自己做”库。根据这些要求，您需要充分了解您希望支持的众多平台之间的差异。

这显然是一个重要的分析和体系结构问题，因为两者都会遭受另一个平台的缺失。

这是我怎么会在这样的情况继续前：

1. 我会调查特定于平台的.NET Framework之间的差异;
2. 我会放下所有（根据需要）你认为你可能需要的共同对象;
3. 我会强调一下不同之处，也就是说，您可以在一个平台下使用对象，但不能使用其他平台;

这是一个有机分析，您将不得不执行以查看接下来会发生什么。

也就是说，对于某种瀑布方法。

---

至于Scrum的方法，如果我可以这样说，因为这表明经验，我会说尝试他们都一个共同的图书馆，看看你能做些什么。如果你遇到了一些你绝对不能做的事情，那么创建另一个类库可能是相关的，这将取决于你的“他们全部”库，以便你为每个平台都有一个共同的块，然后一些其他特定的图书馆为什么你不能在共同的。这样做，看看你从中得到什么好处，并找到一条摆脱困境的出路，以便更具体。

Answer 3

我做了一些类似于.NET和Silverlight的库。我有一组源文件和单独的项目文件链接到相同的共享文件。

有时候我会使用条件编译来包含仅针对.NET而不是Silverlight的功能，或者利用.NET中可用的功能来实现更好的实现，并为Silverlight提供一个回退实现，因为它存在空白。

相同的方法可用于您提到的其他平台 - 一组源文件，但是每个平台目标都有一个单独的项目文件。

如果您使用MSBuild或NAnt等构建工具，则可以在运行脚本时让该构建为所有目标平台生成所有DLL。

Answer 4

带有共享的通用源文件的独立项目文件是最好的选择。确保项目设置为构建到不同的输出文件夹（例如，不是\bin\Debug，但是\CF\bin\debug），以防止从多个目标（如桌面和设备项目）中使用库时产生的烦恼。

OpenNETCF.IoC framework就是这样的一个例子 - 它支持桌面，CF，Windows Phone和MonoTouch都具有相同的源文件，但是每个平台都有独立的项目文件。试图编译为一个单一的二进制程序集，可用于所有这些程序集太混乱，难以维护。

这里的主要问题在于，当您添加/更改文件并确保所有文件始终编译时，所有项目文件都保持同步。构建服务器可以做到这一点，如果你有自动化访问（Codeplex不幸的是不公开）。

Answer 5

看那Portable Library Tools（最后更新日期：2011年6月17日）从BLC团队（微软）延伸和本次的介绍MSDN article（最后更新：2011年8月）。