.Net Core，Portable，Standard，Compact，UWP和PCL之間的區別？

Question

我聽說過

• .Net核心
• .Net Portable
• .Net標准
• .Net Compact
• 通用Windows平台
• 便攜式類庫

所有這些都被解釋為“完整.Net的一個子集，允許您定位多個平台” 。 所以我的問題是

1. 有什么不同！？
2. 如果我想編寫一個可供盡可能多的受眾使用的庫， 我需要使用哪一個（或多個） ？

---

（我的具體情況：我有一個針對.Net 2.0，.Net 4.5和UWP的庫。針對UWP需要創建一個新的VS項目並鏈接所有現有文件，這是一個巨大的痛苦。現在有人告訴我它沒有不適用於PCL，從它的聲音我必須再次為.Net標准！？）

Answer 1

我先回答你的第二個問題：

我有一個針對.Net 2.0，.Net 4.5和UWP的庫。 針對UWP需要創建一個新的VS項目並鏈接所有現有文件，這是一個巨大的痛苦。 現在有人告訴我它對PCL不起作用，從它的聲音我必須再次為.Net標准做！？）

如果我想編寫一個可供盡可能多的受眾使用的庫，我需要使用哪一個（或多個）？

簡短的回答：你應該以netstandard目標。 使用包含所需API的最低版本 。 您可以使用API端口等工具檢查現有項目是否與給定的netstandard版本兼容 。

不幸的是，這種方法將留下舊的平台，在您的情況下，.NET 2.0。 如果需要維護.NET 2.0支持，那么您將需要一個單獨的項目（帶有鏈接文件）來構建單獨的.NET 2.0程序集。

關於細節......

有什么不同！？

• .Net Standard （ netstandard ） - 這是新的跨平台BCL API。 它是一個“標准”，因為它只是一個API定義，而不是一個實現。 我們的想法是您可以將庫編譯為此API的（版本），它將在支持該版本的任何平台上運行。
• .Net Core - 您可以將其視為netstandard的參考實現（帶有一些額外的位）。 它是該API的跨平台實現 。 UI和其他框架可能構建在它上面，但是現在它唯一可靠的立足點是作為ASP.NET Core的首選平台。 [旁注：由於歷史原因，“.NET Core”與netcore NuGet目標完全不同 ; 當你在NuGet上下文時， netcore意味着“Windows 8 / 8.1 / 10”] 。
• .Net便攜式和可移植類庫 - 可移植類庫（PCL）是提供跨平台API的最常見分母方法。 它們涵蓋了廣泛的目標平台 ，但它們不完整且不具備前瞻性。 它們基本上已被netstandard取代。
• .Net Compact - 這是一個完全不同的.NET框架，它有自己獨特的API。 它與任何其他框架，PCL或netstandard版本完全不兼容; 因此，支持比任何其他平台都困難得多。 但是，它仍然在具有嚴格內存限制的設備上使用。
• 通用Windows平台 - 這是Windows Phone和桌面之間的Win10時代的API合並，允許為兩個平台編寫Windows應用商店應用/庫。 這基本上已被netstandard取代。

Answer 2

正如評論中所鏈接的那樣，Microsoft已經描述了所有這些信息。 但是，根據你的回答，似乎你並沒有完全理解整個事情。 它很長，所以這里（希望）是一個tl; dr版本。

我們將從上面鏈接的下表開始，希望這將消除一些混亂：

稍后對其他人發現的概述：.NET庫在其存在的15年中經歷了很多變化和端口。 在那段時間里，許多智能手機現在幾乎與2001年使用的一些桌面一樣強大。在這個國際米蘭中， .NET框架的子集被創建（並且很快被放棄）用於不同的平台。 隨着Satya Nadella將.NET作為盡可能廣泛的平台的新方法，需要改變一些事情。

作為一項已有15年歷史的技術，需要改進。 自2014年以來， .NET Core一直是.NET架構的徹底改革之一。 它已經從頭開始重寫為.NET語言的新版本。 Core的目標之一是實現跨平台部署。 無論是在iPhone / Android / XBox One上運行的應用程序，還是可以在IIS或Linux機器上托管的網站，.NET Core都能滿足您的需求。 它通過幾種不同的方式實現這一點，包括不需要在機器上安裝.NET Framework，而是使用您的解決方案打包必要的庫。

最值得注意的是，.NET Core是對ASP.NET的重大改變。 舊的System.Web完全消失並重寫為盡可能高效，效果令人印象深刻 。 單獨的WebApi控制器已經消失，因為一切都在一個控制器內完成。 整個過程現在是選擇加入，而不是默認允許您可能不想要的事情。

但是，我們作為開發人員最終會想要遷移一些應用程序，那么我們如何確保我們已經編寫的代碼沒有對方法進行一些小的名稱更改，從而打破了巨型解決方案的編譯？ 來自.NET標准 。 這是一組必須實現的API，以便您的平台將自己稱為“.NET”。

作為我們多年來一直使用的基本.NET框架已經很成熟，它被用作標准將包含的基礎。 但是，一切都不包括在內，重點是什么？ 因此，標准只是各種類型的.NET平台之間存在的通用API。 您最終不會在“.NET Standard”中編寫代碼。

Xamarin（包含在上表中）於2016年被Microsoft收購 ，該技術用於幫助構建（或至少激發）.NET Core跨平台。 它仍然作為一種工具存在，但與過去使用的靜脈相同。 根據該表，它將在vNext版本中符合.NET Standard 2.0標准。 但是，它的目標受眾不會改變。

要直接回答您的問題，如果您想使用盡可能廣泛的單一部署解決方案編寫應用程序，則需要使用.NET Core 。 但是，如果您使用的是當前基於.NET Framework 2.0和4.5構建的庫，那么您將無法使用.NET Framework並為該目標使用單獨的UWP解決方案。

如果它提供了可以通過Web API調用調用的內容，則可以在.NET Framework中的服務器上運行該調用，並在.NET Core中使用單個解決方案來部署到最終用戶。 如果它已集成到您的代碼中，那么在提供.NET Core更新之前，您很幸運。

希望這可以消除不同技術名稱之間的一些混淆。

編輯

在對您的具體情況作出一些澄清后，我可以為您解決問題。 您無法制作同時針對.NET Framework和.NET Core的單一解決方案。 使用不同的底層技術以完全不同的方式進行編譯，因此這與嘗試在.NET 2.0解決方案中使用.NET 4.5版本的情況相同。

但是，有一些教程允許您將項目移植到Core。 在大多數情況下，只需將類主體復制到.NET Core解決方案中，大多數東西都能正常工作。 有些部分已經被廢棄，有些部分尚未完全100％充實（不適用於您的情況，但實體框架並不具備所有相同的功能）。 還有一些電話改變了一點點。

好的新東西是向前發展，.NET Core將為您提供最廣泛的可能性。 .NET Framework不會消失，但它和Core將更加同步。

.NET Core的另一個好處是它使用迭代方法進行部署，因此您不會等待2年時間進行下一次重大升級。 通過NuGet提供的一切，您將在改進和新功能上實現更快的轉變。

Answer 3

我假設你已經用漂亮的表讀過微軟的文章，現在一切都很清楚。 如果是這樣的話，你和我之前在同一條船上度過了一個下午的大部分時間（並嘗試將我的反思重型庫移植到.NET Core，我應該提到它也是我唯一的 .NET）核心移植工作）。 接下來的不是官方派對，而是我通過大量閱讀（以及自.NET 1.0以來成為.NET開發人員）所發現的內容。 我無法保證其完全准確性（特別是涉及移動開發時，我幾乎完全無知）並且肯定會更正。 如果有很多我會把它做成維基。

我會或多或少地按時間順序瀏覽它，因為我發現如果你想了解新舊有何關聯，那就最有意義了。 它可能應該減少很多，但目前我沒有時間這樣做。 有一個TL; DR版本在最后，雖然。

漫長而曲折的道路

盡管它具有Java系統，但.NET從未真正嘗試過“一次編寫，隨處運行”。 它開始於Windows的陣營，即使它編譯為字節碼並且沒有過度使用明確的Windows主義，因此理論上非常便攜，這不是MS真正感興趣的。部分.NET Framework是早期開源，一群開源的enthousiast選擇了它並與它一起運行，給我們Mono 。 Mono很重要，因為它是.NET的第一個備用平台和庫集 ，並說明了平台與庫與工具鏈的思想。 Mono嘗試提供公共語言運行時的（或多或少）完整實現，以及它的關聯基類庫。 這很重要：雖然Mono在Linux（以及其他一些Unices）上運行，但它並不是一個單獨的平台，因為它實現了CLR + BCL（某些版本）。 存在與應用程序開發人員相關的運行時差異（路徑名稱等），但對於實際的庫編程，您可以將Mono和.NET Framework for Windows視為“相同”的平台，實現略有不同。 我強調這一點是因為我們將遇到針對未在CLR上運行的Windows的.NET代碼，並且（具有諷刺意義或其他方面）難以移植。

然后出現了Windows Phone（多個版本），Windows CE（多個版本），Windows Embedded CE，Windows Toaster（好的，那個實際上並不存在），並且每次基本上都重新發明了.NET的某些風格 - 仍然是.NET但是運行時和/或BCL的基本內容缺失或改變了。 這是我們獲得.NET Compact ， .NET Micro ， Windows Phone （舊樣式，框架沒有單獨名稱）和Silverlight的地方 。 所有這些都應該被認為是類似於.NET Framework的獨立平台+庫組合，足以使跨平台開發成為可能，但不同於它足以使它變得不那么容易 。 為了跟蹤支持共享庫最不方便的內容，有人提出了可移植類庫及其相關配置文件（其集合稱為.NET可移植參考組件 ）的概念。

基本上，您定位一組.NET版本，平台（和庫）的特定組合，並且您將獲得模仿這些組合以進行編譯的參考程序集。 根據您明確希望定位的口味，存在許多不同的配置文件。 這是.NET Standard現在嘗試更大規模的第一次嘗試。 基本上， PCL現在已經過時了，除非你的目標是.NET Standard沒有試圖支持的東西 。 .NET標准不再考慮大量不同的配置文件，這樣做很好，但卻犧牲了你的庫可以早先定位的一些東西，這很糟糕。 有在線資源可以幫助從PCL過渡到.NET Standard。 如果你現在正在尋找可移植的代碼，你不想把重點放在PCL，除非你真的想支持一些漂亮的邊際平台（無犯罪意圖的人對他們仍處於發展階段）。

顧名思義， 通用Windows平台是一個平台。 具體來說，Windows Store應用程序（桌面和手機）都支持.NET平台。 就是這樣，不多也不少。 它最好被認為是Silverlight的自然繼承者，因為它是桌面和移動設備的沙盒框架支持。 盡管有這個名字，但它並不是一個通用的平台，它不是你想要的所有代碼所針對的。 它是您可能希望為您的代碼啟用的平台，它的獨特之處在於它是我所知道的唯一一個在同一版本中具有兩個運行時的平台。 馬上就來！

原始帖子中沒有提到.NET Native ，但是經常出現在這些討論中，因為它也是新的，比如.NET Core，聽起來非常性感，因為它直接將.NET編譯為機器代碼（提前編譯，而不是JIT編譯）。 在發布模式下編譯時，它不是一個完整的新平台，而是UWP應用程序的新運行時（僅限於那些）。 在調試模式下，它們使用CoreCLR（.NET Core運行時）。 除非你真的想要構建一個UWP應用程序，否則你不需要考慮這個問題，因為.NET Native中的反射會發生各種有趣的事情需要應用程序開發人員的單獨關注。

現在我們來到.NET Core ！ .NET Core起初是“ASP.NET核心”，但人們很快意識到它可能比這更大。 .NET Core是一個新的運行時（CoreCLR）+庫組合，具有明確的跨平台支持（如跨操作系統）。 與CLR + BCL組合不同，其中有Windows版本和Mono形式的Unix版本，.NET Core是所有平台的一個代碼庫（當然，通常平台特定的脆弱位支持蓬松的便攜層） 。 令人困惑的是.NET Core 也是支持構建.NET Core應用程序的新工具鏈/項目類型的名稱，之前我們只有MSBuild。 這是必需的，因為沒有Visual Studio for Linux，但MS 已經擺脫了“讓我們保持簡單和JSON”的方法，並回歸到.NET Framework和.NET Core的一種通用格式（它將會是MSBuild，因為那里有更多的東西）。

.NET Core在很大程度上與.NET Framework非常兼容。 因此，如果您的.NET Core應用程序實際上在.NET Framework上運行（在Windows上），它可以加載面向.NET Framework的程序集，而不僅僅是.NET Core。 這是混淆和不可移植代碼的重要來源：雖然您可以構建並加載這些程序集，但它們會使您的代碼不可移植。 .NET Core本身不會阻止你這樣做; 如果您正確排列聲明，.NET Standard（即將推出）將會出現。

和我一起到目前為止？ 很好，因為現在我們已經准備好將.NET Standard放在你不知情的頭上了。 .NET Standard不是一個平台（在某種意義上說你不能在機器上下載和安裝它），它不是一個庫（但是有一些軟件包支持它用於構建目的），它是一個配置文件。 這是嘗試在我們剛剛討論的各種事物中標准化庫表面。 我們的想法是，如果您的代碼以.NET Standard XY為目標，您只需要將構建工具切換為“請給我.NET標准XY”，並且在構建程序集時，您可以確保它可用於所有平台由XY萬歲覆蓋！ 世界又變得簡單了！

好吧，還沒有。 問題是.NET Core目前處於大量開發階段，這意味着很多東西都缺失或不同 - 甚至是.NET Framework代碼庫中可能存在的非常基本的東西，比如標記您的異常Serializable並給予它們用於反序列化的單獨構造函數，以便它們可以在AppDomain很好地工作。 .NET Core中沒有AppDomain ，因此沒有序列化，因此這些構造函數將無法編譯。 在舊版本的CoreCLR中，甚至缺少Serializable屬性本身。 如果您的MSBuild項目使用自定義目標，那么.NET Core工具鏈目前不支持這些內容（將來可能再次使用MSBuild）。 當然，您可以重寫，但不能重復使用。 因此，雖然您可以定位.NET Standard，但您可能需要兩個單獨的項目和/或一些條件編譯來為兩個不同的平台獲取.NET Standard程序集。 如果你很幸運（或者可以妥協一下），你的庫很簡單，只用.NET Core構建它就足夠了。 毫無疑問：仍有多個.NET平台，它們仍然存在差異，.NET Standard只是試圖讓它更容易移植。 到目前為止它有限，但已經比PCL做得更干凈。

總結一下：.NET Core和.NET Framework（以及他們所有的小表兄弟和侄子）在概念上和實現上都是獨立的平台。 .NET Standard是一種定位配置文件，可簡化在它們之間移植代碼所需的工作（但尚未使其完全透明）。 PCL是標准的前身，如果你是進步的話可以被忽視。

---

TL; DR從這里開始（但仍然是TL）

要最終回答您的問題，如果您是一名現代圖書館開發人員，並且希望“盡可能多的受眾”，您應該怎么做？ 首先，如果可能的話，你必須讓它變小。 您將明確支持和測試哪些平台？ 您真的想在XBox 360上使用.NET Compact嗎？ Windows Phone 7？ 八年前的Silverlight？ 如果你這樣做，你可能無法繞過PCL，但我們大多數人都會有幸能夠避免這種情況。 如果不是：如果您的配置文件與.NET Standard中的任何內容都不匹配，則排隊單獨的PCL構建。

你的庫是非常簡單的（不使用反射，沒有async / await ，不依賴於像WCF這樣的大型框架）？ 然后，您可以定位.NET 2.0的橫截面以及具有所需框架依賴性的最低版本的.NET Standard。 不要被愚弄，.NET Standard的較低版本在它們提供的產品中實際上是令人失望的，但是你必須付出一定的便攜性價格。 構建.NET 2.0和某些.NET Standard版本沒有工具鏈支持。 您必須構建它兩次並“在任何地方”進行測試，盡管橫截面意味着您可以合理地確定它在編譯時能夠正常工作。 生成的庫將支持每個可以加載vanilla .NET 2.0程序集（幾乎全部，但特別是不是Micro和Compact）和.NET Core的.NET平台，並且所有這些程序都沒有平台切換。 恭喜，世界上從未見過如此便攜的東西！

你的圖書館會用反射嗎？ 那么你可能無法繞過重寫代碼以使其為.NET Core編譯，因為反射API改變了一段時間后你的代碼可能還沒有趕上（因為沒有必要，如果你繼續瞄准完整的框架）只要）。 在這種情況下，您需要將目標.NET Framework版本提升到4.5，因為這是與這些更改兼容的.NET Framework版本。 在這里，您開始獲得工具支持：您可以定位.NET Standard 1.1，它涵蓋了.NET 4.5的一個子集 。 如果您發現此子集是不夠的，您將再次使用構建兩次：對於完整的.NET Framework和.NET Core。 原因是.NET Core 1.0比.NET Framework 4.5支持“更多”，但是目前還沒有.NET Framework的版本可以與Core（即“vNext”）相提並論。 因此，如果您不想僅限於.NET Core，而且還希望支持我們這些仍然構建普通的舊4.5桌面應用程序並且 .NET Standard 1.1對您來說還不夠，那么您將不得不拆分。 錯誤的做法是目標1.1，然后只導入Framework 4.5包/程序集，因為這將使您在可移植性方面成為最糟糕的兩個世界！

您的庫是否需要4.5.1或更高版本中引入的4.5以上的一些改進/擴展，或僅適用於更高.NET標准版本的軟件包？ 然后定位適當的更高的.NET標准版本。 請注意，Microsoft 不再正式支持低於4.5.2的任何4.x. 這並不意味着你不應該針對這些版本（盡可能的低，你可以合理的），但它確實意味着你有一個論據使用無外乎.NET 1.2的標准，如果你可以要求4.6，不小於1.5。 這對消費者來說並不累贅（如果你願意並且能夠安裝4.6，你幾乎肯定願意並且能夠安裝4.6.2）並且讓你的生活更輕松。 根據您的代碼，您可以只使用.NET Core構建，但您可能不想這樣做，因為.NET Core構建鏈尚未穩定並將返回到MSBuild（如前所述）。 放棄JSON的所有項目文件只是為了以后再回來！

您的庫是否使用任何類型的條件編譯？ 請注意，使用.NET Core工具鏈，您可以獲得不同的預定義符號 。 他們非常討厭，因為他們堅持（比如說）區分4.5,4.5.1和4.5.2，如果你想要涵蓋“4.5及以上”，那將是一種痛苦。 沒有任何細心的構建無法處理，但您需要考慮的事情。

我不是在這里介紹移動版本（Xamarin和舊手機版本）因為，我對這些知之甚少！ 我想這個故事與構建.NET Core和.NET Framework非常相似，因為該構建只適用於簡單的庫和庫，您不必關心向后兼容性，並且需要（至少）否則兩個構建，但正如我在開始時說的那樣，歡迎更正。