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

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

ASP.NETASP.NET

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

分析工具不會列舉 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.

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

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

現在,當 .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

嘗試建立 TCP/IP 連線至解析為 localhost 的 SQL Server 資料庫會失敗Attempting a TCP/IP connection to a SQL Server database that resolves to localhost fails

詳細資料Details

在 .NET Framework 4.6 和 4.6.1 中,嘗試建立 TCP/IP 連線至解析為 localhost 的 SQL Server 資料庫會失敗,錯誤為:「建立連線至 SQL Server 時,發生網路相關或執行個體特定的錯誤。In the .NET Framework 4.6 and 4.6.1, attempting a TCP/IP connection to a SQL Server database that resolves to localhost fails with the error, "A network-related or instance-specific error occurred while establishing a connection to SQL Server. 找不到或無法存取伺服器。The server was not found or was not accessible. 檢查執行個體名稱是否正確以及 SQL Server 執行個體是否設定為允許遠端連接。Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (提供者:SQL 網路介面,錯誤:26 - 搜尋指定的伺服器/執行個體時發生錯誤)」(provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)"

建議Suggestion

在 .NET Framework 4.6.2 中已解決此問題,並還原舊版行為。This issue has been addressed and the previous behavior restored in the .NET Framework 4.6.2. 若要連線至解析為 localhost 的 SQL Server 資料庫,請升級至 .NET Framework 4.6.2。To connect to a SQL Server database that resolves to localhost, upgrade to the .NET Framework 4.6.2.

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

受影響的 APIAffected APIs

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

偵錯工具Debugger

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

網路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

序列化Serialization

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

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

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

詳細資料Details

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

建議Suggestion

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

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

警告

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

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

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

警告

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

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

受影響的 APIAffected APIs

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

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

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

CoerceIsSelectionBoxHighlightedCoerceIsSelectionBoxHighlighted

詳細資料Details

涉及 System.Windows.Controls.ComboBox 及其資料來源的特定動作順序會導致 System.NullReferenceExceptionCertain sequences of actions involving a System.Windows.Controls.ComboBox and its data source can result in a System.NullReferenceException.

建議Suggestion

可能的話,請升級至 .NET Framework 4.6.2。If possible, upgrade to .NET Framework 4.6.2.

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

受影響的 APIAffected APIs

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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.

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

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