.NET 5 的 Target Framework 詳解

?

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

?

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

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

我們已經(jīng)用 .NET Standard 簡化了世界。在類庫中，作者不必考慮用不同的“盒子”去包裝不同的 .NET 實現(xiàn)。這是因為我們?yōu)椴煌?.NET 實現(xiàn)統(tǒng)一了上層 API。具有諷刺意味的是，這導致我們不得不添加另一個大“箱子”，即 .NET Standard。

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

雖然我們在努力為開發(fā)者提供良好的開發(fā)體驗，讓你不必對不同種類的 .NET 編寫不同的實現(xiàn)。但我們?nèi)匀徊幌胪耆橄蟮舻讓拥牟僮飨到y(tǒng)，所以你將繼續(xù)能夠調(diào)用操作系統(tǒng)特定的 API，無論是通過 P/Invokes、WinRT， 還是 Xamarin 為 iOS 和 Android 提供的綁定。

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

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

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

我們的提議是通過新的語法重新使用現(xiàn)有的 net TFM 和操作系統(tǒng)特定的 API 模型：

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

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

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

場景和用戶體驗

不同的實現(xiàn)

小花正在開發(fā)一個支持 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?||?WINDOWS
????????????return?true;
#else
????????????return?false;
#endif
????????}
????}

????public?static?(double?Latitude,?double?Longitude)?GetCoordinates()
????{
#if?ANDROID
????????return?AndroidAPI();
#elif?IOS
????????return?AppleAPI();
#elif?WINDOWS
????????return?WindowsAPI();
#else
????????throw?new?PlatformNotSupportedException();
#endif
????}
}

不同的 API

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

public?class?SkiaSharpImage
{
#if?ANDROID
????public?SkiaSharpImage(Android.Media.Image?nativeImage)?{?/*?...?*/??}
#endif

#if?IOS
????public?SkiaSharpImage(NSImage?nativeImage)?{?/*?...?*/?}
#endif

#if?WINDOWS
????public?SkiaSharpImage(Windows.Media.BitmapImage?nativeImage)?{?/*?...?*/?}
#endif
}

更新 OS 綁定

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

<Project?Sdk="Microsoft.NET.Sdk">

??<PropertyGroup>
????<TargetFramework>net5.0-ios13.0TargetFramework>
??PropertyGroup>

??...

Project>

他把 修改為 net5.0-ios14.0。

點亮新的 OS 版本

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

<Project?Sdk="Microsoft.NET.Sdk">

??<PropertyGroup>
????<TargetFramework>net5.0-ios14.0TargetFramework>
????<SupportedOSPlatformVersion>13.0SupportedOSPlatformVersion>
??PropertyGroup>

??...

Project>

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

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

消費更高的 SupportedOSPlatformVersion 庫

在直接使用 NSFizzBuzz 一段時間后，小明注意到這些操作系統(tǒng)的 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.

?

由于小明已經(jīng)對所有的方法調(diào)用進行了保護，所以他只是取消了警告（譯注：可以在項目文件中通過設(shè)置）。

消費更高的 TargetPlatformVersion 庫

小明在他的 Baby Shark 應用中成功使用 Monkey.FizzBuzz 后，小明想在其它地方也使用它，所以他決定在他現(xiàn)有的 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

小翠的環(huán)境安裝的是第一個版本的 .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]

?

要求

目標

• 使用與產(chǎn)品戰(zhàn)略一致的命名；
• 將 .NET Core 和 .NET Standard 合并為一個概念；
• 開發(fā)人員應該能夠理解兼容性關(guān)系，而不必查閱映射表；
• 提供與現(xiàn)有概念和 NuGet 包的兼容性；
• 如果能在 .NET 5 的早期預覽版中加入這個功能就再好不過了；
• 支持同一操作系統(tǒng)的不同版本的 multi-target；
• 不強迫同一操作系統(tǒng)應用不同版本的 multi-target。當調(diào)用被操作系統(tǒng)的檢查保護時，應當能夠產(chǎn)生一個可以使用較新 API 的二進制文件。

非目標

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

未完待續(xù)

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