?

作者：.NET Team
翻譯：精致碼農-王亮
原文：http://dwz.win/Q4v

?

我們希望極大地簡化開發人員必須在項目文件和 NuGet 包中使用的「TFM」 (Target Framework Name, 目標框架名稱)。這包括合并 .NET 5 和 .NET Standard 的概念，同時仍然可以使用 #if 來編寫特定于操作系統的代碼。本文解釋了開發的動機和由此產生的開發者體驗。

.NET 和大多數有二十年歷史的技術一樣，有很多歷史遺留問題，特別是在產品命名和版本方面：.NET Framework, .NET Compact Framework, Silverlight, .NET Micro Framework, .NET Portable Class Libraries, .NET for Windows Store, .NET Native, .NET Core, .NET Standard 等等，這還不包括 Mono 系的產品。雖然 .NET 的這種演變是情有可原的，但它創造了一個巨大的學習成本：不計其數的概念。如果你是 .NET 的新手，你會從哪里開始？最新技術棧是什么？你可能會說，當然那是 .NET Core 了，但是新手們怎么可能只看名字就知道它是什么？

我們已經用 .NET Standard 簡化了世界。在類庫中，作者不必考慮用不同的“盒子”去包裝不同的 .NET 實現。這是因為我們為不同的 .NET 實現統一了上層 API。具有諷刺意味的是，這導致我們不得不添加另一個大“箱子”，即 .NET Standard。

為了使未來的 .NET 生態更加健康地發展，我們必須減少“包裝盒”的數量。我們也不想讓 .NET 變得不那么靈活，但是我們想減少純粹因為我們沒有盡早地開源而導致的荒謬差異。例如，Mono/Xamarin/Unity 與 .NET Framework/Silverlight/UWP/.NET Core 基于不同的運行時和框架。我們已經開始使用 .NET Standard 消除 API 表面上的差異。.NET 5 的目標是將這些產品線聚合到單個產品技術棧上，從而統一它們的實現。

雖然我們在努力為開發者提供良好的開發體驗，讓你不必對不同種類的 .NET 編寫不同的實現。但我們仍然不想完全抽象掉底層的操作系統，所以你將繼續能夠調用操作系統特定的 API，無論是通過 P/Invokes、WinRT， 還是 Xamarin 為 iOS 和 Android 提供的綁定。

現在想想那些開始使用這個技術棧的開發者，可以為 .NET 提供支持的任何平臺編寫任何應用程序，他們需要的是更快的找到文檔和教程。為此，他們只需要知道兩件事，就是他們的技術棧名稱和版本。

讓我們看看目前這是一個什么樣的體驗，以幾個比較流行的 NuGet 包為例，作者必須編寫：

有很多名稱和版本號。如果沒有“解碼環”（譯注：一種比喻），想知道誰與誰兼容是不可能的。我們已經用 .NET Standard 大大簡化了這一點，但這仍然需要一個映射表將 .NET Standard 版本和 .NET 實現版本進行匹配。

我們的提議是通過新的語法重新使用現有的 net TFM 和操作系統特定的 API 模型：

net5.0，這個 TFM 是表示代碼可以在任何環境運行，它結合并取代了 netcoreapp 和 netstandard 的名稱。這個 TFM 一般只包括跨平臺的技術（像我們已經在 .NET Standard 中做的那樣）。

net5.0-android、net5.0-ios 和 net5.0-windows，這些 TFM 代表了 .NET 5 的特定操作系統，包括 net5.0 加上特定操作系統的綁定。

NuGet 應該使用這種新的語法來自動理解：在 net6.0-windows 中可以使用 net5.0（而反過來不行）。更重要的是，這種符號還能讓開發人員直觀地理解兼容性關系。

場景和用戶體驗

不同的實現

小花正在開發一個支持 Android、iOS 和 Windows 的 Xamarin Forms 應用程序。她的應用需要獲取 GPS 信息，但只是針對非常有限平臺。由于沒有可移植的 GPS API，她使用 multi-target 寫了自己的小抽象庫。

通過這種方式，她能夠封裝 GPS 訪問，而不必對整個應用進行 multi-target，只需在一個地方進行 multi-target 即可。

public?static?class?GpsLocation {public?static?bool?IsSupported{get{ #if?ANDROID?||?IOS?||?WINDOWSreturn?true; #elsereturn?false; #endif}}public?static?(double?Latitude,?double?Longitude)?GetCoordinates(){ #if?ANDROIDreturn?AndroidAPI(); #elif?IOSreturn?AppleAPI(); #elif?WINDOWSreturn?WindowsAPI(); #elsethrow?new?PlatformNotSupportedException(); #endif} }

不同的 API

小花是 SkiaSharp 的開發者，SkiaSharp 是一個基于谷歌 Skia 圖形庫的 .NET 跨平臺 2D 圖形 API。該項目已經在使用 multi-target 來為不同平臺提供不同的實現。為了讓它更容易使用，她增加了一個新的 SkiaSharpImage 類型，它代表一個位圖，并通過 OS 提供的數據類型來構造。小花使用 #if 在不同平臺上暴露不同的構造函數：

public?class?SkiaSharpImage { #if?ANDROIDpublic?SkiaSharpImage(Android.Media.Image?nativeImage)?{?/*?...?*/??} #endif#if?IOSpublic?SkiaSharpImage(NSImage?nativeImage)?{?/*?...?*/?} #endif#if?WINDOWSpublic?SkiaSharpImage(Windows.Media.BitmapImage?nativeImage)?{?/*?...?*/?} #endif }

更新 OS 綁定

小明正在構建一個叫 Baby Shark 的 iOS 應用。他一開始使用的是支持 iOS 13 的 .NET，但蘋果剛剛發布了 iOS 14。他下載了更新版的 .NET 5 SDK，它包含了對 iOS 14 的支持。為了獲得蘋果添加的新 API 的訪問支持，小明打開了他的項目文件，目前這個文件是這樣的：

<Project?Sdk="Microsoft.NET.Sdk"><PropertyGroup><TargetFramework>net5.0-ios13.0</TargetFramework></PropertyGroup>...</Project>

他把 <TargetFramework> 修改為 net5.0-ios14.0。

點亮新的 OS 版本

小明不想切斷目前使用 iOS 13 的用戶，所以他希望自己的應用也能繼續在 iOS 13 上運行。為了達到這個目的，小明修改了項目文件，添加了 <SupportedOSPlatformVersion>：

<Project?Sdk="Microsoft.NET.Sdk"><PropertyGroup><TargetFramework>net5.0-ios14.0</TargetFramework><SupportedOSPlatformVersion>13.0</SupportedOSPlatformVersion></PropertyGroup>...</Project>

不過，由于小明也使用了蘋果在 iOS 14 中加入的新的 NSFizBuzz API，所以他也修改了自己的源代碼，在調用之前檢查 OS 版本：

public?void?OnClick(object?sender,?EventArgs?e) {if?(Environment.OSVersion.Version?>=?new?Version(14,?0)){NSFizBuzz();} }

消費更高的 SupportedOSPlatformVersion 庫

在直接使用 NSFizzBuzz 一段時間后，小明注意到這些操作系統的 API 有點難用，于是他開始尋找一個.NET 庫。他找到了 Monkey.FizzBuzz，并嘗試引用它，成功了。然而，當編譯他的應用程序時，他得到以下警告：

?

warning NU1702: Package 'Monkey.FizzBuzz' was restored using 'net5.0-ios14' and has 'SupportedOSPlatformVersion' of '14.0' while the project has a value of '13.0'. You should either upgrade your project to '14.0' or only make calls into the library after checking that the OS version is '14.0' or higher.

?

由于小明已經對所有的方法調用進行了保護，所以他只是取消了警告（譯注：可以在項目文件中通過<NoWarn>設置）。

消費更高的 TargetPlatformVersion 庫

小明在他的 Baby Shark 應用中成功使用 Monkey.FizzBuzz 后，小明想在其它地方也使用它，所以他決定在他現有的 Laserizer 5000 應用中使用它。然而，當他添加對 Monkey.FizzBuzz 的引用時，他得到一個 NuGet 引用錯誤：

?

error NU1202: Package 'Monkey.FizzBuzz' is not compatible with 'net5.0-ios13.0'. Package 'Monkey.FizzBuzz' supports: net5.0-ios14.0

?

所以小明修改了他的項目文件，將 net5.0-ios13.0 改為 net5.0-ios14.0，從而解決了這個錯誤。

使用比當前 SDK 更高的 TargetPlatformVersion

小翠的環境安裝的是第一個版本的 .NET 5 SDK，它只提供到 iOS 13 的支持。她從 GitHub 上克隆了小明的 Baby Shark 倉庫，并試圖在她的機器上編譯它。由于 Baby Shark 的目標是 net5.0-ios14.0，她得到了一個編譯錯誤：

?

error NETSDK1045: The current .NET SDK does not support targeting iOS 14.0. Either target iOS 13.0, or use a version of the .NET SDK that supports iOS 14.0. [BabyShark.csproj]

?

要求

目標

• 使用與產品戰略一致的命名；

• 將 .NET Core 和 .NET Standard 合并為一個概念；

• 開發人員應該能夠理解兼容性關系，而不必查閱映射表；

• 提供與現有概念和 NuGet 包的兼容性；

• 如果能在 .NET 5 的早期預覽版中加入這個功能就再好不過了；

• 支持同一操作系統的不同版本的 multi-target；

• 不強迫同一操作系統應用不同版本的 multi-target。當調用被操作系統的檢查保護時，應當能夠產生一個可以使用較新 API 的二進制文件。

非目標

• 換 TFM 或擴大運行時標識符(RID)

未完待續

譯注：文章太長，今天先翻譯一半，有空再繼續翻譯。后一半主要講 TFM 的設計細節，比如多個 TFM 選擇的優先級、 MSBuild 的屬性（TFI、TFV、TFP、TPI、TPV 等）、NuGet 包的行為等。其中比較重要的是下面這張表，它列出了現有的 TFM，我覺得大家有必要了解一下：

-

精致碼農

帶你洞悉編程與架構

↑長按圖片識別二維碼關注，不要錯過網海相遇的緣分

總結

以上是生活随笔為你收集整理的.NET 5 的 Target Framework 详解[上篇]的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。