移轉至 .NET Framework 4.6.x 時的執行階段變更
本文列出 .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.AllowCustomPaging 的 System.Web.UI.WebControls.GridView 引發 System.Web.UI.WebControls.GridView.PageIndexChanging。
建議
此此問題在 .NET Framework 4.6 中已修正,因此可藉由升級至該版 .NET Framework 來解決。 應用程式可以對叫用這些條件 (System.Web.UI.WebControls.GridView 位在最後一個頁面上且 LastSystem.Web.UI.WebControls.GridView.PageSize 不同於 System.Web.UI.WebControls.GridView.PageSize) 的 Page_Load
執行明確的 BindGrid,來解決這個問題。 或者,可以修改應用程式以允許分頁 (而不是自訂分頁),因為該情況不會顯示此問題。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 4.5 |
類型 | 執行階段 |
受影響的 API
核心
在 .NET Framework 4.5 中利用 NetDataContractSerializer 序列化過的 ConcurrentDictionary,無法由 .NET Framework 4.5.1 或 4.5.2 還原序列化
詳細資料
由於此類型的內部變更,使用 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 還原序列化) 則運作正常。 同樣地,所有 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 來解決。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 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 開始,將會正確地傳回屬性 (Property) 的屬性 (Attributee)。
建議
請注意,GetCustomAttribute 現在正常運作的頻率會更高。 如果應用程式先前依賴 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 來解決。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 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 類別會使用回教陽曆演算法。 從 .NET Framework 4.6 開始,針對 1800 年以前的日期或 2023 年以後的日期 (西曆),在 System.Globalization.PersianCalendar 與其他日曆之間轉換這些日期可能會產生稍微不同的結果。此外,PersianCalendar.MinSupportedDateTime 現在是 March 22, 0622
,而不是 March 21, 0622
。
建議
請注意,在 .NET Framework 4.6 中使用 PersianCalendar 時,某些較早或較晚的日期可能會稍微不同。 此外,在不同 .NET Framework 版本上執行的處理序之間序列化日期,不會將日期儲存為 PersianCalendar 日期字串 (因為這些值可能不同)。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 4.6 |
類型 | 執行階段 |
受影響的 API
無法再將反映物件從受控程式碼傳遞至跨處理序的 DCOM 用戶端
詳細資料
無法再將反映物件從 Managed 程式碼傳遞至跨處理序的 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
。
建議
更新封送處理程式碼以使用非反映物件。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 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
資料
嘗試建立 TCP/IP 連線至解析為 localhost
的 SQL Server 資料庫會失敗
詳細資料
在 .NET Framework 4.6 和 4.6.1 中,嘗試建立 TCP/IP 連線至解析為 localhost
的 SQL Server 資料庫會失敗,錯誤為:「建立連線至 SQL Server 時,發生網路相關或執行個體特定的錯誤。 找不到或無法存取伺服器。 檢查執行個體名稱是否正確以及 SQL Server 執行個體是否設定為允許遠端連接。 (提供者: SQL 網路錯誤,錯誤: 26 - 搜尋指定的伺服器/執行個體時發生錯誤)」。
建議
在 .NET Framework 4.6.2 中已解決此問題,並還原舊版行為。 若要連線至解析為 localhost
的 SQL Server 資料庫,請升級至 .NET Framework 4.6.2。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 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 會傳回稍微不同的字串
詳細資料
System.Net.Mime.ContentDisposition 的字串表示已更新,從 4.6 開始,一律會以兩個位數表示 System.DateTime 的小時元件。 這是為了遵守 RFC822 和 RFC2822。 這會導致 ToString() 在 4.6 中傳回稍微不同的字串,例如,當其中一個配置的時間項目早於上午 10:00 時。 請注意,ContentDispositions 有時會透過轉換成字串來進行序列化,因此應檢閱任何 ToString() 作業、序列化或 GetHashCode 呼叫。
建議
在不同的 .NET Framework 版本中,ContentDispositions 的字串表示不會正確地相互比較。 如果可能的話,請將字串轉換回 ContentDispositions,再進行比較。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 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) 的產品版本已變更。 以下是詳細的變更:
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)。 在 .NET Framework 4.5、4.5.1 和 4.5.2 中,其格式為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)。 當您以滑鼠右鍵按一下檔案後再檢視檔案的屬性時,會看到這些新值。
- 受控組件的 AssemblyFileVersionAttribute 和 AssemblyInformationalVersionAttribute 屬性,對於 .NET Framework 4.6 及其小數點發行版本,其 Version 值的格式為 4.6.X.0,對於 .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 的安裝路徑,請使用
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full
機碼中的InstallPath
項目值。
重要
子機碼名稱是 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。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 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 登錄機碼來更新 .NET Framework 4.5 安裝的應用程式探查,使其也接受 4.6。
名稱 | 值 |
---|---|
範圍 | Edge |
版本 | 4.6 |
類型 | 執行階段 |
受影響的 API
無法透過 API 分析偵測。
Windows Communication Foundation (WCF)
使用 NETTCP 進行 SSL 安全性和 MD5 憑證驗證的 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 雜湊演算法的憑證並不安全。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 4.6 |
類型 | 執行階段 |
受影響的 API
無法透過 API 分析偵測。
Windows Presentation Foundation (WPF)
從 DataGrid 的 UnloadingRow 事件處理常式存取 WPF DataGrid 的選取項目可能會導致 NullReferenceException
詳細資料
由於 .NET Framework 4.5 中的 Bug),涉及移除資料列之 DataGrid 事件的事件處理常式,可能會在它們存取 DataGrid 的 System.Windows.Controls.Primitives.Selector.SelectedItem 或 System.Windows.Controls.Primitives.MultiSelector.SelectedItems 屬性時導致擲回 System.NullReferenceException。
建議
此此問題在 .NET Framework 4.6 中已修正,因此可藉由升級至該版 .NET Framework 來解決。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 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 來解決。
值 | |
---|---|
範圍 | Minor |
版本 | 4.5 |
類型 | 執行階段 |
受影響的 API
CoerceIsSelectionBoxHighlighted
詳細資料
涉及 System.Windows.Controls.ComboBox 及其資料來源的特定動作順序會導致 System.NullReferenceException。
建議
可能的話,請升級至 .NET Framework 4.6.2。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 4.6 |
類型 | 執行階段 |
受影響的 API
ObservableCollection<T>.Move 的 ListBoxItem IsSelected 繫結問題
詳細資料
針對繫結至 System.Windows.Controls.ListBox 且已選取項目的集合呼叫 Move(Int32, Int32) 或 MoveItem(Int32, Int32),可能會在未來選取或取消選取 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 來解決。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 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 分析偵測。
若語言不在 OS 的輸入語言清單中,啟用文字之控制項中的 WPF 拼字檢查不適用於 Windows 10
詳細資料
因為只有輸入語言清單上的語言可以使用平台拼字檢查功能,所以拼字檢查工具在 Windows 10 上執行時可能不適用於啟用 WPF 文字的控制項。在 Windows 10 中,將語言新增至可用鍵盤的清單時,Windows 會自動下載並安裝對應的 Feature on Demand (FOD) 套件,以提供拼字檢查功能。 只要將語言加入輸入語言清單中,就可支援拼字檢查工具。
建議
請注意,要進行拼字檢查的語言或文字必須新增為輸入語言,拼字檢查才能在 Windows 10 中正常運作。
名稱 | 值 |
---|---|
範圍 | Edge |
版本 | 4.6 |
類型 | 執行階段 |
受影響的 API
無法透過 API 分析偵測。
WPF 視窗在擴充到單一顯示器之外時呈現而不裁剪
詳細資料
在 Windows 8 和更新版本中執行的 .NET Framework 4.6 多重監視器案例中,如果視窗擴充到單一顯示畫面之外,可呈現完整視窗而不會將其裁剪。 這與舊版 .NET Framework 不同,後者會在 WPF 視窗擴充到單一顯示畫面之外時裁剪該視窗。
建議
您可以在應用程式組態檔的 <appSettings>
中使用 <EnableMultiMonitorDisplayClipping>
項目,或在應用程式啟動時藉由設定 EnableMultiMonitorDisplayClipping
屬性,來明確設定這項行為 (不論是否裁剪)。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 4.6 |
類型 | 執行階段 |
受影響的 API
無法透過 API 分析偵測。
.NET Framework 4.6.1
工具
Contract.Invariant 或 Contract.Requires<TException> 不會將 String.IsNullOrEmpty 視為 pure
詳細資料
針對以 .NET Framework 4.6.1 為目標的應用程式,如果 Contract.Invariant 的非變異合約或 Requires 的前置條件合約呼叫 String.IsNullOrEmpty 方法,重寫器會發出編譯器警告 CC1036:「偵測到對方法 'System.String.IsNullOrWhiteSpace(System.String)' 的呼叫,但在方法中沒有 [Pure]。」這是編譯器警告,不是編譯器錯誤。
建議
GitHub 問題 #339 中已解決這種行為。 若要移除這個警告,您可以從 GitHub 下載並編譯程式碼合約工具原始程式碼的更新版本。 您可以在頁面底部找到下載資訊。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 4.6.1 |
類型 | 執行階段 |
受影響的 API
Windows Presentation Foundation (WPF)
在具有不同像素高度之項目的簡單列表中進行項目捲動
詳細資料
System.Windows.Controls.ItemsControl 使用虛擬化 (IsVirtualizing=true
) 及項目捲動 (ScrollUnit=Item
) 顯示集合時,以及捲動控制項以顯示高度 (以像素為單位) 與其相鄰項目不同的項目時,System.Windows.Controls.VirtualizingStackPanel 會逐一查看集合中的所有項目。 此反覆運算期間 UI 沒有回應。 反覆運算會在其他情況發生,甚至在先前的 .NET Framework 版本中。 例如,在下列情況會發生這種情況:如果在發現像素高度不同的項目時進行像素捲動 (ScrollUnit=Pixel
),以及如果在發現子系項目數與其相鄰項目不同的項目時進行階層式資料項目捲動 (例如,在已啟用群組的 System.Windows.Controls.TreeView 或 System.Windows.Controls.ItemsControl 中)。針對項目捲動和不同像素高度的情況,.NET Framework 4.6.1 中引進了逐一查看,以修正階層式資料配置中的 Bug。 如果是單層式資料 (沒有階層),則不需要逐一查看,而且 .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。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 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
資料
嘗試建立 TCP/IP 連線至解析為 localhost
的 SQL Server 資料庫會失敗
詳細資料
在 .NET Framework 4.6 和 4.6.1 中,嘗試建立 TCP/IP 連線至解析為 localhost
的 SQL Server 資料庫會失敗,錯誤為:「建立連線至 SQL Server 時,發生網路相關或執行個體特定的錯誤。 找不到或無法存取伺服器。 檢查執行個體名稱是否正確以及 SQL Server 執行個體是否設定為允許遠端連接。 (提供者: SQL 網路錯誤,錯誤: 26 - 搜尋指定的伺服器/執行個體時發生錯誤)」。
建議
在 .NET Framework 4.6.2 中已解決此問題,並還原舊版行為。 若要連線至解析為 localhost
的 SQL Server 資料庫,請升級至 .NET Framework 4.6.2。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 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 可以還原舊有行為。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 4.6.2 |
類型 | 執行階段 |
受影響的 API
全球化
現在支援 Unicode 標準 8.0 版分類
詳細資料
在 .NET Framework 4.6.2 中,Unicode 資料已從 Unicode 標準 6.3 版升級至 8.0 版。 在 .NET Framework 4.6.2 中要求 Unicode 字元分類時,某些結果可能不符合舊版 .NET Framework 中的結果。 這項變更主要會影響柴羅基文音節和新傣文母音符號和音調標記。
建議
請檢閱程式碼,並移除/變更仰賴硬式編碼的 Unicode 字元分類的邏輯。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 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。
建議
如果驗證失敗且此方法傳回 False,應改為執行任何仰賴處理 System.Security.Cryptography.CryptographicException 來執行的程式碼。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 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 之類型的使用方式,因為文件收件者可能無法處理它。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 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 通訊協定已不再是用來交涉安全連接的預設通訊協定。 在大部分情況下,應該不會影響現有的應用程式,因為 TLS 1.0 一律包含在 NetTcp 的通訊協定清單中。 所有現有的用戶端應該能夠使用至少 TLS 1.0 來交涉連接。
建議
如果需要 SSL3,請使用下列組態機制其中之一,將 SSL3 新增至交涉通訊協定的清單。
名稱 | 值 |
---|---|
範圍 | Edge |
版本 | 4.6.2 |
類型 | 執行階段 |
受影響的 API
Windows Presentation Foundation (WPF)
變更 TextBlock 控制項之父代的 IsEnabled 屬性會影響任何子控制項
詳細資料
從 .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 屬性狀態。
建議
無。 這項變更符合 System.Windows.Controls.TextBlock 控制項內的之控制項的預期行為。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 4.6.2 |
類型 | 執行階段 |
受影響的 API
CoerceIsSelectionBoxHighlighted
詳細資料
涉及 System.Windows.Controls.ComboBox 及其資料來源的特定動作順序會導致 System.NullReferenceException。
建議
可能的話,請升級至 .NET Framework 4.6.2。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 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 (主要範例是 EnableColumnVirtualization="True" 的 System.Windows.Controls.DataGrid)。 某些水平捲動作業的結果已變更,產生的結果更直覺,且更類似於可比較的垂直作業的結果。
這些作業包括「捲動至此處」和「右邊緣」,以使用以滑鼠右鍵按一下水平捲軸所取得之功能表中的名稱。 這兩個都會計算候選位移並呼叫 SetHorizontalOffset(Double)。
捲動至新的位移後,「此處」或「右邊緣」的定義可能已變更,因為最近取消虛擬化的內容已變更 System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth 的值。
在 .NET Framework 4.6.2 之前,捲軸作業會直接使用候選位移,即使它可能已不再是「此處」或位於「右邊緣」。 這會導致類似捲動指標「反彈」的效果,以範例說明最為合適。 假設 System.Windows.Controls.DataGrid 具有 ExtentWidth=1000 和 Width=200。 捲動到「右邊緣」會使用候選位移 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.ExtentWidth 的任何水平捲動之後,為 System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset 使用預測值的應用程式應該改為擷取實際值 (以及 System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth 的值)。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 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。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 4.5 |
類型 | 執行階段 |
受影響的 API
在具有不同像素高度之項目的簡單列表中進行項目捲動
詳細資料
System.Windows.Controls.ItemsControl 使用虛擬化 (IsVirtualizing=true
) 及項目捲動 (ScrollUnit=Item
) 顯示集合時,以及捲動控制項以顯示高度 (以像素為單位) 與其相鄰項目不同的項目時,System.Windows.Controls.VirtualizingStackPanel 會逐一查看集合中的所有項目。 此反覆運算期間 UI 沒有回應。 反覆運算會在其他情況發生,甚至在先前的 .NET Framework 版本中。 例如,在下列情況會發生這種情況:如果在發現像素高度不同的項目時進行像素捲動 (ScrollUnit=Pixel
),以及如果在發現子系項目數與其相鄰項目不同的項目時進行階層式資料項目捲動 (例如,在已啟用群組的 System.Windows.Controls.TreeView 或 System.Windows.Controls.ItemsControl 中)。針對項目捲動和不同像素高度的情況,.NET Framework 4.6.1 中引進了逐一查看,以修正階層式資料配置中的 Bug。 如果是單層式資料 (沒有階層),則不需要逐一查看,而且 .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。
名稱 | 值 |
---|---|
範圍 | Minor |
版本 | 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 分析偵測。