從 .NET Framework 4.6.2 移轉至 4.8 的執行階段變更Runtime Changes for Migration from .NET Framework 4.6.2 to 4.8

如果您想從 .NET Framework 4.6.2 移轉至 4.8,請檢閱下列主題中可能會影響應用程式的應用程式相容性問題:If you are migrating from the .NET Framework 4.6.2 to 4.8, review the following topics for application compatibility issues that may affect your app:

ASP.NETASP.NET

ASP.NET 修正 WebForms CheckBox 控制項的 InputAttributes 和 LabelAttributes 處理方式ASP.NET Fix handling of InputAttributes and LabelAttributes for WebForms CheckBox control

詳細資料Details

若應用程式是以 .NET Framework 4.7.2 和更早版本為目標,回傳後會遺失以程式設計方式新增至 WebForms CheckBox 控制項的 CheckBox.InputAttributesCheckBox.LabelAttributesFor applications that target .NET Framework 4.7.2 and earlier versions, CheckBox.InputAttributes and CheckBox.LabelAttributes that are programmatically added to a WebForms CheckBox control are lost after postback. 若應用程式是以 .NET Framework 4.8 或更新版本為目標,則回傳後仍會保留這些項目。For applications that target .NET Framework 4.8 or later versions, they are preserved after postback.

建議Suggestion

為了確保回傳時還原屬性的正確行為,請將 targetFrameworkVersion 設為 4.8 或更高。For the correct behavior for restoring attributes on postback, set the targetFrameworkVersion to 4.8 or higher. 例如:For example:

<configuration>
<system.web>
<httpRuntime targetFramework="4.8"/>
</system.web>
</configuration>
將它設得更低或完全不設時,則會保留既有的不正確行為。Setting it lower, or not at all, preserves the old incorrect behavior.

名稱Name Value
範圍Scope 未知Unknown
版本Version 4.84.8
類型Type 執行階段Runtime

受影響的 APIAffected APIs

ASP.NET 無法正確進行多部分處理,可能會導致遺失表單資料。ASP.NET Incorrect multipart handling may result in lost form data.

詳細資料Details

在以 .NET Framework 4.7.2 和更早版本為目標的應用程式中,ASP.NET 可能會不正確地剖析多部分界限值,導致在要求執行期間無法使用表單資料。In applications that target .NET Framework 4.7.2 and earlier versions, ASP.NET might incorrectly parse multipart boundary values, resulting in form data being unavailable during request execution. 以 .NET Framework 4.8 或更新版本為目標的應用程式則可正確剖析多部分資料,因此在要求執行期間可使用表單值。Applications that target .NET Framework 4.8 or later versions correctly parse multipart data, so form values are available during request execution.

建議Suggestion

從執行 .NET Framework 4.8 的應用程式開始,當使用 targetFrameworkVersion 項目將目標設為 .NET Framework 4.8 或更新版本時,預設行為會變更為去除分隔符號。Starting with applications running on .NET Framework 4.8, when targeting .NET Framework 4.8 or later by using the targetFrameworkVersion element, the default behavior changes to strip delimiters. 當以舊版 Framework 為目標,或不使用 targetFrameworkVersion 時,仍會傳回某些值的尾端分隔符號。您也可以使用 appSetting 明確地控制此行為:When targeting previous framework versions or not using targetFrameworkVersion, trailing delimiters for some values are still returned.This behavior can also be explicitly controlled with an appSetting:

<configuration>
<appSettings>
...
<add key="aspnet:UseLegacyMultiValueHeaderHandling"  value="true"/>
...
</appSettings>
</configuration>

名稱Name Value
範圍Scope UnknownUnknown
版本Version 4.84.8
類型Type 執行階段Runtime

受影響的 APIAffected APIs

使用自訂 DataAnnotations.ValidationAttribute 時 ASP.NET ValidationContext.MemberName 不是 NULLASP.NET ValidationContext.MemberName is not NULL when using custom DataAnnotations.ValidationAttribute

詳細資料Details

在 .NET Framework 4.7.2 和更早版本中使用自訂 System.ComponentModel.DataAnnotations.ValidationAttribute 時,ValidationContext.MemberName 屬性會傳回 nullIn .NET Framework 4.7.2 and earlier versions, when using a custom System.ComponentModel.DataAnnotations.ValidationAttribute, the ValidationContext.MemberName property returns null. 在2019年10月更新之前 .NET Framework 4.8 版中,它會傳回成員名稱。In .NET Framework 4.8 version prior to the October 2019 update, it returns the member name. 2019 年10月 .NET Framework .NET Framework 4.8 的品質匯總預覽版 開始,預設會傳回 null ,但您可以改為選擇改回傳回成員名稱。Starting with .NET Framework October 2019 Preview of Quality Rollup for .NET Framework 4.8, it returns null by default, but you can opt in to return the member name instead.

建議Suggestion

將下列設定新增至您的 web.config 檔案,以在 2019 年10月 .NET Framework .NET Framework 4.8 和更新版本的品質匯總預覽版本中傳回成員名稱:Add the following setting to your web.config file for the property to return the member name in .NET Framework October 2019 Preview of Quality Rollup for .NET Framework 4.8 and later versions:

<configuration>
<appSettings>
...
<add key="aspnet:GetValidationMemberName"  value="true"/>
...
</appSettings>
</configuration>
在2019年10月更新之前的 .NET Framework 4.8 版本中,將其新增至您的 web.config 檔會還原先前的行為,而屬性會傳回 nullIn .NET Framework 4.8 version prior to the October 2019 update, adding this to your web.config file restores the previous behavior and the property returns null.

名稱Name Value
範圍Scope 未知Unknown
版本Version 4.84.8
類型Type 執行階段Runtime

受影響的 APIAffected APIs

核心Core

.NET COM 成功封送處理事件上的 ByRef SafeArray 參數.NET COM successfully marshals ByRef SafeArray parameters on events

詳細資料Details

在 .NET Framework 4.7.2 和舊版中,COM 事件上的 ByRef SafeArray 參數無法封送處理回機器碼。In the .NET Framework 4.7.2 and earlier versions, a ByRef SafeArray parameter on a COM event would fail to marshal back to native code. 現在,透過這項變更,系統可成功封送處理 SafeArrayWith this change the SafeArray is now marshalled successfully.

  • [ x ] Quirked[ x ] Quirked

建議Suggestion

如果正確封送處理 COM 事件上的 ByRef SafeArray 參數會導致執行中斷,您可以將下列組態參數新增至應用程式組態來停用此程式碼:If properly marshalling ByRef SafeArray parameters on COM Events breaks execution, you can disable this code by adding the following configuration switch to your application config:

<appSettings>
<add key="Switch.System.Runtime.InteropServices.DoNotMarshalOutByrefSafeArrayOnInvoke" value="true" />
</appSettings>

名稱Name Value
範圍Scope MinorMinor
版本Version 4.84.8
類型Type 執行階段Runtime

受影響的 APIAffected APIs

無法透過 API 分析偵測。Not detectable via API analysis.

.NET Interop 現會進行 IAgileObject 的 QueryInterface 作業 (WinRT 介面).NET Interop will now QueryInterface for IAgileObject (a WinRT interface)

詳細資料Details

從 .NET Framework 4.8 開始,當您搭配使用 WinRT 事件與 .NET 委派時,Windows 會進行 IAgileObject 的 QI 作業。When using a WinRT event with a .NET delegate, Windows will QI for IAgileObject starting with the .NET Framework 4.8. 在舊版 .NET Framework 中,執行階段會讓該 QI 失敗,而無法訂閱此事件。In previous versions of the .NET Framework, the runtime would fail that QI, and the event could not be subscribed.

  • [ x ] Quirked[ x ] Quirked

建議Suggestion

如果啟用 IAgileObject 的 QI 作業會導致執行中斷,您可以進行下列設定來停用此程式碼。If enabling the QI for IAgileObject breaks execution, you can disable this code by setting the following configuration.

方法1:環境變數Method 1: Environment variable

設定下列環境變數:COMPLUS_DisableCCWSupportIAgileObject=1 這個方法會影響任何繼承此環境變數的環境。Set the following environment variable:COMPLUS_DisableCCWSupportIAgileObject=1This method affects any environment that inherits this environment variable. 這可能只是單一主控台會話,如果您在全域設定環境變數,它可能會影響整部電腦。This might be just a single console session, or it might affect the entire machine if you set the environment variable globally. 環境變數名稱不區分大小寫。The environment variable name is not case-sensitive.

方法2:登錄Method 2: Registry

使用登錄編輯程式 ( # A0) 中,找出下列其中一個子機碼: HKEY_LOCAL_MACHINE \SOFTWARE\Microsoft.NETFramework HKEY_CURRENT_USER \SOFTWARE\Microsoft.NETFrameworkThen 新增下列子機碼:值名稱: DisableCCWSupportIAgileObject 類型: DWORD (32 位) 值 (也稱為 REG_WORD) 值:1您可以使用 Windows REG.EXE 工具,從命令列或腳本環境新增此值。Using Registry Editor (regedit.exe), find either of the following subkeys:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework HKEY_CURRENT_USER\SOFTWARE\Microsoft.NETFrameworkThen add the following:Value name: DisableCCWSupportIAgileObject Type: DWORD (32-bit) Value (also called REG_WORD) Value: 1You can use the Windows REG.EXE tool to add this value from a command-line or scripting environment. 例如:For example:
reg add HKLM\SOFTWARE\Microsoft.NETFramework /v DisableCCWSupportIAgileObject /t REG_DWORD /d 1
此案例會使用 HKLM,而不是 HKEY_LOCAL_MACHINEIn this case, HKLM is used instead of HKEY_LOCAL_MACHINE. 使用 reg add /? 以查看此語法的說明。Use reg add /? to see help on this syntax. 登錄值名稱不區分大小寫。The registry value name is not case-sensitive.

名稱Name Value
範圍Scope EdgeEdge
版本Version 4.84.8
類型Type 執行階段Runtime

受影響的 APIAffected APIs

無法透過 API 分析偵測。Not detectable via API analysis.

允許在與 UNC 共用相似的 URI 中使用 UnicodeAllow Unicode in URIs that resemble UNC shares

詳細資料Details

System.Uri 中,若您建構的檔案 URI 同時包含 UNC 共用名稱和 Unicode 字元時,不會再導致 URI 出現無效的內部狀態。In System.Uri, constructing a file URI containing both a UNC share name and Unicode characters will no longer result in a URI with invalid internal state. 這項行為只有在下列所有條件都符合時才會變更:The behavior will change only when all of the following are true:

  • URI 具有 file: 配置,且後接 4 條以上的斜線。The URI has the scheme file: and is followed by four or more slashes.
  • 主機名稱開頭為底線或其他非保留符號。The host name begins with an underscore or other non-reserved symbol.
  • URI 包含 Unicode 字元。The URI contains Unicode characters.

建議Suggestion

如果應用程式使用的 URI 始終包含 Unicode,可想而知,該應用程式會使用這項行為來禁止參考 UNC 共用。Applications working with URIs consistently containing Unicode could have conceivably used this behavior to disallow references to UNC shares. 因此,這類應用程式應該改用 IsUncThose applications should use IsUnc instead.

名稱Name Value
範圍Scope EdgeEdge
版本Version 4.7.24.7.2
類型Type 執行階段Runtime

受影響的 APIAffected APIs

Unicode 存在時,支援特殊的相對 URI 標記法Support special relative URI notation when Unicode is present

詳細資料Details

UriNullReferenceException TryCreate 包含 Unicode 的特定相對 uri 上呼叫時,不會再擲回。Uri will no longer throw a NullReferenceException when calling TryCreate on certain relative URIs containing Unicode. 的最簡單重現 NullReferenceException 如下,其中兩個語句是相等的:The simplest reproduction of the NullReferenceException is below, with the two statements being equivalent:

bool success = Uri.TryCreate("http:%C3%A8", UriKind.RelativeOrAbsolute, out Uri href);
bool success = Uri.TryCreate("http:è", UriKind.RelativeOrAbsolute, out Uri href);
若要重現 NullReferenceException,必須符合下列項目:To reproduce the NullReferenceException, the following items must be true:
  • URI 前面必須加上 ‘http:’,且不是後面加上 ‘//’ 來指定為相對的。The URI must be specified as relative by prepending it with ‘http:’ and not following it with ‘//’.
  • URI 必須包含百分比編碼的 Unicode 或未保留的符號。The URI must contain percent-encoded Unicode or unreserved symbols.

建議Suggestion

根據此行為不允許相對 URI 的使用者,在建立 URI 時應該改指定 UriKind.AbsoluteUsers depending on this behavior to disallow relative URIs should instead specify UriKind.Absolute when creating a URI.

名稱Name Value
範圍Scope EdgeEdge
版本Version 4.7.24.7.2
類型Type 執行階段Runtime

受影響的 APIAffected APIs

執行階段Runtime

針對 Net.Tcp 憑證驗證改善的 WCF 鏈結信任憑證驗證Improved WCF chain trust certificate validation for Net.Tcp certificate authentication

詳細資料Details

.NET Framework 4.7.2 若以傳輸安全性搭配 WCF 使用憑證驗證,就可以改善鏈結信任憑證驗證。.NET Framework 4.7.2 improves chain trust certificate validation when using certificate authentication with transport security with WCF. 利用這項改善,必須針對用戶端驗證設定用來驗證伺服器的用戶端憑證。With this improvement, client certificates that are used to authenticate to a server must be configured for client authentication. 同樣地,必須針對伺服器驗證設定用來驗證伺服器的伺服器憑證。Similarly server certificates that are for the authenticating a server must be configured for server authentication. 利用這項變更,如果已停用根憑證,憑證鏈結驗證就會失敗。With this change, if the root certificate is disabled, the certificate chain validation fails. 同時,已透過 Windows 安全性彙總對 .NET Framework 3.5 和更新版本進行了相同的變更。The same change was also made to .NET Framework 3.5 and later versions via Windows security roll-up. 您可以在這裡找到更多資訊。這項變更預設為開啟,而且可以透過組態設定加以關閉。You can find more information here.This change is on by default and can be turned off by a configuration setting.

建議Suggestion

  • 驗證您的伺服器和用戶端憑證是否具有必要的 EKU OID。Validate if your server and client certification has the required EKU OID. 如果沒有,請更新您的憑證。If not, update your certification.
  • 驗證您的根憑證是否無效。Validate if your root certificate is invalid. 如果是,請更新根憑證。If so, update the root certificate.
  • 如何退出宣告變更:如果無法更新憑證,您可以使用下列設定設定暫時解決這項重大變更,不過,退出宣告變更會讓您的系統容易受到安全性問題的影響。How to opt out of the change: If you can't update the certificate, you can work around the breaking change temporarily with the following configuration setting, However, opting out of the change will leave your system vulnerable to the security issue.
<appSettings>
<add key="wcf:useLegacyCertificateUsagePolicy" value="true" />
</appSettings>
名稱Name Value
範圍Scope MinorMinor
版本Version 4.7.24.7.2
類型Type 執行階段Runtime

受影響的 APIAffected APIs

無法透過 API 分析偵測。Not detectable via API analysis.

安全性Security

RSACng 和 DSACng 再次可在部分信任案例中使用RSACng and DSACng are once again usable in Partial Trust scenarios

詳細資料Details

CngLightup (用於數個較高層級的加密 API,例如 System.Security.Cryptography.Xml.EncryptedXml) 和 System.Security.Cryptography.RSACng 在某些情況下依賴完全信任。CngLightup (used in several higher-level crypto apis, such as System.Security.Cryptography.Xml.EncryptedXml) and System.Security.Cryptography.RSACng in some cases rely on full trust. 這些包括沒有主張 SecurityPermissionFlag.UnmanagedCode 權限的 P/Invoke,以及 System.Security.Cryptography.CngKey 具有 SecurityPermissionFlag.UnmanagedCode 之權限要求的程式碼路徑。These include P/Invokes without asserting SecurityPermissionFlag.UnmanagedCode permissions, and code paths where System.Security.Cryptography.CngKey has permission demands for SecurityPermissionFlag.UnmanagedCode. 從 .NET Framework 4.6.2 開始,盡量使用 CngLightup 來切換至 System.Security.Cryptography.RSACngStarting with the .NET Framework 4.6.2, CngLightup was used to switch to System.Security.Cryptography.RSACng wherever possible. 因此,成功使用 System.Security.Cryptography.Xml.EncryptedXml 的部分信任應用程式開始失敗,並擲回 SecurityException 例外狀況。這項變更將新增所需的主張,讓所有使用 CngLightup 的函式具有必要權限。As a result, partial trust apps that successfully used System.Security.Cryptography.Xml.EncryptedXml began to fail and throw SecurityException exceptions.This change adds the required asserts so that all functions using CngLightup have the required permissions.

建議Suggestion

如果 .NET Framework 4.6.2 中的這項變更已對部分信任應用程式產生負面影響,請升級至 .NET Framework 4.7.1。If this change in the .NET Framework 4.6.2 has negatively impacted your partial trust apps, upgrade to the .NET Framework 4.7.1.

名稱Name Value
範圍Scope EdgeEdge
版本Version 4.6.24.6.2
類型Type 執行階段Runtime

受影響的 APIAffected APIs

Web 應用程式Web Applications

"dataAnnotations:dataTypeAttribute:disableRegEx" 應用程式設定,在 .NET Framework 4.7.2 中預設會開啟"dataAnnotations:dataTypeAttribute:disableRegEx" app setting is on by default in .NET Framework 4.7.2

詳細資料Details

在 .NET Framework 4.6.1 中,提供了應用程式設定 ("dataAnnotations:dataTypeAttribute:disableRegEx"),可讓使用者能停用在資料類型屬性 (例如 System.ComponentModel.DataAnnotations.EmailAddressAttributeSystem.ComponentModel.DataAnnotations.UrlAttributeSystem.ComponentModel.DataAnnotations.PhoneAttribute) 中使用規則運算式。In .NET Framework 4.6.1, an app setting ("dataAnnotations:dataTypeAttribute:disableRegEx") was introduced that allows users to disable the use of regular expressions in data type attributes (such as System.ComponentModel.DataAnnotations.EmailAddressAttribute, System.ComponentModel.DataAnnotations.UrlAttribute, and System.ComponentModel.DataAnnotations.PhoneAttribute). 如此有助於降低安全性弱點,例如避免發生使用特定規則運算式的拒絕服務攻擊之可能性。This helps to reduce security vulnerability such as avoiding the possibility of a Denial of Service attack using specific regular expressions.
在 .NET Framework 4.6.1 中,停用使用 RegEx 的此應用程式設定,預設會設為 falseIn .NET Framework 4.6.1, this app setting to disable RegEx usage was set to false by default. 從 .NET Framework 4.7.2 開始,此設定參數預設會設定為, true 以進一步降低以 .NET Framework 4.7.2 和更新版本為目標之 web 應用程式的安全性漏洞。Starting with .NET Framework 4.7.2, this config switch is set to true by default to further reduce secure vulnerability for web applications that target .NET Framework 4.7.2 and above.

建議Suggestion

若您發現您 Web 應用程式中的規則運算式,在升級至 .NET Framework 4.7.2 之後無法運作,可將 "dataAnnotations:dataTypeAttribute:disableRegEx" 設定的值,更新為 false,以還原為先前的行為。If you find that regular expressions in your web application do not work after upgrading to .NET Framework 4.7.2, you can update the value of the "dataAnnotations:dataTypeAttribute:disableRegEx" setting to false to revert to the previous behavior.

<configuration>
<appSettings>
...
<add key="dataAnnotations:dataTypeAttribute:disableRegEx" value="false"/>
...
</appSettings>
</configuration>

名稱Name Value
範圍Scope MinorMinor
版本Version 4.7.24.7.2
類型Type 執行階段Runtime

受影響的 APIAffected APIs

無法透過 API 分析偵測。Not detectable via API analysis.

Windows Communication Foundation (WCF)Windows Communication Foundation (WCF)

svcTraceViewer ComboBox 高對比變更svcTraceViewer ComboBox high contrast change

詳細資料Details

Microsoft 服務追蹤檢視器工具中,某些高對比佈景主題的 ComboBox 控制項未顯示正確色彩。In the Microsoft Service Trace Viewer tool, ComboBox controls were not displayed in the correct color in certain high contrast themes. 此問題已在 .NET Framework 4.7.2 中修正。The issue was fixed in .NET Framework 4.7.2. 不過,由於 .NET Framework SDK 的回溯相容性需求,因此預設為客戶看不到此項修正。However, due to .NET Framework SDK backward compatibility requirements, the fix was not visible to customers by default. .NET 4.8 將下列 AppContext 組態參數新增至 svcTraceViewer.exe.config 檔案,以呈現這項變更:.NET 4.8 surfaces this change by adding the following AppContext configuration switches to the svcTraceViewer.exe.config file:

<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false" />

建議Suggestion

如果您不想要變更高對比行為,可以從 svcTraceViewer.exe.config 檔案中移除下列區段來停用它:If you don't want to have the high contrast behavior change, you can disable it by removing the following section from the svcTraceViewer.exe.config file:

<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false" />
NameName Value
範圍Scope EdgeEdge
版本Version 4.84.8
類型Type 執行階段Runtime

受影響的 APIAffected APIs

無法透過 API 分析偵測。Not detectable via API analysis.

如果 addressHeader 項目為 Null,WCF AddressHeaderCollection 現在會擲回 ArgumentExceptionWCF AddressHeaderCollection now throws an ArgumentException if an addressHeader element is null

詳細資料Details

從 .NET Framework 4.7.1 開始,如果其中一個項目是 nullAddressHeaderCollection(IEnumerable<AddressHeader>) 建構函式會擲回 ArgumentExceptionStarting with the .NET Framework 4.7.1, the AddressHeaderCollection(IEnumerable<AddressHeader>) constructor throws an ArgumentException if one of the elements is null. 在 .NET Framework 4.7 和舊版中,不會擲回任何例外狀況。In the .NET Framework 4.7 and earlier versions, no exception is thrown.

建議Suggestion

如果您在 .NET Framework 4.7.1 或更新版本上遇到這項變更的相容性問題,您可以將下列程式程式碼新增至 app.config 檔的區段,以退出宣告 <runtime>If you encounter compatibility issues with this change on the .NET Framework 4.7.1 or a later version, you can opt-out of it by adding the following line to the <runtime> section of the app.config file:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableAddressHeaderCollectionValidation=true" />
  </runtime>
</configuration>
NameName Value
範圍Scope MinorMinor
版本Version 4.7.14.7.1
類型Type 執行階段Runtime

受影響的 APIAffected APIs

WCF MsmqSecureHashAlgorithm 預設值現在是 SHA256WCF MsmqSecureHashAlgorithm default value is now SHA256

詳細資料Details

從 .NET Framework 4.7.1 開始,WCF 中用於 Msmq 訊息的預設訊息簽署演算法是 SHA256。Starting with the .NET Framework 4.7.1, the default message signing algorithm in WCF for Msmq messages is SHA256. 在 .NET Framework 4.7 和舊版中,預設的訊息簽署演算法是 SHA1。In the .NET Framework 4.7 and earlier versions, the default message signing algorithm is SHA1.

建議Suggestion

如果您在 .NET Framework 4.7.1 或更新版本上遇到這項變更的相容性問題,您可以在 app.config 檔案的區段中加入下列這一行,以退出宣告變更 <runtime>If you run into compatibility issues with this change on the .NET Framework 4.7.1 or later, you can opt-out the change by adding the following line to the <runtime> section of your app.config file:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value=&quot;Switch.System.ServiceModel.UseSha1InMsmqEncryptionAlgorithm=true&quot; />
  </runtime>
</configuration>
NameName Value
範圍Scope MinorMinor
版本Version 4.7.14.7.1
類型Type 執行階段Runtime

受影響的 APIAffected APIs

無法透過 API 分析偵測。Not detectable via API analysis.

WCF PipeConnection.GetHashAlgorithm 現在會使用 SHA256WCF PipeConnection.GetHashAlgorithm now uses SHA256

詳細資料Details

從 .NET Framework 4.7.1 開始,Windows Communication Foundation 會使用 SHA256 雜湊來產生具名管道的隨機名稱。Starting with the .NET Framework 4.7.1, Windows Communication Foundation uses a SHA256 hash to generate random names for named pipes. 在 .NET Framework 4.7 和舊版中,它已使用 SHA1 雜湊。In the .NET Framework 4.7 and earlier versions, it used a SHA1 hash.

建議Suggestion

如果在 .NET Framework 4.7.1 或更新版本上遇到這項變更的相容性問題,您可以在 app.config 檔案的 <runtime> 區段中新增下列程式行來退出變更:If you run into compatibility issue with this change on the .NET Framework 4.7.1 or later, you can opt-out it by adding the following line to the <runtime> section of your app.config file:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.ServiceModel.UseSha1InPipeConnectionGetHashAlgorithm=true" />
  </runtime>
</configuration>
NameName Value
範圍Scope MinorMinor
版本Version 4.7.14.7.1
類型Type 執行階段Runtime

受影響的 APIAffected APIs

無法透過 API 分析偵測。Not detectable via API analysis.

Windows Presentation Foundation (WPF)Windows Presentation Foundation (WPF)

StaysOpen=False 時的鏈結快顯視窗Chained Popups with StaysOpen=False

詳細資料Details

當您按一下 StaysOpen=False 快顯視窗的外部時,該快顯視窗應該要關閉。A Popup with StaysOpen=False is supposed to close when you click outside the Popup. 當兩個或多個這類快顯視窗鏈結在一起 (也就是其中一個包含另一個) 時,會發生許多問題,包括:When two or more such Popups are chained (i.e. one contains another), there were many problems, including:

  • 開啟兩個層級,按一下 P2 外部 (但在 P1 內部)。Open two levels, click outside P2 but inside P1. 沒有發生任何事。Nothing happens.
  • 開啟兩個層級,按一下 P1 外部。Open two levels, click outside P1. 這兩個快顯視窗會關閉。Both popups close.
  • 開啟及關閉兩個層級。Open and close two levels. 然後嘗試再次開啟 P2。Then try to open P2 again. 沒有發生任何事。Nothing happens.
  • 嘗試開啟三個層級。Try to open three levels. 你無此權限。You can't. (不會發生任何事,或是前兩個層級關閉,視您按一下的位置而定。 ) 這些案例 (和其他變異) 現在可如預期般運作。(Either nothing happens or the first two levels close, depending on where you click.) These cases (and other variants) now work as expected.

名稱Name Value
範圍Scope EdgeEdge
版本Version 4.7.14.7.1
類型Type 執行階段Runtime

受影響的 APIAffected APIs

KeyedCollection 的資料繫結改進Data Binding improvement for KeyedCollection

詳細資料Details

修正 Binding 當來源物件以相同的簽章宣告自訂索引子時,不正確地使用 IList 索引子 (例如,system.collections.objectmodel.keyedcollection < Int,TItem >) 。Fixed Binding incorrect use of IList indexer when the source object declares a custom indexer with the same signature (for example, KeyedCollection<int,TItem>).

建議Suggestion

為了讓以較舊版本為目標的應用程式受益于這項變更,它必須在 .NET Framework 4.8 或更新版本上執行,而且必須在應用程式佈建檔的區段中新增下列 AppCoNtext 參數<runtime> 並將其設定為,以加入宣告變更 falseIn order for an application that targets an older version to benefit from this change, it must run on the .NET Framework 4.8 or later, and it must opt in to the change by adding the following AppContext switch to the <runtime> section of the app config file and setting it to false:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
</startup>
<runtime>
<!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false  -->
<AppContextSwitchOverrides value="Switch.System.Windows.Data.Binding.IListIndexerHidesCustomIndexer=false" />
</runtime>
</configuration>

名稱Name Value
範圍Scope 主要Major
版本Version 4.84.8
類型Type 執行階段Runtime

受影響的 APIAffected APIs

無法透過 API 分析偵測。Not detectable via API analysis.

DataGridCellsPanel.BringIndexIntoView 擲回 ArgumentOutOfRangeExceptionDataGridCellsPanel.BringIndexIntoView throws ArgumentOutOfRangeException

詳細資料Details

啟用資料行虛擬化,但尚未決定資料行寬度時,ScrollIntoView(Object) 將以非同步方式運作。ScrollIntoView(Object) will work asynchronously when column virtualization is enabled but the column widths have not yet been determined. 如果資料行在非同步工作進行之前遭到移除,會發生 System.ArgumentOutOfRangeExceptionIf columns are removed before the asynchronous work happens, an System.ArgumentOutOfRangeException can occur.

建議Suggestion

下列任一步驟:Any one of the following:

  1. 升級至 .NET Framework 4.7。Upgrade to .NET Framework 4.7.
  2. 為 .NET Framework 4.6.2 安裝最新的服務修補程式。Install the latest servicing patch for .NET Framework 4.6.2.
  3. ScrollIntoView(Object) 的非同步回應完成之前,避免移除資料行。Avoid removing columns until the asynchronous response to ScrollIntoView(Object) has completed.

名稱Name Value
範圍Scope EdgeEdge
版本Version 4.6.24.6.2
類型Type 執行階段Runtime

受影響的 APIAffected APIs

已修正當 ListBox 包含重複實值型別時的停止回應問題Fixed a hang when ListBox contains duplicate value-types

詳細資料Details

已修正下列問題:當虛擬化 ItemsControl 的項目集合包含重複實值型別物件時,其在捲動期間會停止回應。Fixed a problem where a virtualizingItemsControl can hang during scrolling when its Items collection contains duplicate value-typed objects.

名稱Name Value
範圍Scope 主要Major
版本Version 4.84.8
類型Type 執行階段Runtime

受影響的 APIAffected APIs

無法透過 API 分析偵測。Not detectable via API analysis.

格線含星號資料列空間配置演算法的改進Improvements to Grid star-rows space allocating algorithm

詳細資料Details

已修正 Grid (於 .NET Framework 4.7 推出) 中配置大小至 的演算法錯誤 (Bug)。Fixed a bug in the algorithm for allocating sizes to) in a Grid introduced in .NET Framework 4.7. 在某些情況下,例如含 Height="Auto" 與空白資料列的格線,資料列會排列在錯誤的位置,可能會全部擠在格線外。In some cases, such as a Grid with Height="Auto" containing empty rows, rows were arranged at the wrong position, possibly outside the Grid altogether.

建議Suggestion

若要讓應用程式受益於這些變更,您必須在 .NET Framework 4.8 或更新版本上執行應用程式。In order for the application to benefit from these changes, it must run on the .NET Framework 4.8 or later.

名稱Name Value
範圍Scope 主要Major
版本Version 4.84.8
類型Type 執行階段Runtime

受影響的 APIAffected APIs

無法透過 API 分析偵測。Not detectable via API analysis.

詳細資料Details

已修正下列問題:當焦點在某個項目內的超連結,但該項目不是上層 ItemsControl 的選取項目時,按下方向鍵會顯示不正確的結果。Fixed incorrect result of pressing an arrow key when the focus is on a hyperlink within an item that is not the selected item of the parent ItemsControl.

名稱Name Value
範圍Scope 主要Major
版本Version 4.84.8
類型Type 執行階段Runtime

受影響的 APIAffected APIs

無法透過 API 分析偵測。Not detectable via API analysis.

已改進 WPF 中的按鍵提示行為Keytips behavior improved in WPF

詳細資料Details

按鍵提示行為已經過修改,讓 Microsoft Word 與 Windows 檔案總管之間的行為趨於一致。Keytips behavior has been modified to bring parity with behavior on Microsoft Word and Windows Explorer. WPF 會藉由查看是否已啟用按鍵提示狀態,或是並非按下 SystemKey (特別是 KeyF11) 的情況,正確地處理按鍵提示的按鍵。By checking whether keytip state is enabled or not in the case of a SystemKey (in particular, Key or F11) being pressed, WPF handles keytip keys appropriately. 現在即使滑鼠已開啟了按鍵提示,其仍會關閉功能表。Keytips now dismiss a menu even when it is opened by mouse.

建議Suggestion

N/AN/A

名稱Name Value
範圍Scope EdgeEdge
版本Version 4.7.24.7.2
類型Type 執行階段Runtime

受影響的 APIAffected APIs

無法透過 API 分析偵測。Not detectable via API analysis.

WPF 拼字檢查功能所擲回的 ObjectDisposedExceptionObjectDisposedException thrown by WPF spellchecker

詳細資料Details

在應用程式關閉期間,WPF 應用程式偶爾會因拼字檢查功能所擲回的 System.ObjectDisposedException 而損毀。WPF applications occasionally crash during application shutdown with an System.ObjectDisposedException thrown by the spellchecker. 此問題已在 .NET Framework 4.7 WPF 中透過依正常程序處理例外狀況來修正,進而確保應用程式不會再受到負面影響。This is fixed in .NET Framework 4.7 WPF by handling the exception gracefully, and thus ensuring that applications are no longer adversely affected. 請注意,在偵錯工具下執行的應用程式偶爾還是會發生第一個例外狀況。It should be noted that occasional first-chance exceptions would continue to be observed in applications running under a debugger.

建議Suggestion

升級至 .NET Framework 4.7Upgrade to .NET Framework 4.7

名稱Name Value
範圍Scope EdgeEdge
版本Version 4.6.14.6.1
類型Type 執行階段Runtime

受影響的 APIAffected APIs

無法透過 API 分析偵測。Not detectable via API analysis.

在自動化樹狀目錄中的 ItemsControls 分組效能改進Performance improvement in Automation tree for grouping ItemsControls

詳細資料Details

改善重建 ItemsControl 自動化樹狀目錄的效能,例如啟用分組的 ListBox 或 DataGrid。Improved the performance of rebuilding the automation tree of an ItemsControl, such as a ListBox or DataGrid, in which grouping is enabled.

名稱Name Value
範圍Scope 主要Major
版本Version 4.84.8
類型Type 執行階段Runtime

受影響的 APIAffected APIs

無法透過 API 分析偵測。Not detectable via API analysis.

RibbonGroup 背景在當地語系化組建中設定為透明RibbonGroup background is set to transparent in localized builds

詳細資料Details

當地語系化組建中的 System.Windows.Controls.Ribbon.RibbonGroup 背景一律使用透明筆刷繪製,導致不良的 UI 使用體驗。System.Windows.Controls.Ribbon.RibbonGroup background on localized builds was always painted with Transparent brush, resulting in poor UI experience. 此問題已在 .NET Framework 4.7 WPF 修正程式中透過更新 System.Windows.Controls.Ribbon.RibbonGroup 的當地語系化資源來修正,而這可確保已選取正確的筆刷。This is fixed in .NET Framework 4.7 WPF fix by updating the localized resources for System.Windows.Controls.Ribbon.RibbonGroup, which in turn ensures that the correct brush is selected.

建議Suggestion

升級至 .NET Framework 4.7Upgrade to .NET Framework 4.7

名稱Name Value
範圍Scope EdgeEdge
版本Version 4.6.24.6.2
類型Type 執行階段Runtime

受影響的 APIAffected APIs

無法透過 API 分析偵測。Not detectable via API analysis.

WPF 列印堆疊更新WPF Printing Stack Update

詳細資料Details

使用 System.Printing.PrintQueue 的 WPF 列印 API 現在會呼叫 Windows 的列印文件套件 API,以支援目前已淘汰的 XPS 列印 API。WPF's Printing APIs using System.Printing.PrintQueue now call Window's Print Document Package API in favor of the now deprecated XPS Print API. 進行這項變更是考慮到服務能力;使用者和開發人員都不應該會看到行為或 API 使用方式中有任何變更。The change was made with serviceability in mind; neither users nor developers should see any changes in behavior or API usage. 在 Windows 10 Creators Update 中執行時,預設會啟用新的列印堆疊。The new printing stack is enabled by default when running in Windows 10 Creators Update. 舊版 Windows 上的舊列印堆疊仍會繼續如往常一般運作。The old printing stack will still continue to work just as before in older Windows versions.

建議Suggestion

若要在 Windows 10 Creators Update 中使用舊堆疊,請將 HKEY_CURRENT_USER\Software\Microsoft.NETFramework\Windows Presentation Foundation\Printing 登錄機碼的 UseXpsOMPrinting REG_DWORD 值設為 1To use the old stack in Windows 10 Creators Update, set the UseXpsOMPrinting REG_DWORD value of the HKEY_CURRENT_USER\Software\Microsoft.NETFramework\Windows Presentation Foundation\Printing registry key to 1.

名稱Name Value
範圍Scope EdgeEdge
版本Version 4.74.7
類型Type 執行階段Runtime

受影響的 APIAffected APIs

無法透過 API 分析偵測。Not detectable via API analysis.

Windows Workflow Foundation (WF)Windows Workflow Foundation (WF)

在某些情況下,工作流程現在會擲回原始例外狀況,而不是 NullReferenceExceptionWorkflow now throws original exception instead of NullReferenceException in some cases

詳細資料Details

在 .NET Framework 4.6.2 和舊版中,工作流程活動的 Execute 方法擲回 Message 屬性為 null 值的例外狀況時,System.Activities 工作流程執行階段會擲回 System.NullReferenceException,進而遮罩原始的例外狀況。在 .NET Framework 4.7 中,會擲回之前遮罩的例外狀況。In the .NET Framework 4.6.2 and earlier versions, when the Execute method of a workflow activity throws an exception with a null value for the Message property, the System.Activities Workflow runtime throws a System.NullReferenceException, masking the original exception.In the .NET Framework 4.7, the previously masked exception is thrown.

建議Suggestion

如果您的程式碼依賴處理 System.NullReferenceException,請將它變更為攔截可能會從自訂活動擲回的例外狀況。If your code relies on handling the System.NullReferenceException, change it to catch the exceptions that could be thrown from your custom activities.

名稱Name Value
範圍Scope MinorMinor
版本Version 4.74.7
類型Type 執行階段Runtime

受影響的 APIAffected APIs

工作流程 SQL 持續性會新增叢集主索引鍵,且在某些資料行中不允許有 Null 值Workflow SQL persistence adds primary key clusters and disallows null values in some columns

詳細資料Details

從 .NET Framework 4.7 開始,SqlWorkflowInstanceStoreSchema.sql 指令碼針對 SQL 工作流程執行個體存放區 (SWIS) 所建立的資料表使用叢集主索引鍵。Starting with the .NET Framework 4.7, the tables created for the SQL Workflow Instance Store (SWIS) by the SqlWorkflowInstanceStoreSchema.sql script use clustered primary keys. 因此,識別不支援 null 值。Because of this, identities do not support null values. SWIS 的作業不會受到這項變更影響。The operation of SWIS is not impacted by this change. 已進行更新以支援 SQL Server 異動複寫。The updates were made to support SQL Server Transactional Replication.

建議Suggestion

必須將 SQL 檔案 SqlWorkflowInstanceStoreSchemaUpgrade.sql 套用到現有安裝,才能體驗這項變更。The SQL file SqlWorkflowInstanceStoreSchemaUpgrade.sql must be applied to existing installations in order to experience this change. 新的資料庫安裝將會自動進行此變更。New database installations will automatically have the change.

名稱Name Value
範圍Scope EdgeEdge
版本Version 4.74.7
類型Type 執行階段Runtime

受影響的 APIAffected APIs

無法透過 API 分析偵測。Not detectable via API analysis.