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

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

ADO.NETADO.NET

ADO.NET 現在會嘗試自動重新連接中斷的 SQL 連線ADO.NET now attempts to automatically reconnect broken SQL connections

詳細資料Details

從 .NET Framework 4.5.1 中開始,.NET Framework 將嘗試自動重新連接中斷的 SQL 連線。Beginning in the .NET Framework 4.5.1, the .NET Framework will attempt to automatically reconnect broken SQL connections. 雖然這通常會讓應用程式更可靠,但是會有邊緣案例,應用程式必須知道連線已中斷,讓它可以在重新連接時採取某些動作。Although this will typically make apps more reliable, there are edge cases in which an app needs to know that the connection was lost so that it can take some action upon reconnection.

建議Suggestion

如果基於相容性考量,您不想要這項功能,可以將連接字串的 System.Data.SqlClient.SqlConnectionStringBuilder.ConnectRetryCount 屬性 (或 System.Data.SqlClient.SqlConnectionStringBuilder) 設為 0 來加以停用。If this feature is undesirable due to compatibility concerns, it can be disabled by setting the System.Data.SqlClient.SqlConnectionStringBuilder.ConnectRetryCount property of a connection string (or System.Data.SqlClient.SqlConnectionStringBuilder) to 0.

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

受影響的 APIAffected APIs

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

ASP.NET MVC 現在會將透過路由參數傳入之字串中的空格逸出ASP.NET MVC now escapes spaces in strings passed in via route parameters

詳細資料Details

為了遵守 RFC 2396,從路由填入動作參數時,現在會將路由路徑中的空格逸出。In order to conform to RFC 2396, spaces in route paths are now escaped when populating action parameters from a route. 因此,雖然 /controller/action/some data 先前會比對路由 /controller/action/{data} 並提供 some data 作為資料參數,但現在會改為提供 some%20dataSo, whereas /controller/action/some data would previously match the route /controller/action/{data} and provide some data as the data parameter, it will now provide some%20data instead.

建議Suggestion

您應該更新程式碼,以將路由中的字串參數設為未逸出。Code should be updated to unescape string parameters from a route. 如果需要原始 URI,您可以使用 RequestUri.OriginalString API 來存取。If the original URI is needed, it can be accessed with the RequestUri.OriginalString API.

名稱Name Value
範圍Scope MinorMinor
版本Version 4.5.24.5.2
類型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

AllowCustomPaging 設為 true 的 GridView 可能在離開檢視的最後一頁時引發 PageIndexChanging 事件GridViews with AllowCustomPaging set to true may fire the PageIndexChanging event when leaving the final page of the view

詳細資料Details

.NET Framework 4.5 中的 Bug) 導致有時不會針對已啟用 System.Web.UI.WebControls.GridView.AllowCustomPagingSystem.Web.UI.WebControls.GridView 引發 System.Web.UI.WebControls.GridView.PageIndexChangingA bug in the .NET Framework 4.5 causes System.Web.UI.WebControls.GridView.PageIndexChanging to sometimes not fire for System.Web.UI.WebControls.GridViews that have enabled System.Web.UI.WebControls.GridView.AllowCustomPaging.

建議Suggestion

此問題在 .NET Framework 4.6 中已修正,因此可藉由升級至該版 .NET Framework 來解決。This issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework. 應用程式可以對叫用這些條件 (System.Web.UI.WebControls.GridView 位在最後一個頁面上且 LastSystem.Web.UI.WebControls.GridView.PageSize 不同於 System.Web.UI.WebControls.GridView.PageSize) 的 Page_Load 執行明確的 BindGrid,來解決這個問題。As a work-around, the app can do an explicit BindGrid on any Page_Load that would hit these conditions (the System.Web.UI.WebControls.GridView is on the last page and LastSystem.Web.UI.WebControls.GridView.PageSize is different from System.Web.UI.WebControls.GridView.PageSize). 或者,可以修改應用程式以允許分頁 (而不是自訂分頁),因為該情況不會顯示此問題。Alternatively, the app can be modified to allow paging (instead of custom paging), as that scenario does not demonstrate the problem.

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

受影響的 APIAffected APIs

無法再將 EnableViewStateMac 設定為 falseNo longer able to set EnableViewStateMac to false

詳細資料Details

ASP.NET 不再允許開發人員指定 <pages enableViewStateMac="false"/><@Page EnableViewStateMac="false" %>ASP.NET no longer allows developers to specify <pages enableViewStateMac="false"/> or <@Page EnableViewStateMac="false" %>. 檢視狀態訊息驗證碼 (MAC) 現在會強制所有要求內嵌檢視狀態。The view state message authentication code (MAC) is now enforced for all requests with embedded view state. 只會影響將 EnableViewStateMac 屬性明確設定為 false 的應用程式。Only apps that explicitly set the EnableViewStateMac property to false are affected.

建議Suggestion

EnableViewStateMac 必須假設為 true,而且必須解決任何產生的 MAC 錯誤 (如 本指南所述,其中包含多個解決方法,視造成 MAC 錯誤的特定原因而定) 。EnableViewStateMac must be assumed to be true, and any resulting MAC errors must be resolved (as explained in this guidance, which contains multiple resolutions depending on the specifics of what is causing MAC errors).

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

受影響的 APIAffected APIs

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

分析 ASP.NET MVC4 應用程式可能會導致嚴重的執行引擎錯誤Profiling ASP.NET MVC4 apps can lead to Fatal Execution Engine Error

詳細資料Details

使用 NGEN /Profile 組件的分析工具可能會在啟動時損毀已分析的 ASP.NET MVC4 應用程式,並顯示「嚴重的執行引擎例外狀況」Profilers using NGEN /Profile assemblies may crash profiled ASP.NET MVC4 applications on startup with a 'Fatal Execution Engine Exception'

建議Suggestion

此問題在 .NET Framework 4.5.2 中已修正。This issue is fixed in the .NET Framework 4.5.2. 或者,分析工具時可能會藉由在其事件遮罩中指定 COR_PRF_DISABLE_ALL_NGEN_IMAGES 來避免這個問題。Alternatively, the profiler may avoid this issue by specifying COR_PRF_DISABLE_ALL_NGEN_IMAGES in its event mask.

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

受影響的 APIAffected APIs

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

核心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

AppDomainSetup.DynamicBase 不再由 UseRandomizedStringHashAlgorithm 隨機化AppDomainSetup.DynamicBase is no longer randomized by UseRandomizedStringHashAlgorithm

詳細資料Details

在 .NET Framework 4.6 之前,如果已在應用程式組態檔中啟用 UseRandomizedStringHashAlgorithm,DynamicBase 的值就會在應用程式定義域或處理序之間隨機化。Prior to the .NET Framework 4.6, the value of DynamicBase would be randomized between application domains, or between processes, if UseRandomizedStringHashAlgorithm was enabled in the app's config file. 從 .NET Framework 4.6 開始,DynamicBase 將會在執行之應用程式的不同執行個體之間以及不同的應用程式定義域之間,傳回穩定的結果。Beginning in the .NET Framework 4.6, DynamicBase will return a stable result between different instances of an app running, and between different app domains. 動態基底仍會因不同的應用程式而異;這項變更只會移除相同應用程式之不同執行個體的隨機命名項目。Dynamic bases will still differ for different apps; this change only removes the random naming element for different instances of the same app.

建議Suggestion

請注意,啟用 UseRandomizedStringHashAlgorithm 不會導致 DynamicBase 隨機化。Be aware that enabling UseRandomizedStringHashAlgorithm will not result in DynamicBase being randomized. 如果需要隨機基底,必須在您的應用程式程式碼中產生它,而不是透過此 API 產生。If a random base is needed, it must be produced in your app's code rather than via this API.

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

受影響的 APIAffected APIs

如果索引類型可解決語意模糊,在索引子屬性上呼叫 Attribute.GetCustomAttributes 不會再擲回 AmbiguousMatchExceptionCalling Attribute.GetCustomAttributes on an indexer property no longer throws AmbiguousMatchException if the ambiguity can be resolved by index's type

詳細資料Details

在 .NET Framework 4.6 之前,在索引子屬性上呼叫 GetCustomAttribute(s),而且該索引子屬性與其他屬性只有索引類型不同時,會造成 System.Reflection.AmbiguousMatchExceptionPrior to the .NET Framework 4.6, calling GetCustomAttribute(s) on an indexer property which differed from another property only by the type of the index would result in an System.Reflection.AmbiguousMatchException. 從 .NET Framework 4.6 開始,將會正確地傳回屬性 (Property) 的屬性 (Attributee)。Beginning in the .NET Framework 4.6, the property's attributes will be correctly returned.

建議Suggestion

請注意,GetCustomAttribute 現在正常運作的頻率會更高。Be aware that GetCustomAttribute(s) will work more frequently now. 如果應用程式先前依賴 System.Reflection.AmbiguousMatchException,現在應該改用反映來明確尋找多個索引子。If an app was previously relying on the System.Reflection.AmbiguousMatchException, reflection should now be used to explicitly look for multiple indexers, instead.

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

受影響的 APIAffected APIs

ConcurrentQueue<T>.TryPeek 可透過其 out 參數傳回錯誤的 NullConcurrentQueue<T>.TryPeek can return an erroneous null via its out parameter

詳細資料Details

在某些多執行緒案例中,System.Collections.Concurrent.ConcurrentQueue<T>.TryPeek(T) 可能會傳回 true,但以 Null 值 (而不是查看到的正確值) 填入 out 參數。In some multi-threaded scenarios, System.Collections.Concurrent.ConcurrentQueue<T>.TryPeek(T) can return true, but populate the out parameter with a null value (instead of the correct, peeked value).

建議Suggestion

此問題在 .NET Framework 4.5.1 中已修正。This issue is fixed in the .NET Framework 4.5.1. 升級至該 Framework 將會解決問題。Upgrading to that Framework will solve the issue.

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

受影響的 APIAffected APIs

還原序列化跨應用程式網域的物件會失敗Deserialization of objects across appdomains can fail

詳細資料Details

在某些情況下,當應用程式使用具有不同應用程式基底的兩個或多個應用程式網域時,嘗試在邏輯呼叫內容中還原序列化跨應用程式網域的物件會擲回例外狀況。In some cases, when an app uses two or more app domains with different application bases, trying to deserialize objects in the logical call context across app domains throws an exception.

建議Suggestion

請參閱緩和:在應用程式定義域之間還原序列化物件See Mitigation: Deserialization of Objects Across App Domains

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

受影響的 APIAffected APIs

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

ETW EventListeners 無法使用 Explicit 關鍵字從提供者擷取事件 (例如 TPL 提供者)ETW EventListeners do not capture events from providers with explicit keywords (like the TPL provider)

詳細資料Details

具有空白關鍵字遮罩的 ETW EventListeners 無法使用 Explicit 關鍵字從提供者正確地擷取事件。ETW EventListeners with a blank keyword mask do not properly capture events from providers with explicit keywords. 在 .NET Framework 4.5 中,TPL 提供者已開始提供 Explicit 關鍵字並觸發此問題。In the .NET Framework 4.5, the TPL provider began providing explicit keywords and triggered this issue. 在 .NET Framework 4.6 中,已更新 EventListeners,因此不會再發生此問題。In the .NET Framework 4.6, EventListeners have been updated to no longer have this issue.

建議Suggestion

若要解決此問題,請將 EnableEvents(EventSource, EventLevel) 的呼叫取代為 EnableEvents 多載的呼叫,該呼叫明確指定「任何關鍵字」遮罩以使用︰EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff))。此外,此問題在 .NET Framework 4.6 中已修正,因此可藉由升級至該版 .NET Framework 來解決。To work around this problem, replace calls to EnableEvents(EventSource, EventLevel) with calls to the EnableEvents overload that explicitly specifies the "any keywords" mask to use: EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff)).Alternatively, this issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.

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

受影響的 APIAffected APIs

EventListener 會截斷內嵌 Null 的字串EventListener truncates strings with embedded nulls

詳細資料Details

System.Diagnostics.Tracing.EventListener 會截斷內嵌 Null 的字串。System.Diagnostics.Tracing.EventListener truncates strings with embedded nulls. System.Diagnostics.Tracing.EventSource 類別不支援 Null 字元。Null characters are not supported by the System.Diagnostics.Tracing.EventSource class. 這項變更只會影響使用 System.Diagnostics.Tracing.EventListener 讀取處理中 System.Diagnostics.Tracing.EventSource 資料並使用 Null 字元做為分隔符號的應用程式。The change only affects apps that use System.Diagnostics.Tracing.EventListener to read System.Diagnostics.Tracing.EventSource data in process and that use null characters as delimiters.

建議Suggestion

如果可能的話,您應該更新 System.Diagnostics.Tracing.EventSource 資料,不要使用內嵌 Null 字元。System.Diagnostics.Tracing.EventSource data should be updated, if possible, to not use embedded null characters.

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

受影響的 APIAffected APIs

EventSource.WriteEvent impl 必須將收到的相同參數傳遞給 WriteEvent (再加上識別碼)EventSource.WriteEvent impls must pass WriteEvent the same parameters that it received (plus ID)

詳細資料Details

執行階段現在會強制執行指定下列作業的合約:定義 ETW 事件方法之衍生自 System.Diagnostics.Tracing.EventSource 的類別在呼叫基底類別 EventSource.WriteEvent 方法時,必須在事件識別碼後面接著傳遞 ETW 事件方法的相同目的地引數。The runtime now enforces the contract that specifies the following: A class derived from System.Diagnostics.Tracing.EventSource that defines an ETW event method must call the base class EventSource.WriteEvent method with the event ID followed by the same arguments that the ETW event method was passed.

建議Suggestion

如果 System.IndexOutOfRangeException 讀取來自於違反此合約之事件來源的處理中 System.Diagnostics.Tracing.EventListener 資料,則會擲回 System.Diagnostics.Tracing.EventSource 例外狀況。An System.IndexOutOfRangeException exception is thrown if an System.Diagnostics.Tracing.EventListener reads System.Diagnostics.Tracing.EventSource data in process for an event source that violates this contract.

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

受影響的 APIAffected APIs

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

Marshal.SizeOf 和 Marshal.PtrToStructure 多載會中斷動態程式碼Marshal.SizeOf and Marshal.PtrToStructure overloads break dynamic code

詳細資料Details

在 .NET Framework 4.5.1 中,動態繫結至方法 SizeOf<T>()SizeOf<T>(T), PtrToStructure(IntPtr, Object)PtrToStructure(IntPtr, Type)PtrToStructure<T>(IntPtr)PtrToStructure<T>(IntPtr, T) (例如透過 Windows PowerShell、IronPython 或 C# 動態關鍵字) 可能會造成 MethodInvocationExceptions,因為新增了可能對指令碼引擎模稜兩可的方法多載。Beginning in the .NET Framework 4.5.1, dynamically binding to the methods SizeOf<T>(), SizeOf<T>(T), PtrToStructure(IntPtr, Object), PtrToStructure(IntPtr, Type), PtrToStructure<T>(IntPtr), or PtrToStructure<T>(IntPtr, T), (via Windows PowerShell, IronPython, or the C# dynamic keyword, for example) can result in MethodInvocationExceptions because new overloads of these methods have been added that may be ambiguous to the scripting engines.

建議Suggestion

請更新指令碼,以清楚指出應使用哪個多載。Update scripts to clearly indicate which overload should be used. 一般而言,將方法的型別參數明確轉換成 Type,即可完成此作業。This can typically done by explicitly casting the methods' type parameters as Type. 如需如何解決問題的詳細資訊和範例,請參閱這個連結See this link for more detail and examples of how to workaround the issue.

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

受影響的 APIAffected APIs

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

波斯曆現在會使用回教陽曆演算法Persian calendar now uses the Hijri solar algorithm

詳細資料Details

從 .NET Framework 4.6 開始,System.Globalization.PersianCalendar 類別會使用回教陽曆演算法。Starting with the .NET Framework 4.6, the System.Globalization.PersianCalendar class uses the Hijri solar algorithm. 從 .NET Framework 4.6 開始,針對 1800 年以前的日期或 2023 年以後的日期 (西曆),在 System.Globalization.PersianCalendar 與其他日曆之間轉換這些日期可能會產生稍微不同的結果。此外,PersianCalendar.MinSupportedDateTime 現在是 March 22, 0622,而不是 March 21, 0622Converting dates between the System.Globalization.PersianCalendar and other calendars may produce a slightly different result beginning with the .NET Framework 4.6 for dates earlier than 1800 or later than 2023 (Gregorian).Also, PersianCalendar.MinSupportedDateTime is now March 22, 0622 instead of March 21, 0622.

建議Suggestion

請注意,在 .NET Framework 4.6 中使用 PersianCalendar 時,某些較早或較晚的日期可能會稍微不同。Be aware that some early or late dates may be slightly different when using the PersianCalendar in .NET Framework 4.6. 此外,在不同 .NET Framework 版本上執行的處理序之間序列化日期,不會將日期儲存為 PersianCalendar 日期字串 (因為這些值可能不同)。Also, when serializing dates between processes which may run on different .NET Framework versions, do not store them as PersianCalendar date strings (since those values may be different).

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

受影響的 APIAffected APIs

無法再將反映物件從受控程式碼傳遞至跨處理序的 DCOM 用戶端Reflection objects can no longer be passed from managed code to out-of-process DCOM clients

詳細資料Details

無法再將反映物件從 Managed 程式碼傳遞至跨處理序的 DCOM 用戶端。Reflection objects can no longer be passed from managed code to out-of-process DCOM clients. 以下是受到影響的類型:The following types are affected:

呼叫物件的 IMarshal 會傳回 E_NOINTERFACECalls to IMarshal for the object return E_NOINTERFACE.

建議Suggestion

更新封送處理常式代碼以使用非反映物件。Update marshaling code to work with non-reflection objects.

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

受影響的 APIAffected APIs

某些 .NET API 會造成第一個可能發生 (已處理) 的 EntryPointNotFoundExceptionSome .NET APIs cause first chance (handled) EntryPointNotFoundExceptions

詳細資料Details

在 .NET Framework 4.5 中,少數 .NET 方法已開始擲回第一個可能發生的 System.EntryPointNotFoundExceptionIn the .NET Framework 4.5, a small number of .NET methods began throwing first chance System.EntryPointNotFoundExceptions. 這些例外狀況在 .NET Framework 中已處理,但可能會中斷未預期第一個可能發生例外狀況的測試自動化。These exceptions were handled within the .NET Framework, but could break test automation that did not expect the first chance exceptions. 這些相同的 API 會在啟用 HighVersionLie 時中斷一些 ApiVerifier 案例。These same APIs break some ApiVerifier scenarios when HighVersionLie is enabled.

建議Suggestion

您可以升級至 .NET Framework 4.5.1 來避免此錯誤 (bug)。This bug can be avoided by upgrading to .NET Framework 4.5.1. 或者,您也可以更新測試自動化,不要在發生第一個可能的 System.EntryPointNotFoundException 時中斷。Alternatively, test automation can be updated to not break on first-chance System.EntryPointNotFoundExceptions.

名稱Name Value
範圍Scope EdgeEdge
版本Version 4.54.5
類型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

預設應用程式定義域的 TargetFrameworkName 若未設定,不會再預設為 NullTargetFrameworkName for default app domain no longer defaults to null if not set

詳細資料Details

除非明確設定,否則 System.AppDomainSetup.TargetFrameworkName 之前在預設應用程式定義域中為 Null。The System.AppDomainSetup.TargetFrameworkName was previously null in the default app domain, unless it was explicitly set. 從 4.6 開始,預設應用程式定義域的 System.AppDomainSetup.TargetFrameworkName 屬性會有衍生自 TargetFrameworkAttribute 的預設值 (如果有一個預設值的話)。Beginning in 4.6, the System.AppDomainSetup.TargetFrameworkName property for the default app domain will have a default value derived from the TargetFrameworkAttribute (if one is present). 除非明確遭到覆寫,否則非預設應用程式定義域會繼續從預設應用程式定義域繼承其 System.AppDomainSetup.TargetFrameworkName (在 4.6 中不會預設為 Null)。Non-default app domains will continue to inherit their System.AppDomainSetup.TargetFrameworkName from the default app domain (which will not default to null in 4.6) unless it is explicitly overridden.

建議Suggestion

您應該更新程式碼,讓 TargetFrameworkName 不會預設為 Null。Code should be updated to not depend on TargetFrameworkName defaulting to null. 如果此屬性必須繼續評估為 Null,則可以將它明確設定為該值。If it is required that this property continue to evaluate to null, it can be explicitly set to that value.

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

受影響的 APIAffected APIs

WinRT 資料流配接器不會再於關閉時自動呼叫 FlushAsyncWinRT stream adapters no long call FlushAsync automatically on close

詳細資料Details

在 Windows 市集應用程式中,Windows 執行階段資料流配接器不會再從 Dispose 方法呼叫 FlushAsync 方法。In Windows Store apps, Windows Runtime stream adapters no longer call the FlushAsync method from the Dispose method.

建議Suggestion

這項變更應該是透明的。This change should be transparent. 開發人員可以撰寫下列程式碼來還原舊有行為:Developers can restore the previous behavior by writing code like this:

using (var stream = GetWindowsRuntimeStream() as Stream)
{
// do something
await stream.FlushAsync();
}

名稱Name Value
範圍Scope 透明Transparent
版本Version 4.5.14.5.1
類型Type 執行階段Runtime

受影響的 APIAffected APIs

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

現在,當 .NET 無法處理憑證時,X509Certificate2.ToString(Boolean) 不會擲回例外狀況X509Certificate2.ToString(Boolean) does not throw now when .NET cannot handle the certificate

詳細資料Details

在 .NET Framework 4.5.2 和更早版本中,如果將 true 傳遞給詳細資訊參數,但 .NET Framework 不支援已安裝的憑證時,此方法會擲回例外狀況。In .NET Framework 4.5.2 and earlier versions, this method would throw if true was passed for the verbose parameter and there were certificates installed that weren't supported by the .NET Framework. 現在,此方法會成功,並傳回省略無法存取之憑證部分的有效字串。Now, the method will succeed and return a valid string that omits the inaccessible portions of the certificate.

建議Suggestion

您應該更新所有相依於 X509Certificate2.ToString(Boolean) 的程式碼,以確保傳回字串可在 API 先前擲回例外狀況的特定情況下排除某些憑證資料 (例如公開金鑰、私密金鑰和延伸內容)。Any code depending on X509Certificate2.ToString(Boolean) should be updated to expect that the returned string may exclude some certificate data (such as public key, private key, and extensions) in some cases in which the API would have previously thrown.

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

受影響的 APIAffected APIs

資料Data

ADO.NET 現在會嘗試自動重新連接中斷的 SQL 連線ADO.NET now attempts to automatically reconnect broken SQL connections

詳細資料Details

從 .NET Framework 4.5.1 中開始,.NET Framework 將嘗試自動重新連接中斷的 SQL 連線。Beginning in the .NET Framework 4.5.1, the .NET Framework will attempt to automatically reconnect broken SQL connections. 雖然這通常會讓應用程式更可靠,但是會有邊緣案例,應用程式必須知道連線已中斷,讓它可以在重新連接時採取某些動作。Although this will typically make apps more reliable, there are edge cases in which an app needs to know that the connection was lost so that it can take some action upon reconnection.

建議Suggestion

如果基於相容性考量,您不想要這項功能,可以將連接字串的 System.Data.SqlClient.SqlConnectionStringBuilder.ConnectRetryCount 屬性 (或 System.Data.SqlClient.SqlConnectionStringBuilder) 設為 0 來加以停用。If this feature is undesirable due to compatibility concerns, it can be disabled by setting the System.Data.SqlClient.SqlConnectionStringBuilder.ConnectRetryCount property of a connection string (or System.Data.SqlClient.SqlConnectionStringBuilder) to 0.

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

受影響的 APIAffected APIs

Azure SQL 資料庫的連線集區封鎖期已移除Connection pool blocking period for Azure SQL databases is removed

詳細資料Details

從 .NET Framework 4.6.2 開始,針對已知 Azure SQL 資料庫的連線開啟要求 (* . database.windows.net、 * database.chinacloudapi.cn、 * database.usgovcloudapi.net、 * database.cloudapi.de) 、已移除連接集區封鎖期間,且未快取連接開啟的錯誤。Starting with the .NET Framework 4.6.2, for connection open requests to known Azure SQL databases (*.database.windows.net, *.database.chinacloudapi.cn, *.database.usgovcloudapi.net, *.database.cloudapi.de), the connection pool blocking period is removed, and connection open errors are not cached. 發生暫時性連線錯誤之後,幾乎會立即嘗試重試連線開啟要求。Attempts to retry connection open requests will occur almost immediately after transient connection errors. 這項變更允許立即重試 Azure SQL Database 的連線開啟嘗試,因而提升啟用雲端功能的應用程式效能。This change allows the connection open attempt to be retried immediately for Azure SQL databases, thereby improving the performance of cloud- enabled apps. 至於所有其他連線嘗試,則會繼續強制執行連線集區封鎖期。For all other connection attempts, the connection pool blocking period continues to be enforced.

在 .NET Framework 4.6.1 和舊版中,如果應用程式在連線到資料庫時發生暫時性連線失敗,由於連線集區會快取此錯誤並在 5 秒鐘到 1 分鐘後重新擲回,因此無法很快就重試連線。In the .NET Framework 4.6.1 and earlier versions, when an app encounters a transient connection failure when connecting to a database, the connection attempt cannot be retried quickly, because the connection pool caches the error and re-throws it for 5 seconds to 1 minute. 如需詳細資訊,請參閱 SQL Server 連線共用 (ADO.NET) (機器翻譯)。For more information, see SQL Server Connection Pooling (ADO.NET). 此行為會對 Azure SQL Database 連線造成問題,連線通常會因暫時性錯誤而失敗,而且一般會在幾秒內復原。This behavior is problematic for connections to Azure SQL databases, which often fail with transient errors that are typically recovered from within a few seconds. 連線集區封鎖功能表示應用程式有很長的一段時間無法連線到資料庫,即使資料庫可供使用且應用程式需要在幾秒內呈現也一樣。The connection pool blocking feature means that the app cannot connect to the database for an extensive period, even though the database is available and the app needs to render within a few seconds.

建議Suggestion

如果不需要這種行為,可以藉由設定 .NET Framework 4.6.2 中引進的 System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod 屬性來設定連線集區封鎖期。If this behavior is undesirable, the connection pool blocking period can be configured by setting the System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod property introduced in the .NET Framework 4.6.2. 屬性的值是 System.Data.SqlClient.PoolBlockingPeriod 列舉的成員,可以採用三個值的其中一個值︰The value of the property is a member of the System.Data.SqlClient.PoolBlockingPeriod enumeration that can take either of three values:

System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod 屬性設為 AlwaysBlock 可以還原舊有行為。The previous behavior can be restored by setting the System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod property to AlwaysBlock.

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

受影響的 APIAffected APIs

SqlConnection.Open 在有非 IFS Winsock BSP 或 LSP 的 Windows 7 上會失敗SqlConnection.Open fails on Windows 7 with non-IFS Winsock BSP or LSP present

詳細資料Details

在 .NET Framework 4.5 中,如果 Open()OpenAsync(CancellationToken) 在 Windows 7 電腦上執行,而且該電腦上有非 IFS Winsock BSP 或 LSP,則會失敗。若要判斷是否已安裝非 IFS BSP 或 LSP,請使用 netsh WinSock Show Catalog 命令,並檢查每個傳回的 Winsock Catalog Provider Entry 項目。Open() and OpenAsync(CancellationToken) fail in the .NET Framework 4.5 if running on a Windows 7 machine with a non-IFS Winsock BSP or LSP are present on the computer.To determine whether a non-IFS BSP or LSP is installed, use the netsh WinSock Show Catalog command, and examine every Winsock Catalog Provider Entry item that is returned. 如果服務旗標值已設定 0x20000 位元,提供者會使用 IFS 控制代碼並將正常運作。If the Service Flags value has the 0x20000 bit set, the provider uses IFS handles and will work correctly. 如果 0x20000 位元已清除 (未設定),就是非 IFS BSP 或 LSP。If the 0x20000 bit is clear (not set), it is a non-IFS BSP or LSP.

建議Suggestion

此錯誤 (bug) 在 .NET Framework 4.5.2 中已修正,因此可藉由升級 .NET Framework 來避免。This bug has been fixed in the .NET Framework 4.5.2, so it can be avoided by upgrading the .NET Framework. 或者,您也可以移除任何安裝的非 IFS Winsock LSP 來避免此錯誤 (bug)。Alternatively, it can be avoided by removing any installed non-IFS Winsock LSPs.

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

受影響的 APIAffected APIs

偵錯工具Debugger

在稍後的步驟中,偵錯工具才會顯示 Null 聯合器值Null coalescer values are not visible in debugger until one step later

詳細資料Details

.NET Framework 4.5 中的 Bug) 會導致在 64 位元版本的 Framework 上執行時,透過 Null 聯合運算設定的值不會立即於執行指派作業之後顯示在偵錯工具中。A bug in the .NET Framework 4.5 causes values set via a null coalescing operation to not be visible in the debugger immediately after the assignment operation is executed when running on the 64-bit version of the Framework.

建議Suggestion

在偵錯工具中逐步執行一段額外時間,將使本機/欄位的值正確更新。Stepping one additional time in the debugger will cause the local/field's value to be correctly updated. 此外,此問題已在 .NET Framework 4.6 中修正;升級至該版 .NET Framework 應可解決此問題。Also, this issue has been fixed in the .NET Framework 4.6; upgrading to that version of the Framework should solve the issue.

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

受影響的 APIAffected APIs

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

Entity FrameworkEntity Framework

針對具有特定字元的 QueryView,不再擲回 EFEF no longer throws for QueryViews with specific characteristics

詳細資料Details

當應用程式執行與 QueryView (導覽屬性為 0..1) 相關的查詢,嘗試在查詢中包含相關的項目時,Entity Framework 不再擲回 System.StackOverflowException 例外狀況。Entity Framework no longer throws a System.StackOverflowException exception when an app executes a query that involves a QueryView with a 0..1 navigation property that attempts to include the related entities as part of the query. 例如,藉由呼叫 .Include(e => e.RelatedNavProp)For example, by calling .Include(e => e.RelatedNavProp).

建議Suggestion

這項變更只會影響在執行呼叫 .Include 的查詢時,使用 QueryView (關聯性為 1-0..1) 的程式碼。This change only affects code that uses QueryViews with 1-0..1 relationships when running queries that call .Include. 這項功能可提高可靠性,對於幾乎所有應用程式應該都是透明的。It improves reliability and should be transparent to almost all apps. 不過,如果這項功能造成未預期的行為,您可以在應用程式組態檔的 <appSettings> 區段中加入下列項目,來停用這項功能:However, if it causes unexpected behavior, you can disable it by adding the following entry to the <appSettings> section of the app's configuration file:

<add key="EntityFramework_SimplifyUserSpecifiedViews" value="false" />

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

受影響的 APIAffected APIs

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

選擇中斷以從不同的 4.5 SQL 產生還原為更簡單的 4.0 SQL 產生Opt-in break to revert from different 4.5 SQL generation to simpler 4.0 SQL generation

詳細資料Details

產生 JOIN 陳述式並包含限制作業呼叫 (不先使用 OrderBy) 的查詢,現在能產生更簡單的 SQL。Queries that produce JOIN statements and contain a call to a limiting operation without first using OrderBy now produce simpler SQL. 升級至 .NET Framework 4.5 之後,這些查詢會產生比舊版更複雜的 SQL。After upgrading to .NET Framework 4.5, these queries produced more complicated SQL than previous versions.

建議Suggestion

此功能預設為停用。This feature is disabled by default. 如果 Entity Framework 產生額外的 JOIN 陳述式而造成效能降低,您可以啟用這項功能,方法是在應用程式組態檔 (app.config) 的 <appSettings> 區段中新增下列項目:If Entity Framework generates extra JOIN statements that cause performance degradation, you can enable this feature by adding the following entry to the <appSettings> section of the application configuration (app.config) file:

<add key="EntityFramework_SimplifyLimitOperations" value="true" />

名稱Name Value
範圍Scope 透明Transparent
版本Version 4.5.24.5.2
類型Type 執行階段Runtime

受影響的 APIAffected APIs

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

全球化Globalization

現在支援 Unicode 標準 8.0 版分類Unicode standard version 8.0 categories now supported

詳細資料Details

在 .NET Framework 4.6.2 中,Unicode 資料已從 Unicode 標準 6.3 版升級至 8.0 版。In .NET Framework 4.6.2, Unicode data has been upgraded from Unicode Standard version 6.3 to version 8.0. 在 .NET Framework 4.6.2 中要求 Unicode 字元分類時,某些結果可能不符合舊版 .NET Framework 中的結果。When requesting Unicode character categories in .NET Framework 4.6.2, some results might not match the results in previous .NET Framework versions. 這項變更主要會影響柴羅基文音節和新傣文母音符號和音調標記。This change mostly affects Cherokee syllables and New Tai Lue vowels signs and tone marks.

建議Suggestion

請檢閱程式碼,並移除/變更仰賴硬式編碼的 Unicode 字元分類的邏輯。Review code and remove/change logic that depends on hard-coded Unicode character categories.

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

受影響的 APIAffected APIs

網路Networking

ContentDisposition DateTimes 會傳回稍微不同的字串ContentDisposition DateTimes returns slightly different string

詳細資料Details

System.Net.Mime.ContentDisposition 的字串表示已更新,從 4.6 開始,一律會以兩個位數表示 System.DateTime 的小時元件。String representations of System.Net.Mime.ContentDisposition's have been updated, beginning in 4.6, to always represent the hour component of a System.DateTime with two digits. 這是為了遵守 RFC822RFC2822This is to comply with RFC822 and RFC2822. 這會導致 ToString() 在 4.6 中傳回稍微不同的字串,例如,當其中一個配置的時間項目早於上午 10:00 時。This causes ToString() to return a slightly different string in 4.6 in scenarios where one of the disposition's time elements was before 10:00 AM. 請注意,ContentDispositions 有時會透過轉換成字串來進行序列化,因此應檢閱任何 ToString() 作業、序列化或 GetHashCode 呼叫。Note that ContentDispositions are sometimes serialized via converting them to strings, so any ToString() operations, serialization, or GetHashCode calls should be reviewed.

建議Suggestion

在不同的 .NET Framework 版本中,ContentDispositions 的字串表示不會正確地相互比較。Do not expect that string representations of ContentDispositions from different .NET Framework versions will correctly compare to one another. 如果可能的話,請將字串轉換回 ContentDispositions,再進行比較。Convert the strings back to ContentDispositions, if possible, before conducting a comparison.

名稱Name Value
範圍Scope MinorMinor
版本Version 4.64.6
類型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.VerifyHash 現在會針對任何驗證失敗傳回 FalseRSACng.VerifyHash now returns False for any verification failure

詳細資料Details

從 .NET Framework 4.6.2 開始,如果簽章本身的格式不正確,此方法會傳回 FalseStarting with the .NET Framework 4.6.2, this method returns False if the signature itself is badly formatted. 現在任何驗證失敗都會傳回 False。在 .NET Framework 4.6 和 4.6.1 中,如果簽章本身的格式不正確,此方法會擲回 System.Security.Cryptography.CryptographicExceptionIt now returns false for any verification failure.In the .NET Framework 4.6 and 4.6.1, the method throws a System.Security.Cryptography.CryptographicException if the signature itself is badly formatted.

建議Suggestion

如果驗證失敗且此方法傳回 False,應改為執行任何仰賴處理 System.Security.Cryptography.CryptographicException 來執行的程式碼。Any code whose execution depends on handling the System.Security.Cryptography.CryptographicException should instead execute if validation fails and the method returns False.

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

受影響的 APIAffected APIs

SignedXml 和 EncryptedXml 重大變更SignedXml and EncryptedXml Breaking Changes

詳細資料Details

在 .NET Framework 4.6.2 中,System.Security.Cryptography.Xml.SignedXmlSystem.Security.Cryptography.Xml.EncryptedXml 的安全性修正會導致不同的執行階段行為。In .NET Framework 4.6.2, Security fixes in System.Security.Cryptography.Xml.SignedXml and System.Security.Cryptography.Xml.EncryptedXml lead to different run-time behaviors. 例如,For example,

  • 如果文件具有包含相同 id 屬性的多個項目,且簽章將目標設為這些項目之一以作為簽章的根項目,該文件現在會視為無效。If a document has multiple elements with the same id attribute and a signature targets one of those elements as the root of the signature, the document will now be considered invalid.
  • 在參考中使用非標準 XPath 轉換演算法的文件現在都視為無效。Documents using non-canonical XPath transform algorithms in references are now considered invalid.
  • 在參考中使用非標準 XSLT 轉換演算法的文件現在會視為無效。Documents using non-canonical XSLT transform algorithms in references are now consider invalid.
  • 任何使用外部資源中斷簽章的程式都無法這麼做。Any program making use of external resource detached signatures will be unable to do so.

建議Suggestion

開發人員可能想要檢閱 XmlDsigXsltTransformXmlDsigXsltTransform,以及衍生自 Transform 之類型的使用方式,因為文件收件者可能無法處理它。Developers might want to review the usage of XmlDsigXsltTransform and XmlDsigXsltTransform, as well as types derived from Transform since a document receiver may not be able to process it.

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

受影響的 APIAffected APIs

序列化Serialization

DataContract 因未知類型而序列化失敗的例外狀況訊息已變更Exception message has changed for failed DataContract serialization in case of an unknown type

詳細資料Details

從 .NET Framework 4.6 開始,如果 System.Runtime.Serialization.DataContractSerializerSystem.Runtime.Serialization.Json.DataContractJsonSerializer 由於遺漏「已知類型」而無法序列化或還原序列化,則會發出例外狀況訊息。Beginning in the .NET Framework 4.6, the exception message given if a System.Runtime.Serialization.DataContractSerializer or System.Runtime.Serialization.Json.DataContractJsonSerializer fails to serialize or deserialize due to missing 'known types' has been clarified.

建議Suggestion

應用程式不應該相依於特定的例外狀況訊息。Apps should not depend on specific exception messages. 如果應用程式相依於此訊息,請更新它以預期新的訊息,或者 (最好是) 將它變更為只相依於例外狀況類型。If an app depends on this message, either update it to expect the new message or (preferably) change it to depend only on the exception type.

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

受影響的 APIAffected APIs

NetDataContractSerializer 無法將使用不同 .NET 版本序列化的 ConcurrentDictionary 還原序列化NetDataContractSerializer fails to deserialize a ConcurrentDictionary serialized with a different .NET version

詳細資料Details

根據設計,只有當序列化和還原序列化兩端共用相同的 CLR 類型時,才能使用 System.Runtime.Serialization.NetDataContractSerializerBy design, the System.Runtime.Serialization.NetDataContractSerializer can be used only if both the serializing and deserializing ends share the same CLR types. 因此,不保證使用其中一個 .NET Framework 版本序列化的物件可以透過不同版本還原序列化。System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue>Therefore, it is not guaranteed that an object serialized with one version of the .NET Framework can be deserialized by a different version.System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> 是使用 .NET Framework 4.5 或舊版序列化並使用 .NET Framework 4.5.1 或更新版本還原序列化時,無法正確還原序列化的已知類型。is a type that is known to not to deserialize correctly if serialized with the .NET Framework 4.5 or earlier and deserialized with the .NET Framework 4.5.1 or later.

建議Suggestion

此問題有許多可能的因應措施:There are a number of possible work-arounds for this issue:

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

受影響的 APIAffected APIs

安裝和部署Setup and Deployment

.NET Framework 4.6 和更新版本中的產品版本變更Product versioning changes in the .NET Framework 4.6 and later versions

詳細資料Details

舊版 .NET Framework (特別是 .NET Framework 4、4.5、4.5.1 和 4.5.2) 的產品版本已變更。Product versioning has changed from the previous releases of the .NET Framework, and particularly from the .NET Framework 4, 4.5, 4.5.1, and 4.5.2. 以下是詳細的變更:The following are the detailed changes:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full 機碼中的 Version 項目值已變更為 4.6.xxxxx (.NET Framework 4.6 及其小數點發行版本),以及 4.7.xxxxx (.NET Framework 4.7 和 4.7.1)。The value of the Version entry in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full key has changed to 4.6.xxxxx for the .NET Framework 4.6 and its point releases, and to 4.7.xxxxx for the .NET Framework 4.7 and 4.7.1. 在 .NET Framework 4.5、4.5.1 和 4.5.2 中,其格式為 4.5.xxxxxIn the .NET Framework 4.5, 4.5.1, and 4.5.2, it had the format 4.5.xxxxx.
  • .NET Framework 檔案的檔案和產品版本已從舊版配置 4.0.30319.x 變更為 4.6.X.0 (.NET Framework 4.6 及其小數點發行版本),以及 4.7.X.0 (.NET Framework 4.7 和 4.7.1)。The file and product versioning for .NET Framework files has changed from the earlier versioning scheme of 4.0.30319.x to 4.6.X.0 for the .NET Framework 4.6 and its point releases, and to 4.7.X.0 for the .NET Framework 4.7 and 4.7.1. 當您以滑鼠右鍵按一下檔案後再檢視檔案的屬性時,會看到這些新值。You can see these new values when you view the file's Properties after right-clicking on a file.
  • 受控組件的 AssemblyFileVersionAttributeAssemblyInformationalVersionAttribute 屬性,對於 .NET Framework 4.6 及其小數點發行版本,其 Version 值的格式為 4.6.X.0,對於 .NET Framework 4.7 和 4.7.1,格式則為 4.7.X.0。The AssemblyFileVersionAttribute and AssemblyInformationalVersionAttribute attributes for managed assemblies have Version values in the form 4.6.X.0 for the .NET Framework 4.6 and its point releases, and 4.7.X.0 for the .NET Framework 4.7 and 4.7.1.
  • 在 .NET Framework 4.6、4.6.1、4.6.2、4.7 和 4.7.1 中,Environment.Version 屬性會傳回固定的版本字串 4.0.30319.42000In the .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, and 4.7.1, the Environment.Version property returns the fixed version string 4.0.30319.42000. 在 .NET Framework 4、4.5、4.5.1 和 4.5.2 中,其會以 4.0.30319.xxxxx 格式傳回版本字串 (例如 "4.0.30319.18010")。In the .NET Framework 4, 4.5, 4.5.1, and 4.5.2, it returns version strings in the format 4.0.30319.xxxxx (for example, "4.0.30319.18010"). 請注意,建議應用程式程式碼與 Environment.Version 屬性有任何新的相依性。Note that we do not recommend application code taking any new dependency on the Environment.Version property.
如需詳細資訊,請參閱如何:判斷安裝的 .NET Framework 版本For more information, see How to: Determine which .NET Framework Versions Are Installed.

建議Suggestion

一般而言,應用程式需要具備可偵測 .NET Framework 的執行階段版本和安裝目錄等項目的建議技術:In general, applications should depend on the recommended techniques for detecting such things as the runtime version of the .NET Framework and the installation directory:

  • 若要偵測 .NET Framework 的執行階段版本,請參閱如何:判斷安裝的 .NET Framework 版本To detect the runtime version of the .NET Framework, see How to: Determine Which .NET Framework Versions Are Installed.
  • 若要判斷 .NET Framework 的安裝路徑,請使用 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full 機碼中的 InstallPath 項目值。To determine the installation path for the .NET Framework, use the value of the InstallPath entry in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full key.
[!IMPORTANT] 子機碼名稱是 NET Framework Setup,不是 .NET Framework SetupThe subkey name is NET Framework Setup, not .NET Framework Setup.
  • 若要判斷 .NET Framework Common Language Runtime 的目錄路徑,請呼叫 RuntimeEnvironment.GetRuntimeDirectory() 方法。To determine the directory path to the .NET Framework common language runtime, call the RuntimeEnvironment.GetRuntimeDirectory() method.
  • 若要取得 CLR 版本,請呼叫 RuntimeEnvironment.GetSystemVersion() 方法。To get the CLR version, call the RuntimeEnvironment.GetSystemVersion() method. 針對 .NET Framework 4 及其小數點發行版本 (.NET Framework 4.5、4.5.1、4.5.2 以及 .NET Framework 4.6、4.6.1、4.6.2、4.7 和 4.7.1),該方法會傳回字串 v4.0.30319。For the .NET Framework 4 and its point releases (the .NET Framework 4.5, 4.5.1, 4.5.2, and .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, and 4.7.1), it returns the string v4.0.30319.

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

受影響的 APIAffected APIs

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

.NET Framework 4.6 在登錄中註冊本身時不使用 4.5.x.x 版本The .NET Framework 4.6 does not use a 4.5.x.x version when registering itself in the registry

詳細資料Details

如預期一般,.NET Framework 4.6 在登錄中的版本機碼設定 (位於 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full) 開頭為 '4.6',而不是 '4.5'。As one might expect, the version key set in the registry (at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full) for the .NET Framework 4.6 begins with '4.6', not '4.5'. 相依於這些登錄機碼以得知電腦上所安裝之 .NET Framework 版本的應用程式應該加以更新,才能了解 4.6 是新的可能版本,以及其與先前的 4.5.x 版相容。Apps that depend on these registry keys to know which .NET Framework versions are installed on a machine should be updated to understand that 4.6 is a new possible version, and one that is compatible with previous 4.5.x releases.

建議Suggestion

藉由尋找 4.5 登錄機碼來更新 .NET Framework 4.5 安裝的應用程式探查,使其也接受 4.6。Update apps probing for a .NET Framework 4.5 install by looking for 4.5 registry keys to also accept 4.6.

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

受影響的 APIAffected APIs

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

工具Tools

Contract.Invariant 或 Contract.Requires<TException> 不會將 String.IsNullOrEmpty 視為 pureContract.Invariant or Contract.Requires<TException> do not consider String.IsNullOrEmpty to be pure

詳細資料Details

針對以 .NET Framework 4.6.1 為目標的應用程式,如果的非變異合約 Contract.Invariant 或呼叫方法的前置條件合約 Requires ,重寫器 String.IsNullOrEmpty 會發出編譯器警告 CC1036:偵測 " 到方法 ' System.string. IsNullOrWhiteSpace (system.string) ' 的呼叫,但方法中沒有 [純]。 " 這是編譯器警告,而不是編譯器錯誤。For apps that target the .NET Framework 4.6.1, if the invariant contract for Contract.Invariant or the precondition contract for Requires calls the String.IsNullOrEmpty method, the rewriter emits compiler warning CC1036: "Detected call to method 'System.String.IsNullOrWhiteSpace(System.String)' without [Pure] in method." This is a compiler warning rather than a compiler error.

建議Suggestion

GitHub 問題 #339 中已解決這種行為。This behavior was addressed in GitHub Issue #339. 若要移除這個警告,您可以從 GitHub 下載並編譯程式碼合約工具原始程式碼的更新版本。To eliminate this warning, you can download and compile an updated version of the source code for the Code Contracts tool from GitHub. 您可以在頁面底部找到下載資訊。Download information is found at the bottom of the page.

名稱Name Value
範圍Scope MinorMinor
版本Version 4.6.14.6.1
類型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)

現在會遵守 MinFreeMemoryPercentageToActiveServiceMinFreeMemoryPercentageToActiveService is now respected

詳細資料Details

此設定建立伺服器上必須提供才能啟動 WCF 服務的最小記憶體。This setting establishes the minimum memory that must be available on the server before a WCF service can be activated. 其設計目的是為了防止發生 System.OutOfMemoryException 例外狀況。It is designed to prevent System.OutOfMemoryException exceptions. 在 .NET Framework 4.5 中,此設定不會造成影響。In the .NET Framework 4.5, this setting had no effect. 在 .NET Framework 4.5.1 中,會遵守此設定。In the .NET Framework 4.5.1, the setting is observed.

建議Suggestion

如果 Web 伺服器上可用的記憶體小於此組態設定所定義的百分比,則會發生例外狀況。An exception occurs if the free memory available on the web server is less than the percentage defined by the configuration setting. 某些成功啟動並在有限記憶體環境下執行的 WCF 服務現在可能會失敗。Some WCF services that successfully started and ran in a constrained memory environment may now fail.

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

受影響的 APIAffected APIs

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

從 WCF TransportDefaults 中移除 SSL3Remove Ssl3 from the WCF TransportDefaults

詳細資料Details

當使用 NetTcp 搭配傳輸安全性和憑證類型的認證時,SSL 3 通訊協定已不再是用來交涉安全連接的預設通訊協定。When using NetTcp with transport security and a credential type of certificate, the SSL 3 protocol is no longer a default protocol used for negotiating a secure connection. 在大部分情況下,應該不會影響現有的應用程式,因為 TLS 1.0 一律包含在 NetTcp 的通訊協定清單中。In most cases there should be no impact to existing apps as TLS 1.0 has always been included in the protocol list for NetTcp. 所有現有的用戶端應該能夠使用至少 TLS 1.0 來交涉連接。All existing clients should be able to negotiate a connection using at least TLS1.0.

建議Suggestion

如果需要 SSL3,請使用下列組態機制其中之一,將 SSL3 新增至交涉通訊協定的清單。If Ssl3 is required, use one of the following configuration mechanisms to add Ssl3 to the list of negotiated protocols.

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

受影響的 APIAffected APIs

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.

使用 NETTCP 進行 SSL 安全性和 MD5 憑證驗證的 WCF 服務WCF services that use NETTCP with SSL security and MD5 certificate authentication

詳細資料Details

.NET Framework 4.6 新增了 TLS 1.1 和 TLS 1.2 至 WCF SSL 的預設通訊協定清單。The .NET Framework 4.6 adds TLS 1.1 and TLS 1.2 to the WCF SSL default protocol list. 當用戶端和伺服器電腦安裝 .NET Framework 4.6 或更新版本時,會使用 TLS 1.2 進行交涉。TLS 1.2 不支援 MD5 憑證驗證。When both client and server machines have the .NET Framework 4.6 or later installed, TLS 1.2 is used for negotiation.TLS 1.2 does not support MD5 certificate authentication. 因此,如果客戶使用 MD5 憑證,WCF 用戶端將無法連線到 WCF 服務。As a result, if a customer uses an MD5 certificate, the WCF client will fail to connect to the WCF service.

建議Suggestion

您可以執行下列其中一項動作來解決這個問題,使 WCF 用戶端可以連線到 WCF 伺服器︰You can work around this issue so that a WCF client can connect to a WCF server by doing any of the following:

  • 更新憑證為不使用 MD5 演算法。Update the certificate to not use the MD5 algorithm. 這是建議的解決方案。This is the recommended solution.
  • 如果繫結在原始程式碼中不是以動態方式設定,請更新應用程式的組態檔,以使用 TLS 1.1 或舊版的通訊協定。If the binding is not dynamically configured in source code, update the application's configuration file to use TLS 1.1 or an earlier version of the protocol. 這可讓您繼續使用執行 MD5 雜湊演算法的憑證。This allows you to continue to use a certificate with the MD5 hash algorithm.

警告

我們不建議採取這項因應措施,因為使用 MD5 雜湊演算法的憑證並不安全。This workaround is not recommended, since a certificate with the MD5 hash algorithm is considered insecure.

下列組態檔示範如何進行:The following configuration file does this:

<configuration>
  <system.serviceModel>
    <bindings>
      <netTcpBinding>
        <binding>
          <security mode= "None/Transport/Message/TransportWithMessageCredential" >
            <transport clientCredentialType="None/Windows/Certificate"
                       protectionLevel="None/Sign/EncryptAndSign"
                       sslProtocols="Ssl3/Tls1/Tls11">
            </transport>
          </security>
        </binding>
      </netTcpBinding>
    </bindings>
  </system.ServiceModel>
</configuration>

警告

我們不建議採取這項因應措施,因為使用 MD5 雜湊演算法的憑證並不安全。This workaround is not recommended, since a certificate with the MD5 hash algorithm is considered insecure.

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

受影響的 APIAffected APIs

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

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

從 DataGrid 的 UnloadingRow 事件處理常式存取 WPF DataGrid 的選取項目可能會導致 NullReferenceExceptionAccessing a WPF DataGrid's selected items from a handler of the DataGrid's UnloadingRow event can cause a NullReferenceException

詳細資料Details

由於 .NET Framework 4.5 中的 Bug),涉及移除資料列之 DataGrid 事件的事件處理常式,可能會在它們存取 DataGridSystem.Windows.Controls.Primitives.Selector.SelectedItemSystem.Windows.Controls.Primitives.MultiSelector.SelectedItems 屬性時導致擲回 System.NullReferenceExceptionDue to a bug in the .NET Framework 4.5, event handlers for DataGrid events involving the removal of a row can cause a System.NullReferenceException to be thrown if they access the DataGrid's System.Windows.Controls.Primitives.Selector.SelectedItem or System.Windows.Controls.Primitives.MultiSelector.SelectedItems properties.

建議Suggestion

此問題在 .NET Framework 4.6 中已修正,因此可藉由升級至該版 .NET Framework 來解決。This issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.

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

受影響的 APIAffected APIs

從 CellEditEnding 處理常式呼叫 DataGrid.CommitEdit 會卸除焦點Calling DataGrid.CommitEdit from a CellEditEnding handler drops focus

詳細資料Details

從其中一個 System.Windows.Controls.DataGridSystem.Windows.Controls.DataGrid.CellEditEnding 事件處理常式呼叫 CommitEdit() 會導致 System.Windows.Controls.DataGrid 失去焦點。Calling CommitEdit() from one of the System.Windows.Controls.DataGrid's System.Windows.Controls.DataGrid.CellEditEnding event handlers causes the System.Windows.Controls.DataGrid to lose focus.

建議Suggestion

此錯誤 (bug) 在 .NET Framework 4.5.2 中已修正,因此可藉由升級 .NET Framework 來避免。This bug has been fixed in the .NET Framework 4.5.2, so it can be avoided by upgrading the .NET Framework. 或者,您也可以在呼叫 System.Windows.Controls.DataGrid.CommitEdit() 之後明確重新選取 System.Windows.Controls.DataGrid,來避免此 Bug。Alternatively, it can be avoided by explicitly re-selecting the System.Windows.Controls.DataGrid after calling System.Windows.Controls.DataGrid.CommitEdit().

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

受影響的 APIAffected APIs

在已選取項目的 WPF ListBox、ListView 或 DataGrid 上呼叫 Items.Refresh 會導致在項目中出現重複的項目Calling Items.Refresh on a WPF ListBox, ListView, or DataGrid with items selected can cause duplicate items to appear in the element

詳細資料Details

在 .NET Framework 4.5 中,如果 System.Windows.Controls.ListBox 中已選取項目,從程式碼呼叫 ListBox.Items.Refresh 可能會導致選取的項目在清單中重複出現。In the .NET Framework 4.5, calling ListBox.Items.Refresh from code while items are selected in a System.Windows.Controls.ListBox can cause the selected items to be duplicated in the list. System.Windows.Controls.ListViewSystem.Windows.Controls.DataGrid 會發生類似的問題。A similar issue occurs with System.Windows.Controls.ListView and System.Windows.Controls.DataGrid. 這在 .NET Framework 4.6 中已修正。This is fixed in the .NET Framework 4.6.

建議Suggestion

您可以在呼叫 System.Windows.Data.CollectionView.Refresh() 之前以程式設計方式取消選取項目,然後在呼叫完成之後重新選取項目來解決此問題。This issue may be worked around by programmatically unselecting items before System.Windows.Data.CollectionView.Refresh() is called and then re-selecting them after the call is completed. 此外,此問題在 .NET Framework 4.6 中已修正,因此可藉由升級至該版 .NET Framework 來解決。Alternatively, this issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.

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

受影響的 APIAffected APIs

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

變更 TextBlock 控制項之父代的 IsEnabled 屬性會影響任何子控制項Changing the IsEnabled property of the parent of a TextBlock control affects any child controls

詳細資料Details

從 .NET Framework 4.6.2 開始,變更 System.Windows.Controls.TextBlock 控制項之父代的 System.Windows.UIElement.IsEnabled 屬性,會影響 System.Windows.Controls.TextBlock 控制項的任何子控制項 (例如超連結和按鈕)。在 .NET Framework 4.6.1 和舊版中,System.Windows.Controls.TextBlock 內的控制項不一定會反映 System.Windows.Controls.TextBlock 父代的 System.Windows.UIElement.IsEnabled 屬性狀態。Starting with the .NET Framework 4.6.2, changing the System.Windows.UIElement.IsEnabled property of the parent of a System.Windows.Controls.TextBlock control affects any child controls (such as hyperlinks and buttons) of the System.Windows.Controls.TextBlock control.In the .NET Framework 4.6.1 and earlier versions, controls inside a System.Windows.Controls.TextBlock did not always reflect the state of the System.Windows.UIElement.IsEnabled property of the System.Windows.Controls.TextBlock parent.

建議Suggestion

無。None. 這項變更符合 System.Windows.Controls.TextBlock 控制項內的之控制項的預期行為。This change conforms to the expected behavior for controls inside a System.Windows.Controls.TextBlock control.

名稱Name Value
範圍Scope MinorMinor
版本Version 4.6.24.6.2
類型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.

已修正當 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.

水平捲動和虛擬化Horizontal scrolling and virtualization

詳細資料Details

此變更會套用至以正交於主要捲動方向之方向執行自身虛擬化的 System.Windows.Controls.ItemsControl (主要範例是 EnableColumnVirtualization="True" 的 System.Windows.Controls.DataGrid)。This change applies to an System.Windows.Controls.ItemsControl that does its own virtualization in the direction orthogonal to the main scrolling direction (the chief example is System.Windows.Controls.DataGrid with EnableColumnVirtualization="True"). 某些水平捲動作業的結果已變更,產生的結果更直覺,且更類似於可比較的垂直作業的結果。The outcome of certain horizontal scrolling operations has been changed to produce results that are more intuitive and more analogous to the results of comparable vertical operations.

這些作業包括 [捲動至此處] 和 [右邊緣],以使用以滑鼠右鍵按一下水平捲軸所取得之功能表中的名稱。The operations include "Scroll Here" and "Right Edge", to use the names from the menu obtained by right-clicking a horizontal scrollbar. 這兩個都會計算候選位移並呼叫 SetHorizontalOffset(Double)Both of these compute a candidate offset and call SetHorizontalOffset(Double).

捲動至新的位移後,「此處」或「右邊緣」的定義可能已變更,因為最近取消虛擬化的內容已變更 System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth 的值。After scrolling to the new offset, the notion of "here" or "right edge" may have changed because newly de-virtualized content has changed the value of System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth.

在 .NET Framework 4.6.2 之前,捲軸作業會直接使用候選位移,即使它可能已不再是「此處」或位於「右邊緣」。Prior to .NET Framework 4.6.2, the scroll operation simply uses the candidate offset, even though it may not be "here" or at the "right edge" any more. 這會導致類似捲動指標「反彈」的效果,以範例來說明最為合適。This results in effects like "bouncing" the scroll thumb, best illustrated by example. 假設 System.Windows.Controls.DataGrid 具有 ExtentWidth=1000 和 Width=200。Suppose a System.Windows.Controls.DataGrid has ExtentWidth=1000 and Width=200. 捲動到「右邊緣」會使用候選位移 1000 - 200 = 800。A scroll to "Right Edge" uses candidate offset 1000 - 200 = 800. 捲動到該位移時,新的資料行會取消虛擬化;假設它們非常寬,因此 System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth 變更為 2000。While scrolling to that offset, new columns are de- virtualized; let's suppose they are very wide, so that the System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth changes to 2000. 捲軸在 HorizontalOffset=800 結束,而指標會「反彈」回到捲軸中央附近,精確來說是在 800/2000 等於 40% 的位置。The scroll ends with HorizontalOffset=800, and the thumb "bounces" back to near the middle of the scrollbar - precisely at 800/2000 = 40%.

發生這種情況時,變更是重新計算新的候選位移,然後再試一次。The change is to recompute a new candidate offset when this situation occurs, and try again. (這是垂直捲動目前運作的方式)。(This is how vertical scrolling works already.)

此變更會為使用者產生更為可預測且直覺式的體驗,但它會影響依賴 System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset 於水平捲動後 (無論是由使用者叫用或是明確呼叫 SetHorizontalOffset(Double)) 之確切值的所有應用程式。The change produces a more predictable and intuitive experience for the end user, but it could also affect any app that depends on the exact value of System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset after a horizontal scroll, whether invoked by the end user or by an explicit call to SetHorizontalOffset(Double).

建議Suggestion

在因為取消虛擬化而可能變更 System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth 的任何水平捲動之後,為 System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset 使用預測值的應用程式應該改為擷取實際值 (以及 System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth 的值)。An app that uses a predicted value for System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset should be changed to fetch the actual value (and the value of System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth) after any horizontal scroll that could change System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth due to de-virtualization.

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

受影響的 APIAffected APIs

格線含星號資料列空間配置演算法的改進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.

使用自訂 DataTemplates 時,會斷斷續續無法捲動至 ItemsControls (例如 ListBox 和 DataGrid) 中的底部項目Intermittently unable to scroll to bottom item in ItemsControls (like ListBox and DataGrid) when using custom DataTemplates

詳細資料Details

在某些情況下,.NET Framework 4.5 中的 Bug 會導致在使用自訂 DataTemplates 時,ItemsControls (例如 System.Windows.Controls.ListBoxSystem.Windows.Controls.ComboBoxSystem.Windows.Controls.DataGrid 等) 無法捲動至其底部項目。In some instances, a bug in the .NET Framework 4.5 is causing ItemsControls (like System.Windows.Controls.ListBox, System.Windows.Controls.ComboBox, System.Windows.Controls.DataGrid, etc.) to not scroll to their bottom item when using custom DataTemplates. 如果嘗試捲動第二次 (在向上捲動之後),則會再次運作。If the scrolling is attempted a second time (after scrolling back up), it will work then.

建議Suggestion

此問題在 .NET Framework 4.5.2 中已修正,因此可藉由升級至該版 .NET Framework (或更新版本) 來解決。This issue has been fixed in the .NET Framework 4.5.2 and may be addressed by upgrading to that version (or a later version) of the .NET Framework. 此外,使用者仍可將捲軸拖曳至這些集合中的最後一個項目,但可能需要嘗試兩次才能成功。Alternatively, users can still drag scroll bars to the final items in these collections, but may need to try twice to do so successfully.

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

受影響的 APIAffected APIs

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

Items.Clear 不會從 SelectedItems 移除重複項目Items.Clear does not remove duplicates from SelectedItems

詳細資料Details

假設選取器 (啟用了多個選取項目) 在其 System.Windows.Controls.Primitives.MultiSelector.SelectedItems 集合中有重複項目 - 相同的項目出現一次以上。Suppose a Selector (with multiple selection enabled) has duplicates in its System.Windows.Controls.Primitives.MultiSelector.SelectedItems collection - the same item appears more than once. 從資料來源移除這些項目 (例如,藉由呼叫 Items.Clear) 無法從 System.Windows.Controls.Primitives.MultiSelector.SelectedItems 中加以移除;只會移除第一個執行個體。Removing those items from the data source (e.g. by calling Items.Clear) fails to remove them from System.Windows.Controls.Primitives.MultiSelector.SelectedItems; only the first instance is removed. 此外,後續使用 System.Windows.Controls.Primitives.MultiSelector.SelectedItems (例如 SelectedItems.Clear()) 可能會發生像是 System.ArgumentException 的問題,因為 System.Windows.Controls.Primitives.MultiSelector.SelectedItems 包含已不在資料來源中的項目。Furthermore, subsequent use of System.Windows.Controls.Primitives.MultiSelector.SelectedItems (e.g. SelectedItems.Clear()) can encounter problems such as System.ArgumentException, because System.Windows.Controls.Primitives.MultiSelector.SelectedItems contains items that are no longer in the data source.

建議Suggestion

如有可能,請升級至 .NET Framework 4.6.2。Upgrade if possible to .NET Framework 4.6.2.

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

受影響的 APIAffected APIs

詳細資料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.

ObservableCollection<T>.Move 的 ListBoxItem IsSelected 繫結問題ListBoxItem IsSelected binding issue with ObservableCollection<T>.Move

詳細資料Details

針對繫結至 System.Windows.Controls.ListBox 且已選取項目的集合呼叫 Move(Int32, Int32)MoveItem(Int32, Int32),可能會在未來選取或取消選取 System.Windows.Controls.ListBox 項目時導致不穩定的行為。Calling Move(Int32, Int32) or MoveItem(Int32, Int32) on a collection bound to a System.Windows.Controls.ListBox with items selected can lead to erratic behavior with future selection or unselection of System.Windows.Controls.ListBox items.

建議Suggestion

呼叫 System.Collections.ObjectModel.Collection<T>.Remove(T)System.Collections.ObjectModel.Collection<T>.Insert(Int32, T) 而不是 Move(Int32, Int32) 可解決此問題。Calling System.Collections.ObjectModel.Collection<T>.Remove(T) and System.Collections.ObjectModel.Collection<T>.Insert(Int32, T) instead of Move(Int32, Int32) will work around this issue. 此外,此問題在 .NET Framework 4.6 中已修正,因此可藉由升級至該版 .NET Framework 來解決。Alternatively, this issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.

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

受影響的 APIAffected APIs

在自動化樹狀目錄中的 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.

以滑鼠右鍵按一下 WPF DataGrid 資料列標頭會變更 DataGrid 選取項目Right clicking on a WPF DataGrid row header changes the DataGrid selection

詳細資料Details

選取多個資料列時,若以滑鼠右鍵按一下選取的 System.Windows.Controls.DataGrid 資料列標頭,會導致 System.Windows.Controls.DataGrid 的選取項目變更為只有該資料列。Right-clicking a selected System.Windows.Controls.DataGrid row header while multiple rows are selected results in the System.Windows.Controls.DataGrid's selection changing to only that row.

建議Suggestion

此問題在 .NET Framework 4.6 中已修正,因此可藉由升級至該版 .NET Framework 來解決。This issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.

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

受影響的 APIAffected APIs

在 VirtualizingStackPanel 中捲動 WPF TreeView 或群組 ListBox 可能會造成停止回應Scrolling a WPF TreeView or grouped ListBox in a VirtualizingStackPanel can cause a hang

詳細資料Details

在 .NET Framework v4.5 中,如果檢視區有邊界 (例如在 System.Windows.Controls.TreeView 中的項目之間或在 ItemsPresenter 項目上),在虛擬化堆疊面板中捲動 WPF System.Windows.Controls.TreeView 可能會造成停止回應。In the .NET Framework v4.5, scrolling a WPF System.Windows.Controls.TreeView in a virtualized stack panel can cause hangs if there are margins in the viewport (between the items in the System.Windows.Controls.TreeView, for example, or on an ItemsPresenter element). 此外,在某些情況下,即使沒有邊界,檢視中不同大小的項目也可能會造成不穩定的情況。Additionally, in some cases, different sized items in the view can cause instability even if there are no margins.

建議Suggestion

您可以升級至 .NET Framework 4.5.1 來避免此錯誤 (bug)。This bug can be avoided by upgrading to .NET Framework 4.5.1. 或者,如果所有包含的項目大小都相同,您也可以從虛擬化堆疊面板內的檢視集合 (例如 System.Windows.Controls.TreeView) 移除邊界。Alternatively, margins can be removed from view collections (like System.Windows.Controls.TreeViews) within virtualized stack panels if all contained items are the same size.

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

受影響的 APIAffected APIs

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.

若語言不在 OS 的輸入語言清單中,啟用文字之控制項中的 WPF 拼字檢查不適用於 Windows 10WPF spell checking in text-enabled controls will not work in Windows 10 for languages not in the OS's input language list

詳細資料Details

因為只有輸入語言清單上的語言可以使用平台拼字檢查功能,所以拼字檢查工具在 Windows 10 上執行時可能不適用於啟用 WPF 文字的控制項。在 Windows 10 中,將語言新增至可用鍵盤的清單時,Windows 會自動下載並安裝對應的 Feature on Demand (FOD) 套件,以提供拼字檢查功能。When running on Windows 10, the spell checker may not work for WPF text-enabled controls because platform spell-checking capabilities are available only for languages present in the input languages list.In Windows 10, when a language is added to the list of available keyboards, Windows automatically downloads and installs a corresponding Feature on Demand (FOD) package that provides spell-checking capabilities. 只要將語言加入輸入語言清單中,就可支援拼字檢查工具。By adding the language to the input languages list, the spell checker will be supported.

建議Suggestion

請注意,要進行拼字檢查的語言或文字必須新增為輸入語言,拼字檢查才能在 Windows 10 中正常運作。Be aware that the language or text to be spell-checked must be added as an input language for spell-checking to work in Windows 10.

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

受影響的 APIAffected APIs

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

WPF 視窗在擴充到單一顯示器之外時呈現而不裁剪WPF windows are rendered without clipping when extending outside a single monitor

詳細資料Details

在 Windows 8 和更新版本中執行的 .NET Framework 4.6 多重監視器案例中,如果視窗擴充到單一顯示畫面之外,可呈現完整視窗而不會將其裁剪。In the .NET Framework 4.6 running on Windows 8 and above, the entire window is rendered without clipping when it extends outside of single display in a multi-monitor scenario. 這與舊版 .NET Framework 不同,後者會在 WPF 視窗擴充到單一顯示畫面之外時裁剪該視窗。This is different from previous versions of the .NET Framework which would clip WPF windows that extended beyond a single display.

建議Suggestion

您可以在應用程式組態檔的 <appSettings> 中使用 <EnableMultiMonitorDisplayClipping> 項目,或在應用程式啟動時藉由設定 EnableMultiMonitorDisplayClipping 屬性,來明確設定這項行為 (不論是否裁剪)。This behavior (whether to clip or not) can be explicitly set using the <EnableMultiMonitorDisplayClipping> element in <appSettings> in an application's configuration file, or by setting the EnableMultiMonitorDisplayClipping property at app startup.

名稱Name Value
範圍Scope MinorMinor
版本Version 4.64.6
類型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.

XMLXML

XML 剖析變更XML parsing changes

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

詳細資料Details

基於安全性考慮,下列變更已引入 XML 剖析 API:For security reasons, the following changes were introduced into XML parsing APIS:

注意

XmlReaderSettings 所有 XML 剖析器都會使用,因此雖然這項變更有助於這 XmlReader 種情況,但它也會影響其他案例。XmlReaderSettings is used by all XML parsers, so while this change helps the XmlReader case, it also affects other scenarios.

建議Suggestion

若要還原為先前的行為,您可以在登錄中設定值。To revert to the previous behavior, you can set a value in the registry. 將名為的 DWORD 值新增至登錄機 EnableLegacyXmlSettings HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\XML 碼,並將其值設定為 1Add a DWORD value named EnableLegacyXmlSettings to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\XML registry key, and set its value to 1. 您也可以改為在 HKEY_CURRENT_USER hive 中新增登錄值。You can also add the registry value in the HKEY_CURRENT_USER hive instead.

受影響的 APIAffected APIs

此外,任何相依于 XmlResolver (直接或間接)的 XML API 都會受到影響。In addition, any XML API that depends on XmlResolver, either directly or indirectly, is affected.