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

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

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

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

使用 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

如果索引類型可解決語意模糊,在索引子屬性上呼叫 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

含逾時引數之 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.

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

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.

波斯曆現在會使用回教陽曆演算法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

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

預設應用程式定義域的 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

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

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.

全球化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

JITJIT

傳遞和比較 UInt16 值時,產生不正確的程式碼Incorrect code generation when passing and comparing UInt16 values

詳細資料Details

由於 .NET Framework 4.7 中引入的變更,在某些情況下,JIT 編譯器在執行於 .NET Framework 4.7 上的應用程式中所產生的程式碼會錯誤地比較兩個 T:System.UInt16 值。Because of changes introduced in the .NET Framework 4.7, in some cases the code generated by the JIT compiler in applications running on the .NET Framework 4.7 incorrectly compares two T:System.UInt16 values. 如需詳細資訊,請參閱 GitHub.com 上的 Issue #11508: Silent bad codegen when passing and comparing ushort argss (問題 #11508:傳遞和比較 ushort 引數時無訊息的錯誤 codegen)。For more information, see Issue #11508: Silent bad codegen when passing and comparing ushort args on GitHub.com.

建議Suggestion

如果您在 .NET Framework 4.7 中比較 16 位元不帶正負號的值時遇到問題,請升級至 .NET Framework 4.7.1。If you encounter issues in the comparison of 16-bit unsigned values in the .NET Framework 4.7, upgrade to the .NET Framework 4.7.1.

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

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

將在 .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

安全性Security

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

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

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

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

安裝和部署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

.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.

從 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

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

使用 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 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)

變更 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

從自訂 INCC 集合中移除項目時,選取器發生損毀Crash in Selector when removing an item from a custom INCC collection

詳細資料Details

在下列狀況中可能發生 T:System.InvalidOperationExceptionAn T:System.InvalidOperationException can occur in the following scenario:

  • T:System.Windows.Controls.Primitives.Selector 的 ItemsSource 是具有 T:System.Collections.Specialized.INotifyCollectionChanged 自訂實作的集合。The ItemsSource for a T:System.Windows.Controls.Primitives.Selector is a collection with a custom implementation of T:System.Collections.Specialized.INotifyCollectionChanged.
  • 已從集合中移除選取的項目。The selected item is removed from the collection.
  • T:System.Collections.Specialized.NotifyCollectionChangedEventArgs 具有 P:System.Collections.Specialized.NotifyCollectionChangedEventArgs.OldStartingIndex = -1 (表示未知的位置)。The T:System.Collections.Specialized.NotifyCollectionChangedEventArgs has P:System.Collections.Specialized.NotifyCollectionChangedEventArgs.OldStartingIndex = -1 (indicating an unknown position).
例外狀況的呼叫堆疊開頭為:at System.Windows.Threading.Dispatcher.VerifyAccess() at System.Windows.DependencyObject.GetValue(DependencyProperty dp) at System.Windows.Controls.Primitives.Selector.GetIsSelected(DependencyObject element)。在 .NET Framework 4.5 中,如果應用程式有超過一個以上的發送器執行緒,可能會發生此例外狀況。The exception's callstack begins at System.Windows.Threading.Dispatcher.VerifyAccess() at System.Windows.DependencyObject.GetValue(DependencyProperty dp) at System.Windows.Controls.Primitives.Selector.GetIsSelected(DependencyObject element)This exception can occur in .NET Framework 4.5 if the application has more than one Dispatcher thread. 在 .NET Framework 4.7 中,具有單一發送器執行緒的應用程式也可能會發生此例外狀況。In .NET Framework 4.7 the exception can also occur in applications with a single Dispatcher thread. 此問題已在 .NET Framework 4.7.1 中修正。The issue is fixed in .NET Framework 4.7.1.

建議Suggestion

升級至 .NET Framework 4.7.1。Upgrade to .NET Framework 4.7.1.

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

受影響的 APIAffected APIs

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

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

水平捲動和虛擬化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

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

調整方格大小可能會當機Resizing a Grid can hang

詳細資料Details

在下列情況下,T:System.Windows.Controls.Grid 配置期間可能會發生無限迴圈:An infinite loop can occur during layout of a T:System.Windows.Controls.Grid under the following circumstances:

  • 資料列定義包含兩個數據 * 列,同時宣告 MinHeight 和 MaxHeight。Row definitions contain two *-rows, both declaring a MinHeight and a MaxHeight.
  • -資料列的內容 * 不會超過對應的 MaxHeightContent of the *-rows doesn't exceed the corresponding MaxHeight
  • 第一個 MinHeight (加上任何其他固定或自動的資料列) 超過方格的可用高度The Grid's available height is exceeded by the first MinHeight (plus any other fixed or Auto rows)
  • 應用程式將目標設為 .NET Framework 4.7,或藉由設定 Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=false 選擇新增 4.7 配置演算法The app targets .NET Framework 4.7, or opts in to the 4.7 allocation algorithm by setting Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=false
迴圈也會發生在兩個以上的資料列,或在類似的資料行案例中。The loop would also happen with more than two rows, or in the analogous case for columns. 此問題已在 .NET Framework 4.7.1 中修正。The issue is fixed in .NET Framework 4.7.1.

建議Suggestion

升級至 .NET Framework 4.7.1。Upgrade to .NET Framework 4.7.1. 或者,如果您不需要 4.7 配置演算法,可以使用下列組態設定:Alternatively, if you don't need the 4.7 allocation algorithm you can use the following configuration setting:

<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>

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

受影響的 APIAffected APIs

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

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 列印堆疊更新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 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.

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)

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.

在某些情況下,工作流程現在會擲回原始例外狀況,而不是 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.

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.