將執行階段變更從 .NET Framework 4.0 移轉至 4.5.2Runtime Changes for Migration from .NET Framework 4.0 to 4.5.2

如果您想從 .NET Framework 4.0 移轉至 4.5.2,請檢閱下列主題中可能會影響應用程式的應用程式相容性問題:If you are migrating from the .NET Framework 4.0 to 4.5.2, 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 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

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

HttpRequest.ContentEncoding 屬性禁止 UTF7HttpRequest.ContentEncoding property prohibits UTF7

詳細資料Details

從 .NET Framework 4.5 開始,在 System.Web.HttpRequest 本文中禁止使用 UTF-7 編碼。Beginning in .NET Framework 4.5, UTF-7 encoding is prohibited in System.Web.HttpRequests' bodies. 在某些情況下,倚賴傳入 UTF-7 資料的應用程式資料將無法正確解碼。Data for applications that depend on incoming UTF-7 data will not decode properly in some cases.

建議Suggestion

在理想情況下,您應該更新應用程式,不要在 System.Web.HttpRequest 中使用 UTF-7 編碼。Ideally, applications should be updated to not use UTF-7 encoding in System.Web.HttpRequests. 或者,您也可以使用 appSettings 項目的 aspnet:AllowUtf7RequestContentEncoding 屬性還原舊版行為。Alternatively, legacy behavior can be restored by using the aspnet:AllowUtf7RequestContentEncoding attribute of the appSettings element.

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

受影響的 APIAffected APIs

HttpUtility.JavaScriptStringEncode 會逸出 & 符號HttpUtility.JavaScriptStringEncode escapes ampersand

詳細資料Details

從 .NET Framework 4.5 開始,System.Web.HttpUtility.JavaScriptStringEncode(String) 會逸出 & 字元。Starting with the .NET Framework 4.5, System.Web.HttpUtility.JavaScriptStringEncode(String) escapes the ampersand (&) character.

建議Suggestion

如果您的應用程式相依於此方法的舊版行為,您可以將 aspnet:JavaScriptDoNotEncodeAmpersand 設定新增至組態檔中的 ASP.NET appSettings 項目If your app depends on the previous behavior of this method, you can add an aspnet:JavaScriptDoNotEncodeAmpersand setting to the ASP.NET appSettings element in your configuration file.

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

受影響的 APIAffected APIs

IPad 不應用於自訂功能檔案,因為現在它是一種瀏覽器功能IPad should not be used in custom capabilities file because it is now a browser capability

詳細資料Details

從 .NET Framework 4.5 開始,iPad 是預設 ASP.NET 瀏覽器功能檔案中的識別碼,所以不應將其用於自訂功能檔案Beginning in .NET Framework 4.5, iPad is an identifier in the default ASP.NET browser capabilities file, so it should not be used in a custom capabilities file

建議Suggestion

如果需要 iPad 特定功能,則必須以修改 iPad 行為,方法是在預先定義的閘道 refID "IPad" 上設定功能 ,而不是透過使用者代理程式比對產生新的 "IPad" 識別碼。If iPad-specific capabilities are required, it is necessary to modify iPad behavior by setting capabilities on the pre-defined gateway refID "IPad" instead of by generating a new "IPad" ID by user agent matching.

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

無法再將 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.

Page.LoadComplete 事件不再導致 System.Web.UI.WebControls.EntityDataSource 控制項叫用資料繫結Page.LoadComplete event no longer causes System.Web.UI.WebControls.EntityDataSource control to invoke data binding

詳細資料Details

LoadComplete 事件不再使 System.Web.UI.WebControls.EntityDataSource 控制項叫用資料繫結,讓變更建立/更新/刪除參數。The LoadComplete event no longer causes the System.Web.UI.WebControls.EntityDataSource control to invoke data binding for changes to create/update/delete parameters. 這項變更可以消除來回存取資料庫的額外作業,防止重設控制項的值,並且產生與其他資料控制項 (例如 System.Web.UI.WebControls.SqlDataSourceSystem.Web.UI.WebControls.ObjectDataSource) 一致的行為。This change eliminates an extraneous trip to the database, prevents the values of controls from being reset, and produces behavior that is consistent with other data controls, such as System.Web.UI.WebControls.SqlDataSource and System.Web.UI.WebControls.ObjectDataSource. 在像是應用程式倚賴於 LoadComplete 事件中叫用資料繫結這類不常見的情況下,這項變更會產生不同的行為。This change produces different behavior in the unlikely event that applications rely on invoking data binding in the LoadComplete event.

建議Suggestion

如果需要資料繫結,請在回傳初期的事件中手動叫用資料繫結。If there is a need for databinding, manually invoke databind in an event that is earlier in the post-back.

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

受影響的 APIAffected APIs

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

使用 ASP.NET StateServer 共用會話狀態需要 web 伺服陣列中的所有伺服器都使用相同的 .NET Framework 版本Sharing session state with ASP.NET StateServer requires all servers in the web farm to use the same .NET Framework version

詳細資料Details

啟用 System.Web.SessionState.SessionStateMode.StateServer 工作階段狀態時,指定之 Web 伺服陣列中的所有伺服器必須使用相同版本的 .NET Framework,才能正確共用狀態。When enabling System.Web.SessionState.SessionStateMode.StateServer session state, all of the servers in the given web farm must use the same version of the .NET Framework in order for state to be properly shared.

建議Suggestion

請務必將共用狀態之 Web 伺服器上的 .NET Framework 版本同時升級。Be sure to upgrade .NET Framework versions on web servers that share state at the same time.

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

受影響的 APIAffected APIs

WebUtility.HtmlDecode 不再將無效的輸入序列解碼WebUtility.HtmlDecode no longer decodes invalid input sequences

詳細資料Details

根據預設,解碼方法不再將無效的輸入序列解碼為無效的 UTF-16 字串,By default, decoding methods no longer decode an invalid input sequence into an invalid UTF-16 string. 而是改為傳回原始輸入。Instead, they return the original input.

建議Suggestion

解碼器輸出的變更只有在您於字串中儲存二進位資料而不是 UTF-16 資料時才相關。The change in decoder output should matter only if you store binary data instead of UTF-16 data in strings. 若要明確控制這個行為,請將 appSettings 項目的 aspnet:AllowRelaxedUnicodeDecoding 屬性設為 true 以啟用舊版行為,或是設為 false 以啟用目前的行為。To explicitly control this behavior, set the aspnet:AllowRelaxedUnicodeDecoding attribute of the appSettings element to true to enable legacy behavior or to false to enable the current behavior.

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

受影響的 APIAffected APIs

核心Core

在 .NET Framework 4.5 中利用 NetDataContractSerializer 序列化過的 ConcurrentDictionary,無法由 .NET Framework 4.5.1 或 4.5.2 還原序列化A ConcurrentDictionary serialized in .NET Framework 4.5 with NetDataContractSerializer cannot be deserialized by .NET Framework 4.5.1 or 4.5.2

詳細資料Details

由於此類型的內部變更,使用 System.Runtime.Serialization.NetDataContractSerializer 以 .NET Framework 4.5 序列化的 ConcurrentDictionary<TKey,TValue> 物件,無法在 .NET Framework 4.5.1 或 .NET Framework 4.5.2 中還原序列化。請注意,反向移動 (以 .NET Framework 4.5.x 序列化並以 .NET Framework 4.5 還原序列化) 則運作正常。Due to internal changes to the type, ConcurrentDictionary<TKey,TValue> objects that are serialized with the .NET Framework 4.5 using the System.Runtime.Serialization.NetDataContractSerializer cannot be deserialized in the .NET Framework 4.5.1 or in the .NET Framework 4.5.2.Note that moving in the other direction (serializing with the .NET Framework 4.5.x and deserializing with the .NET Framework 4.5) works. 同樣地,所有 4.x 跨版本序列化在 .NET Framework 4.6 中都會正常運作。以單一 .NET Framework 版本進行序列化和還原序列化則不受影響。Similarly, all 4.x cross-version serialization works with the .NET Framework 4.6.Serializing and deserializing with a single version of the .NET Framework is not affected.

建議Suggestion

如果必須在 .NET Framework 4.5 和 .NET Framework 4.5.1/4.5.2 之間序列化和還原序列化 System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue>,則應該使用替代的序列化程式 (例如 System.Runtime.Serialization.DataContractSerializerSystem.Runtime.Serialization.Formatters.Binary.BinaryFormatter 序列化程式) 來取代 System.Runtime.Serialization.NetDataContractSerializer。此外,由於此問題已在 .NET Framework 4.6 中解決,因此可藉由升級至該版 .NET Framework 來解決。If it is necessary to serialize and deserialize a System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> between the .NET Framework 4.5 and .NET Framework 4.5.1/4.5.2, an alternate serializer like the System.Runtime.Serialization.DataContractSerializer or System.Runtime.Serialization.Formatters.Binary.BinaryFormatter serializer should be used instead of the System.Runtime.Serialization.NetDataContractSerializer.Alternatively, because this issue is addressed in the .NET Framework 4.6, it may be solved by upgrading to that version of the .NET Framework.

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

受影響的 APIAffected APIs

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

使用 Regex.CompileToAssembly 編譯的組件在 4.0 與 4.5 之間中斷Assemblies compiled with Regex.CompileToAssembly breaks between 4.0 and 4.5

詳細資料Details

如果使用 .NET Framework 4.5 建置編譯之規則運算式的組件,但以 .NET Framework 4 為目標,嘗試在安裝 .NET Framework 4 的系統上使用該組件中的其中一個規則運算式時,會擲回例外狀況。If an assembly of compiled regular expressions is built with the .NET Framework 4.5 but targets the .NET Framework 4, attempting to use one of the regular expressions in that assembly on a system with .NET Framework 4 installed throws an exception.

建議Suggestion

若要解決這個問題,您可以執行下列任何一項操作:To work around this problem, you can do either of the following:

  • 使用 .NET Framework 4 建置包含規則運算式的組件。Build the assembly that contains the regular expressions with the .NET Framework 4.
  • 使用解譯的規則運算式。Use an interpreted regular expression.

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

受影響的 APIAffected APIs

lBlockingCollection<T>.TryTakeFromAny 不會再擲回例外狀況BlockingCollection<T>.TryTakeFromAny does not throw anymore

詳細資料Details

如果其中一個輸入集合標記為已完成,則 TryTakeFromAny(BlockingCollection<T>[], T) 不會再傳回 -1,而且 TakeFromAny(BlockingCollection<T>[], T) 不會再擲回例外狀況。If one of the input collections is marked completed, TryTakeFromAny(BlockingCollection<T>[], T) no longer returns -1 and TakeFromAny(BlockingCollection<T>[], T) no longer throws an exception. 這項變更能夠讓您在其中一個集合為空集合或已完成,而另一個集合仍有可擷取的項目時處理集合。This change makes it possible to work with collections when one of the collections is either empty or completed, but the other collection still has items that can be retrieved.

建議Suggestion

如果在防止集合完成時,使用了傳回 -1 的 TryTakeFromAny 或擲回的 TakeFromAny 來控制流程,現在應該將這類程式碼變更為使用 .Any(b => b.IsCompleted) 來偵測該情況。If TryTakeFromAny returning -1 or TakeFromAny throwing were used for control-flow purposes in cases of a blocking collection being completed, such code should now be changed to use .Any(b => b.IsCompleted) to detect that condition.

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

受影響的 APIAffected APIs

含逾時引數之 Task.WaitAll 方法的行為變更Change in behavior for Task.WaitAll methods with time-out arguments

詳細資料Details

在 .NET Framework 4.5 中,Task.WaitAll 行為變得更一致。在 .NET Framework 4 中,這些方法的行為不一致。Task.WaitAll behavior was made more consistent in .NET Framework 4.5.In the .NET Framework 4, these methods behaved inconsistently. 逾時過期時,如果在方法呼叫之前已完成或取消一個或多個工作,則方法會擲回 System.AggregateException 例外狀況。When the time-out expired, if one or more tasks were completed or canceled before the method call, the method threw an System.AggregateException exception. 當逾時過期時,如果在方法呼叫之前沒有任何已完成或取消的工作,但是有一個或多個工作在方法呼叫之後進入這兩種狀態,則方法會傳回 false。When the time-out expired, if no tasks were completed or canceled before the method call, but one or more tasks entered these states after the method call, the method returned false.

在 .NET Framework 4.5 中,如果逾時間隔到期時仍有任何工作正在執行,這些方法多載現在會傳回 false,而只有在取消輸入工作 (不論是在方法呼叫之前或之後),且沒有其他工作仍在執行時,才會擲回 System.AggregateException 例外狀況。In the .NET Framework 4.5, these method overloads now return false if any tasks are still running when the time-out interval expired, and they throw an System.AggregateException exception only if an input task was cancelled (regardless of whether it was before or after the method call) and no other tasks are still running.

建議Suggestion

如果透過攔截 System.AggregateException 來偵測某個工作在叫用 WaitAll 呼叫之前是否已取消,該程式碼應改為透過 IsCanceled 屬性 (例如:.Any(t => t.IsCanceled)) 執行相同的偵測,因為 .NET Framework 4.6 只會在所有等候的工作在逾時前都已完成時,才會擲回此例外狀況。If an System.AggregateException was being caught as a means of detecting a task that was cancelled prior to the WaitAll call being invoked, that code should instead do the same detection via the IsCanceled property (for example: .Any(t => t.IsCanceled)) since .NET Framework 4.6 will only throw in that case if all awaited tasks are completed prior to the timeout.

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

受影響的 APIAffected APIs

編譯器支援多目標 mscorlib 時的類型轉送Compiler support for type forwarding when multi-targeting mscorlib

詳細資料Details

新的 CodeDOM 功能可讓編譯器針對設為目標的 mscorlib.dll 版本 (而非 .NET Framework 4.5 版的 mscorlib.dll) 進行編譯。A new CodeDOM feature allows a compiler to compile against the targeted version of mscorlib.dll instead of the .NET Framework 4.5 version of mscorlib.dll.

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

受影響的 APIAffected APIs

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

分析工具不會列舉 COR_PRF_GC_ROOT_HANDLECOR_PRF_GC_ROOT_HANDLEs are not being enumerated by profilers

詳細資料Details

在 .NET Framework v4.5.1 中,分析 API RootReferences2() 會錯誤地永不傳回 COR_PRF_GC_ROOT_HANDLE (而是傳回為 COR_PRF_GC_ROOT_OTHER)。In the .NET Framework v4.5.1, the profiling API RootReferences2() is incorrectly never returning COR_PRF_GC_ROOT_HANDLE (they are returned as COR_PRF_GC_ROOT_OTHER instead). 從 .NET Framework 4.6 開始,已修正此問題。This issue is fixed beginning in the .NET Framework 4.6.

建議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.5.14.5.1
類型Type 執行階段Runtime

受影響的 APIAffected APIs

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

還原序列化跨應用程式網域的物件會失敗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.

在 System.Threading.Tasks.Task 中未觀察到的處理期間發生的例外狀況,將不再於完成項執行緒上傳播Exceptions during unobserved processing in System.Threading.Tasks.Task no longer propagate on finalizer thread

詳細資料Details

由於 System.Threading.Tasks.Task 類別代表非同步作業,因此它會攔截非同步處理期間發生的所有非嚴重的例外狀況。Because the System.Threading.Tasks.Task class represents an asynchronous operation, it catches all non-severe exceptions that occur during asynchronous processing. 在 .NET Framework 4.5 中,如果未觀察到某個例外狀況,而您的程式碼絕不會等候這項工作,則該例外狀況將不再於完成項執行緒上傳播,並且會在記憶體回收期間損毀處理序。In the .NET Framework 4.5, if an exception is not observed and your code never waits on the task, the exception will no longer propagate on the finalizer thread and crash the process during garbage collection. 這項變更可以增強使用 Task 類別執行未觀察到的非同步處理之應用程式的可靠性。This change enhances the reliability of applications that use the Task class to perform unobserved asynchronous processing.

建議Suggestion

如果應用程式必須將未觀察到的非同步例外狀況傳播至完成項執行緒,可以藉由提供適當的處理常式給 UnobservedTaskException 事件,或藉由設定執行階段組態項目,來還原舊版行為。If an app depends on unobserved asynchronous exceptions propagating to the finalizer thread, the previous behavior can be restored by providing an appropriate handler for the UnobservedTaskException event, or by setting a runtime configuration element.

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

受影響的 APIAffected APIs

List.Sort 演算法已變更List.Sort algorithm changed

詳細資料Details

從 .NET Framework 4.5 開始,System.Collections.Generic.List<T> 的排序演算法已變更 (變更為內省式排序,而不是快速排序)。Beginning in .NET Framework 4.5, System.Collections.Generic.List<T>'s sort algorithm has changed (to be an introspective sort instead of a quick sort). System.Collections.Generic.List<T> 的排序從未穩定,但這項變更可能會導致不同的案例以不穩定的方式排序。System.Collections.Generic.List<T>'s sort has never been stable, but this change may cause different scenarios to sort in unstable ways. 這只是表示對等項目可能會在 API 的後續呼叫中以不同的順序排序。That simply means that equivalent items may sort in different orders in subsequent calls of the API.

建議Suggestion

因為舊的排序演算法也不穩定 (儘管方式略有不同),應該沒有任何程式碼相依於一律以特定順序排序的對等項目。Because the old sort algorithm was also unstable (though in slightly different ways), there should be no code that depends on equivalent items always sorting in a particular order. 如果有程式碼的執行個體相依於該項目,且湊巧使用舊行為,該程式碼應該更新為使用將明確地以所需順序排序項目的比較子。If there are instances of code depending upon that and being lucky with the old behavior, that code should be updated to use a comparer that will deterministically sort the items in the desired order.

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

受影響的 APIAffected APIs

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.

在 4.0 行為中遺漏目標 Framework Moniker 結果Missing Target Framework Moniker results in 4.0 behavior

詳細資料Details

未在組件層級套用 System.Runtime.Versioning.TargetFrameworkAttribute 的應用程式將會使用 .NET Framework 4.0 的語意 (Quirks) 來自動執行。Applications without a System.Runtime.Versioning.TargetFrameworkAttribute applied at the assembly level will automatically run using the semantics (quirks) of the .NET Framework 4.0. 為了確保有高品質,建議明確設定所有二進位檔的 System.Runtime.Versioning.TargetFrameworkAttribute 屬性,以指出用來建置的 .NET Framework 版本。To ensure high quality, it is recommended that all binaries be explicitly attributed with a System.Runtime.Versioning.TargetFrameworkAttribute indicating the version of the .NET Framework they were built with. 請注意,在專案檔中使用目標 Framework Moniker 會使 MSBuild 自動套用 System.Runtime.Versioning.TargetFrameworkAttributeNote that using a target framework moniker in a project file will cause MSBuild to automatically apply a System.Runtime.Versioning.TargetFrameworkAttribute.

建議Suggestion

您應該透過直接將屬性新增至組件,或藉由在專案檔中或透過 Visual Studio 的專案屬性 GUI 來指定目標 Framework,以提供 System.Runtime.Versioning.TargetFrameworkAttributeA System.Runtime.Versioning.TargetFrameworkAttribute should be supplied, either through adding the attribute directly to the assembly or by specifying a target framework in the project file or through Visual Studio's project properties GUI.

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

受影響的 APIAffected APIs

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

System.Threading.Tasks.Task 不會再於處置物件之後擲回 ObjectDisposedExceptionSystem.Threading.Tasks.Task no longer throw ObjectDisposedException after object is disposed

詳細資料Details

除了 IAsyncResult.AsyncWaitHandle 以外,System.Threading.Tasks.Task 方法將不再於處置物件之後擲回 System.ObjectDisposedException 例外狀況。這項變更支援使用快取的工作。Except for IAsyncResult.AsyncWaitHandle, System.Threading.Tasks.Task methods no longer throw an System.ObjectDisposedException exception after the object is disposed.This change supports the use of cached tasks. 例如,方法可能傳回快取的工作來表示已完成的作業,而不配置新的工作。For example, a method can return a cached task to represent an already completed operation instead of allocating a new task. 舊版的 .NET Framework 並未提供這項功能,因為工作的任何消費者都可能會處置它,使它變得無法使用。This was impossible in previous .NET Framework versions, because any consumer of the task could dispose of it, which rendered it unusable.

建議Suggestion

請注意,Task 方法可能不會再於處置物件之後擲回 System.ObjectDisposedExceptionBe aware that Task methods may no longer throw System.ObjectDisposedException in cases when the object is disposed. 如果應用程式根據此例外狀況得知某個工作已處置,則應該將它更新,以使用 Status 明確檢查工作的狀態。If an app was depending on this exception to know that a task was disposed, it should be updated to explicitly check the task's status using Status.

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

受影響的 APIAffected APIs

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

System.URI 逸出現在支援 RFC 3986System.Uri escaping now supports RFC 3986

詳細資料Details

URI 逸出在 .NET Framework 4.5 中已變更,可支援 RFC 3986URI escaping has changed in .NET Framework 4.5 to support RFC 3986. 特定變更包括:Specific changes include:

建議Suggestion

  • 請更新應用程式,以便在逸出序列無效時,不依賴 擲回例外狀況。Update applications to not rely on to throw in the case of an invalid escape sequence. 現在必須直接偵測這類序列。Such sequences must be detected directly now.
  • 同樣地,逸出和未逸出 URI 以及資料字串可能會因 .NET Framework 4.0 和 .NET Framework 4.5 而有所不同,因此不應該在不同的 .NET 版本之間直接進行比較。Similarly, expect that Escaped and Unescaped URI and Data strings may vary from .NET Framework 4.0 and .NET Framework 4.5 and should not be compared across .NET versions directly. 相反地,應該將這些字串剖析和正規化為單一 .NET 版本,再進行任何比較。Instead, they should be parsed and normalized in a single .NET version before any comparisons are made.
名稱Name Value
範圍Scope MinorMinor
版本Version 4.54.5
類型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.

資料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

Sql_variant 資料使用的是 sql_variant 定序,而不是資料庫定序Sql_variant data uses sql_variant collation rather than database collation

詳細資料Details

sql_variant 資料使用的是 sql_variant 定序,而不是資料庫定序。sql_variant data uses sql_variant collation rather than database collation.

建議Suggestion

這項變更可以解決資料庫定序與 sql_variant 定序不同時,可能發生的資料毀損。This change addresses possible data corruption if the database collation differs from the sql_variant collation. 依賴損毀資料的應用程式可能會失敗。Applications that rely on the corrupted data may experience failure.

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

受影響的 APIAffected APIs

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

SqlBulkCopy 針對字串使用目的地資料行編碼方式SqlBulkCopy uses destination column encoding for strings

詳細資料Details

將資料插入資料行時,System.Data.SqlClient.SqlBulkCopy 會使用目的地資料行的編碼方式,而不是 VARCHARCHAR 類型的預設編碼方式。When inserting data into a column, System.Data.SqlClient.SqlBulkCopy uses the encoding of the destination column rather than the default encoding for VARCHAR and CHAR types. 這項變更可排除當目的地資料行未使用預設編碼方式時,使用預設編碼方式可能造成的資料損毀。This change eliminates the possibility of data corruption caused by using the default encoding when the destination column does not use the default encoding. 在某些鮮少發生的情況下,如果變更編碼方式後產生的資料太大而不適用於目的地資料行,現有的應用程式可能會擲回 SqlException 例外狀況。In rare cases, an existing application may throw a SqlException exception if the change in encoding produces data that is too big to fit into the destination column.

建議Suggestion

由於編碼方式的差異,預期 System.Data.SqlClient.SqlBulkCopy 不會再損毀資料。Expect that System.Data.SqlClient.SqlBulkCopy will no longer corrupt data due to encoding differences. 如果所複製的字串接近目的地資料行的大小限制,可能必須預先編碼資料 (要複製以確認資料可納入目的地資料行) 或攔截 System.Data.SqlClient.SqlExceptionIf strings near the destination column's size limit are being copied, it may be necessary to either pre-encode data (to be copied to check that the data will fit in the destination column) or catch System.Data.SqlClient.SqlExceptions.

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

受影響的 APIAffected APIs

SqlConnection 無法再使用 VIA 配接器連線至 SQL Server 1997 或資料庫SqlConnection can no longer connect to SQL Server 1997 or databases using the VIA adapter

詳細資料Details

不再支援透過 ) 通訊協定使用虛擬介面配接器 ( SQL Server 資料庫的連接。Connections to SQL Server databases using the Virtual Interface Adapter (VIA) protocol are no longer supported. 用來連線至 SQL Server 資料庫的通訊協定會顯示在接字串中。The protocol used to connect to a SQL Server database is visible in the connection string. VIA 連線將包含 via:<伺服器名稱>。A VIA connection will contain via:<servername>. 如果此應用程式透過通訊協定(而非 VIA (tcp:或 np) :)連接到 SQL,則不會發生任何重大變更。If this app is connecting to SQL via a protocol other than VIA (tcp: or np: for example), then no breaking change will be encountered. 此外,不再支援 SQL Server 7 (1997) 的連接。Also, connections to SQL Server 7 (1997) are no longer supported.

建議Suggestion

VIA 通訊協定已淘汰,因此應該使用替代的通訊協定來連線至 SQL 資料庫。The VIA protocol is deprecated, so an alternative protocol should be used to connect to SQL databases. 最常用的通訊協定是 TCP/IP。The most common protocol used is TCP/IP. 如需透過 TCP/IP 進行連線的詳細資訊,請參閱啟用資料庫執行個體的 TCP/IP 通訊協定For more information about connecting through TCP/IP, see Enable the TCP/IP protocol for a database instance. 如果只能從內部網路中存取資料庫,若網路太慢,則共用管道通訊協定可以提供更好的效能。If the database is only accessed from within an intranet, the shared pipes protocol may provide better performance if the network is slow.

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

資料定義語言 (DDL) API 的行為變更Change in behavior in Data Definition Language (DDL) APIs

詳細資料Details

指定 AttachDBFilename 時,DDL API 的行為已變更如下:The behavior of DDL APIs when AttachDBFilename is specified has changed as follows:

  • 連接字串不需要指定 Initial Catalog 值。Connection strings need not specify an Initial Catalog value. 以往 AttachDBFilename 和 Initial Catalog 都是必要項。Previously, both AttachDBFilename and Initial Catalog were required.
  • 如果同時指定 AttachDBFilename 和 Initial Catalog,且指定的 MDF 檔案存在,則 DatabaseExists 方法會傳回 trueIf both AttachDBFilename and Initial Catalog are specified and the given MDF file exists, the DatabaseExists method returns true. 以往它會傳回 falsePreviously, it returned false.
  • 如果同時指定 AttachDBFilename 和 Initial Catalog,且指定的 MDF 檔案存在,則呼叫 DeleteDatabase 方法會刪除檔案。If both AttachDBFilename and Initial Catalog are specified and the given MDF file exists, calling the DeleteDatabase method deletes the files.
  • 如果在連接字串指定 AttachDBFilename,而其中 MDF 不存在且初始目錄也不存在時呼叫 DeleteDatabase,則方法會擲回 InvalidOperationException 例外狀況。If DeleteDatabase is called when the connection string specifies an AttachDBFilename value with an MDF that doesn't exist and an Initial Catalog that doesn't exist, the method throws an InvalidOperationException exception. 以往它會擲回 SqlException 例外狀況。Previously, it threw a SqlException exception.

建議Suggestion

這些變更可讓您更容易建置使用 DDL 應用程式開發介面的工具和應用程式。These changes make it easier to build tools and applications that use the DDL APIs. 在下列情節中,這些變更可能會影響應用程式相容性:These changes can affect application compatibility in the following scenarios:

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

受影響的 APIAffected APIs

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

ObjectContext.CreateDatabase 和 DbProviderServices.CreateDatabase 方法處理例外狀況的方式不同Different exception handling for ObjectContext.CreateDatabase and DbProviderServices.CreateDatabase methods

詳細資料Details

從 .NET Framework 4.5 開始,如果資料庫建立失敗,CreateDatabase 方法會嘗試卸除空白資料庫。Beginning in .NET Framework 4.5, if database creation fails, CreateDatabase methods will attempt to drop the empty database. 如果該作業成功,則會傳播原始 System.Data.SqlClient.SqlException (而不是在 .NET Framework 4.0 中一律擲回的 System.InvalidOperationException)If that operation succeeds, the original System.Data.SqlClient.SqlException will be propagated (instead of the System.InvalidOperationException that was always thrown in .NET Framework 4.0)

建議Suggestion

如果在執行 CreateDatabase()CreateDatabase(DbConnection, Nullable<Int32>, StoreItemCollection) 時攔截 System.InvalidOperationException,現在也應該要攔截 SQLException。When catching an System.InvalidOperationException while executing CreateDatabase() or CreateDatabase(DbConnection, Nullable<Int32>, StoreItemCollection), SQLExceptions should now also be caught.

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

受影響的 APIAffected APIs

針對具有特定字元的 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.

EntityFramework 6.0 在從 Visual Studio 啟動的應用程式中的載入速度很慢EntityFramework 6.0 loads very slowly in apps launched from Visual Studio

詳細資料Details

從 Visual Studio 2013 啟動使用 EntityFramework 6.0 的應用程式可能會很慢。Launching an app from Visual Studio 2013 that uses EntityFramework 6.0 can be very slow.

建議Suggestion

此問題在 EntityFramework 6.0.2 中已修正。This issue is fixed in EntityFramework 6.0.2. 更新 EntityFramework 可避免發生效能問題。Update EntityFramework to avoid the performance issue.

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

受影響的 APIAffected APIs

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

ObjectContext.CreateDatabase 方法所建立的記錄檔名稱已變更為符合 SQL Server 規格Log file name created by the ObjectContext.CreateDatabase method has changed to match SQL Server specifications

詳細資料Details

無論是直接呼叫 System.Data.Objects.ObjectContext.CreateDatabase() 方法,或在連接字串中使用 Code First 搭配 SqlClient 提供者和 AttachDBFilename 值進行呼叫,該方法都會建立名為 filename_log.ldf 的記錄檔,而不是 filename.ldf (其中 filename 是 AttachDBFilename 值所指定的檔案名稱)。When the System.Data.Objects.ObjectContext.CreateDatabase() method is called either directly or by using Code First with the SqlClient provider and an AttachDBFilename value in the connection string, it creates a log file named filename_log.ldf instead of filename.ldf (where filename is the name of the file specified by the AttachDBFilename value). 這項變更可透過提供依據 SQL Server 規格命名的記錄檔改善偵錯功能。This change improves debugging by providing a log file named according to SQL Server specifications.

建議Suggestion

如果記錄檔名稱對應用程式很重要,則應更新應用程式以採用標準 _log.ldf 檔案名稱格式。If the log file name is important for an app, the app should be updated to expect the standard _log.ldf file name format.

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

受影響的 APIAffected APIs

ObjectContext.Translate 和 ObjectContext.ExecuteStoreQuery 現在支援列舉類型ObjectContext.Translate and ObjectContext.ExecuteStoreQuery now support enum type

詳細資料Details

在 .NET Framework 4.0 中,ObjectContext.TranslateObjectContext.ExecuteStoreQuery 方法的泛型參數 T 不可為列舉。In .NET Framework 4.0, the generic parameter T of ObjectContext.Translate and ObjectContext.ExecuteStoreQuery methods could not be an enum. 現在支援這種情況。That scenario is now supported.

建議Suggestion

如果在 .NET Framework 4.0 中對列舉類型呼叫 Translate 或 ExecuteStoreQuery,則會傳回 '0'。If Translate or ExecuteStoreQuery was called on an enum type in .NET Framework 4.0, '0' was returned. 如果這不是您要的行為,請以常數 0 (或相當於此值的列舉) 取代呼叫。If that behavior was desirable, the calls should be replaced with a constant 0 (or the enum equivalent of it).

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

受影響的 APIAffected APIs

|

選擇中斷以從不同的 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.

LINQLINQ

Enumerable.Empty<TResult> 一律會傳回快取的執行個體Enumerable.Empty<TResult> always returns cached instance

詳細資料Details

從 .NET Framework 4.5 開始,Empty<TResult>() 一律會傳回快取的內部執行個體 IEnumerable<T>。之前,Empty<TResult>() 會在呼叫 API 時快取空的 IEnumerable<T>,也就是說,在快速且同時呼叫 Empty<TResult>() 的某些情況下,可能會針對不同的 API 呼叫傳回不同的類型執行個體。Beginning in .NET Framework 4.5, Empty<TResult>() always returns a cached internal instance IEnumerable<T>.Previously, Empty<TResult>() would cache an empty IEnumerable<T> at the time the API was called, meaning that in some conditions in which Empty<TResult>() was called rapidly and concurrently, different instances of the type could be returned for different calls to the API.

建議Suggestion

由於舊版行為不具決定性,因此程式碼不太可能取決於此行為。Because the previous behavior was non-deterministic, code is unlikely to depend on it. 不過,在罕見的情況下,如果空的可列舉值經比較有時必須不相等,則應該建立明確的空陣列 (new T[0]),而不是使用 Empty<TResult>()However, in the unlikely case that empty enumerables are being compared and expected to sometimes be unequal, explicit empty arrays should be created (new T[0]) instead of using Empty<TResult>().

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

受影響的 APIAffected APIs

Managed Extensibility Framework (MEF)Managed Extensibility Framework (MEF)

MEF 目錄會實作 IEnumerable,因此不能再用來建立序列化程式MEF catalogs implement IEnumerable and therefore can no longer be used to create a serializer

詳細資料Details

從 .NET Framework 4.5 開始,MEF 目錄會實作 IEnumerable,因此不能再用來建立序列化程式 (System.Xml.Serialization.XmlSerializer 物件)。Starting with the .NET Framework 4.5, MEF catalogs implement IEnumerable and therefore can no longer be used to create a serializer (System.Xml.Serialization.XmlSerializer object). 嘗試序列化 MEF 目錄會擲回例外狀況。Trying to serialize a MEF catalog throws an exception.

建議Suggestion

無法再使用 MEF 建立序列化程式Can no longer use MEF to create a serializer

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

受影響的 APIAffected APIs

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

網路Networking

將在 .NET Framework 4.5 下序列化的 MailMessage 物件還原序列化可能會失敗Deserialization of MailMessage objects serialized under the .NET Framework 4.5 may fail

詳細資料Details

從 .NET Framework 4.5 開始,MailMessage 物件可以包含非 ASCII 字元。Starting with the .NET Framework 4.5, MailMessage objects can include non-ASCII characters. 在 .NET Framework 4 中,僅支援 ASCII 字元。In the .NET Framework 4, only ASCII characters are supported. 包含非 ASCII 字元且在 .NET Framework 4.5 或更新版本下序列化的 MailMessage 物件,無法在 .NET Framework 4 下還原序列化。MailMessage objects that contain non-ASCII characters and that are serialized under the .NET Framework 4.5 or later cannot be deserialized under the .NET Framework 4.

建議Suggestion

請確定您的程式碼在將 MailMessage 物件還原序列化時,會提供例外狀況處理。Ensure that your code provides exception handling when deserializing a MailMessage object.

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

受影響的 APIAffected APIs

Windows 8 上無法使用 System.Net.PeerToPeer.CollaborationSystem.Net.PeerToPeer.Collaboration unavailable on Windows 8

詳細資料Details

在 Windows 8 (含) 以上版本上無法使用 System.Net.PeerToPeer.Collaboration 命名空間。The System.Net.PeerToPeer.Collaboration namespace is unavailable on Windows 8 or above.

建議Suggestion

您必須更新支援 Windows 8 (含) 以上版本的應用程式,使其不相依於此命名空間或其成員。Apps that support Windows 8 or above must be updated to not depend on this namespace or its members.

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

受影響的 APIAffected APIs

列印Printing

寫入 PrintSystemJobInfo.JobStream 的資料必須是 XPS 格式Data written to PrintSystemJobInfo.JobStream must be in XPS format

詳細資料Details

JobStream 屬性會公開列印工作的資料流。The JobStream property exposes the stream of a print job. 使用者可藉由寫入此資料流,將原始資料傳送至基礎作業系統列印元件。從 Windows 8 和更新版本的 Windows 作業系統上的 .NET Framework 4.5 開始,寫入此資料流的資料必須是作為套件資料流的 XPS 格式。The user can send raw data to the underlying operating system printing components by writing to this stream.Starting with the .NET Framework 4.5 on Windows 8 and later versions of the Windows operating system, data written to this stream must be in XPS format as a package stream.

建議Suggestion

若要輸出列印的內容,您可以執行下列任何一項操作:To output print content, you can do either of the following:

  • 使用 XpsDocumentWriter 類別來輸出列印的內容。Use the XpsDocumentWriter class to output print content. 這是建議的替代方案。This is the recommended alternative.
  • 請確定傳送至 JobStream 屬性所傳回之資料流的資料是作為套件資料流的 XPS 格式。Ensure that the data sent to the stream returned by the JobStream property is in XPS format as a package stream.

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

受影響的 APIAffected APIs

序列化Serialization

BinaryFormatter 可能無法從 LoadFrom 內容尋找類型BinaryFormatter can fail to find type from LoadFrom context

詳細資料Details

從 .NET Framework 4.5 開始,使用 System.Runtime.Serialization.Formatters.Binary.BinaryFormatter 將已在 LoadFrom 內容中載入的類型還原序列化時,System.Xml.Serialization.XmlSerializer 變更可能會造成還原序列化的差異。As of .NET Framework 4.5, a number of System.Xml.Serialization.XmlSerializer changes may cause differences in deserialization when using System.Runtime.Serialization.Formatters.Binary.BinaryFormatter to deserialize types that had been loaded in the LoadFrom context. 這些變更是由於新方法 System.Xml.Serialization.XmlSerializer 現在會載入類型,因此這會在 System.Runtime.Serialization.Formatters.Binary.BinaryFormatter 稍後嘗試為該類型還原序列化時,導致不同的行為。These changes are due to the new ways System.Xml.Serialization.XmlSerializer now loads a type which causes different behavior when a System.Runtime.Serialization.Formatters.Binary.BinaryFormatter attempts to deserialize to that type later on. 預設序列化繫結器不會自動搜尋 LoadFrom 內容,雖然在某些狀況下,其根據 XmlSerializer 舊有行為可正常運作。The default serialization binder does not automatically search the LoadFrom context, although it may have worked in some circumstances based on the old behavior of XmlSerializer. 由於這些變更之故,從在不同內容載入的組件中載入類型時,可能會擲回 System.IO.FileNotFoundExceptionDue to the changes, when a type is being loaded from an assembly loaded in a different context, a System.IO.FileNotFoundException may be thrown.

建議Suggestion

如果看到這個例外狀況,System.Runtime.Serialization.Formatters.Binary.BinaryFormatterBinder 屬性可以設定為自訂繫結器,用來尋找正確的類型。If this exception is seen, the Binder property of the System.Runtime.Serialization.Formatters.Binary.BinaryFormatter can be set to a custom binder that will find the correct type.

var formatter = new BinaryFormatter { Binder = new TypeFinderBinder() }
然後,自訂繫結器:And then the custom binder:
public class TypeFinderBinder : SerializationBinder
{
private static readonly string s_assemblyName = Assembly.GetExecutingAssembly().FullName;

public override Type BindToType(string assemblyName, string typeName)
{
return Type.GetType(String.Format(CultureInfo.InvariantCulture, "{0}, {1}", typeName, s_assemblyName));
}
}

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

SoapFormatter 無法將 Hashtable 和類似的已排序集合物件還原序列化SoapFormatter cannot deserialize Hashtable and similar ordered collection objects

詳細資料Details

System.Runtime.Serialization.Formatters.Soap.SoapFormatter 不保證以某個 .NET Framework 版本序列化的物件,可成功以另一個版本還原序列化。The System.Runtime.Serialization.Formatters.Soap.SoapFormatter does not guarantee that objects serialized under one .NET Framework version will successfully deserialize under a different version. 具體來說,某些已排序的集合 (例如 System.Collections.Hashtable) 在 4.0 和 4.5 之間新增成員;如果這些類型的物件以 .NET Framework 4.5 序列化,就無法以 .NET Framework 4.0 還原序列化。Specifically, some ordered collections (like System.Collections.Hashtable) added members between 4.0 and 4.5 such that objects of these types cannot deserialize with .NET Framework 4.0 if they were serialized with .NET Framework 4.5. 請注意,如果序列化資料以相同的 .NET Framework 版本序列化和還原序列化,就不會發生任何問題。Note that if the serialized data is both serialized and deserialized with the same .NET Framework version, no issue will occur.

建議Suggestion

System.Runtime.Serialization.Formatters.Soap.SoapFormatter 應該取代為 System.Runtime.Serialization.Formatters.Binary.BinaryFormatter 序列化或 System.Runtime.Serialization.NetDataContractSerializer 應該彈性處理 .NET Framework 變更。System.Runtime.Serialization.Formatters.Soap.SoapFormatter serialization should be replaced with System.Runtime.Serialization.Formatters.Binary.BinaryFormatter serialization or System.Runtime.Serialization.NetDataContractSerializer to be resilient to .NET Framework changes.

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

受影響的 APIAffected APIs

在序列化以無法存取的成員隱藏可存取成員的類型時,XmlSerializer 會失敗XmlSerializer fails while serializing a type that hides an accessible member with an inaccessible one

詳細資料Details

序列化衍生的類型時,如果類型包含無法存取的欄位或屬性,而此欄位或屬性隱藏 (透過 'new' 關鍵字) 先前在基底類型上可存取 (例如,公用) 之相同名稱的欄位或屬性,System.Xml.Serialization.XmlSerializer 可能會失敗。When serializing a derived type, the System.Xml.Serialization.XmlSerializer can fail if the type contains an inaccessible field or property that hides (via the 'new' keyword) a field or property of the same name that was previously accessible (public, for example) on the base type.

建議Suggestion

請使隱藏成員可供 System.Xml.Serialization.XmlSerializer 存取 (例如,將其設為公開) 來解決這個問題。此外,下列組態設定會還原為 4.0 System.Xml.Serialization.XmlSerializer 行為,以修正此問題:This problem can be solved by making the new, hiding member accessible to the System.Xml.Serialization.XmlSerializer (by marking it public, for example).Alternatively, the following config setting will revert to 4.0 System.Xml.Serialization.XmlSerializer behavior, which will fix the problem:

<system.xml.serialization>
<xmlSerializer useLegacySerializerGeneration="true" />
</system.xml.serialization>

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

受影響的 APIAffected APIs

Web 應用程式Web Applications

.NET Framework 1.1 和 2.0 的受控瀏覽器裝載控制項已封鎖Managed browser hosting controls from the .NET Framework 1.1 and 2.0 are blocked

詳細資料Details

Internet Explorer 中已封鎖裝載這些控制項。Hosting these controls is blocked in Internet Explorer.

建議Suggestion

Internet Explorer 將無法啟動使用 Managed 瀏覽器裝載控制項的應用程式。Internet Explorer will fail to launch an application that uses managed browser hosting controls. 可還原先前行為的方式包括:在 x86 系統和 x64 系統的 32 位元處理序上,將登錄子機碼 HKLM/SOFTWARE/MICROSOFT/.NETFramework 的 EnableIEHosting 值設為 1,在 x64 系統的 64 位元處理序上,將登錄子機碼 HKLM/SOFTWARE/Wow6432Node/Microsoft/.NETFrameworkEnableIEHosting 值設為 1The previous behavior can be restored by setting the EnableIEHosting value of the registry subkey HKLM/SOFTWARE/MICROSOFT/.NETFramework to 1 for x86 systems and for 32-bit processes on x64 systems, and by setting the EnableIEHosting value of the registry subkey HKLM/SOFTWARE/Wow6432Node/Microsoft/.NETFramework to 1 for 64-bit processes on x64 systems.

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

受影響的 APIAffected APIs

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

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

maxRequestLength 或 maxReceivedMessageSize 的錯誤碼不同Error codes for maxRequestLength or maxReceivedMessageSize are different

詳細資料Details

Internet Information Services (IIS) 或 ASP.NET 程式開發伺服器裝載的 WCF Web 服務中,超過 maxRequestLength (在 ASP.NET 中) 或 maxReceivedMessageSize (在 WCF 中) 的訊息具有不同的錯誤碼。HTTP 狀態碼已從 400 (錯誤的要求) 變更為 413 (要求的實體太大),而且超過 maxRequestLength 或 maxReceivedMessageSize 設定的訊息會擲回 System.ServiceModel.ProtocolException 例外狀況。Messages in WCF web services hosted in Internet Information Services (IIS) or ASP.NET Development Server that exceed maxRequestLength (in ASP.NET) or maxReceivedMessageSize (in WCF) have different error codeThe HTTP status code has changed from 400 (Bad Request) to 413 (Request Entity Too Large), and messages that exceed either the maxRequestLength or the maxReceivedMessageSize setting throw a System.ServiceModel.ProtocolException exception. 傳輸模式為 Streamed 的案例也包括在內。This includes cases in which the transfer mode is Streamed.

建議Suggestion

這項變更有助於在訊息長度超過 ASP.NET 或 WCF 所允許之限制的情況下進行偵錯。您必須修改任何依據 HTTP 400 狀態碼執行處理的程式碼。This change facilitates debugging in cases where the message length exceeds the limits allowed by ASP.NET or WCF.You must modify any code that performs processing based on an HTTP 400 status code.

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

受影響的 APIAffected APIs

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

現在會遵守 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.

System.ServiceModel.Web.WebServiceHost 物件不會再新增預設端點System.ServiceModel.Web.WebServiceHost object no longer adds a default endpoint

詳細資料Details

如果應用程式程式碼加入明確的端點,WebServiceHost 物件將不再加入預設端點。The WebServiceHost object no longer adds a default endpoint if an explicit endpoint has been added by application code.

建議Suggestion

如果使用者希望能夠連線到預設端點,而且 System.ServiceModel.Web.WebServiceHost 已新增其他明確的端點,也應該明確新增預設端點 (使用 System.ServiceModel.ServiceHostBase.AddDefaultEndpoints())。If users will expect to be able to connect to a default endpoint and other explicit endpoints have been added to the System.ServiceModel.Web.WebServiceHost, default endpoints should also be added explicitly (using System.ServiceModel.ServiceHostBase.AddDefaultEndpoints()).

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

受影響的 APIAffected APIs

OData URL 中的 Replace 方法預設為停用The Replace method in OData URLs is disabled by default

詳細資料Details

從 .NET Framework 4.5 開始,OData URL 中的 Replace 方法預設為停用。Beginning in the .NET Framework 4.5, the Replace method in OData URLs is disabled by default. 當 OData Replace 停用 (現在為預設) 時,任何包含取代功能的使用者要求 (不常見) 將會失敗。When OData Replace is disabled (now by default), any user requests including replace functions (which are uncommon) will fail.

建議Suggestion

如果需要 Replace 方法 (不常見),可以透過組態設定 (System.Data.Services.Configuration.DataServicesFeaturesSection.ReplaceFunction) 將它重新啟用。If the replace method is required (which is uncommon), it can be re-enabled through a config settings (System.Data.Services.Configuration.DataServicesFeaturesSection.ReplaceFunction). 不過,已啟用的 Replace 方法可能會有資訊安全漏洞,因此只有在仔細檢閱之後才能使用。However, an enabled replace method can open security vulnerabilities and should only be used after careful review.

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

受影響的 APIAffected APIs

Windows FormsWindows Forms

如果其處理常式顯示 Windows Forms 訊息方塊,則會重複呼叫 PreviewLostKeyboardFocusPreviewLostKeyboardFocus is called repeatedly if its handler shows a Windows Forms message box

詳細資料Details

從 .NET Framework 4.5 開始,從 PreviewLostKeyboardFocus 處理常式呼叫 MessageBox.Show 會使處理常式在關閉訊息方塊時重新引發,而可能產生無限的訊息方塊迴圈。Beginning in the .NET Framework 4.5, calling MessageBox.Show from a PreviewLostKeyboardFocus handler will cause the handler to re-fire when the message box is closed, potentially resulting in an infinite loop of message boxes.

建議Suggestion

此問題有兩個解決方法:There are two options to work around this issue:

  1. 藉由呼叫 MessageBox.Show (而不是 MessageBox.Show) 來避免此問題。It may be avoided by calling MessageBox.Show instead of MessageBox.Show.
  2. 藉由從 LostKeyboardFocus 事件處理常式 (相對於 System.Windows.UIElement.PreviewLostKeyboardFocus 事件處理常式) 顯示訊息方塊來避免此問題。It may be avoided by showing the message box from a LostKeyboardFocus event handler (as opposed to a System.Windows.UIElement.PreviewLostKeyboardFocus event handler).

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

受影響的 APIAffected APIs

WinForm 的 CheckForOverflowUnderflow 屬性對於 System.Drawing 現在是 trueWinForm's CheckForOverflowUnderflow property is now true for System.Drawing

詳細資料Details

System.Drawing.dll 組件的 CheckForOverflowUnderflow 屬性設定為 true。The CheckForOverflowUnderflow property for the System.Drawing.dll assembly is set to true.

建議Suggestion

以往發生溢位時,結果會以無訊息模式截斷。Previously when overflows occurred, the result would be silently truncated. 現在則會擲回 System.OverflowException 例外狀況。Now an System.OverflowException exception is thrown.

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

在已選取項目的 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

FlowDocument 可能會顯示額外的文字行FlowDocument may show an extra line of text

詳細資料Details

在某些情況下,相較於 FlowDocument 項目在 .NET Framework 4.0 上執行時的顯示方式,其在 .NET Framework 4.5 上執行時,會顯示額外的文字行。In some cases, a FlowDocument element will display an extra line of text when running on the .NET Framework 4.5 compared to how it displayed when run on the .NET Framework 4.0. 沒有任何已知的變更情況會導致文字顯示不良或無法辨識,但它可能會導致顯示之前已從 FlowDocument 檢視表中省略的文字。There are no known cases of the change causing any text to be displayed poorly or illegibly, but it could cause text to appear that previously was omitted from a FlowDocument's view.

建議Suggestion

在某些情況下,將顯示項目的 PageHeight 屬性減 1 可以還原先前顯示的行數。In some cases, decreasing the display element's PageHeight property by one can restore the previous number of displayed lines.

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

受影響的 APIAffected APIs

從 .NET Framework 4.5 開始,GlyphRun.ComputeInkBoundingBox() 和 FormattedText.Extent 會傳回不同的值GlyphRun.ComputeInkBoundingBox() and FormattedText.Extent return different values beginning in .NET Framework 4.5

詳細資料Details

在 .NET Framework 4.5 中,已改善 ComputeInkBoundingBox()Extent,以解決這些方塊在 .NET Framework 4.0 的某些情況下對包含的字符太小的問題。Improvements were made to ComputeInkBoundingBox() and Extent in the .NET Framework 4.5 to address issues where the boxes were too small for the contained glyphs in some cases in the .NET Framework 4.0. 因此,從 .NET Framework 4.5 開始,某些週框方塊會比較大,導致 UI 配置中有些微差異。As a result of this, some bounding boxes will be larger beginning in the .NET Framework 4.5, resulting in subtle differences in UI layout.

建議Suggestion

請注意,某些字符週框方塊大小已增加。Be aware that some glyph bounding box sizes have increased. 這些變更通常會改進呈現方式和叫用方塊測試,但如果想要舊版 (.NET 4.5 之前) 行為,則可以將下列項目新增至 app.config 檔案來加入此行為:These changes will usually improve presentation and hit box testing, but if the older (pre-.NET 4.5) behavior is desired, it can be opted into by adding the following entry to the app.config file:

<appsettings>
<add key="IncludeAllInkInBoundingBox" value="false">
</appsettings>

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

受影響的 APIAffected APIs

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

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

WPF PageRangeSelection 中的新列舉值New enum values in WPF's PageRangeSelection

詳細資料Details

兩個新成員 (System.Windows.Controls.PageRangeSelection.CurrentPageSystem.Windows.Controls.PageRangeSelection.SelectedPages) 已新增至 System.Windows.Controls.PageRangeSelection 列舉。Two new members (System.Windows.Controls.PageRangeSelection.CurrentPage and System.Windows.Controls.PageRangeSelection.SelectedPages) have been added to the System.Windows.Controls.PageRangeSelection enum.

建議Suggestion

在大多數情況下,這些變更不會影響使用者程式碼。In most cases, these changes won't impact user code. 不過,您應該修改與 System.Windows.Controls.PageRangeSelection 型別的 GetNames(Type)GetValues(Type) 呼叫中現有的特定項目數目相依的程式碼。Code that depends on a particular number of elements existing in GetNames(Type) or GetValues(Type) calls on the System.Windows.Controls.PageRangeSelection type should be modified, though.

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

受影響的 APIAffected APIs

如果其處理常式顯示 Windows Forms 訊息方塊,則會重複呼叫 PreviewLostKeyboardFocusPreviewLostKeyboardFocus is called repeatedly if its handler shows a Windows Forms message box

詳細資料Details

從 .NET Framework 4.5 開始,從 PreviewLostKeyboardFocus 處理常式呼叫 MessageBox.Show 會使處理常式在關閉訊息方塊時重新引發,而可能產生無限的訊息方塊迴圈。Beginning in the .NET Framework 4.5, calling MessageBox.Show from a PreviewLostKeyboardFocus handler will cause the handler to re-fire when the message box is closed, potentially resulting in an infinite loop of message boxes.

建議Suggestion

此問題有兩個解決方法:There are two options to work around this issue:

  1. 藉由呼叫 MessageBox.Show (而不是 MessageBox.Show) 來避免此問題。It may be avoided by calling MessageBox.Show instead of MessageBox.Show.
  2. 藉由從 LostKeyboardFocus 事件處理常式 (相對於 System.Windows.UIElement.PreviewLostKeyboardFocus 事件處理常式) 顯示訊息方塊來避免此問題。It may be avoided by showing the message box from a LostKeyboardFocus event handler (as opposed to a System.Windows.UIElement.PreviewLostKeyboardFocus event handler).

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

受影響的 APIAffected APIs

以滑鼠右鍵按一下 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

UIA 現在看得到 WPF DataTemplate 項目WPF DataTemplate elements are now visible to UIA

詳細資料Details

之前,UI 自動化看不到 System.Windows.DataTemplate 項目。Previously, System.Windows.DataTemplate elements were invisible to UI Automation. 從 4.5 開始,使用者介面自動化將會偵測這些項目。Beginning in 4.5, UI Automation will detect these elements. 這在許多情況下很有用,但可能會中斷相依於不含 System.Windows.DataTemplate 項目之 UIA 樹狀目錄的測試。This is useful in many cases, but can break tests that depend on UIA trees not containing System.Windows.DataTemplate elements.

建議Suggestion

您可能需要更新此應用程式的 UI 自動化測試,UIA 樹狀目錄現在才能包含先前不可見的 System.Windows.DataTemplate 項目。UI Automation tests for this app may need updated to account for the UIA tree now including previously invisible System.Windows.DataTemplate elements. 例如,預期某些項目彼此相鄰的測試,現在可能需要預期這些項目之間會出現先前不可見的 UIA 項目。For example, tests that expect some elements to be next to each other may now need to expect previously invisible UIA elements in between. 或者,依賴幾個 UIA 項目或其索引的測試,可能需要以新值更新。Or tests that rely on certain counts or indexes for UIA elements may need updated with new values.

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

受影響的 APIAffected APIs

WPF DispatcherSynchronizationContext.CreateCopy 現在會傳回新的複本,而不是目前的執行個體WPF DispatcherSynchronizationContext.CreateCopy now returns a new copy instead of the current instance

詳細資料Details

在 .NET Framework 4 中,CreateCopy() 會傳回目前執行個體的參考,主要是當作效能最佳化。In the .NET Framework 4, CreateCopy() returned a reference to the current instance, primarily as a performance optimization. 在 .NET Framework 4.5 中,則會傳回新的執行個體,這是第一次能夠認定同等參考,表示執行中執行緒是在正確的同步處理內容中。In the .NET Framework 4.5, it returns a new instance which makes it possible for the first time to conclude that equal references indicate the executing thread is in the correct synchronization context. 程式碼不太可能檢查這些參考的識別是否會受到影響,但由於這項變更,您應該在移轉至 .NET Framework 4.5 或更新版本的過程中,測試呼叫 CreateCopy() 的程式碼。It is unlikely that code that checks the identity of these references will be affected, but because of the change, code that calls CreateCopy() should be tested as part of migration to the .NET Framework 4.5 or newer.

建議Suggestion

請注意,CreateCopy() 現在會傳回新的 System.Threading.SynchronizationContext 物件。Be aware that CreateCopy() will now return a new System.Threading.SynchronizationContext object. 之前,使用以此方式產生之對等參考的程式碼不會實際檢查它是否在適當的內容中,但針對 .NET Framework 4.5 或更新版本建置時則會進行檢查。Previously, code that used equivalence of references generated this way was not actually checking whether it was in the proper context, but does when built against .NET Framework 4.5 or later. 雖然不太可能會造成問題,但執行受影響的程式碼路徑應該足以判斷是否會造成任何問題。While unlikely to cause issues, exercising the affected code paths should be enough to determine if this poses any problem.

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

受影響的 APIAffected APIs

WPF 會繁衍可以凍結滑鼠的 wisptis.exe 處理序WPF spawns a wisptis.exe process which can freeze the mouse

詳細資料Details

在 4.5.2 中產生了一個問題,導致繁衍可凍結滑鼠輸入的 wisptis.exeAn issue was introduced in 4.5.2 that causes wisptis.exe to be spawned that can freeze mouse input.

建議Suggestion

解決此問題的修正程式可在 .NET Framework 4.5.2 的服務版本 (Hotfix 彙總套件 3026376) 中取得,或藉由升級至 .NET Framework 4.6 取得A fix for this issue is available in a servicing release of the .NET Framework 4.5.2 (hotfix rollup 3026376), or by upgrading to the .NET Framework 4.6

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

受影響的 APIAffected APIs

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

WPF TextBox 的預設復原限制為 100WPF TextBox defaults to undo limit of 100

詳細資料Details

在 .NET Framework 4.5 中,WPF TextBox 的預設復原限制為 100 (在 .NET Framework 4.0 中則沒有限制)In .NET Framework 4.5, the default undo limit for a WPF textbox is 100 (as opposed to being unlimited in .NET Framework 4.0)

建議Suggestion

如果 100 的復原限制太低,可以使用 UndoLimit 明確設定此限制If an undo limit of 100 is too low, the limit can be set explicitly with UndoLimit

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

受影響的 APIAffected APIs

WPF TextBox 選取文字在文字方塊非作用中時,會以不同的色彩來顯示WPF TextBox selected text appears a different color when the text box is inactive

詳細資料Details

在 .NET Framework 4.5 中,當 WPF 文字方塊控制項非作用中時 (沒有焦點),方塊內的選取文字會以不同於控制項作用中的色彩來顯示。In .NET Framework 4.5, when a WPF text box control is inactive (it doesn't have focus), the selected text inside the box will appear a different color than when the control is active.

建議Suggestion

AreInactiveSelectionHighlightBrushKeysSupported 屬性設為 false 可以還原舊有 (.NET Framework 4.0) 行為。The previous (.NET Framework 4.0) behavior may be restored by setting the AreInactiveSelectionHighlightBrushKeysSupported property to false.

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

受影響的 APIAffected APIs

WPF TreeViewItem 必須在 TreeView 內使用WPF TreeViewItem must be used within a TreeView

詳細資料Details

4.5 中引進一項變更,限制在 System.Windows.Controls.TreeView 外使用 System.Windows.Controls.TreeViewItem 項目。A change was introduced in 4.5 that restricts usage of System.Windows.Controls.TreeViewItem elements outside of a System.Windows.Controls.TreeView. 在下列狀況下可能會發生這種情形:This manifests under the following conditions:

換句話說,在 System.Windows.Controls.TreeView 外使用 System.Windows.Controls.TreeViewItem,然後使用者點選 System.Windows.Controls.TreeViewItem 的子系將其帶入檢視時,就會看到此問題。In other words, this is seen when a System.Windows.Controls.TreeViewItem is used outside of a System.Windows.Controls.TreeView, and the user clicks on a descendant of the System.Windows.Controls.TreeViewItem to bring it into view. 如果 System.Windows.Controls.TreeViewItem 沒有可設定焦點的子系,則絕不會看到此問題。If the System.Windows.Controls.TreeViewItem has no focusable descendants, you'll never see this issue. 例如,當 System.Windows.Controls.TreeViewItem 是 DataTemplate 的根項目時,就會遇到此問題。An example of a situation where this is hit is when a System.Windows.Controls.TreeViewItem is the root of a DataTemplate. 遇到此問題時,WPF 架構內會出現 InvalidCastException。When this issue is hit, there is an InvalidCastException that occurs within the WPF framework.

建議Suggestion

未來將針對此問題提供 Hotfix。A hotfix will be made available for this.

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

受影響的 APIAffected APIs

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

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

System.Activities 現在是 APTCASystem.Activities is now APTCA

詳細資料Details

組件會以 System.Security.AllowPartiallyTrustedCallersAttribute 屬性標記。The assembly is marked with the System.Security.AllowPartiallyTrustedCallersAttribute attribute.

建議Suggestion

衍生類別無法以 System.Security.SecurityCriticalAttribute 標記。Derived classes cannot be marked with the System.Security.SecurityCriticalAttribute. 以往衍生類型必須以 System.Security.SecurityCriticalAttribute 標記。Previously, derived types had to be marked with the System.Security.SecurityCriticalAttribute. 不過,這項變更應該不會產生實際影響。However, this change should have no real impact.

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

受影響的 APIAffected APIs

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

WF 現在會以不同的方式來序列化 Expressions.Literal<T> DateTimes (中斷自訂 XAML 剖析器)WF serializes Expressions.Literal<T> DateTimes differently now (breaks custom XAML parsers)

詳細資料Details

相關聯的 ValueSerializer 物件會將 Second 和 System.DateTime.Millisecond 元件為非零且 (針對 System.DateTime 值) Kind 屬性不是 Unspecified 的 System.DateTimeSystem.DateTimeOffset 物件轉換為屬性項目語法,而非字串。The associated ValueSerializer object will convert a System.DateTime or System.DateTimeOffset object whose Second and System.DateTime.Millisecond components are non-zero and (for a System.DateTime value) whose Kind property is not Unspecified to property element syntax instead of a string. 這項變更會允許往返 System.DateTimeSystem.DateTimeOffset 值。This change allows System.DateTime and System.DateTimeOffset values to be round-tripped. 假設輸入 XAML 是使用屬性語法的自訂 XAML 剖析器將無法正常運作。Custom XAML parsers that assume that input XAML is in the attribute syntax will not function correctly.

建議Suggestion

這項變更會允許往返 System.DateTimeSystem.DateTimeOffset 值。This change allows System.DateTime and System.DateTimeOffset values to be round-tripped. 假設輸入 XAML 是使用屬性語法的自訂 XAML 剖析器將無法正常運作。Custom XAML parsers that assume that input XAML is in the attribute syntax will not function correctly.

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

受影響的 APIAffected APIs

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

XML、XSLTXML, XSLT

XmlSchemaException 現在會正確設定行位置XmlSchemaException now sets line positions properly

詳細資料Details

如果將 SetLineInfo 值傳遞至 Load 方法且發生驗證錯誤,則 LineNumberLinePosition 屬性現在會包含行資訊。If the SetLineInfo value is passed to the Load method and a validation error occurs, the LineNumber and LinePosition properties now contain line information.

建議Suggestion

您應該更新假設不會設定 LineNumberLinePosition 的例外狀況處理程式碼,因為當使用 SetLineInfo 載入 XML 時,現在會正確設定這些屬性。Exception-handling code that assumes LineNumber and LinePosition will not be set should be updated since these properties will now be set properly when SetLineInfo is used while loading XML.

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

受影響的 APIAffected APIs

XmlTextReader DTD 實體展開限制為 10,000,000 個字元XmlTextReader DTD entity expansion is limited to 10,000,000 characters

詳細資料Details

DTD 實體展開現在限制為 10,000,000 個字元。DTD entity expansion is now limited to 10,000,000 characters. 載入無 DTD 實體展開或 DTD 實體展開受限的 XML 檔案並不會受到影響。Loading XML files without DTD entity expansion or with limited DTD entity expansion is unaffected. 若檔案具有展開至超過 10,000,000 個字元的 DTD 實體,則會載入失敗,而且現在會擲回例外狀況。Files with DTD entities that expand to more than 10,000,000 characters fail to load, and now throw an exception.

建議Suggestion

如果 DTD 實體展開的限制太低,可以使用 MaxCharactersFromEntities 屬性覆寫值 10,000,000。If the limit of DTD entity expansion is too low 10,000,000, the value can be overridden with the MaxCharactersFromEntities property. 具有適當 System.Xml.XmlReaderSettings.MaxCharactersFromEntities 值的 System.Xml.XmlReaderSettings 可以傳遞至採用 System.Xml.XmlReaderSettings (即 Create(String, XmlReaderSettings)) 的 XmlReader.CreateAn System.Xml.XmlReaderSettings with the proper System.Xml.XmlReaderSettings.MaxCharactersFromEntities value can be passed to XmlReader.Create that takes System.Xml.XmlReaderSettings (ie. Create(String, XmlReaderSettings))

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

受影響的 APIAffected APIs

XSLT 往後相容性現在可運作XSLT forward compat now works

詳細資料Details

在 .NET Framework 4 中,XSLT 1.0 往後相容性有下列問題:In the .NET Framework 4, XSLT 1.0 forward compatibility had the following issues:

  • 如果樣式表的版本設為 2.0,而且剖析器遇到無法辨識的 XSLT 1.0 結構,則載入樣式表會失敗。Loading a style sheet failed if its version was set to 2.0 and the parser encountered an unrecognized XSLT 1.0 construct.
  • 如果樣式表版本設為 1.1, xsl:sort 結構就無法排序資料。The xsl:sort construct failed to sort data if the style sheet version was set to 1.1.
在 .NET Framework 4.5 中,這些問題已獲得修正,而且 XSLT 1.0 往後相容性模式可正常運作。In the .NET Framework 4.5, these issues have been fixed, and XSLT 1.0 forward compatibility mode works properly.

建議Suggestion

大部分的應用程式應該不會受到影響,不過在某些情況下,資料的排序方式將不同於 xsl:sort 現在遵守的方式。Most apps should be unaffected, however data will be sorted differently in some cases now that xsl:sort is respected. 如果在 1.1 樣式表中使用 xsl:sort,確認應用程式不會依據未排序的資料順序。If xsl:sort is used in 1.1 style sheets, confirm that apps were not depending on the unsorted order of data. 如果應用程式依賴 4.0 排序行為,請從樣式表中移除 xsl:sortIf apps rely on the 4.0 sorting behavior, remove xsl:sort from the style sheet.

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

受影響的 APIAffected APIs

XSLT 樣式表例外狀況訊息已變更XSLT style sheet exception message changed

詳細資料Details

在 .NET Framework 4.5 中,當 XSLT 檔太複雜時,錯誤訊息的文字是 " 樣式表單太複雜。 " 在先前的版本中,錯誤訊息是 " XSLT 編譯錯誤。 " 相依于錯誤訊息文字的應用程式程式碼將無法再運作。In the .NET Framework 4.5, the text of the error message when an XSLT file is too complex is "The style sheet is too complex." In previous versions, the error message was "XSLT compile error." Application code that depends on the text of the error message will no longer work. 不過,例外狀況類型會保持不變,因此這項變更應該不會產生實際影響。However, the exception types remain the same, so this change should have no real impact.

建議Suggestion

請將依據此錯誤狀況之例外狀況訊息的任何應用程式程式碼更新為預期會有新訊息,或是 (甚至更佳的做法) 將程式碼更新為只依據尚未變更的例外狀況類型 (System.Xml.Xsl.XsltException)。Update any app code depending on the exception message from this error condition to expect the new message, or (even better) update the code to depend only on the exception type (System.Xml.Xsl.XsltException), which has not changed.

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

受影響的 APIAffected APIs

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.