多目標.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月）。