這篇文章將介紹將C# 7類庫升級到C# 8（支持可空引用類型）的一個案例。本案例中使用的項目Tortuga Anchor由一組MVVM風格的基類、反射代碼和各種實用程序函數組成。之所以選擇這個項目，是因為它很小，并且同時包含了慣用和不常用的C#模式。
關鍵要點
- 為每個項目啟用可空引用類型。
- 使用泛型時，可能需要禁用可空引用類型。
- 可以通過在本地變量中緩存屬性來修復警告。
- 公開方法仍然需要進行Null參數檢查。
- .NET Framework和.NET Core的反序列化方式是不一樣的。
這篇文章將介紹將C# 7類庫升級到C# 8（支持可空引用類型）的一個案例。本案例中使用的項目Tortuga Anchor由一組MVVM風格的基類、反射代碼和各種實用程序函數組成。之所以選擇這個項目，是因為它很小，并且同時包含了慣用和不常用的C#模式。
項目設置
目前，可空引用類型僅適用于.NET Standard和.NET Core項目。在Visual Studio 2019發布時，應該也支持.NET Framework。
在項目文件中，添加或修改以下配置：
\u0026lt;/PropertyGroup\u0026gt;? ? \u0026lt;LangVersion\u0026gt;8.0\u0026lt;/LangVersion\u0026gt;? ? \u0026lt;NullableContextOptions\u0026gt;enable\u0026lt;/NullableContextOptions\u0026gt;\u0026lt;/PropertyGroup\u0026gt;在保存文件后，應該會看到可空性錯誤。如果沒有看到，請嘗試構建項目。
指示一個類型可以為空
在接口方法GetPreviousValue中，返回類型可以為空。為了顯式地說明這一點，可以在object后面跟上可空類型修飾符（?）。
object? GetPreviousValue(string propertyName);使用這個類型修飾符注解變量、參數和返回類型，就可以解決項目中的很多編譯器錯誤。
延遲加載屬性
如果一個屬性的求值成本非常高，可以使用延遲加載模式。在使用這個模式時，如果私有字段為空，表示尚未生成字段的值。
C# 8可以很好地處理這種情況。在不改變代碼的情況下，它能夠正確地分析代碼，以確定getter的結果將始終非空，盡管返回的變量可以為空。
string? m_CSharpFullName;public string CSharpFullName{? ? get? ? {? ? ? ? if (m_CSharpFullName == null)? ? ? ? {? ? ? ? ? ? var result = new StringBuilder(m_TypeInfo.ToString().Length);? ? ? ? ? ? BuildCSharpFullName(m_TypeInfo.AsType(), null, result);? ? ? ? ? ? m_CSharpFullName = result.ToString();? ? ? ? }? ? ? ? return m_CSharpFullName;? ? }}需要注意的是，這里存在潛在的競態條件。理論上，另一個線程可以將m_CSharpFullName的值設置回null，而編譯器無法檢測到。因此，在處理多線程代碼時要特別小心。
一個變量的可空性由另一個變量決定
在下一個代碼示例中，當且僅當m_ItemPropertyChanged不為空時，m_ListeningToItemEvents才為true。編譯器無法知道這個規則。如果是這種情況，你可以將（!）附加到變量（在本例中為m_ItemPropertyChanged）后面，表示它在這個時間點不會為空。
if (m_ListeningToItemEvents){? ? if (item is INotifyPropertyChangedWeak)? ? ? ? ((INotifyPropertyChangedWeak)item).AddHandler(m_ItemPropertyChanged!);? ? else if (item is INotifyPropertyChanged)? ? ? ? ((INotifyPropertyChanged)item).PropertyChanged += OnItemPropertyChanged;}使用顯式強制轉換糾正誤報
在下一個示例中，編譯器錯誤地報告了m_Base的可空性。Values與IEnumerable的值不兼容。要移除這個警告，我添加了顯式強制轉換。
readonly Dictionary\u0026lt;ValueTuple\u0026lt;TKey1, TKey2\u0026gt;, TValue\u0026gt; m_Base;IEnumerable\u0026lt;TValue\u0026gt; IReadOnlyDictionary\u0026lt;ValueTuple\u0026lt;TKey1, TKey2\u0026gt;, TValue\u0026gt;.Values{? ? get { return (IEnumerable\u0026lt;TValue\u0026gt;)m_Base.Values; }}請注意編譯器將該行標記為具有冗余強制轉換。這是正常的編譯器消息，而不是警告，但希望在發布時能夠得到更正。
使用臨時變量或條件強制轉換糾正誤報
在下一個示例中，編譯器指出CancelEdit所在行存在一個錯誤。雖然前面的if語句證明item.Value不為空，但編譯器不相信下次讀取item.Value時它仍然是不為空。
foreach (var item in m_CheckpointValues){? ? if (item.Value is IEditableObject)? ? ? ? ((IEditableObject)item.Value).CancelEdit();}我們可以將item.Value保存在一個臨時變量中。
foreach (var item in m_CheckpointValues){? ? object? value = item.Value;? ? if (value is IEditableObject)? ? ? ? ((IEditableObject)value).CancelEdit();}對于這種情況，我們可以通過使用條件轉換（as操作符）后面跟上一個條件方法調用（?.操作符）進一步簡化它。
foreach (var item in m_CheckpointValues){? ? (item.Value as IEditableObject)?.CancelEdit();}泛型和可空類型
如果你經常使用泛型，可能會遇到一個有問題的可空類型。看一下這個delegate：
public delegate void ValueChanged\u0026lt;in T\u0026gt;(T oldValue, T newValue);這個delegate的預期設計是oldValue和newValue都可以為空。所以，你會認為加幾個問號就可以解決問題。但是，這樣做會返回下面這樣的錯誤消息：
Error CS8627 可空類型參數必須是值類型或非可空的引用類型。可以考慮添加“class”、“struct”或類型約束。
如果你需要同時支持值類型和引用類型，那么這個問題就沒那么容易解決。由于你無法在類型約束中表達“or”，你需要一個用于類的delegate和一個用于結構體的delegate。
public delegate void ValueChanged\u0026lt;in T\u0026gt;(T? oldValue, T? newValue) where T : class;public delegate void ValueChanged\u0026lt;T\u0026gt;(T? oldValue, T? newValue) where T : struct;但是，這樣不起作用，因為兩個delegate具有相同的名稱。你可以給它們起不一樣的名稱，但你必須復制使用它們的代碼。
所幸的是，C#有一個轉義值。你可以使用#nullable指令恢復成C #7的語義，這樣就可以達到預期的效果。
#nullable disablepublic delegate void ValueChanged\u0026lt;in T\u0026gt;(T oldValue, T newValue);#nullable enable這種方法并非沒有缺陷。禁用可空引用可能是個好東西，但也可能什么都不是。你無法用它來讓oldValue變成可空或讓newValue變成不可空。
構造函數、反序列化器和初始化方法
對于下一個示例，你必須知道序列化器的一些技巧。有一個鮮為人知的函數用來繞過一個叫作FormatterServices.GetUninitializedObject的類構造函數。一些序列化器（如DataContractSerializer）使用它來提高性能。
如果你總是要運行構造函數中的邏輯，應該怎么辦？這個時候需要用到OnDeserializing屬性。這個屬性充當在GetUninitializedObject之后調用的代理構造函數。
為了減少冗余和出錯的可能性，開發人員通常會使用常見的初始化方法，如下面的代碼所示。
protected AbstractModelBase(){? ? Initialize();}?[OnDeserializing]void _ModelBase_OnDeserializing(StreamingContext context){? ? Initialize();}void Initialize(){? ? m_PropertyChangedEventManager = new PropertyChangedEventManager(this);? ? m_Errors = new ErrorsDictionary();}這對null檢查器來說是個問題。由于構造函數中沒有顯式地設置上述兩個變量，因此它會把它們標記為未初始化。這意味著需要進行一些復制粘貼工作來移除這個錯誤。
還有一個風險，那就是忘記包含OnDeserializing方法。由于null檢查器不理解OnDeserializing方法，因此如果出現意外空值就無法提醒你。
大多數開發人員發現這種行為令人困惑。因此，在.NET Core中，DataContractSerializer將調用構造函數。但這意味著如果你的目標是.NET Standard，則需要使用.NET Framework和.NET Core測試反序列化代碼，以理解不同的行為。
可空參數和CallerMemberName
這個庫大量使用了CallerMemberName模式。根據它使用的屬性命名，基本思想是在方法的末尾添加一個可選參數。編譯器將看到CallerMemberName，并隱式地為該參數提供一個值。
public override bool IsDefined([CallerMemberName] string propertyName = null)從理論上講，propertyNameparameter可以顯式設置為null，但人們普遍認為不應該這樣做，因為這樣可能會發生意外的錯誤。
將這行代碼轉換為C# 8時，可能會想要將參數標記為可空。這樣具有誤導性，因為這個方法實際上并不是為處理空值而設計的。相反，你應該用空字符串替換null。
public override bool IsDefined([CallerMemberName] string propertyName = \u0026quot;\u0026quot;)還需要空參數檢查嗎？
如果要構建公共庫（即NuGet），那么是的，所有公開方法仍然需要檢查空參數。使用庫的應用程序可能不一定會使用可空引用類型。事實上，他們甚至可能根本不使用C# 8。
如果你的所有應用程序代碼都使用了可空引用類型，那么答案仍然是“可能是”。雖然從理論上講，你不會看到任何意外的空值，但由于動態代碼、反射或誤用（!）操作符，它們仍然可能會出現。
結論
在一個只有不到60個類文件的項目中，其中24個類文件需要更改。但沒有一個是特別重要的，整個過程花了不到一個小時。總之，這是一個無痛的過程，大多數事情都像預期的那樣。我希望大多數項目都能從這個特性中獲益，并且在C# 8發布后就應該使用這個特性。
關于作者
Jonathan Allen在90年代后期開始為一家醫療診所做MIS項目，逐步將Access和Excel應用到企業解決方案中。在花了五年時間為金融行業編寫自動化交易系統之后，他成為了多個項目的顧問，其中包括機器人倉庫的UI、癌癥研究軟件的中間層，以及一家大型房地產保險公司對大數據的需求。在他的空閑時間，他喜歡學習和寫作與16世紀武術相關的東西。
英文原文：https://www.infoq.com/articles/csharp-nullable-reference-case-study
數組)
