.NET Core 1.0-3.0 中的核心 .NET 程式庫中斷性變更

  • 發行項

核心 .NET 程式庫提供 .NET Core 所使用的主要和其他一般類型。

本頁面說明下列中斷性變更：

重大變更 導入的版本
將 GroupCollection 傳遞至採用 IEnumerable<T> 的擴充方法必須消除岐義 .NET Core 3.0
報告版本的 API 現在報告產品而不是檔案版本 .NET Core 3.0
自訂 EncoderFallbackBuffer 執行個體無法遞迴回復 .NET Core 3.0
浮點格式化和剖析行為變更 .NET Core 3.0
浮點剖析作業不再失敗或擲回 OverflowException .NET Core 3.0
InvalidAsynchronousStateException 移至另一個組件 .NET Core 3.0
遵循 Unicode 指導方針，取代格式不正確的 UTF-8 位元組序列 .NET Core 3.0
TypeDescriptionProviderAttribute 移至另一個組件 .NET Core 3.0
ZipArchiveEntry 不再處理項目大小不一致的封存 .NET Core 3.0
FieldInfo.SetValue 擲回靜態、僅限 init 欄位的例外狀況 .NET Core 3.0
路徑 API 不會針對無效字元擲回例外狀況 .NET Core 2.1
新增至內建結構類型的私人欄位 .NET Core 2.1
UseShellExecute 的預設值變更 .NET Core 2.1
macOS 上的 OpenSSL 版本 .NET Core 2.1
FileSystemInfo.Attributes 擲回的 UnauthorizedAccessException .NET Core 1.0
不支援處理損毀的流程狀態例外狀況 .NET Core 1.0
UriBuilder 屬性不再在前面加上前置字元 .NET Core 1.0
Process.StartInfo 會針對您未啟動的流程擲回 InvalidOperationException .NET Core 1.0

.NET Core 3.0

將 GroupCollection 傳遞至採用 IEnumerable<T> 的擴充方法必須消除岐義

在 GroupCollection 上呼叫採用 IEnumerable<T> 的擴充方法時，您必須使用轉換明確釐清該類型。

變更描述

從 .NET Core 3.0 開始，System.Text.RegularExpressions.GroupCollection 除了本身實作的其他類型外還會實作 IEnumerable<KeyValuePair<String,Group>>，包括 IEnumerable<Group>。 在呼叫採用 IEnumerable<T> 的擴充方法時，這會導致模棱兩可。 如果您在 GroupCollection 執行個體上呼叫這類擴充方法，例如 Enumerable.Count，則會看到下列編譯器錯誤：

CS1061：'GroupCollection' 不包含 'Count' 的定義，而且也找不到可存取的擴充方法 'Count' 來接受類型 'GroupCollection' 的第一個引數 (您是否遺漏了 using 指示詞或組件參考？)

在舊版的 .NET 中，沒有模棱兩可且沒有編譯器錯誤。

導入的版本

3.0

變更原因

這是意外的中斷性變更。 由於它像這樣已有一段時間，所以我們不打算還原它。 此外，這類變更本身會造成中斷。

針對 GroupCollection 執行個體，使用轉換釐清接受 IEnumerable<T> 的擴充方法呼叫。

// Without a cast - causes CS1061.
match.Groups.Count(_ => true)

// With a disambiguating cast.
((IEnumerable<Group>)m.Groups).Count(_ => true);

類別

Core .NET 程式庫

受影響的 API

任何接受 IEnumerable<T> 的擴充方法都會受到影響。 例如：

報告版本的 API 現在報告產品而不是檔案版本

許多在 .NET Core 中傳回版本的 API，現在會傳回產品版本，而不是檔案版本。

變更描述

在 .NET Core 2.2 和舊版本中，Environment.Version、RuntimeInformation.FrameworkDescription 之類的方法，以及 .NET Core 組件的檔案屬性對話方塊均反映檔案版本。 從 .NET Core 3.0 開始，會反映產品版本。

下圖說明在 .NET Core 2.2 (左側) 和 .NET Core 3.0 (右側) 中 System.Runtime.dll 組件的版本資訊差異，如 Windows 檔案總管的檔案屬性對話方塊所示。

Difference in product version information

導入的版本

3.0

無。 這項變更應該讓版本偵測直覺化，而不是模糊化。

類別

Core .NET 程式庫

受影響的 API

自訂 EncoderFallbackBuffer 執行個體無法遞迴回復

自訂 EncoderFallbackBuffer 執行個體無法遞迴回復。 EncoderFallbackBuffer.GetNextChar() 的實作必須產生可以轉換成目的地編碼的字元序列。 否則，會擲回例外狀況。

變更描述

在字元到位元組轉碼作業期間，執行階段會偵測格式錯誤或無法轉換的 UTF-16 序列，並將這些字元提供給 EncoderFallbackBuffer.Fallback 方法。 Fallback 方法會決定哪些字元應該取代原始不可轉換的資料，而且這些字元會藉由在迴圈中呼叫 EncoderFallbackBuffer.GetNextChar 來清空。

執行階段接著會嘗試將這些替代字元轉碼為目標編碼。 如果此作業成功，執行階段會繼續從原始輸入字串離開的位置轉碼。

先前，EncoderFallbackBuffer.GetNextChar() 的自訂實作可以傳回無法轉換成目的地編碼的字元序列。 如果替代字元無法轉碼為目標編碼，則執行階段會使用替代字元再一次叫用 EncoderFallbackBuffer.Fallback 方法，期待 EncoderFallbackBuffer.GetNextChar() 方法傳回新的替代序列。 此程序會繼續執行，直到執行階段最終看到格式正確的可轉換替代，或直到達到最大遞迴計數為止。

從 .NET Core 3.0 開始，EncoderFallbackBuffer.GetNextChar() 的自訂實作必須傳回可以轉換成目的地編碼的字元序列。 如果替代字元無法轉碼為目標編碼，則會擲回 ArgumentException。 執行階段將不再遞迴呼叫 EncoderFallbackBuffer 執行個體。

只有在符合下列三個條件時，才會套用此行為：

  • 執行階段偵測到格式不正確的 UTF-16 序列或無法轉換成目標編碼的 UTF-16 序列。
  • 已指定自訂 EncoderFallback。
  • 自訂 EncoderFallback 嘗試取代新的格式錯誤或無法轉換的 UTF-16 序列。

導入的版本

3.0

大部分的開發人員不需要採取任何動作。

如果應用程式使用自訂 EncoderFallback 和 EncoderFallbackBuffer 類別，請確定 EncoderFallbackBuffer.Fallback 的實作會在執行階段第一次叫用 Fallback 方法時，以格式正確的 UTF-16 資料填入後援緩衝區，而這些資料可直接轉換成目標編碼。

類別

Core .NET 程式庫

受影響的 API

浮點格式化和剖析行為變更

浮點剖析和格式化行為 (依 Double 和 Single 型表) 現在符合 IEEE 規範。 這可確保 .NET 中浮點類型的行為符合其他 IEEE 相容語言的行為。 例如，double.Parse("SomeLiteral") 應該一律符合 C# 在 double x = SomeLiteral 中產生的內容。

變更描述

在 .NET Core 2.2 和舊版中，使用 Double.ToString 和 Single.ToString 進行格式化，以及使用 Double.Parse、Double.TryParse、Single.Parse 和 Single.TryParse 進行剖析，不符合 IEEE 規範。 因此，無法保證值會以任何支援標準或自訂格式字串來回往返。 在某些輸入中，剖析格式化值的嘗試可能會失敗，而在其他輸入中，剖析的值不等於原始值。

從 .NET Core 3.0 開始，浮點剖析和格式化作業均符合 IEEE 754 規範。

下表顯示兩個程式碼片段，以及 .NET Core 2.2 和 .NET Core 3.1 之間的輸出變更。

程式碼片段 .NET Core 2.2 上的輸出 .NET Core 3.1 上的輸出
Console.WriteLine((-0.0).ToString()); 0 0-
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));		 False True

如需詳細資訊，請參閱 .NET Core 3.0 中的浮點剖析和格式化改善部落格文章。

導入的版本

3.0

在 .NET Core 3.0 中的浮點剖析和格式化改善部落格文章的對現存程式碼的潛在影響一節中，建議如果您想要維持之前的行為，可以對程式碼做一些變更。

  • 對於格式化的某些差異，您可以藉由指定不同的格式字串，取得與先前行為相等的行為。
  • 對於剖析的差異，沒有任何機制可以回復為先前的行為。

類別

Core .NET 程式庫

受影響的 API

浮點剖析作業不再失敗或擲回 OverflowException

當浮點剖析方法所剖析字串的數值不屬於 Single 或 Double 浮點類型時，就不會再擲回 OverflowException 或傳回 false。

變更描述

在 .NET Core 2.2 和舊版中，Double.Parse 和 Single.Parse 方法會針對不屬於其各自類型範圍的值擲回 OverflowException。 Double.TryParse and Single.TryParse 方法會針對超出數值範圍的字串表示，傳回 false。

從 .NET Core 3.0 開始，在剖析超出範圍的數值字串時，Double.Parse、Double.TryParse、Single.Parse 和 Single.TryParse 方法不再失敗。 針對超過 Double.MaxValue 的值，Double 剖析方法會改為傳回 Double.PositiveInfinity，以及針對小於 Double.MinValue 的值，傳回 Double.NegativeInfinity。 同樣地，針對超過 Single.MaxValue 的值，Single 剖析方法會傳回 Single.PositiveInfinity，且針對小於 Single.MinValue 的值，傳回 Single.NegativeInfinity。

這項變更是為了遵守改善後的 IEEE 754:2008 規範。

導入的版本

3.0

這項變更可能會以下列兩種方式之一影響您的程式碼：

  • 您的程式碼取決於 OverflowException 的處理常式，在發生溢位時執行。 在此情況下，您應該移除 catch 陳述式並將任何必要的程式碼放置在 If 陳述式，測試 Double.IsInfinity 或 Single.IsInfinity 是否為 true。

  • 您的程式碼假設浮點值不是 Infinity。 在此情況下，您應該新增必要的程式碼，以檢查 PositiveInfinity 和 NegativeInfinity 的浮點值。

類別

Core .NET 程式庫

受影響的 API

InvalidAsynchronousStateException 移至另一個組件

InvalidAsynchronousStateException 類別已移動。

變更描述

在 .NET Core 2.2 和舊版中，InvalidAsynchronousStateException 類別位於 System.ComponentModel.TypeConverter 組件中。

從 .NET Core 3.0 開始，位於 System.ComponentModel.Primitives 組件中。

導入的版本

3.0

只有使用反映並呼叫 Assembly.GetType 之類的方法來載入 InvalidAsynchronousStateException，或假設該類型是在特定組件而多載 Activator.CreateInstance 的應用程式，才會受到這項變更的影響。 如果是這種情況，請更新方法呼叫中參考的組件，以反映該類型的新組件位置。

類別

Core .NET 程式庫

受影響的 API

無。

遵循 Unicode 指導方針，取代格式不正確的 UTF-8 位元組序列

當類別 UTF8Encoding 在位元組對字元轉碼作業期間遇到格式不正確的 UTF-8 位元組序列時，會將輸出字串中的該序列取代為 '�' (U+FFFD 替換字元) 字元。 .NET Core 3.0 不同於舊版的 .NET Core 和 .NET Framework，在轉碼作業期間會依照 Unicode 最佳做法來執行這項取代。

這是在 .NET 中改善 UTF-8 處理作業的巨大工作中的一部分，包括利用新的 System.Text.Unicode.Utf8 和 System.Text.Rune 類型。 UTF8Encoding 類型已獲得改善的錯誤處理機制，使其產生與新建立類型一致的輸出。

變更描述

從 .NET Core 3.0 開始，將位元組轉碼為字元時，UTF8Encoding 類別會依據 Unicode 最佳做法執行字元替代。 如需使用的替代機制說明，請參閱 The Unicode Standard, Version 12.0, Sec. 3.9 (PDF) 中標題為 U+FFFD Substitution of Maximal Subparts 的章節。

只有在輸入位元組序列包含格式不正確的 UTF-8 資料時，才會套用此行為。 此外，如果 UTF8Encoding 執行個體已使用 throwOnInvalidBytes: true 建構，UTF8Encoding 執行個體將會繼續擲回無效輸入，而不是執行 U+FFFD 取代。 如需 UTF8Encoding 建構函式的詳細資訊，請參閱 UTF8Encoding(Boolean, Boolean)。

下表說明此變更對 3 位元組無效輸入的影響：

格式不正確的 3 位元組輸入 .NET Core 3.0 之前的輸出 從 .NET Core 3.0 開始的輸出
[ ED A0 90 ] [ FFFD FFFD ] (2 字元輸出) [ FFFD FFFD FFFD ] (3 字元輸出)

根據前面連結的 Unicode 標準 PDF 所提供的表 3-9，3 字元輸出是慣用輸出。

導入的版本

3.0

開發人員無須採取任何動作。

類別

Core .NET 程式庫

受影響的 API

TypeDescriptionProviderAttribute 移至另一個組件

TypeDescriptionProviderAttribute 類別已移動。

變更描述

在 .NET Core 2.2 和舊版中，TypeDescriptionProviderAttribute 類別位於 System.ComponentModel.TypeConverter 組件中。

從 .NET Core 3.0 開始，會位於 System.ObjectModel 組件中。

導入的版本

3.0

只有使用反映並呼叫 Assembly.GetType 之類的方法來載入 TypeDescriptionProviderAttribute 類型，或假設該類型是在特定組件而多載 Activator.CreateInstance 的應用程式，才會受到這項變更的影響。 如果是這種情況，應更新方法呼叫中參考的組件，以反映該類型的新組件位置。

類別

Windows Forms

受影響的 API

無。

ZipArchiveEntry 不再處理項目大小不一致的封存

Zip 封存會在中央目錄和本機標頭中列出壓縮大小和未壓縮大小。 項目資料本身也會指出其大小。 在 .NET Core 2.2 和舊版中，一律不會檢查這些值的一致性。 從 .NET Core 3.0 開始，現在會檢查了。

變更描述

在 .NET Core 2.2 和舊版中，即使本機標頭與 zip 檔案的中央標頭不一致，ZipArchiveEntry.Open() 仍會成功。 即使資料長度超過中央目錄/本機標頭列出的未壓縮檔案大小，仍會解壓縮到壓縮資料串流的結尾為止。

從 .NET Core 3.0 開始，ZipArchiveEntry.Open() 方法會檢查本機標頭和中央標頭中項目的壓縮和未壓縮大小是否一致。 如果不一致，則在封存的本機標頭和/或資料描述項列出的大小與 zip 檔案的中央目錄不符時，方法會擲回 InvalidDataException。 讀取項目時，解壓縮的資料會截斷為標頭中列出的未壓縮檔案大小。

這項變更是為了確保 ZipArchiveEntry 可以正確表示其資料的大小，以及只讀取該資料量。

導入的版本

3.0

重新封裝任何出現這些問題的 zip 封存。

類別

Core .NET 程式庫

受影響的 API

FieldInfo.SetValue 擲回靜態、僅限 init 欄位的例外狀況

從 .NET Core 3.0 開始，當您嘗試藉由呼叫 InitOnly 來設定靜態 System.Reflection.FieldInfo.SetValue 欄位的值時，就會擲回例外狀況。

變更描述

在 .NET Framework 和 3.0 之前的 .NET Core 版本中，您可以藉由呼叫 System.Reflection.FieldInfo.SetValue 來設定靜態欄位的值，該值在初始化後即保持不變 (在 C# 中為唯讀)。 不過，以此方式設定這類欄位會導致無法預測以目標架構和最佳化設定為基礎的行為。

在 .NET Core 3.0 和更新版本中，當您在靜態 InitOnly 欄位上呼叫 SetValue 時，會擲回 System.FieldAccessException 例外狀況。

提示

InitOnly 欄位是只能在宣告時或在內含類別的建構函式中設定的欄位。 換句話說，它會在初始化之後保持不變。

導入的版本

3.0

在靜態建構函式中初始化靜態 InitOnly 欄位。 這同時適用於動態和非動態類型。

或者，您也可以從欄位中移除 FieldAttributes.InitOnly 屬性，然後呼叫 FieldInfo.SetValue。

類別

Core .NET 程式庫

受影響的 API

.NET Core 2.1

Path API 不會針對無效字元擲回例外狀況

涉及檔案路徑的 API，已不再會驗證路徑字元，或在偵測到無效字元時擲回 ArgumentException。

變更描述

在 .NET Framework 和 .NET Core 1.0 - 2.0 中，若 path 引數包含無效的路徑字元，受影響的 API 區段中所列的方法，將會擲回 ArgumentException。 自 .NET Core 2.1 起，這些方法已不再會檢查無效的路徑字元，或在偵測到無效字元時，擲回例外狀況。

變更原因

積極驗證路徑字元會造成某些跨平台案例窒礙難行。 進行這項變更之後，.NET 將不再嘗試複寫或預測作業系統 API 呼叫的結果。 如需詳細資訊，請參閱 .NET Core 2.1 中的 System.IO 搶先看部落格文章。

導入的版本

.NET Core 2.1

若您的程式碼仍須透過這些 API 檢查無效的字元，可以新增對 Path.GetInvalidPathChars 的呼叫。

受影響的 API

另請參閱

新增至內建結構類型的私人欄位

私人欄位已新增至參考元件中的特定結構類型。 因此在 C# 中，這些建構類型一律需要使用 new 運算子或預設常值加以具現化。

變更描述

在 .NET Core 2.0 和舊版中，所提供的一些結構類型 (例如 ConsoleKeyInfo) 在 C# 中無須使用 new 運算子或預設常值，就能具現化。 這是因為 C# 編譯器使用的參考元件不含結構的私人欄位。 .NET 結構類型的所有私人欄位自 .NET Core 2.1 起，都已新增至參考元件。

例如下列 C# 程式碼會在 .NET Core 2.0 中編譯，而不在 .NET Core 2.1 中編譯：

ConsoleKeyInfo key;    // Struct type

if (key.ToString() == "y")
{
    Console.WriteLine("Yes!");
}

在 .NET Core 2.1 中，舊版的程式碼會引發下列編譯器錯誤：CS0165 - 使用未指派的區域變數 'key'

導入的版本

2.1

使用 new 運算子或預設常值具現化結構類型。

例如：

ConsoleKeyInfo key = new ConsoleKeyInfo();    // Struct type.

if (key.ToString() == "y")
    Console.WriteLine("Yes!");

ConsoleKeyInfo key = default;    // Struct type.

if (key.ToString() == "y")
    Console.WriteLine("Yes!");

類別

Core .NET 程式庫

受影響的 API

UseShellExecute 的預設值變更

ProcessStartInfo.UseShellExecute 在 .NET Core 上的預設值為 false。 在 .NET Framework 上，其預設值為 true。

變更描述

例如，Process.Start 可讓您使用啟動 Paint 的 Process.Start("mspaint.exe") 之類的程式碼直接啟動應用程式。 如果 ProcessStartInfo.UseShellExecute 設定為 true，這也可讓您間接啟動相關聯的應用程式。 在 .NET Framework 上，ProcessStartInfo.UseShellExecute 的預設值為 true，這表示如果您已將 .txt 檔案與「記事本」相關聯，Process.Start("mytextfile.txt") 之類的程式碼便會啟動該編輯器。 若要防止在 .NET Framework 上間接啟動應用程式，您必須明確地將 ProcessStartInfo.UseShellExecute 設定為 false。 在 .NET Core 上，ProcessStartInfo.UseShellExecute 的預設值為 false。 這表示您呼叫 Process.Start 時，預設不會啟動相關聯的應用程式。

只有在 ProcessStartInfo.UseShellExecute 是 true 時，System.Diagnostics.ProcessStartInfo 上的下列屬性才有作用：

基於效能考量，.NET Core 中已引入此變更。 一般而言，Process.Start 用來直接啟動應用程式。 直接啟動應用程式不需要涉及 Windows 殼層並產生相關聯的效能成本。 為了加快此預設案例的速度，.NET Core 將 ProcessStartInfo.UseShellExecute 的預設值變更為 false。 如有需要，您可以選擇加入較慢的路徑。

導入的版本

2.1

注意

舊版的 .NET Core 並未針對 Windows 實作 UseShellExecute。

如果您的應用程式依賴舊行為，請使用在 ProcessStartInfo 物件設定為 true 的 UseShellExecute 呼叫 Process.Start(ProcessStartInfo)。

類別

Core .NET 程式庫

受影響的 API

macOS 上的 OpenSSL 版本

macOS 上的 .NET Core 3.0 及更新版本的執行階段，對於 AesCcm、AesGcm、DSAOpenSsl、ECDiffieHellmanOpenSsl、ECDsaOpenSsl、RSAOpenSsl 和 SafeEvpPKeyHandle 類型，仍會優先使用 OpenSSL 1.1.x 版至 OpenSSL 1.0.x 版。

.NET Core 2.1 執行階段現在已支援 OpenSSL 1.1.x 版，但仍會優先使用 OpenSSL 1.0.x 版。

變更描述

早先 .NET Core 執行階段 macOS 上對於和 OpenSSL 互動的類型，會使用 OpenSSL 1.0.x 版。 目前已不支援最新的 OpenSSL 1.0.x 版和 OpenSSL 1.0.2。 為維持使用 OpenSSL 的類型使用支援的 OpenSSL 版本，.NET Core 3.0 及更新版本的執行階段現在會在 macOS 上使用較新版本的 OpenSSL。

這項變更促使 macOS 上 .NET Core 執行階段的行為執行如下：

  • 如有提供 OpenSSL 1.1.x，.NET Core 3.0 及更新版本的執行階段會使用 OpenSSL 1.1.x，只有在未提供 1.1.x 版的情況下，才會回復為 OpenSSL 1.0.x。

    對於使用 OpenSSL Interop 搭配自訂 P/Invokes 的呼叫端，請遵循 SafeEvpPKeyHandle.OpenSslVersion 備註中的指引作業。 若未檢查 OpenSslVersion 值，您的應用程式可能損毀。

  • 如有提供 OpenSSL 1.0.x，.NET Core 2.1 執行階段會使用 OpenSSL 1.0.x；若無 1.0.x 版，才會回復為 OpenSSL 1.1.x。

    2.1 執行階段會優先使用舊版的 OpenSSL 1.0.x。這是因為 .NET Core 2.1 沒有 SafeEvpPKeyHandle.OpenSslVersion 屬性，以致於無法在執行時準確判斷 OpenSSL 版本。

導入的版本

  • .NET Core 2.1.16
  • .NET Core 3.0.3
  • .NET Core 3.1.2

類別

Core .NET 程式庫

受影響的 API

.NET Core 1.0

FileSystemInfo.Attributes 擲回的 UnauthorizedAccessException

在 .NET Core 中，當呼叫端嘗試設定檔案屬性值卻沒有寫入權限時，系統會擲回 UnauthorizedAccessException。

變更描述

在 .NET Framework 中，當呼叫端嘗試在 FileSystemInfo.Attributes 中設定檔案屬性值卻沒有寫入權限時，系統會擲回 ArgumentException。 在 .NET Core 中，則會改為擲回 UnauthorizedAccessException。 (在 .NET Core 中，如果呼叫端嘗試設定不正確的檔案屬性，則仍會擲回 ArgumentException。)

導入的版本

1.0

視需要修改任何 catch 陳述式以攔截 UnauthorizedAccessException 而不是視需要改為攔截或另外攔截 ArgumentException。

類別

Core .NET 程式庫

受影響的 API

不支援處理損毀的狀態例外狀況

不支援在 .NET Core 中處理損毀的流程狀態例外狀況。

變更描述

先前，在 C# 中使用 try-catch 陳述式，即可攔截並處理受控程式碼例外狀況處理常式的損毀流程狀態例外狀況。

從 .NET Core 1.0 開始，受控程式碼無法處理損毀的流程狀態例外狀況。 通用語言執行平台不會將損毀的流程狀態例外狀況傳遞給受控程式碼。

導入的版本

1.0

藉由解決導致這些例外狀況的情況，避免處理損毀的流程狀態例外狀況。 如果絕對需要處理損毀的流程狀態例外狀況，請在 C 或 C++ 程式碼中撰寫例外狀況處理常式。

類別

Core .NET 程式庫

受影響的 API

UriBuilder 屬性不再在前面加上前置字元

已經有前置字元時，UriBuilder.Fragment 不再在前面加上前置 # 字元，而且 UriBuilder.Query 不再在前面加上前置 ? 字元。

變更描述

在 .NET Framework 中，UriBuilder.Fragment 和 UriBuilder.Query 屬性一律會分別在儲存的值前面加上 # 或 ? 字元。 如果字串已經包含其中一個前置字元，這種行為可能會導致預存值中的多個 # 或 ? 字元。 例如，UriBuilder.Fragment 的值可能會變成 ##main。

從 .NET Core 1.0 開始，如果字串開頭已有字元，這些屬性就不會再在預存值前面加上 # 或 ? 字元。

導入的版本

1.0

設定屬性值時，您不再需要明確移除上述任何前置字元。 您附加值時，這特別有用，因為每次附加時您不再需要移除前置 # 或 ?。

例如，下列程式碼片段顯示 .NET Framework 與 .NET Core 之間的行為差異。

var builder = new UriBuilder();
builder.Query = "one=1";
builder.Query += "&two=2";
builder.Query += "&three=3";
builder.Query += "&four=4";

Console.WriteLine(builder.Query);
  • 在 .NET Framework 中，輸出為 ????one=1&two=2&three=3&four=4。
  • 在 .NET Core 中，輸出為 ?one=1&two=2&three=3&four=4。

類別

Core .NET 程式庫

受影響的 API

Process.StartInfo 會針對您未啟動的流程擲回 InvalidOperationException

對於程式碼未啟動的流程讀取 Process.StartInfo 屬性會擲回 InvalidOperationException。

變更描述

在 .NET Framework 中，對於程式碼未啟動的流程存取 Process.StartInfo 屬性會傳回虛擬 ProcessStartInfo 物件。 虛擬物件包含其中所有屬性的預設值，但 EnvironmentVariables 除外。

從 .NET Core 1.0 開始，如果您對於未啟動的流程讀取 Process.StartInfo 屬性 (也就是藉由呼叫 Process.Start)，就會擲回 InvalidOperationException。

導入的版本

1.0

請勿對於程式碼未啟動的流程存取 Process.StartInfo 屬性。 例如，請勿對於 Process.GetProcesses 傳回的流程讀取此屬性。

類別

Core .NET 程式庫

受影響的 API