將移轉至 .NET Framework 4.6.x 的重定目標變更

本文列出 .NET Framework 4.6、4.6.1 和 4.6.2 中介紹的應用程式相容性問題。

.NET Framework 4.6

ASP.NET

HtmlTextWriter 無法正確轉譯 <br/> 項目

詳細資料

從 .NET Framework 4.6 開始，使用 <BR /> 項目呼叫 RenderBeginTag(String) 和 RenderEndTag() 將會正確地只插入一個 <BR /> (而不是兩個)

建議

如果應用程式需要額外的 <BR /> 標籤，則應該再次呼叫 RenderBeginTag(String)。 請注意，這項行為變更只會影響以 .NET Framework 4.6 或更新版本為目標的應用程式，因此另一個做法是以舊版 .NET Framework 為目標，以取得舊版行為。

名稱	值
範圍	Edge
版本	4.6
類型	正在重定目標

受影響的 API

• HtmlTextWriter.RenderBeginTag(String)
• HtmlTextWriter.RenderBeginTag(HtmlTextWriterTag)

ClickOnce

透過 ClickOnce 發行的應用程式，這些應用程式使用可能會在 Windows 2003 上失敗的 SHA-256 程式碼簽署憑證

詳細資料

這個可執行檔使用 SHA256 簽署。 之前，不論程式碼簽署憑證為 SHA-1 或 SHA-256，都會使用 SHA1 簽署。 這適用於：

• 使用 Visual Studio 2012 (含) 以後版本建置的所有應用程式。
• 使用 Visual Studio 2010 (含) 以前版本，在具有 .NET Framework 4.5 的系統上建置應用程式。 此外，如果有 .NET Framework 4.5 (含) 以後版本，也會針對 SHA-256 憑證使用 SHA-256 來簽署 ClickOnce 資訊清單，而不論編譯的 .NET Framework 版本為何。

建議

對簽署 ClickOnce 可執行檔所做的變更只會影響 Windows Server 2003 系統；這些變更需要安裝 KB 938397。 對使用 SHA-256 簽署資訊清單所做的變更還會引進 .NET Framework 4.5 (含) 以後版本的執行階段相依性，即使應用程式是以 .NET Framework 4.0 (含) 以前版本為目標亦然。

名稱	值
範圍	Edge
版本	4.5
類型	正在重定目標

ClickOnce 在 4.0 為目標的應用程式上支援 SHA-256

詳細資料

先前，具有使用 SHA-256 簽署之憑證的 ClickOnce 應用程式，需要有 .NET Framework 4.5 或更新版本存在，即使應用程式是以 4.0 為目標。 現在，即使使用 SHA-256 簽署，以 .NET Framework 4.0 為目標的 ClickOnce 應用程式也可以在 .NET Framework 4.0 上執行。

建議

這項變更移除了該相依性，並允許使用 SHA-256 憑證來簽署以 .NET Framework 4 和更早版本為目標的 ClickOnce 應用程式。

名稱	值
範圍	Minor
版本	4.6
類型	正在重定目標

核心

工作之間的 CurrentCulture 和 CurrentUICulture 流程

詳細資料

從 .NET Framework 4.6 開始，System.Globalization.CultureInfo.CurrentCulture 和 System.Globalization.CultureInfo.CurrentUICulture 會儲存在執行緒的 System.Threading.ExecutionContext，它會在非同步作業之間流動。這表示變更 System.Globalization.CultureInfo.CurrentCulture 或 System.Globalization.CultureInfo.CurrentUICulture 會反映在稍後以非同步方式執行的工作。 這與舊版 .NET Framework 的行為不同，而舊版本會重設所有非同步工作中的 System.Globalization.CultureInfo.CurrentCulture 和 System.Globalization.CultureInfo.CurrentUICulture。

建議

受到此變更影響的應用程式，可以藉由明確地設定所需的 System.Globalization.CultureInfo.CurrentCulture 或 System.Globalization.CultureInfo.CurrentUICulture 作為非同步工作中的第一個作業來因應。 或者，可以藉由設定下列相容性參數，以選擇加入舊的行為 (不流動 System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture)：

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

.NET Framework 4.6.2 中的 WPF 已修正此問題。 .NET Frameworks 4.6、4.6.1 也已透過 KB 3139549 進行修正。 以 .NET Framework 4.6 或更新版本為目標的應用程式將在 WPF 應用程式中自動取得正確的行為 - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture 會跨發送器作業保留。

名稱	值
範圍	Minor
版本	4.6
類型	正在重定目標

受影響的 API

• CultureInfo.CurrentCulture
• Thread.CurrentCulture
• CultureInfo.CurrentUICulture
• Thread.CurrentUICulture

ETW 事件名稱不能只有 "Start" 或 "Stop" 尾碼不同

詳細資料

在 .NET Framework 4.6 和 4.6.1 中，當兩個 Windows 事件追蹤 (ETW) 事件名稱的差異只在「Start」或「Stop」尾碼時 (例如當一個事件的名稱為 LogUser 而另一個事件的名稱為 LogUserStart 時)，執行階段會擲回 ArgumentException。 在此情況下，執行階段無法建構事件來源，因此無法發出任何記錄。

建議

若要避免這個例外狀況，請確定沒有兩個事件的名稱差異只在「Start」或「Stop」尾碼。從 .NET Framework 4.6.2 開始已移除這項需求；執行階段可以釐清差異只在於「Start」或「Stop」尾碼的事件名稱。

名稱	值
範圍	Edge
版本	4.6
類型	正在重定目標

Entity Framework

如果使用 EntityDeploySplit 或 EntityClean 工作，以 Visual Studio 2013 建置 Entity Framework edmx 可能會失敗，並出現錯誤 MSB4062

詳細資料

MSBuild 12.0 工具 (隨附於 Visual Studio 2013) 已變更 MSBuild 檔案位置，導致舊版 Entity Framework 的目標檔案無效。 結果是 EntityDeploySplit 和 EntityClean 工作會失敗，因為找不到 Microsoft.Data.Entity.Build.Tasks.dll。 請注意，造成此中斷的原因是工具組 (MSBuild/VS) 變更，而不是 .NET Framework 變更。 只有在升級開發人員工具時才會發生此情況，若只是升級 .NET Framework 則不會發生。

建議

Entity Framework 的目標檔案已修正，從 .NET Framework 4.6 開始，可搭配新的 MSBuild 配置使用。 升級至該版 Framework 將會修正此問題。 或者，您也可以使用此因應措施來直接修補目標檔案。

名稱	值
範圍	主修
版本	4.5.1
類型	正在重定目標

JIT

try 區域中不允許 IL ret

詳細資料

不同於 JIT64 Just-In-Time 編譯器，RyuJIT (用於 .NET Framework 4.6) 不允許在 try 區域中使用 IL ret 指令。 ECMA-335 規格不允許從 try 區域傳回，而且不會有已知的受控編譯器產生這類 IL。 不過，如果這類 IL 是由反映發出所產生，則 JIT64 編譯器將會執行這類 IL。

建議

如果應用程式產生在 try 區域中包含 ret opcode 的 IL，應用程式可以 .NET Framework 4.5 為目標，即可使用舊的 JIT，以避免這項中斷。 或者，可以將產生的 IL 更新為在 try 區域之後傳回。

名稱	值
範圍	Edge
版本	4.6
類型	正在重定目標

.NET Framework 4.6 中的新 64 位元 JIT 編譯器

詳細資料

從 .NET Framework 4.6 開始，使用新的 64 位元 JIT 編譯器來進行 Just-In-Time 編譯。 在某些情況下，如果使用 32 位元編譯器或舊版 64 位元 JIT 編譯器來執行應用程式，則會擲回非預期的例外狀況或遵守不同的行為。 這項變更不會影響 32 位元 JIT 編譯器。 下列是已知的差異︰

• 在某些情況下，已開啟最佳化的發行組建中的 Unboxing 作業可能會擲回 NullReferenceException。
• 在某些情況下，執行大型方法主體中的實際執行程式碼可能會擲回 StackOverflowException。
• 某些狀況下，發行組建中傳遞至方法的結構會被視為參考型別而非實值型別。 這個問題的其中一種表現，就是集合中的個別項目會以非預期的順序出現。
• 在某些情況下，如果啟用最佳化，UInt16 的值在設定高位元時的比較會不正確。
• 在某些情況下，尤其是初始化陣列值時，使用 OpCodes.Initblk IL 指令初始化記憶體，可能會以不正確的值初始化記憶體。 這會造成未處理的例外狀況或不正確的輸出。
• 在少數情況下，如果啟用編譯器最佳化，條件式位元測試可能會傳回不正確的 Boolean 值或擲回例外狀況。
• 某些狀況下，如果使用 if 陳述式在進入 try 區塊之前和自 try 區塊退出時測試某項條件，而且也在 catch 或 finally 區塊中評估該條件時，新版 64 位元 JIT 編譯器在最佳化程式碼時會將 if 條件自 catch 或 finally 區塊中移除。 因此，catch 或 finally 區塊的 if 陳述式中的程式碼會無條件執行。

建議

降低已知問題的風險
如果您遇到上述問題，可以採取以下任一種方式來解決︰

• 升級至 .NET Framework 4.6.2。 隨附於 .NET Framework 4.6.2 中的新版 64 位元編譯器可以解決這些已知問題。

• 執行 Windows Update，確定您的 Windows 已更新至最新版本。 .NET Framework 4.6 和 4.6.1 的服務更新可解決上述問題中除了 Unboxing 作業之 NullReferenceException 以外的所有問題。

• 使用舊版 64 位元 JIT 編譯器編譯。 如需如何進行的詳細資訊，請參閱降低其他問題的風險一節。 降低其他問題的風險
  如果舊版和新版 64 位元 JIT 編譯器編譯的程式碼之間有任何差異，或是使用新版 64 位元 JIT 編譯器編譯的應用程式偵錯版本和發行版本之間有任何差異，您可以使用舊版 64 位元 JIT 編譯器搭配下列方式來編譯應用程式：

• 若以每一應用程式為基礎，您可以將 < 項目新增至應用程式的組態檔。 下列程式碼會停止以新版 64 位元 JIT 編譯器進行編譯，改用舊版 64 位元 JIT 編譯器。

  <?xml version ="1.0"?>
  <configuration>
    <runtime>
     <useLegacyJit enabled="1" />
    </runtime>
  </configuration>
  

• 若以每一使用者為基礎，您可以將名為 useLegacyJit 的 REG_DWORD 值加入至登錄的 HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework 索引鍵。 值為 1 會啟用舊版 64 位元 JIT 編譯器；值為 0 會停用它，並啟用新版 64 位元 JIT 編譯器。

• 若以每一電腦為基礎，您可以將名為 useLegacyJit 的 REG_DWORD 值加入至登錄的 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework 索引鍵。 值為 1 會啟用舊版 64 位元 JIT 編譯器；值為 0 會停用它，並啟用新版 64 位元 JIT 編譯器。 您也可以前往 Microsoft Connect 回報錯誤，讓我們知道問題所在。

名稱	值
範圍	Edge
版本	4.6
類型	正在重定目標

網路

憑證 EKU OID 驗證

詳細資料

從 .NET Framework 4.6 開始，SslStream 或 ServicePointManager 類別會執行增強金鑰使用方法 (EKU) 物件識別碼 (OID) 驗證。 增強金鑰使用方法 (EKU) 延伸模組是表示使用金鑰之應用程式的物件識別碼 (OID) 集合。 EKU OID 驗證會使用遠端憑證回呼，以確保遠端憑證有用於預定目的的正確 OID。

建議

如果不需要這項變更，您可以在程式應用程式設定檔的 ` 中新增下列參數到 <AppContextSwitchOverrides>，停用憑證 EKU OID 驗證：

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontCheckCertificateEKUs=true" />
</runtime>

重要

提供此設定的目的，只是為了回溯相容性。 不建議用於其他用途。

名稱	值
範圍	Minor
版本	4.6
類型	正在重定目標

受影響的 API

• System.Net.Security.SslStream
• System.Net.ServicePointManager
• System.Net.Http.HttpClient
• System.Net.Mail.SmtpClient
• System.Net.HttpWebRequest
• System.Net.FtpWebRequest

在 System.Net.ServicePointManager 和 System.Net.Security.SslStream 只支援 Tls 1.0、1.1 及 1.2 通訊協定

詳細資料

從 .NET Framework 4.6 開始，只有 ServicePointManager 和 SslStream 類別可以使用 Tls1.0、Tls1.1 或 Tls 1.2 這三種通訊協定之一。 不支援 SSL3.0 通訊協定與 RC4 編碼器。

建議

建議的緩和措施是將伺服器端應用程式升級至 Tls1.0、Tls1.1 或 Tls1.2。 如果這並不可行，或是用戶端應用程式已中斷，則可使用 System.AppContext 類別搭配下列兩種方式之一，停用這項功能：

• 以程式設計方式設定 System.AppContext 的相容性參數，如這裡所述。
• 將下列程式行加入至 app.config 檔案的 <runtime> 區段：

<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>

名稱	值
範圍	Minor
版本	4.6
類型	正在重定目標

受影響的 API

• SecurityProtocolType.Ssl3
• SslProtocols.None
• SslProtocols.Ssl2
• SslProtocols.Ssl3

TLS 1.x 依預設會將 SCH_SEND_AUX_RECORD 旗標傳遞至基礎的 SCHANNEL API

詳細資料

使用 TLS 1.x 時，.NET Framework 依賴基礎的 Windows SCHANNEL API。 從 .NET Framework 4.6 開始，預設會傳遞 SCH_SEND_AUX_RECORD 旗標給 SCHANNL。 這會導致 SCHANNEL 分割資料，以便加密成兩個不同的記錄，第一個是單一位元組，第二個則是 n-1 個位元組。 在罕見的情況下，這會中斷用戶端與假設資料位於單一記錄中的現有伺服器之間的通訊。

建議

如果這項變更會中斷與現有伺服器的通訊，您可以停用傳送 SCH_SEND_AUX_RECORD 旗標，並還原先前的行為，不將資料分割成個別的記錄，其方法是新增下列參數到應用程式組態檔 <runtime> 區段中的 <AppContextSwitchOverrides> 項目：

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchSendAuxRecord=true" />
</runtime>

重要

提供此設定的目的，只是為了回溯相容性。 不建議用於其他用途。

名稱	值
範圍	Edge
版本	4.6
類型	正在重定目標

受影響的 API

• System.Net.Security.SslStream
• System.Net.ServicePointManager
• System.Net.Http.HttpClient
• System.Net.Mail.SmtpClient
• System.Net.HttpWebRequest
• System.Net.FtpWebRequest

Windows Communication Foundation (WCF)

使用 Null 引數呼叫 CreateDefaultAuthorizationContext 已變更

詳細資料

使用 Null authorizationPolicies 引數呼叫 System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) 所傳回的 System.IdentityModel.Policy.AuthorizationContext 實作，已變更其在 .NET Framework 4.6 中的實作。

建議

在少數情況下，使用自訂驗證的 WCF 應用程式，在行為上可能會有些許差異。 在此情況下，您可使用下列兩種方式之一還原舊版行為：

• 以 .NET Framework 4.6 之前的舊版為目標，重新編譯您的應用程式。 對於裝載在 IIS 上的服務，請使用 <httpRuntime targetFramework="x.x"> 項目，將目標設為舊版 .NET Framework。

• 將下列行加入 app.config 檔案中的 <appSettings> 區段：

  <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />
  

名稱	值
範圍	Minor
版本	4.6
類型	正在重定目標

受影響的 API

• AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>)

Windows Forms

Icon.ToBitmap 成功將具有 PNG 畫面格的圖示轉換成點陣圖物件

詳細資料

從以 .NET Framework 4.6 為目標的應用程式開始，Icon.ToBitmap 方法可將具有 PNG 框架的圖示成功轉換成點陣圖物件。

在以 .NET Framework 4.5.2 (含) 之前版本為目標的應用程式中，如果圖示物件具有 PNG 框架，則 Icon.ToBitmap 方法會擲回 ArgumentOutOfRangeException 例外狀況。

這項變更會影響重新撰寫之以 .NET Framework 4.6 為目標的應用程式，以及針對圖示物件具有 PNG 框架時所擲回的 ArgumentOutOfRangeException 實作特殊處理的應用程式。 以 .NET Framework 4.6 執行時，轉換會成功，且不再擲回 ArgumentOutOfRangeException ，因此不會再叫用例外狀況處理常式。

建議

如果不需要這項行為，您可以在 app.config 檔案的 <runtime> 區段中新增下列項目，以保留舊版行為：

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true" />

如果 app.config 檔案已經包含 AppContextSwitchOverrides 項目，則應以下列程式碼將新值與值屬性合併：

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true;<previous key>=<previous value>" />

名稱	值
範圍	Minor
版本	4.6
類型	正在重定目標

受影響的 API

• Icon.ToBitmap()

Windows Presentation Foundation (WPF)

CurrentCulture 無法跨 WPF 發送器作業保留

詳細資料

從 .NET Framework 4.6 開始，在 System.Windows.Threading.Dispatcher 內對 System.Globalization.CultureInfo.CurrentCulture 或 System.Globalization.CultureInfo.CurrentUICulture 所做的變更，將會在發送器作業結束時遺失。 同樣地，在發送器作業外部對 System.Globalization.CultureInfo.CurrentCulture 或 System.Globalization.CultureInfo.CurrentUICulture 所做的變更，不會在執行該作業時反映出來。實際上，這表示 System.Globalization.CultureInfo.CurrentCulture 和 System.Globalization.CultureInfo.CurrentUICulture 變更可能不會在 WPF UI 回呼與 WPF 應用程式的其他程式碼之間流動。這是因為從以 .NET Framework 4.6 為目標的應用程式開始，System.Threading.ExecutionContext 的變更會導致 System.Globalization.CultureInfo.CurrentCulture 和 System.Globalization.CultureInfo.CurrentUICulture 儲存在執行內容中。 WPF 發送器作業會儲存用來開始作業的執行內容，並在作業完成時還原先前的內容。 因為 System.Globalization.CultureInfo.CurrentCulture 和 System.Globalization.CultureInfo.CurrentUICulture 現在是該內容的一部分，所以在發送器作業內對其進行的變更不會保留到作業外。

建議

您可以將所需的 System.Globalization.CultureInfo.CurrentCulture 或 System.Globalization.CultureInfo.CurrentUICulture 儲存在欄位中，然後簽入設定正確 System.Globalization.CultureInfo.CurrentCulture 和 System.Globalization.CultureInfo.CurrentUICulture 的所有發送器作業主體 (包括 UI 事件回呼處理常式)，來解決受此變更影響的應用程式。 此外，由於此 WPF 變更的基本 ExecutionContext 變更只會影響以 .NET Framework 4.6 或更新版本為目標的應用程式，因此您可以將目標設為 .NET Framework 4.5.2 來避免此中斷情況。以 .NET Framework 4.6 或更新版本為目標的應用程式，也可以設定下列相容性參數來解決此問題：

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

.NET Framework 4.6.2 中的 WPF 已修正此問題。 .NET Frameworks 4.6、4.6.1 也已透過 KB 3139549 進行修正。 以 .NET Framework 4.6 或更新版本為目標的應用程式將在 WPF 應用程式中自動取得正確的行為 - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture 會跨發送器作業保留。

名稱	值
範圍	Minor
版本	4.6
類型	正在重定目標

邊界的 WPF 版面配置進位已變更

詳細資料

邊界的進位方式以及邊界內部的框線和背景皆有所變更。 此變更的結果：

• 項目寬度或高度的增減最多不超過一個像素。
• 物件的位置的位最多不超過一個像素。
• 置中項目的垂直或水平位移最多不超過一個像素。 預設只有以 .NET Framework 4.6 為目標的應用程式才會啟用此新版面配置。

建議

由於此修改會停用高 DPI 之 WPF 控制項右側或底端的裁剪功能，因此，應用程式若是以舊版 .NET Framework 為目標，但要在 .NET Framework 4.6 上執行，可將下行加入 app.config 檔案中的 <runtime> 區段來選擇使用此新行為：

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=false" />

應用程式若是以 .NET Framework 4.6 為目標，但想使用先前的配置演算法來呈現 WPF 控制項，可將下行新增至 app.config 檔案中的 <runtime> 區段，以執行此作業：

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=true" />

名稱	值
範圍	Minor
版本	4.6
類型	正在重定目標

XML、XSLT

無效的代理字組會擲回 XmlWriter

詳細資料

針對以 .NET Framework 4.5.2 或之前版本為目標的應用程式，使用例外狀況後援處理寫入無效的 Surrogate 字組時不一定每次都會擲回例外狀況。 針對以 .NET Framework 4.6 為目標的應用程式，嘗試寫入無效的代理字組會擲回 System.ArgumentException 例外狀況。

建議

如有必要，可以將目標設為 .NET Framework 4.5.2 或更早版本以避免這項中斷。 或者，可以將無效的代理字組字組預先處理成有效的 XML，再寫入它們。

名稱	值
範圍	Edge
版本	4.6
類型	正在重定目標

受影響的 API

• XmlWriter.WriteAttributeString(String, String)
• XmlWriter.WriteAttributeString(String, String, String)
• XmlWriter.WriteAttributeString(String, String, String, String)
• XmlWriter.WriteAttributeStringAsync(String, String, String, String)
• XmlWriter.WriteCData(String)
• XmlWriter.WriteCDataAsync(String)
• XmlWriter.WriteChars(Char[], Int32, Int32)
• XmlWriter.WriteCharsAsync(Char[], Int32, Int32)
• XmlWriter.WriteComment(String)
• XmlWriter.WriteCommentAsync(String)
• XmlWriter.WriteEntityRef(String)
• XmlWriter.WriteEntityRefAsync(String)
• XmlWriter.WriteRaw(Char[], Int32, Int32)
• XmlWriter.WriteProcessingInstruction(String, String)
• XmlWriter.WriteProcessingInstructionAsync(String, String)
• XmlWriter.WriteRaw(String)
• XmlWriter.WriteRawAsync(Char[], Int32, Int32)
• XmlWriter.WriteRawAsync(String)
• XmlWriter.WriteString(String)
• XmlWriter.WriteStringAsync(String)
• XmlWriter.WriteSurrogateCharEntity(Char, Char)
• XmlWriter.WriteSurrogateCharEntityAsync(Char, Char)
• XmlWriter.WriteValue(String)

如果使用複合索引鍵，而且一個索引鍵為空白，XSD 結構描述驗證現在會正確地偵測唯一條件約束的違規

詳細資料

.NET Framework 4.6 之前的版本有錯誤 (bug)，會導致 XSD 驗證在其中一個索引鍵為空白時，無法偵測複合索引鍵上的唯一條件約束。 在 .NET Framework 4.6 中，已修正此問題。 這會導致更正確的驗證，但也可能會導致之前可驗證的某些 XML 無法驗證。

建議

如果需要較鬆散的 .NET Framework 4.0 驗證，正在驗證的應用程式可以將目標設為 .NET Framework 4.5 版 (或舊版)。 不過，重定目標為 .NET Framework 4.6 時，應完成程式碼檢閱，以確保重複的複合索引鍵 (如本問題說明中所述) 不會導致無效。

名稱	值
範圍	Edge
版本	4.6
類型	正在重定目標

.NET Framework 4.6.1

核心

ZipArchiveEntry 物件的 FullName 屬性中路徑分隔符號字元變更

詳細資料

若為以 .NET Framework 4.6.1 和更新版本為目標的應用程式，在 CreateFromDirectory 方法的多載所建立之 ZipArchiveEntry 物件的 FullName 屬性中，路徑分隔符號字元已從反斜線 ("\") 變更為正斜線 ("/")。 這項變更使得 .NET 實作遵守 .ZIP File Format Specification (.ZIP 檔案格式規格) 的 4.4.17.1 小節，並允許在非 Windows 系統上解壓縮 ZIP 封存。
在非 Windows 作業系統 (例如 Macintosh) 上解壓縮以舊版 .NET Framework 為目標的應用程式所建立的 ZIP 檔案，會無法保留目錄結構。 例如，在 Macintosh 上，其會建立一組檔案，檔案名稱會串連目錄路徑，以及任何反斜線 ("\") 字元和檔案名稱。 因此，解壓縮檔案的目錄結構會無法保留。

建議

對於 Windows 作業系統上由 .NET Framework System.IO 命名空間中 API 解壓縮的 .ZIP 檔案而言，此變更的影響應該很小，因為這些 API 可以將正斜線 ("/") 或反斜線 ("\") 當做路徑分隔符號字元順利地處理。
如果不需要此變更，您可以在應用程式組態檔的 <runtime> 區段新增組態設定，選擇退出。 下列範例顯示 <runtime> 區段及 Switch.System.IO.Compression.ZipFile.UseBackslash 選擇退出參數：

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=true" />
</runtime>

此外，以舊版 .NET Framework 為目標但在 .NET Framework 4.6.1 和更新版本下執行的應用程式，可以藉由將組態設定新增到應用程式組態檔的 <runtime> 區段，以選擇加入這項行為。 下圖顯示 <runtime> 區段及 Switch.System.IO.Compression.ZipFile.UseBackslash 選擇加入參數。

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>

名稱	值
範圍	Edge
版本	4.6.1
類型	正在重定目標

受影響的 API

• ZipFile.CreateFromDirectory(String, String)
• ZipFile.CreateFromDirectory(String, String, CompressionLevel, Boolean)
• ZipFile.CreateFromDirectory(String, String, CompressionLevel, Boolean, Encoding)

Windows Communication Foundation (WCF)

使用 TransportWithMessageCredential 安全性模式的 WCF 繫結

詳細資料

從 .NET Framework 4.6.1 開始，使用 TransportWithMessageCredential 安全性模式的 WCF 繫結可以設定以接收具有不帶正負號「to」標頭的非對稱安全性金鑰訊息。根據預設，不帶正負號的「to」標頭會繼續在 .NET Framework 4.6.1 中遭到拒絕。 其只有在應用程式使用 Switch.System.ServiceModel.AllowUnsignedToHeader 組態參數來接受此新的作業模式時才會接受。

建議

由於這是可選擇加入的功能，因此不會影響現有應用程式的行為。
若要控制是否使用新的行為，請使用下列組態設定：

<runtime>
  <AppContextSwitchOverrides value="Switch.System.ServiceModel.AllowUnsignedToHeader=true" />
</runtime>

名稱	值
範圍	透明
版本	4.6.1
類型	正在重定目標

受影響的 API

• BasicHttpSecurityMode.TransportWithMessageCredential
• BasicHttpsSecurityMode.TransportWithMessageCredential
• SecurityMode.TransportWithMessageCredential
• WSFederationHttpSecurityMode.TransportWithMessageCredential

X509CertificateClaimSet.FindClaims 會考慮所有 claimTypes

詳細資料

在目標為 .NET Framework 4.6.1 的應用程式中，如果 X509 宣告集是初始化自 SAN 欄位中含有多個 DNS 項目的憑證，System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) 方法會嘗試使用所有 DNS 項目來比對 claimType 引數。若是以舊版 .NET Framework 為目標的應用程式，則 System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) 方法僅會嘗試使 claimType 引數符合最後一個 DNS 項目。

建議

這項變更只會影響以 .NET Framework 4.6.1 為目標的應用程式。 您可以使用 DisableMultipleDNSEntries 相容性參數來停用這項變更 (如果以 4.6.1 以前版本為目標則可啟用)。

名稱	值
範圍	Minor
版本	4.6.1
類型	正在重定目標

受影響的 API

• X509CertificateClaimSet.FindClaims(String, String)

Windows Forms

針對 IMessageFilter.PreFilterMessage 的可重新進入實作，Application.FilterMessage 不會再擲回例外狀況

詳細資料

在 .NET Framework 4.6.1 之前，使用呼叫 System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) 或 System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter) 的 PreFilterMessage(Message) 呼叫 FilterMessage(Message) (同時也呼叫DoEvents()) 會造成 System.IndexOutOfRangeException。

從目標為 .NET Framework 4.6.1 的應用程式開始，不會再擲回此例外狀況，而且可能會使用如上所述的可重新進入篩選。

建議

請注意，FilterMessage(Message) 將不再針對上述的可重新進入 PreFilterMessage(Message) 行為進行擲回。 這只會影響以 .NET Framework 4.6.1 為目標的應用程式。藉由使用 DontSupportReentrantFilterMessage 相容性參數，以 .NET Framework 4.6.1 為目標的應用程式可退出這項變更 (或以舊版 Framework 為目標的應用程式可加入這項變更)。

名稱	值
範圍	Edge
版本	4.6.1
類型	正在重定目標

受影響的 API

• Application.FilterMessage(Message)

Windows Presentation Foundation (WPF)

在具有觸控功能的系統上呼叫 System.Windows.Input.PenContext.Disable 可能會擲回 ArgumentException

詳細資料

在某些情況下，在具有觸控功能的系統上呼叫內部 System.Windows.Intput.PenContext.Disable 方法，可能會擲回由於重新進入而未處理的 T:System.ArgumentException。

建議

.NET Framework 4.7 中已解決這個問題。 若要避免這個例外狀況，請升級至從 .NET Framework 4.7 開始的 .NET Framework 版本。

名稱	值
範圍	Edge
版本	4.6.1
類型	正在重定目標

.NET Framework 4.6.2

ASP.NET

HttpRuntime.AppDomainAppPath 擲回 NullReferenceException

詳細資料

在 .NET Framework 4.6.2 中，執行階段在擷取包含 null 字元的 P:System.Web.HttpRuntime.AppDomainAppPath 值時，會擲回 T:System.NullReferenceException。在 .NET Framework 4.6.1 和更早版本中，執行階段會擲回 T:System.ArgumentNullException。

建議

您可以執行下列其中一個動作以回應這項變更︰

• 如果您的應用程式是在 .NET Framework 4.6.2 上執行，請處理 T:System.NullReferenceException。
• 升級至 .NET Framework 4.7，這可以還原舊版行為並擲回 T:System.ArgumentNullException。

名稱	值
範圍	Edge
版本	4.6.2
類型	正在重定目標

受影響的 API

• HttpRuntime.AppDomainAppPath

核心

AesCryptoServiceProvider 解密程式提供可重複使用的轉換

詳細資料

從以 .NET Framework 4.6.2 為目標的應用程式開始，AesCryptoServiceProvider 解密程式會提供可重複使用的轉換。 呼叫 System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) 之後，轉換就會重新初始化並且可重複使用。 若為以舊版 .NET Framework 為目標的應用程式，嘗試透過在呼叫 System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) 之後呼叫 System.Security.Cryptography.CryptoAPITransform.TransformBlock(Byte[], Int32, Int32, Byte[], Int32) 來重複使用解密程式，會擲回 CryptographicException 或產生損毀的資料。

建議

此變更的影響應該很小，因為這是預期的行為。倚賴舊行為的應用程式可以藉由將下列組態設定新增到應用程式設定檔的 <runtime> 區段，選擇不使用：

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=true"/>
</runtime>

此外，以舊版 .NET Framework 為目標，但是在從 .NET Framework 4.6.2 開始的 .NET Framework 版本下執行的應用程式，可以藉由將下列組態設定新增到應用程式設定檔的 <runtime> 區段，來選擇使用：

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=false"/>
</runtime>

名稱	值
範圍	Minor
版本	4.6.2
類型	正在重定目標

受影響的 API

• AesCryptoServiceProvider.CreateDecryptor()

呼叫 ClaimsIdentity 建構函式

詳細資料

從 .NET Framework 4.6.2 開始，具有 System.Security.Principal.IIdentity 參數的 ClaimsIdentity 建構函式如何設定 System.Security.Claims.ClaimsIdentity.Actor 屬性的方法有變更。 如果 System.Security.Principal.IIdentity 引數是 ClaimsIdentity 物件，而且該 ClaimsIdentity 物件的 System.Security.Claims.ClaimsIdentity.Actor 屬性不是 null，則會使用 Clone() 方法來附加 System.Security.Claims.ClaimsIdentity.Actor 屬性。 在 Framework 4.6.1 和更早版本中，System.Security.Claims.ClaimsIdentity.Actor 屬性會附加作為現有的參考。由於此項變更，從 .NET Framework 4.6.2 開始，新 ClaimsIdentity 物件的 System.Security.Claims.ClaimsIdentity.Actor 屬性便不等於建構函式之 System.Security.Principal.IIdentity 引數的 System.Security.Claims.ClaimsIdentity.Actor 屬性。 在 .NET Framework 4.6.1 和更早版本中，它是相等的。

建議

如果不想要這種行為，您可以將應用程式組態檔中的 Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity 參數設為 true 來還原舊版行為。 您會需要將下列內容新增至 web.config 檔案的 <runtime> 區段︰

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity=true" />
  </runtime>
</configuration>

名稱	值
範圍	Edge
版本	4.6.2
類型	正在重定目標

受影響的 API

• ClaimsIdentity(IIdentity)
• ClaimsIdentity(IIdentity, IEnumerable<Claim>)
• ClaimsIdentity(IIdentity, IEnumerable<Claim>, String, String, String)

路徑正規化的變更

詳細資料

從以 .NET Framework 4.6.2 為目標的應用程式開始，執行階段正規化路徑的方式已變更。正規化路徑涉及修改識別路徑或檔案的字串，使它符合目標作業系統上的有效路徑。 正規化通常牽涉到︰

• 規範化元件和目錄分隔符號。
• 將目前的目錄套用到相對路徑。
• 評估路徑中的相對目錄 (.) 或上層目錄 (..)。
• 修剪指定的字元。 從以 .NET Framework 4.6.2 為目標的應用程式開始，預設會啟用路徑正規化的下列變更：
  • 執行階段會延後至作業系統的 GetFullPathName 函式再進行路徑正規化。
• 正規化不再涉及修剪目錄區段的結尾 (例如目錄名稱結尾的空格)。
• 支援完全信任的裝置路徑語法，包括 \\.\ 以及適用於 mscorlib.dll 中之檔案 I/O API 的 \\?\。
• 執行階段不會驗證裝置語法路徑。
• 支援使用裝置語法存取替代資料流。 這些變更可改善效能，同時允許方法存取先前無法存取的路徑。 此變更不會影響以 .NET Framework 4.6.1 和舊版為目標但執行於 .NET Framework 4.6.2 或更新版本下的應用程式。

建議

以 .NET Framework 4.6.2 或更新版本為目標的應用程式可透過在應用程式設定檔的 <runtime> 區段中新增下列內容來選擇退出此變更，並使用舊版行為：

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=true" />
</runtime>

以 .NET Framework 4.6.1 或更早版本為目標，但在 .NET Framework 4.6.2 或更新版本上執行的應用程式，可以藉由在應用程式設定檔的 <runtime> 區段新增下行，就能啟用路徑正規化的變更：

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
</runtime>

名稱	值
範圍	Minor
版本	4.6.2
類型	正在重定目標

工作之間的 CurrentCulture 和 CurrentUICulture 流程

詳細資料

從 .NET Framework 4.6 開始，System.Globalization.CultureInfo.CurrentCulture 和 System.Globalization.CultureInfo.CurrentUICulture 會儲存在執行緒的 System.Threading.ExecutionContext，它會在非同步作業之間流動。這表示變更 System.Globalization.CultureInfo.CurrentCulture 或 System.Globalization.CultureInfo.CurrentUICulture 會反映在稍後以非同步方式執行的工作。 這與舊版 .NET Framework 的行為不同，而舊版本會重設所有非同步工作中的 System.Globalization.CultureInfo.CurrentCulture 和 System.Globalization.CultureInfo.CurrentUICulture。

建議

受到此變更影響的應用程式，可以藉由明確地設定所需的 System.Globalization.CultureInfo.CurrentCulture 或 System.Globalization.CultureInfo.CurrentUICulture 作為非同步工作中的第一個作業來因應。 或者，可以藉由設定下列相容性參數，以選擇加入舊的行為 (不流動 System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture)：

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

.NET Framework 4.6.2 中的 WPF 已修正此問題。 .NET Frameworks 4.6、4.6.1 也已透過 KB 3139549 進行修正。 以 .NET Framework 4.6 或更新版本為目標的應用程式將在 WPF 應用程式中自動取得正確的行為 - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture 會跨發送器作業保留。

名稱	值
範圍	Minor
版本	4.6
類型	正在重定目標

受影響的 API

• CultureInfo.CurrentCulture
• Thread.CurrentCulture
• CultureInfo.CurrentUICulture
• Thread.CurrentUICulture

ETW 事件名稱不能只有 "Start" 或 "Stop" 尾碼不同

詳細資料

在 .NET Framework 4.6 和 4.6.1 中，當兩個 Windows 事件追蹤 (ETW) 事件名稱的差異只在「Start」或「Stop」尾碼時 (例如當一個事件的名稱為 LogUser 而另一個事件的名稱為 LogUserStart 時)，執行階段會擲回 ArgumentException。 在此情況下，執行階段無法建構事件來源，因此無法發出任何記錄。

建議

若要避免這個例外狀況，請確定沒有兩個事件的名稱差異只在「Start」或「Stop」尾碼。從 .NET Framework 4.6.2 開始已移除這項需求；執行階段可以釐清差異只在於「Start」或「Stop」尾碼的事件名稱。

名稱	值
範圍	Edge
版本	4.6
類型	正在重定目標

長路徑支援

詳細資料

從以 .NET Framework 4.6.2 為目標的應用程式開始，支援長路徑 (最多 32K 個字元)，且已移除對於路徑長度的 260 個字元 (或 MAX_PATH) 限制。若為重新編譯以 .NET Framework 4.6.2 為目標的應用程式，先前因為路徑超過 260 個字元而擲回 System.IO.PathTooLongException 的程式碼路徑，現在將只有在下列情況下擲回 System.IO.PathTooLongException：

• 路徑的長度大於 MaxValue (32,767) 個字元。
• 作業系統傳回 COR_E_PATHTOOLONG 或其對應項。 若為以 .NET Framework 4.6.1 和更早版本為目標的應用程式，每當路徑超過 260 個字元時，執行階段就會自動擲回 System.IO.PathTooLongException。

建議

若為以 .NET Framework 4.6.2 為目標的應用程式，如果不需要長路徑支援，您可以透過將下列內容新增至 app.config 檔案的 <runtime> 區段以選擇退出長路徑支援︰

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=true" />
</runtime>

若為以舊版 .NET Framework 為目標但卻在 .NET Framework 4.6.2 或更新版本上執行的應用程式，則可將下列內容新增至 app.config 檔案的 <runtime> 區段，以選擇加入長路徑支援：

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=false" />
</runtime>

名稱	值
範圍	Minor
版本	4.6.2
類型	正在重定目標

路徑冒號檢查更嚴格

詳細資料

在 .NET Framework 4.6.2 中，為了支援先前所不支援的路徑 (就長度和格式兩方面) 而有數項變更。 對於適當磁碟機分隔符號 (冒號) 語法的檢查更為正確，副作用則是會封鎖一些選取路徑 API 中的某些 URI 路徑，而在過去都會容許這些路徑。

建議

如果傳遞 URI 給受影響的 API，請先將字串修改為合法的路徑。

• 以手動方式從 URL 移除配置 (例如，從 URL 移除 file://)。

• 將 URI 傳遞給 Uri 類別，並且使用 LocalPath。

或者，將 Switch.System.IO.UseLegacyPathHandling AppContext 參數設為 true，以選擇退出新的路徑正規化。

名稱	值
範圍	Edge
版本	4.6.2
類型	正在重定目標

受影響的 API

• Path.GetDirectoryName(String)
• Path.GetPathRoot(String)

安全性

RSACng 現在會正確地載入非標準金鑰大小的 RSA 金鑰

詳細資料

在 .NET Framework 4.6.2 之前，使用非標準的 RSA 憑證金鑰大小客戶，無法透過 System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(X509Certificate2) 和 System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2) 擴充方法存取這些金鑰。 會擲回 System.Security.Cryptography.CryptographicException 以及「不支援要求的金鑰大小」訊息。 在 .NET Framework 4.6.2 中，已修正此問題。 同樣地，ImportParameters(RSAParameters) 和 ImportParameters(RSAParameters) 現在可以使用非標準的金鑰大小，而不會擲回 System.Security.Cryptography.CryptographicException。

建議

如果有任何例外狀況處理邏輯會依賴先前的行為，也就是使用非標準的金鑰大小時會擲回 System.Security.Cryptography.CryptographicException，請考慮移除該邏輯。

名稱	值
範圍	Edge
版本	4.6.2
類型	正在重定目標

受影響的 API

• RSA.ImportParameters(RSAParameters)
• RSACng.ImportParameters(RSAParameters)
• RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2)
• RSACertificateExtensions.GetRSAPublicKey(X509Certificate2)

SignedXml.GetPublicKey RSACng 會在 net462 (或 lightup) 上傳回 RSACng，而無重定目標變更

詳細資料

從 .NET Framework 4.6.2 開始，SignedXml.GetPublicKey 方法所傳回的物件具象類型 (毫不奇怪地) 從 CryptoServiceProvider 實作變更為 Cng 實作。 這是因為實作從使用 certificate.PublicKey.Key 變更為使用內部 certificate.GetAnyPublicKey，它會轉送給 RSACertificateExtensions.GetRSAPublicKey。

建議

從在 .NET Framework 4.7.1 上執行的應用程式開始，您可以使用 .NET Framework 4.6.1 和更早版本中預設使用的 CryptoServiceProvider 實作，方法是將下列設定參數新增至您應用程式設定檔的 runtime 區段：

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true" />

名稱	值
範圍	Edge
版本	4.6.2
類型	正在重定目標

受影響的 API

• SignedXml.CheckSignatureReturningKey(AsymmetricAlgorithm)

Windows Communication Foundation (WCF)

使用可重新進入服務時，可能會造成死結

詳細資料

可重新進入服務可能會造成死結，將服務的執行個體限制為一次執行一個執行緒。 容易發生此問題的服務在其程式碼中會有下列 ServiceBehaviorAttribute：

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

建議

若要解決此問題，您可執行以下動作：

• 將服務的並行模式設定為 ConcurrencyMode.Single 或 ConcurrencyMode.Multiple。 例如：

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

• 安裝 .NET Framework 4.6.2 的最新更新，或升級至更新版本的 .NET Framework。 這會停用 OperationContext.Current 中的 ExecutionContext 流程。 這是可設定的行為；相當於在您的組態檔中新增下列應用程式設定：

<appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

Reentrant 服務的值 Switch.System.ServiceModel.DisableOperationContextAsyncFlow 絕對不可設定為 false。

名稱	值
範圍	Minor
版本	4.6.2
類型	正在重定目標

受影響的 API

• System.ServiceModel.ServiceBehaviorAttribute
• ConcurrencyMode.Reentrant

OperationContext.Current 在 using 子句中進行呼叫時，可能會傳回 Null

詳細資料

如果符合下列所有條件，則 OperationContext.Current 可能會傳回 null，而且可能會導致 NullReferenceException：

• 擷取傳回 Task 或 Task<TResult> 的方法中 OperationContext.Current 屬性的值。
• 具現化 using 子句中的 OperationContextScope 物件。
• 擷取 using statement 內 OperationContext.Current 屬性的值。 例如：

using (new OperationContextScope(OperationContext.Current))
{
    // OperationContext.Current is null.
    OperationContext context = OperationContext.Current;

    // ...
}

建議

若要解決此問題，您可執行以下動作：

• 依如下所示修改您的程式碼，以具現化新的非 null Current 物件：

  OperationContext ocx = OperationContext.Current;
  using (new OperationContextScope(OperationContext.Current))
  {
      OperationContext.Current = new OperationContext(ocx.Channel);
  
      // ...
  }
  

• 安裝 .NET Framework 4.6.2 的最新更新，或升級至更新版本的 .NET Framework。 這會停用 OperationContext.Current 中的 ExecutionContext 流程，並還原 WCF 應用程式在 .NET Framework 4.6.1 和舊版中的行為。 這是可設定的行為；相當於在您的組態檔中新增下列應用程式設定：

  <appSettings>
    <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
  </appSettings>
  

  如果這項變更並不適當，且您的應用程式相依於作業內容之間流動的執行內容，您可以啟用其流程，如下所示：

  <appSettings>
    <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="false" />
  </appSettings>
  

名稱	值
範圍	Edge
版本	4.6.2
類型	正在重定目標

受影響的 API

• OperationContext.Current

WCF 傳輸安全性支援使用 CNG 儲存的憑證

詳細資料

從以 .NET Framework 4.6.2 為目標的應用程式開始，WCF 傳輸安全性支援使用 Windows 密碼編譯程式庫 (CNG) 儲存的憑證。 這項支援僅限於具有公開金鑰的憑證，且指數長度不能超過 32 位元。 當應用程式以 .NET Framework 4.6.2 為目標時，此功能預設為開啟。在舊版 .NET Framework 中，嘗試搭配 CSG 金鑰儲存提供者使用 X509 憑證會擲回例外狀況。

建議

應用程式是以 .NET Framework 4.6.1 和更早版本為目標，但卻執行於 .NET Framework 4.6.2 當中，則可將下列這一行新增至 app.config 或 web.config 檔的 <runtime> 區段，來啟用支援 CNG 憑證：

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IdentityModel.DisableCngCertificates=false" />
</runtime>

這也可以用程式設計方式，以下列程式碼完成︰

private const string DisableCngCertificates = @"Switch.System.IdentityModel.DisableCngCertificate";

AppContext.SetSwitch(disableCngCertificates, false);

Const DisableCngCertificates As String = "Switch.System.IdentityModel.DisableCngCertificates"
AppContext.SetSwitch(disableCngCertificates, False)

請注意，由於這項變更，將不再執行任何倚賴使用 CNG 憑證嘗試起始安全通訊失敗的任何例外住況處理程式碼。

名稱	值
範圍	Minor
版本	4.6.2
類型	正在重定目標

Windows Forms

MemberDescriptor.Equals 的實作不正確

詳細資料

MemberDescriptor.Equals 方法的原始實作會比較正在比較之物件的兩個不同字串屬性：分類名稱與描述字串。 修正方法是比較第一個物件的 Category 和第二個物件的 Category，比較第一個物件的 Description 和第二個物件的 Description。

建議

如果您的應用程式相依於當描述項相等時有時會傳回 false 的 MemberDescriptor.Equals，而且您的目標是 .NET Framework 4.6.2 版或更新版本，則有數個選項：

• 變更程式碼以在呼叫 MemberDescriptor.Equals 方法之外，手動比較 Category 和 Description 欄位。
• 在 app.config 檔案中新增下列值，選擇不進行這項變更：

<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=true" />
</runtime>

如果您的應用程式目標設為 .NET Framework 4.6.1 或較舊版本，但在 .NET Framework 4.6.2 或更新版本上執行，而您想要啟用這項變更，您可以在 app.config 檔案中新增下列值，將相容性參數設為 false：

<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=false" />
</runtime>

名稱	值
範圍	Edge
版本	4.6.2
類型	正在重定目標

受影響的 API

• MemberDescriptor.Equals(Object)

Windows Presentation Foundation (WPF)

CurrentCulture 無法跨 WPF 發送器作業保留

詳細資料

從 .NET Framework 4.6 開始，在 System.Windows.Threading.Dispatcher 內對 System.Globalization.CultureInfo.CurrentCulture 或 System.Globalization.CultureInfo.CurrentUICulture 所做的變更，將會在發送器作業結束時遺失。 同樣地，在發送器作業外部對 System.Globalization.CultureInfo.CurrentCulture 或 System.Globalization.CultureInfo.CurrentUICulture 所做的變更，不會在執行該作業時反映出來。實際上，這表示 System.Globalization.CultureInfo.CurrentCulture 和 System.Globalization.CultureInfo.CurrentUICulture 變更可能不會在 WPF UI 回呼與 WPF 應用程式的其他程式碼之間流動。這是因為從以 .NET Framework 4.6 為目標的應用程式開始，System.Threading.ExecutionContext 的變更會導致 System.Globalization.CultureInfo.CurrentCulture 和 System.Globalization.CultureInfo.CurrentUICulture 儲存在執行內容中。 WPF 發送器作業會儲存用來開始作業的執行內容，並在作業完成時還原先前的內容。 因為 System.Globalization.CultureInfo.CurrentCulture 和 System.Globalization.CultureInfo.CurrentUICulture 現在是該內容的一部分，所以在發送器作業內對其進行的變更不會保留到作業外。

建議

您可以將所需的 System.Globalization.CultureInfo.CurrentCulture 或 System.Globalization.CultureInfo.CurrentUICulture 儲存在欄位中，然後簽入設定正確 System.Globalization.CultureInfo.CurrentCulture 和 System.Globalization.CultureInfo.CurrentUICulture 的所有發送器作業主體 (包括 UI 事件回呼處理常式)，來解決受此變更影響的應用程式。 此外，由於此 WPF 變更的基本 ExecutionContext 變更只會影響以 .NET Framework 4.6 或更新版本為目標的應用程式，因此您可以將目標設為 .NET Framework 4.5.2 來避免此中斷情況。以 .NET Framework 4.6 或更新版本為目標的應用程式，也可以設定下列相容性參數來解決此問題：

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

.NET Framework 4.6.2 中的 WPF 已修正此問題。 .NET Frameworks 4.6、4.6.1 也已透過 KB 3139549 進行修正。 以 .NET Framework 4.6 或更新版本為目標的應用程式將在 WPF 應用程式中自動取得正確的行為 - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture 會跨發送器作業保留。

名稱	值
範圍	Minor
版本	4.6
類型	正在重定目標