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

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

ADO.NETADO.NET

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

ASP.NETASP.NET

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

核心Core

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

詳細資料Details

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

建議Suggestion

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

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

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

受影響的 APIAffected APIs

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

資料Data

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

Entity FrameworkEntity Framework

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

詳細資料Details

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

建議Suggestion

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

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

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

受影響的 APIAffected APIs

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

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

詳細資料Details

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

建議Suggestion

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

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

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

受影響的 APIAffected APIs

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

序列化Serialization

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

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

現在會遵守 MinFreeMemoryPercentageToActiveServiceMinFreeMemoryPercentageToActiveService is now respected

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

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

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

XMLXML

XML 剖析變更XML parsing changes

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

詳細資料Details

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

注意

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

建議Suggestion

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

受影響的 APIAffected APIs

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