本文列出 .NET Framework 4.6、4.6.1 和 4.6.2 中介紹的應用程式相容性問題。
.NET Framework 4.6
ASP.NET
AllowCustomPaging 設為 true 的 GridView 可能在離開檢視的最後一頁時引發 PageIndexChanging 事件
詳細資訊
.NET Framework 4.5 中的 Bug) 導致有時不會針對已啟用 System.Web.UI.WebControls.GridView.PageIndexChanging 的 System.Web.UI.WebControls.GridView 引發 System.Web.UI.WebControls.GridView.AllowCustomPaging。
建議
此此問題在 .NET Framework 4.6 中已修正，因此可藉由升級至該版 .NET Framework 來解決。 應用程式可以對叫用這些條件 (Page_Load 位在最後一個頁面上且 LastSystem.Web.UI.WebControls.GridView 不同於 System.Web.UI.WebControls.GridView.PageSize) 的 System.Web.UI.WebControls.GridView.PageSize 執行明確的 BindGrid，來解決這個問題。 或者，可以修改應用程式以允許分頁 (而不是自訂分頁)，因為該情況不會顯示此問題。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.5 |
| 類型 | 執行時間 |
受影響的 API
核心
在 .NET Framework 4.5 中利用 NetDataContractSerializer 序列化過的 ConcurrentDictionary，無法由 .NET Framework 4.5.1 或 4.5.2 還原序列化
詳細資訊
由於此類型的內部變更，使用 ConcurrentDictionary<TKey,TValue> 以 .NET Framework 4.5 序列化的 System.Runtime.Serialization.NetDataContractSerializer 物件，無法在 .NET Framework 4.5.1 或 .NET Framework 4.5.2 中還原序列化。請注意，反向移動 (以 .NET Framework 4.5.x 序列化並以 .NET Framework 4.5 還原序列化) 則運作正常。 同樣地，所有 4.x 跨版本序列化在 .NET Framework 4.6 中都會正常運作。以單一 .NET Framework 版本進行序列化和還原序列化則不受影響。
建議
如果需要在 .NET Framework 4.5 和 .NET Framework 4.5.1/4.5.2 之間序列化和還原序列化 System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue>，則應該使用不同的序列化程式 (例如 System.Runtime.Serialization.DataContractSerializer)，而不是使用 System.Runtime.Serialization.NetDataContractSerializer。 此外，由於此問題在 .NET Framework 4.6 中已解決，因此可藉由升級至該版 .NET Framework 來解決。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.5.1 |
| 類型 | 執行時間 |
受影響的 API
無法透過 API 分析偵測。
AppDomainSetup.DynamicBase 不再受 UseRandomizedStringHashAlgorithm 的影響而被隨機化
詳細資訊
在 .NET Framework 4.6 之前，如果在應用程式的組態檔中啟用了 UseRandomizedStringHashAlgorithm，那麼 DynamicBase 的值會在應用程式域之間或進程之間隨機化。 從 .NET Framework 4.6 開始， DynamicBase 將會傳回執行之應用程式的不同實例與不同應用程式網域之間的穩定結果。 不同應用程式的動態基址仍會有所不同；這項變更只會移除相同應用程式之不同實例的隨機命名元素。
建議
請注意，啟用 UseRandomizedStringHashAlgorithm 不會造成 DynamicBase 隨機化。 如果需要隨機基底，則必須在應用程式的程式代碼中產生它，而不是透過此 API 產生。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 微軟 Edge |
| 版本 | 4.6 |
| 類型 | 執行時間 |
受影響的 API
在索引器屬性上呼叫 Attribute.GetCustomAttributes 時，如果索引的類型能夠解決歧義，就不會再擲回 AmbiguousMatchException。
詳細資訊
在 .NET Framework 4.6 之前，若在索引類型不同的索引器屬性上呼叫 GetCustomAttribute(s)，就會產生 System.Reflection.AmbiguousMatchException。 從 .NET Framework 4.6 開始，屬性屬性將會正確傳回。
建議
請注意，GetCustomAttribute（s） 現在會更頻繁地運作。 如果應用程式先前依賴 System.Reflection.AmbiguousMatchException，則現在應該使用反映來明確尋找多個索引器。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 微軟 Edge |
| 版本 | 4.6 |
| 類型 | 執行時間 |
受影響的 API
- Attribute.GetCustomAttribute(MemberInfo, Type)
- Attribute.GetCustomAttribute(MemberInfo, Type, Boolean)
- Attribute.GetCustomAttributes(MemberInfo)
- Attribute.GetCustomAttributes(MemberInfo, Boolean)
- Attribute.GetCustomAttributes(MemberInfo, Type)
- Attribute.GetCustomAttributes(MemberInfo, Type, Boolean)
- CustomAttributeExtensions.GetCustomAttribute(MemberInfo, Type)
- CustomAttributeExtensions.GetCustomAttribute(MemberInfo, Type, Boolean)
- CustomAttributeExtensions.GetCustomAttribute<T>(MemberInfo)
- CustomAttributeExtensions.GetCustomAttribute<T>(MemberInfo, Boolean)
- CustomAttributeExtensions.GetCustomAttributes(MemberInfo)
- CustomAttributeExtensions.GetCustomAttributes(MemberInfo, Boolean)
- CustomAttributeExtensions.GetCustomAttributes(MemberInfo, Type)
- CustomAttributeExtensions.GetCustomAttributes(MemberInfo, Type, Boolean)
- CustomAttributeExtensions.GetCustomAttributes<T>(MemberInfo)
- CustomAttributeExtensions.GetCustomAttributes<T>(MemberInfo, Boolean)
分析工具不會列舉 COR_PRF_GC_ROOT_HANDLE
詳細資訊
在 .NET Framework v4.5.1 中，分析 API RootReferences2() 會錯誤地永不傳回 COR_PRF_GC_ROOT_HANDLE (而是傳回為 COR_PRF_GC_ROOT_OTHER)。 從 .NET Framework 4.6 開始，已修正此問題。
建議
此此問題在 .NET Framework 4.6 中已修正，因此可藉由升級至該版 .NET Framework 來解決。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.5.1 |
| 類型 | 執行時間 |
受影響的 API
無法透過 API 分析偵測。
ETW EventListeners 無法使用 Explicit 關鍵字從提供者擷取事件 (例如 TPL 提供者)
詳細資訊
具有空白關鍵字遮罩的 ETW EventListeners 無法使用 Explicit 關鍵字從提供者正確地擷取事件。 在 .NET Framework 4.5 中，TPL 提供者已開始提供 Explicit 關鍵字並觸發此問題。 在 .NET Framework 4.6 中，已更新 EventListeners，因此不會再發生此問題。
建議
若要解決此問題，請將 EnableEvents(EventSource, EventLevel) 的呼叫取代為 EnableEvents 多載的呼叫，其明確指定「任何關鍵字」遮罩以使用：EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff))。
此外，此問題在 .NET Framework 4.6 中已修正，因此可藉由升級至該版 .NET Framework 來解決。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 微軟 Edge |
| 版本 | 4.5 |
| 類型 | 執行時間 |
受影響的 API
現在，波斯歷使用希吉拉太陽曆演算法
詳細資訊
從 .NET Framework 4.6 開始，類別 System.Globalization.PersianCalendar 會使用Hijri太陽能演算法。 從 .NET Framework 4.6 開始，轉換日期可能會在 System.Globalization.PersianCalendar 與其他行事曆之間產生稍微不同的結果，特別是在日期早於 1800 或晚於 2023 年（公曆）時。此外，PersianCalendar.MinSupportedDateTime 現在是 March 22, 0622 而不是 March 21, 0622。
建議
請注意，在 .NET Framework 4.6 中使用波斯語Calendar 時，某些早期或晚期日期可能稍有不同。 此外，在不同的 .NET Framework 版本上執行的進程之間串行化日期時，請勿將它們儲存為波斯語Calendar 日期字串（因為這些值可能不同）。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.6 |
| 類型 | 執行時間 |
受影響的 API
無法再將反射物件從受控程式碼傳遞至進程外的 DCOM 用戶端
詳細資訊
不能再將反射物件從受控代碼傳遞至進程外部的 DCOM 用戶端。 下列類型受到影響：
- System.Reflection.Assembly
- System.Reflection.MemberInfo （及其衍生類型，包括 System.Reflection.FieldInfo、 System.Reflection.MethodInfo、 System.Type、 和 System.Reflection.TypeInfo）
- System.Reflection.MethodBody
- System.Reflection.Module
- System.Reflection.ParameterInfo
對物件的呼叫 IMarshal 返回 E_NOINTERFACE。
建議
更新封送處理程式碼以處理非反射性物件。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.6 |
| 類型 | 執行時間 |
受影響的 API
- System.Reflection.Assembly
- System.Reflection.FieldInfo
- System.Reflection.MemberInfo
- System.Reflection.MethodBody
- System.Reflection.MethodInfo
- System.Reflection.Module
- System.Reflection.ParameterInfo
- System.Reflection.TypeInfo
- System.Type
如果未設定，默認應用程式域的 TargetFrameworkName 不會再預設為 null
詳細資訊
System.AppDomainSetup.TargetFrameworkName先前在默認應用程式網域中為 null，除非明確設定。 從 4.6 開始， System.AppDomainSetup.TargetFrameworkName 默認應用程式域的屬性會有衍生自 TargetFrameworkAttribute 的預設值（如果有的話）。 除非明確覆寫，否則非默認應用程式網域會繼續繼承其 System.AppDomainSetup.TargetFrameworkName 自默認應用程式網域（在 4.6 中不會預設為 Null）。
建議
程式代碼應該更新為不依賴 TargetFrameworkName 預設為 null。 如果需要此屬性繼續評估為 null，則可以明確地將它設定為該值。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 微軟 Edge |
| 版本 | 4.6 |
| 類型 | 執行時間 |
受影響的 API
當 .NET 無法處理憑證時，X509Certificate2.ToString（Boolean） 不會立即擲回
詳細資訊
在 .NET Framework 4.5.2 和舊版中，如果 true 傳遞給詳細資訊參數，而且已安裝 .NET Framework 不支持的憑證，這個方法會擲回。 現在，方法會成功並傳回有效的字串，以省略憑證無法存取的部分。
建議
任何相依 X509Certificate2.ToString(Boolean) 的程式代碼都應該更新，以預期傳回的字串可能會排除某些憑證數據（例如公鑰、私鑰和延伸模組），在某些情況下，API 先前會擲回。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 微軟 Edge |
| 版本 | 4.6 |
| 類型 | 執行時間 |
受影響的 API
資料
嘗試與解析成 localhost 的 SQL Server 資料庫進行 TCP/IP 連線失敗
詳細資訊
在 .NET Framework 4.6 和 4.6.1 中，嘗試通過 TCP/IP 與 SQL Server 資料庫建立連線時，如果解析為 localhost，即會失敗，並發生錯誤：「建立 SQL Server 連線時發生網路相關或實例特定的錯誤。」 找不到伺服器或無法存取。 確認實例名稱正確，且 SQL Server 已設定為允許遠端連線。 （提供者： SQL 網路介面， 錯誤： 26 - 尋找指定的伺服器/實例時發生錯誤）
建議
此問題已解決，且已在 .NET Framework 4.6.2 中還原先前的行為。 若要連接到解析為 localhost的 SQL Server 資料庫，請升級至 .NET Framework 4.6.2。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.6 |
| 類型 | 執行時間 |
受影響的 API
無法透過 API 分析偵測。
調試器
在稍後的步驟中，偵錯工具才會顯示 Null 聯合器值
詳細資訊
.NET Framework 4.5 中的 Bug) 會導致在 64 位元版本的 Framework 上執行時，透過 Null 聯合運算設定的值不會立即於執行指派作業之後顯示在偵錯工具中。
建議
在偵錯工具中逐步執行一段額外時間，將使本機/欄位的值正確更新。 此外，此問題已在 .NET Framework 4.6 中修正；升級至該版 .NET Framework 應可解決此問題。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 微軟 Edge |
| 版本 | 4.5 |
| 類型 | 執行時間 |
受影響的 API
無法透過 API 分析偵測。
網路
ContentDisposition DateTimes 會傳回稍微不同的字串
詳細資訊
自 4.6 起，System.Net.Mime.ContentDisposition 的字串表示已更新，以一律以兩位數表示 System.DateTime 的小時元件。 這是為了符合 RFC822 和 RFC2822。 這會導致 ToString() 在 4.6 中傳回稍微不同的字串，其中一個設定的時間屬性在上午 10:00 之前。 請注意，ContentDispositions 有時會透過將它們轉換成字串進行串行化，因此應該檢閱任何 ToString() 作業、串行化或 GetHashCode 呼叫。
建議
請勿預期來自不同 .NET Framework 版本的 ContentDispositions 字串表示會正確地彼此比較。 盡可能將字串轉換為 ContentDispositions，然後再進行比較。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.6 |
| 類型 | 執行時間 |
受影響的 API
序列化
當發生未知類型時，失敗的 DataContract 序列化例外訊息已變更。
詳細資訊
從 .NET Framework 4.6 開始，如果 System.Runtime.Serialization.DataContractSerializer 或 System.Runtime.Serialization.Json.DataContractJsonSerializer 因遺漏「已知型別」而無法序列化或反序列化，則例外狀況訊息已被釐清。
建議
應用程式不應該相依於特定的例外狀況訊息。 如果應用程式相依於此訊息，請更新它以預期新的訊息，或 （最好）將它變更為只取決於例外狀況類型。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 微軟 Edge |
| 版本 | 4.6 |
| 類型 | 執行時間 |
受影響的 API
- DataContractJsonSerializer(Type)
- DataContractJsonSerializer(Type, IEnumerable<Type>)
- DataContractJsonSerializer(Type, DataContractJsonSerializerSettings)
- DataContractJsonSerializer(Type, String)
- DataContractJsonSerializer(Type, String, IEnumerable<Type>)
- DataContractJsonSerializer(Type, XmlDictionaryString)
- DataContractJsonSerializer(Type, XmlDictionaryString, IEnumerable<Type>)
- DataContractJsonSerializer(Type, IEnumerable<Type>, Int32, Boolean, IDataContractSurrogate, Boolean)
- DataContractJsonSerializer(Type, String, IEnumerable<Type>, Int32, Boolean, IDataContractSurrogate, Boolean)
- DataContractJsonSerializer(Type, XmlDictionaryString, IEnumerable<Type>, Int32, Boolean, IDataContractSurrogate, Boolean)
- DataContractSerializer(Type)
- DataContractSerializer(Type, DataContractSerializerSettings)
- DataContractSerializer(Type, IEnumerable<Type>)
- DataContractSerializer(Type, String, String)
- DataContractSerializer(Type, String, String, IEnumerable<Type>)
- DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString)
- DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString, IEnumerable<Type>)
- DataContractSerializer(Type, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate)
- DataContractSerializer(Type, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate, DataContractResolver)
- DataContractSerializer(Type, String, String, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate)
- DataContractSerializer(Type, String, String, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate, DataContractResolver)
- DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate)
- DataContractSerializer(Type, XmlDictionaryString, XmlDictionaryString, IEnumerable<Type>, Int32, Boolean, Boolean, IDataContractSurrogate, DataContractResolver)
安裝及部署
.NET Framework 4.6 和更新版本中的產品版本控制變更
詳細資訊
產品版本設定已從舊版 .NET Framework 變更，特別是從 .NET Framework 4、4.5、4.5.1 和 4.5.2 變更。 以下是詳細的變更：
- 在 .NET Framework 4.6 及其點版本中，
Version鍵中的HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full專案值已變更為4.6.xxxxx；在 .NET Framework 4.7 和 4.7.1 中，變更為4.7.xxxxx。 在 .NET Framework 4.5、4.5.1 和 4.5.2 中，其格式為4.5.xxxxx。 - .NET Framework 檔案的檔案和產品版本設定已從舊版的 4.0.30319.x 變更為 .NET Framework 4.6.X.0 及其點版本，以及 .NET Framework 4.7.X.0 和 4.7.1。 當您在檔案上按下滑鼠右鍵之後，即可檢視檔案的 [屬性] 時看到這些新值。
- AssemblyFileVersionAttribute 和 AssemblyInformationalVersionAttribute 屬性對於受管理的組件，其版本格式為 4.6.X.0，適用於 .NET Framework 4.6 及其更新版本， 而對於 .NET Framework 4.7 和 4.7.1，格式則為 4.7.X.0。
- 在 .NET Framework 4.6、4.6.1、4.6.2、4.7 和 4.7.1 中， Environment.Version 屬性會傳回固定的版本字符串
4.0.30319.42000。 在 .NET Framework 4、4.5、4.5.1 和 4.5.2 中，它會以格式4.0.30319.xxxxx傳回版本字串（例如，“4.0.30319.18010”。 請注意，我們不建議應用程式碼對 Environment.Version 屬性採取任何新的相依性。
如需詳細資訊，請參閱 如何：判斷已安裝哪些 .NET Framework 版本。
建議
一般而言，應用程式應該利用建議的技術來偵測 .NET Framework 的運行時版本以及安裝目錄等項目。
- 若要偵測 .NET Framework 的運行時間版本，請參閱 如何：判斷已安裝哪些 .NET Framework 版本。
- 若要判斷 .NET Framework 的安裝路徑，請使用
InstallPath項目值，該值位於HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full索引鍵中。
這很重要
子機碼名稱為 NET Framework Setup，而非 .NET Framework Setup。
- 若要判斷 .NET Framework Common Language Runtime 的目錄路徑，請呼叫 RuntimeEnvironment.GetRuntimeDirectory() 方法。
- 若要取得 CLR 版本，請呼叫 RuntimeEnvironment.GetSystemVersion() 方法。 針對 .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。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.6 |
| 類型 | 執行時間 |
受影響的 API
無法透過 API 分析偵測。
將自己登錄到登錄檔時，.NET Framework 4.6 不會使用 4.5.x.x 版本
詳細資訊
如預期，.NET Framework 4.6 的登錄中設定 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full的版本機碼是以 '4.6' 開頭，而不是 '4.5'。 相依於這些登錄機碼的應用程式，以了解計算機上安裝哪些 .NET Framework 版本應該更新，以瞭解 4.6 是新的可能版本，以及與先前 4.5.x 版本相容的版本。
建議
藉由尋找 4.5 登錄機碼以接受 4.6，更新 .NET Framework 4.5 安裝的應用程式探查。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 微軟 Edge |
| 版本 | 4.6 |
| 類型 | 執行時間 |
受影響的 API
無法透過 API 分析偵測。
Windows Communication Foundation （WCF）
搭配 SSL 安全性和 MD5 憑證驗證使用 NETTCP 的 WCF 服務
詳細資訊
.NET Framework 4.6 會將 TLS 1.1 和 TLS 1.2 新增至 WCF SSL 預設通訊協議清單。 當客戶端和伺服器機器都已安裝 .NET Framework 4.6 或更新版本時，會使用 TLS 1.2 進行交涉。TLS 1.2 不支援 MD5 憑證驗證。 因此，如果客戶使用 MD5 憑證，WCF 用戶端將無法連線到 WCF 服務。
建議
您可以解決此問題，讓 WCF 用戶端可以執行下列任何動作來連線到 WCF 伺服器：
- 將憑證更新為不使用 MD5 演算法。 這是建議的解決方案。
- 如果未在原始程式碼中動態設定系結，請更新應用程式的組態檔，以使用 TLS 1.1 或舊版的通訊協定。 這可讓您繼續使用具有 MD5 哈希演算法的憑證。
警告
不建議使用此因應措施，因為具有 MD5 哈希演算法的憑證被視為不安全。
下列組態檔會執行此動作：
<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>
- 如果在原始碼中動態設定系結，請更新 TcpTransportSecurity.SslProtocols 屬性以使用TLS 1.1（SslProtocols.Tls11 或原始程式碼中的舊版通訊協定）。
警告
不建議使用此因應措施，因為具有 MD5 哈希演算法的憑證被視為不安全。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.6 |
| 類型 | 執行時間 |
受影響的 API
無法透過 API 分析偵測。
Windows Presentation Foundation （WPF）
從 DataGrid 的 UnloadingRow 事件處理常式存取 WPF DataGrid 的選取項目可能會導致 NullReferenceException
詳細資訊
由於 .NET Framework 4.5 中的 Bug)，涉及移除資料列之 DataGrid 事件的事件處理常式，可能會在它們存取 System.NullReferenceException 的 DataGrid 或 System.Windows.Controls.Primitives.Selector.SelectedItem 屬性時導致擲回 System.Windows.Controls.Primitives.MultiSelector.SelectedItems。
建議
此此問題在 .NET Framework 4.6 中已修正，因此可藉由升級至該版 .NET Framework 來解決。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.5 |
| 類型 | 執行時間 |
受影響的 API
在已選取項目的 WPF ListBox、ListView 或 DataGrid 上呼叫 Items.Refresh 會導致在項目中出現重複的項目
詳細資訊
在 .NET Framework 4.5 中，如果 System.Windows.Controls.ListBox 中已選取項目，從程式碼呼叫 ListBox.Items.Refresh 可能會導致選取的項目在清單中重複出現。 System.Windows.Controls.ListView 和 System.Windows.Controls.DataGrid 會發生類似的問題。 這在 .NET Framework 4.6 中已修正。
建議
您可以在呼叫 System.Windows.Data.CollectionView.Refresh() 之前以程式設計方式取消選取項目，然後在呼叫完成之後重新選取項目來解決此問題。 此外，此問題在 .NET Framework 4.6 中已修正，因此可藉由升級至該版 .NET Framework 來解決。
| 價值觀 | |
|---|---|
| 範圍 | 輕微 |
| 版本 | 4.5 |
| 型別 | 執行時間 |
受影響的 API
強制為選擇框高亮顯示
詳細資訊
涉及 System.Windows.Controls.ComboBox 及其資料來源的特定動作序列可能會導致 System.NullReferenceException。
建議
可能的話，請升級至 .NET Framework 4.6.2。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.6 |
| 類型 | 執行時間 |
受影響的 API
ObservableCollection<T>.Move 的 ListBoxItem IsSelected 繫結問題
詳細資訊
針對繫結至 Move(Int32, Int32) 且已選取項目的集合呼叫 MoveItem(Int32, Int32) 或 System.Windows.Controls.ListBox，可能會在未來選取或取消選取 System.Windows.Controls.ListBox 項目時導致不穩定的行為。
建議
呼叫 System.Collections.ObjectModel.Collection<T>.Remove(T) 和 System.Collections.ObjectModel.Collection<T>.Insert(Int32, T) 而不是 Move(Int32, Int32) 可解決此問題。 此外，此問題在 .NET Framework 4.6 中已修正，因此可藉由升級至該版 .NET Framework 來解決。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.5 |
| 類型 | 執行時間 |
受影響的 API
以滑鼠右鍵按一下 WPF DataGrid 資料列標頭會變更 DataGrid 選取項目
詳細資訊
選取多個資料列時，若以滑鼠右鍵按一下選取的 System.Windows.Controls.DataGrid 資料列標頭，會導致 System.Windows.Controls.DataGrid 的選取項目變更為只有該資料列。
建議
此此問題在 .NET Framework 4.6 中已修正，因此可藉由升級至該版 .NET Framework 來解決。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 微軟 Edge |
| 版本 | 4.5 |
| 類型 | 執行時間 |
受影響的 API
WPF 會繁衍可以凍結滑鼠的 wisptis.exe 處理序
詳細資訊
在 4.5.2 中產生了一個問題，導致繁衍可凍結滑鼠輸入的 wisptis.exe。
建議
解決此問題的修正程式可在 .NET Framework 4.5.2 的服務版本 (Hotfix 彙總套件 3026376) 中取得，或藉由升級至 .NET Framework 4.6 取得
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 主要 |
| 版本 | 4.5.2 |
| 類型 | 執行時間 |
受影響的 API
無法透過 API 分析偵測。
在文本啟用的控制項中的 WPF 拼字檢查功能在 Windows 10 中將對於不在作業系統輸入語言清單中的語言不起作用。
詳細資訊
在 Windows 10 上執行時，拼字檢查程式可能無法用於啟用 WPF 文字的控制件，因為平臺拼字檢查功能僅適用於輸入語言清單中的語言。在 Windows 10 中，當語言新增至可用的鍵盤清單中時，Windows 會自動下載並安裝對應的功能隨選功能 （FOD） 套件，以提供拼字檢查功能。 藉由將語言新增至輸入語言清單，將支援拼字檢查程式。
建議
請注意，要進行拼字檢查的語言或文字必須新增為輸入語言，以進行拼字檢查，才能在 Windows 10 中運作。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 微軟 Edge |
| 版本 | 4.6 |
| 類型 | 執行時間 |
受影響的 API
無法透過 API 分析偵測。
WPF 視窗在超出單一監視器範圍時顯示而不會被裁剪。
詳細資訊
在 Windows 8 和更高版本上執行的 .NET Framework 4.6 中，在多螢幕情境下，當整個視窗延伸到單一顯示器之外時，整個視窗會被完整呈現，而不會被裁剪。 這與舊版 .NET Framework 不同，它會裁剪超出單一顯示器的 WPF 視窗。
建議
此行為（不論是否要裁剪）可以在應用程式組態檔中使用 <EnableMultiMonitorDisplayClipping> 元素來明確設定，或在應用程式啟動時設定 <appSettings> 屬性。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.6 |
| 類型 | 執行時間 |
受影響的 API
無法透過 API 分析偵測。
.NET 框架 4.6.1
工具
Contract.Invariant 或 Contract.Requires<TException> 不會將 String.IsNullOrEmpty 視為純
詳細資訊
針對以 .NET Framework 4.6.1 為目標的應用程式，如果 呼叫 Contract.Invariant 方法的不因合約或前置條件合約RequiresString.IsNullOrEmpty，重寫器會發出編譯程式警告 CC1036：“偵測到方法 'System.String.IsNullOrWhiteSpace（System.String）' 的呼叫，而方法中沒有 [Pure] 。這是編譯程式警告，而不是編譯程序錯誤。
建議
此行為已在 GitHub 問題 #339 中解決。 若要消除此警告，您可以從 GitHub 下載並編譯程式代碼合約工具的更新版本原始碼。 下載信息位於頁面底部。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.6.1 |
| 類型 | 執行時間 |
受影響的 API
Windows Presentation Foundation （WPF）
項目捲動具有不同像素高度的平面列表
詳細資訊
System.Windows.Controls.ItemsControl 在使用虛擬化（IsVirtualizing=true）和項目捲動來顯示集合時，當控件捲動以顯示其高度與鄰近項目不同的項目時，ScrollUnit=Item 會逐一遍歷集合中的所有項目。 在此迭代期間，UI 沒有回應。 反覆操作在其他情境下發生，即使在先前的 .NET Framework 版本中也是如此。 例如，當遇到具有不同圖元高度的專案時發生圖元捲動（ScrollUnit=Pixel），以及在處理階層式數據的專案捲動（例如啟用了群組的System.Windows.Controls.TreeView或System.Windows.Controls.ItemsControl）時，如果遇到具有與鄰近專案的後代專案數目不同的專案，就會出現這種情況。針對項目捲動和不同圖元高度的情況，.NET Framework 4.6.1 中引入了反覆運算，以修正階層式數據版面配置中的漏洞。 如果數據是一般（沒有階層），而且 .NET Framework 4.6.2 在該情況下不會這麼做，則不需要它。
建議
如果反覆項目發生在 .NET Framework 4.6.1 中，但不發生在舊版中，也就是說，如果 System.Windows.Controls.ItemsControl 是項目卷動不同像素高度的扁平列表，則有兩種補救措施：
- 安裝 .NET Framework 4.6.2。
- 安裝適用於 .NET Framework 4.6.1 的 Hotfix HR 1605。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.6.1 |
| 類型 | 執行時間 |
受影響的 API
WPF 拼字檢查程序擲回的 ObjectDisposedException
詳細資訊
WPF 應用程式偶爾會在應用程式關閉時當機，因為拼字檢查程式拋出的 System.ObjectDisposedException。 這是在 .NET Framework 4.7 WPF 中透過正常處理例外狀況來修正此問題，因此可確保應用程式不再受到不良影響。 請注意，在調試程式下執行的應用程式中，偶爾仍會觀察到初次發生的例外狀況。
建議
升級至 .NET Framework 4.7
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 微軟 Edge |
| 版本 | 4.6.1 |
| 類型 | 執行時間 |
受影響的 API
無法透過 API 分析偵測。
WPF 拼字檢查會以非預期的方式失敗
詳細資訊
這包括一些 WPF 拼字檢查程式問題：
- WPF 拼字檢查工具有時會拋出 System.Runtime.InteropServices.COMException
- 使用「以不同使用者身分執行」啟動應用程式時，WPF 拼字檢查程式會失敗UnauthorizedAccessException
- WPF 拼字檢查工具在德文中錯誤地識別複合字詞中的拼字錯誤，例如 'Hausnummer'。
建議
問題 #1 - 此問題已在 .NET Framework 4.6.2 問題 #2 中修正 - 使用「以不同使用者身分執行」啟動應用程式時，不再支援 WPF 拼字檢查程式。 從 .NET Framework 4.6.2 開始，以這種方式啟動的應用程式將不再意外當機，而是以無訊息方式停用拼字檢查程式。 問題 #3 - 已在 .NET Framework 4.6.2 中修正此問題。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 微軟 Edge |
| 版本 | 4.6.1 |
| 類型 | 執行時間 |
受影響的 API
無法透過 API 分析偵測。
.NET Framework 4.6.2
資料
嘗試與解析成 localhost 的 SQL Server 資料庫進行 TCP/IP 連線失敗
詳細資訊
在 .NET Framework 4.6 和 4.6.1 中，嘗試通過 TCP/IP 與 SQL Server 資料庫建立連線時，如果解析為 localhost，即會失敗，並發生錯誤：「建立 SQL Server 連線時發生網路相關或實例特定的錯誤。」 找不到伺服器或無法存取。 確認實例名稱正確，且 SQL Server 已設定為允許遠端連線。 （提供者： SQL 網路介面， 錯誤： 26 - 尋找指定的伺服器/實例時發生錯誤）
建議
此問題已解決，且已在 .NET Framework 4.6.2 中還原先前的行為。 若要連接到解析為 localhost的 SQL Server 資料庫，請升級至 .NET Framework 4.6.2。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.6 |
| 類型 | 執行時間 |
受影響的 API
無法透過 API 分析偵測。
已移除 Azure SQL 資料庫的連線集區封鎖期間
詳細資訊
從 .NET Framework 4.6.2 開始，針對已知 Azure SQL 資料庫的聯機開啟要求（*.database.windows.net、*.database.chinacloudapi.cn、*.database.usgovcloudapi.net、*.database.cloudapi.de），會移除連線集區封鎖期間，而且不會快取連線開啟錯誤。 連線重新開啟的嘗試幾乎會在暫時性連線錯誤之後立即發生。 這項變更允許立即重試 Azure SQL Database 的連線開啟嘗試，因而提升啟用雲端功能的應用程式效能。 至於所有其他連線嘗試，則會繼續強制執行連線集區封鎖期。
在 .NET Framework 4.6.1 及之前的版本中，當應用程式在連接到資料庫時遇到暫時的連線失敗，無法立即重新嘗試連線，因為連線池會快取錯誤並在5秒到1分鐘內再次拋出該錯誤。 如需詳細資訊，請參閱 SQL Server 連線共用 (ADO.NET) \(機器翻譯\)。 此行為會對 Azure SQL Database 連線造成問題，連線通常會因暫時性錯誤而失敗，而且一般會在幾秒內復原。 線上集區封鎖功能表示應用程式無法長時間連線到資料庫，即使資料庫可用，而且應用程式必須在幾秒鐘內轉譯。
建議
如果此行為不理想，您可以藉由設定 .NET Framework 4.6.2 中引進的屬性來設定 System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod 連線集區封鎖期間。 屬性的值是 System.Data.SqlClient.PoolBlockingPeriod 列舉中的一個成員，可以取三個值中的任意一個：
您可以將 System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod 屬性設定為 AlwaysBlock 以還原先前的行為。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.6.2 |
| 類型 | 執行時間 |
受影響的 API
全球化
現在支援 Unicode 標準 8.0 版類別
詳細資訊
在 .NET Framework 4.6.2 中，Unicode 數據已從 Unicode Standard 6.3 版升級至 8.0 版。 在 .NET Framework 4.6.2 中要求 Unicode 字元類別時，某些結果可能不符合先前 .NET Framework 版本中的結果。 這種變化大多影響切羅基音節和新傣仂母音符號及聲調標記。
建議
檢閱程式代碼並移除/變更取決於硬式編碼 Unicode 字元類別的邏輯。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.6.2 |
| 類型 | 執行時間 |
受影響的 API
- Char.GetUnicodeCategory(Char)
- CharUnicodeInfo.GetUnicodeCategory(Char)
- CharUnicodeInfo.GetUnicodeCategory(String, Int32)
安全
部分信任環境中再次可使用 RSACng 和 DSACng
詳細資訊
CngLightup （用於數個較高層級的加密 API，例如 System.Security.Cryptography.Xml.EncryptedXml），在某些情況下 System.Security.Cryptography.RSACng 會依賴完全信任。 這些包括未聲明SecurityPermissionFlag.UnmanagedCode權限的P/Invoke，以及System.Security.Cryptography.CngKey的程式碼路徑具有對SecurityPermissionFlag.UnmanagedCode的權限要求。 從 .NET Framework 4.6.2 開始，CngLightup 可用來盡可能切換至 System.Security.Cryptography.RSACng 。 因此，成功使用 System.Security.Cryptography.Xml.EncryptedXml 的部分信任應用程式開始失敗並擲回 SecurityException 例外狀況。這項變更會新增必要的斷言，以確保所有使用 CngLightup 的函式具有所需的權限。
建議
如果 .NET Framework 4.6.2 中的這項變更對您的部分信任應用程式造成負面影響，請升級至 .NET Framework 4.7.1。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 微軟 Edge |
| 版本 | 4.6.2 |
| 類型 | 執行時間 |
受影響的 API
- DSACng(CngKey)
- DSACng.Key
- DSACng.LegalKeySizes
- DSACng.CreateSignature(Byte[])
- DSACng.VerifySignature(Byte[], Byte[])
- RSACng(CngKey)
- RSACng.Key
- RSACng.Decrypt(Byte[], RSAEncryptionPadding)
- RSACng.SignHash(Byte[], HashAlgorithmName, RSASignaturePadding)
RSACng.VerifyHash 現在會針對任何驗證失敗傳回 False
詳細資訊
從 .NET Framework 4.6.2 開始，如果簽章本身的格式不正確，這個方法會傳回 False 。 它現在會針對任何驗證失敗傳回 false。在 .NET Framework 4.6 和 4.6.1 中，如果簽章本身的格式不正確，方法會擲回 System.Security.Cryptography.CryptographicException 。
建議
任何程式碼如果其執行取決於處理 System.Security.Cryptography.CryptographicException，那麼當驗證失敗且方法傳回 False 時，就應執行該程式碼。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.6.2 |
| 類型 | 執行時間 |
受影響的 API
SignedXml 和 EncryptedXml 重大變更
詳細資訊
在 .NET Framework 4.6.2 中，System.Security.Cryptography.Xml.SignedXml 和 System.Security.Cryptography.Xml.EncryptedXml 的安全性修正導致不同的執行時行為。 例如：
- 如果文件有多個具有相同
id屬性的元素，並且簽章將其中一個元素作為簽章的根元素，則該文件現在會被視為無效。 - 在參考中使用非標準 XPath 轉換演算法的檔現在被視為無效。
- 在參考中使用非標準 XSLT 轉換演算法的文件現在會被視為無效。
- 任何使用外部資源分離簽名的程式將無法執行此動作。
建議
開發人員可能會想要檢閱XmlDsigXsltTransform和XmlDsigXsltTransform的使用方式，以及從Transform衍生出的類型，因為文件接收者可能無法處理這些內容。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.6.2 |
| 類型 | 執行時間 |
受影響的 API
- System.Security.Cryptography.Xml.Transform
- System.Security.Cryptography.Xml.XmlDsigXPathTransform
- System.Security.Cryptography.Xml.XmlDsigXsltTransform
Windows Communication Foundation （WCF）
從 WCF TransportDefaults 中移除 Ssl3
詳細資訊
搭配傳輸安全性和憑證的認證類型使用 NetTcp 時，SSL 3 通訊協定不再是用來交涉安全連線的預設通訊協定。 在大部分情況下，應該不會影響現有的應用程式，因為 NETTcp 的通訊協定清單中一律包含 TLS 1.0。 所有現有的用戶端都應該能夠至少使用 TLS1.0 交涉連線。
建議
如果需要 Ssl3，請使用下列其中一個組態機制，將 Ssl3 新增至交涉通訊協定清單。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 微軟 Edge |
| 版本 | 4.6.2 |
| 類型 | 執行時間 |
受影響的 API
Windows Presentation Foundation （WPF）
變更 TextBlock 控制件父系的 IsEnabled 屬性會影響任何子控件
詳細資訊
從 .NET Framework 4.6.2 開始，變更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 屬性狀態。
建議
沒有。 這項變更符合 System.Windows.Controls.TextBlock 控件內部控件的預期行為。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.6.2 |
| 類型 | 執行時間 |
受影響的 API
強制為選擇框高亮顯示
詳細資訊
涉及 System.Windows.Controls.ComboBox 及其資料來源的特定動作序列可能會導致 System.NullReferenceException。
建議
可能的話，請升級至 .NET Framework 4.6.2。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.6 |
| 類型 | 執行時間 |
受影響的 API
DataGridCellsPanel.BringIndexIntoView 會擲回 ArgumentOutOfRangeException
詳細資訊
ScrollIntoView(Object) 啟用數據行虛擬化但尚未判斷數據行寬度時，將會以異步方式運作。 如果在異步工作發生之前移除資料列， System.ArgumentOutOfRangeException 可能會發生 。
建議
下列任一項：
- 升級至 .NET Framework 4.7。
- 安裝 .NET Framework 4.6.2 的最新維護修補程式。
- 請避免移除列，直到異步 ScrollIntoView(Object) 回應完成為止。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 微軟 Edge |
| 版本 | 4.6.2 |
| 類型 | 執行時間 |
受影響的 API
水平捲動和虛擬化
詳細資訊
這項變更適用於 System.Windows.Controls.ItemsControl 在與主要捲動方向垂直的方向上自身執行虛擬化的情況（主要範例是 System.Windows.Controls.DataGrid，其 EnableColumnVirtualization="True"）。 某些水平卷動作業的結果已變更，以產生更直覺且更類似於可比較垂直作業結果的結果。
這些作業包括 「Scroll Here」 和 「Right Edge」，以使用從以滑鼠右鍵按兩下水平滾動條取得的功能表中的名稱。 這兩個運算都會計算候選位移並呼叫 SetHorizontalOffset(Double)。
捲動至新的位移後，「這裡」或「右邊緣」的概念可能會改變，因為新釋放虛擬化的內容已經改變了System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth的值。
在 .NET Framework 4.6.2 之前，捲動作業只會使用候選位移，即使它可能不是「這裡」或「右邊緣」。 這會導致捲動拇指「彈跳」之類的效果，最能以範例說明。 假設System.Windows.Controls.DataGrid的 ExtentWidth=1000 且 Width=200。 捲動至 "Right Edge" 會使用候選偏移量 1000 - 200 = 800。 捲動至該位移時，會解除虛擬化新的列。假設它們非常寬，因此 System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth 變更為 2000。 捲動條在 HorizontalOffset=800 停止，而游標「彈跳」回到滾動條中間附近 - 精確停留在 800/2000 = 40%。
變更是在這種情況發生時重新計算新的候選位移，然後再試一次。 （這就是垂直捲動已經運作的方式。）
此變更將為最終使用者提供更可預測且直觀的體驗，但也可能影響任何依賴於水平滾動後確切值 System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset 的應用程式，無論是由使用者發起的，還是透過明確呼叫 SetHorizontalOffset(Double) 的。
建議
針對使用預測值System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset的應用程式，在因去虛擬化而變更System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth的任何水平捲動之後，應該擷取實際值以及System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth的值。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.6.2 |
| 類型 | 執行時間 |
受影響的 API
Items.Clear 不會從 SelectedItems 移除重複項目
詳細資訊
假設選取器 (啟用了多個選取項目) 在其 System.Windows.Controls.Primitives.MultiSelector.SelectedItems 集合中有重複項目 - 相同的項目出現一次以上。 從資料來源移除這些項目 (例如，藉由呼叫 Items.Clear) 無法從 System.Windows.Controls.Primitives.MultiSelector.SelectedItems 中加以移除；只會移除第一個執行個體。 此外，後續使用 System.Windows.Controls.Primitives.MultiSelector.SelectedItems (例如 SelectedItems.Clear()) 可能會發生像是 System.ArgumentException 的問題，因為 System.Windows.Controls.Primitives.MultiSelector.SelectedItems 包含已不在資料來源中的項目。
建議
如有可能，請升級至 .NET Framework 4.6.2。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.5 |
| 類型 | 執行時間 |
受影響的 API
項目捲動具有不同像素高度的平面列表
詳細資訊
System.Windows.Controls.ItemsControl 在使用虛擬化（IsVirtualizing=true）和項目捲動來顯示集合時，當控件捲動以顯示其高度與鄰近項目不同的項目時，ScrollUnit=Item 會逐一遍歷集合中的所有項目。 在此迭代期間，UI 沒有回應。 反覆操作在其他情境下發生，即使在先前的 .NET Framework 版本中也是如此。 例如，當遇到具有不同圖元高度的專案時發生圖元捲動（ScrollUnit=Pixel），以及在處理階層式數據的專案捲動（例如啟用了群組的System.Windows.Controls.TreeView或System.Windows.Controls.ItemsControl）時，如果遇到具有與鄰近專案的後代專案數目不同的專案，就會出現這種情況。針對項目捲動和不同圖元高度的情況，.NET Framework 4.6.1 中引入了反覆運算，以修正階層式數據版面配置中的漏洞。 如果數據是一般（沒有階層），而且 .NET Framework 4.6.2 在該情況下不會這麼做，則不需要它。
建議
如果反覆項目發生在 .NET Framework 4.6.1 中，但不發生在舊版中，也就是說，如果 System.Windows.Controls.ItemsControl 是項目卷動不同像素高度的扁平列表，則有兩種補救措施：
- 安裝 .NET Framework 4.6.2。
- 安裝適用於 .NET Framework 4.6.1 的 Hotfix HR 1605。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 輕微 |
| 版本 | 4.6.1 |
| 類型 | 執行時間 |
受影響的 API
在地化版本中，RibbonGroup 的背景設定為透明。
詳細資訊
System.Windows.Controls.Ribbon.RibbonGroup 本地化組建的背景一律會使用透明筆刷繪製，導致UI體驗不佳。 這已在 .NET Framework 4.7 WPF 修正中解決，方法是更新 System.Windows.Controls.Ribbon.RibbonGroup 的當地語系化資源，從而確保已選擇正確的筆刷。
建議
升級至 .NET Framework 4.7
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 微軟 Edge |
| 版本 | 4.6.2 |
| 類型 | 執行時間 |
受影響的 API
無法透過 API 分析偵測。
WPF 拼字檢查會以非預期的方式失敗
詳細資訊
這包括一些 WPF 拼字檢查程式問題：
- WPF 拼字檢查工具有時會拋出 System.Runtime.InteropServices.COMException
- 使用「以不同使用者身分執行」啟動應用程式時，WPF 拼字檢查程式會失敗UnauthorizedAccessException
- WPF 拼字檢查工具在德文中錯誤地識別複合字詞中的拼字錯誤，例如 'Hausnummer'。
建議
問題 #1 - 此問題已在 .NET Framework 4.6.2 問題 #2 中修正 - 使用「以不同使用者身分執行」啟動應用程式時，不再支援 WPF 拼字檢查程式。 從 .NET Framework 4.6.2 開始，以這種方式啟動的應用程式將不再意外當機，而是以無訊息方式停用拼字檢查程式。 問題 #3 - 已在 .NET Framework 4.6.2 中修正此問題。
| 名稱 | 價值觀 |
|---|---|
| 影響範圍 | 微軟 Edge |
| 版本 | 4.6.1 |
| 類型 | 執行時間 |
受影響的 API
無法透過 API 分析偵測。
