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

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

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

Azure SQL 資料庫的連線集區封鎖期已移除Connection pool blocking period for Azure SQL databases is removed

詳細資料Details

從 .NET Framework 4.6.2 開始,針對已知 Azure SQL 資料庫的連線開啟要求 (* . database.windows.net、 * database.chinacloudapi.cn、 * database.usgovcloudapi.net、 * database.cloudapi.de) 、已移除連接集區封鎖期間,且未快取連接開啟的錯誤。Starting with the .NET Framework 4.6.2, for connection open requests to known Azure SQL databases (*.database.windows.net, *.database.chinacloudapi.cn, *.database.usgovcloudapi.net, *.database.cloudapi.de), the connection pool blocking period is removed, and connection open errors are not cached. 發生暫時性連線錯誤之後,幾乎會立即嘗試重試連線開啟要求。Attempts to retry connection open requests will occur almost immediately after transient connection errors. 這項變更允許立即重試 Azure SQL Database 的連線開啟嘗試,因而提升啟用雲端功能的應用程式效能。This change allows the connection open attempt to be retried immediately for Azure SQL databases, thereby improving the performance of cloud- enabled apps. 至於所有其他連線嘗試,則會繼續強制執行連線集區封鎖期。For all other connection attempts, the connection pool blocking period continues to be enforced.

在 .NET Framework 4.6.1 和舊版中,如果應用程式在連線到資料庫時發生暫時性連線失敗,由於連線集區會快取此錯誤並在 5 秒鐘到 1 分鐘後重新擲回,因此無法很快就重試連線。In the .NET Framework 4.6.1 and earlier versions, when an app encounters a transient connection failure when connecting to a database, the connection attempt cannot be retried quickly, because the connection pool caches the error and re-throws it for 5 seconds to 1 minute. 如需詳細資訊,請參閱 SQL Server 連線共用 (ADO.NET) (機器翻譯)。For more information, see SQL Server Connection Pooling (ADO.NET). 此行為會對 Azure SQL Database 連線造成問題,連線通常會因暫時性錯誤而失敗,而且一般會在幾秒內復原。This behavior is problematic for connections to Azure SQL databases, which often fail with transient errors that are typically recovered from within a few seconds. 連線集區封鎖功能表示應用程式有很長的一段時間無法連線到資料庫,即使資料庫可供使用且應用程式需要在幾秒內呈現也一樣。The connection pool blocking feature means that the app cannot connect to the database for an extensive period, even though the database is available and the app needs to render within a few seconds.

建議Suggestion

如果不需要這種行為,可以藉由設定 .NET Framework 4.6.2 中引進的 System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod 屬性來設定連線集區封鎖期。If this behavior is undesirable, the connection pool blocking period can be configured by setting the System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod property introduced in the .NET Framework 4.6.2. 屬性的值是 System.Data.SqlClient.PoolBlockingPeriod 列舉的成員,可以採用三個值的其中一個值︰The value of the property is a member of the System.Data.SqlClient.PoolBlockingPeriod enumeration that can take either of three values:

System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod 屬性設為 AlwaysBlock 可以還原舊有行為。The previous behavior can be restored by setting the System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod property to AlwaysBlock.

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

受影響的 APIAffected APIs

全球化Globalization

現在支援 Unicode 標準 8.0 版分類Unicode standard version 8.0 categories now supported

詳細資料Details

在 .NET Framework 4.6.2 中,Unicode 資料已從 Unicode 標準 6.3 版升級至 8.0 版。In .NET Framework 4.6.2, Unicode data has been upgraded from Unicode Standard version 6.3 to version 8.0. 在 .NET Framework 4.6.2 中要求 Unicode 字元分類時,某些結果可能不符合舊版 .NET Framework 中的結果。When requesting Unicode character categories in .NET Framework 4.6.2, some results might not match the results in previous .NET Framework versions. 這項變更主要會影響柴羅基文音節和新傣文母音符號和音調標記。This change mostly affects Cherokee syllables and New Tai Lue vowels signs and tone marks.

建議Suggestion

請檢閱程式碼,並移除/變更仰賴硬式編碼的 Unicode 字元分類的邏輯。Review code and remove/change logic that depends on hard-coded Unicode character categories.

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

受影響的 APIAffected APIs

安全性Security

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

詳細資料Details

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

建議Suggestion

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

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

受影響的 APIAffected APIs

RSACng.VerifyHash 現在會針對任何驗證失敗傳回 FalseRSACng.VerifyHash now returns False for any verification failure

詳細資料Details

從 .NET Framework 4.6.2 開始,如果簽章本身的格式不正確,此方法會傳回 FalseStarting with the .NET Framework 4.6.2, this method returns False if the signature itself is badly formatted. 現在任何驗證失敗都會傳回 False。在 .NET Framework 4.6 和 4.6.1 中,如果簽章本身的格式不正確,此方法會擲回 System.Security.Cryptography.CryptographicExceptionIt now returns false for any verification failure.In the .NET Framework 4.6 and 4.6.1, the method throws a System.Security.Cryptography.CryptographicException if the signature itself is badly formatted.

建議Suggestion

如果驗證失敗且此方法傳回 False,應改為執行任何仰賴處理 System.Security.Cryptography.CryptographicException 來執行的程式碼。Any code whose execution depends on handling the System.Security.Cryptography.CryptographicException should instead execute if validation fails and the method returns False.

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

受影響的 APIAffected APIs

SignedXml 和 EncryptedXml 重大變更SignedXml and EncryptedXml Breaking Changes

詳細資料Details

在 .NET Framework 4.6.2 中,System.Security.Cryptography.Xml.SignedXmlSystem.Security.Cryptography.Xml.EncryptedXml 的安全性修正會導致不同的執行階段行為。In .NET Framework 4.6.2, Security fixes in System.Security.Cryptography.Xml.SignedXml and System.Security.Cryptography.Xml.EncryptedXml lead to different run-time behaviors. 例如,For example,

  • 如果文件具有包含相同 id 屬性的多個項目,且簽章將目標設為這些項目之一以作為簽章的根項目,該文件現在會視為無效。If a document has multiple elements with the same id attribute and a signature targets one of those elements as the root of the signature, the document will now be considered invalid.
  • 在參考中使用非標準 XPath 轉換演算法的文件現在都視為無效。Documents using non-canonical XPath transform algorithms in references are now considered invalid.
  • 在參考中使用非標準 XSLT 轉換演算法的文件現在會視為無效。Documents using non-canonical XSLT transform algorithms in references are now consider invalid.
  • 任何使用外部資源中斷簽章的程式都無法這麼做。Any program making use of external resource detached signatures will be unable to do so.

建議Suggestion

開發人員可能想要檢閱 XmlDsigXsltTransformXmlDsigXsltTransform,以及衍生自 Transform 之類型的使用方式,因為文件收件者可能無法處理它。Developers might want to review the usage of XmlDsigXsltTransform and XmlDsigXsltTransform, as well as types derived from Transform since a document receiver may not be able to process it.

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

受影響的 APIAffected APIs

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

從 WCF TransportDefaults 中移除 SSL3Remove Ssl3 from the WCF TransportDefaults

詳細資料Details

當使用 NetTcp 搭配傳輸安全性和憑證類型的認證時,SSL 3 通訊協定已不再是用來交涉安全連接的預設通訊協定。When using NetTcp with transport security and a credential type of certificate, the SSL 3 protocol is no longer a default protocol used for negotiating a secure connection. 在大部分情況下,應該不會影響現有的應用程式,因為 TLS 1.0 一律包含在 NetTcp 的通訊協定清單中。In most cases there should be no impact to existing apps as TLS 1.0 has always been included in the protocol list for NetTcp. 所有現有的用戶端應該能夠使用至少 TLS 1.0 來交涉連接。All existing clients should be able to negotiate a connection using at least TLS1.0.

建議Suggestion

如果需要 SSL3,請使用下列組態機制其中之一,將 SSL3 新增至交涉通訊協定的清單。If Ssl3 is required, use one of the following configuration mechanisms to add Ssl3 to the list of negotiated protocols.

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

受影響的 APIAffected APIs

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

變更 TextBlock 控制項之父代的 IsEnabled 屬性會影響任何子控制項Changing the IsEnabled property of the parent of a TextBlock control affects any child controls

詳細資料Details

從 .NET Framework 4.6.2 開始,變更 System.Windows.Controls.TextBlock 控制項之父代的 System.Windows.UIElement.IsEnabled 屬性,會影響 System.Windows.Controls.TextBlock 控制項的任何子控制項 (例如超連結和按鈕)。在 .NET Framework 4.6.1 和舊版中,System.Windows.Controls.TextBlock 內的控制項不一定會反映 System.Windows.Controls.TextBlock 父代的 System.Windows.UIElement.IsEnabled 屬性狀態。Starting with the .NET Framework 4.6.2, changing the System.Windows.UIElement.IsEnabled property of the parent of a System.Windows.Controls.TextBlock control affects any child controls (such as hyperlinks and buttons) of the System.Windows.Controls.TextBlock control.In the .NET Framework 4.6.1 and earlier versions, controls inside a System.Windows.Controls.TextBlock did not always reflect the state of the System.Windows.UIElement.IsEnabled property of the System.Windows.Controls.TextBlock parent.

建議Suggestion

無。None. 這項變更符合 System.Windows.Controls.TextBlock 控制項內的之控制項的預期行為。This change conforms to the expected behavior for controls inside a System.Windows.Controls.TextBlock control.

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

受影響的 APIAffected APIs

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

DataGridCellsPanel.BringIndexIntoView 擲回 ArgumentOutOfRangeExceptionDataGridCellsPanel.BringIndexIntoView throws ArgumentOutOfRangeException

詳細資料Details

啟用資料行虛擬化,但尚未決定資料行寬度時,ScrollIntoView(Object) 將以非同步方式運作。ScrollIntoView(Object) will work asynchronously when column virtualization is enabled but the column widths have not yet been determined. 如果資料行在非同步工作進行之前遭到移除,會發生 System.ArgumentOutOfRangeExceptionIf columns are removed before the asynchronous work happens, an System.ArgumentOutOfRangeException can occur.

建議Suggestion

下列任一步驟:Any one of the following:

  1. 升級至 .NET Framework 4.7。Upgrade to .NET Framework 4.7.
  2. 為 .NET Framework 4.6.2 安裝最新的服務修補程式。Install the latest servicing patch for .NET Framework 4.6.2.
  3. ScrollIntoView(Object) 的非同步回應完成之前,避免移除資料行。Avoid removing columns until the asynchronous response to ScrollIntoView(Object) has completed.

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

受影響的 APIAffected APIs

水平捲動和虛擬化Horizontal scrolling and virtualization

詳細資料Details

此變更會套用至以正交於主要捲動方向之方向執行自身虛擬化的 System.Windows.Controls.ItemsControl (主要範例是 EnableColumnVirtualization="True" 的 System.Windows.Controls.DataGrid)。This change applies to an System.Windows.Controls.ItemsControl that does its own virtualization in the direction orthogonal to the main scrolling direction (the chief example is System.Windows.Controls.DataGrid with EnableColumnVirtualization="True"). 某些水平捲動作業的結果已變更,產生的結果更直覺,且更類似於可比較的垂直作業的結果。The outcome of certain horizontal scrolling operations has been changed to produce results that are more intuitive and more analogous to the results of comparable vertical operations.

這些作業包括 [捲動至此處] 和 [右邊緣],以使用以滑鼠右鍵按一下水平捲軸所取得之功能表中的名稱。The operations include "Scroll Here" and "Right Edge", to use the names from the menu obtained by right-clicking a horizontal scrollbar. 這兩個都會計算候選位移並呼叫 SetHorizontalOffset(Double)Both of these compute a candidate offset and call SetHorizontalOffset(Double).

捲動至新的位移後,「此處」或「右邊緣」的定義可能已變更,因為最近取消虛擬化的內容已變更 System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth 的值。After scrolling to the new offset, the notion of "here" or "right edge" may have changed because newly de-virtualized content has changed the value of System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth.

在 .NET Framework 4.6.2 之前,捲軸作業會直接使用候選位移,即使它可能已不再是「此處」或位於「右邊緣」。Prior to .NET Framework 4.6.2, the scroll operation simply uses the candidate offset, even though it may not be "here" or at the "right edge" any more. 這會導致類似捲動指標「反彈」的效果,以範例來說明最為合適。This results in effects like "bouncing" the scroll thumb, best illustrated by example. 假設 System.Windows.Controls.DataGrid 具有 ExtentWidth=1000 和 Width=200。Suppose a System.Windows.Controls.DataGrid has ExtentWidth=1000 and Width=200. 捲動到「右邊緣」會使用候選位移 1000 - 200 = 800。A scroll to "Right Edge" uses candidate offset 1000 - 200 = 800. 捲動到該位移時,新的資料行會取消虛擬化;假設它們非常寬,因此 System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth 變更為 2000。While scrolling to that offset, new columns are de- virtualized; let's suppose they are very wide, so that the System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth changes to 2000. 捲軸在 HorizontalOffset=800 結束,而指標會「反彈」回到捲軸中央附近,精確來說是在 800/2000 等於 40% 的位置。The scroll ends with HorizontalOffset=800, and the thumb "bounces" back to near the middle of the scrollbar - precisely at 800/2000 = 40%.

發生這種情況時,變更是重新計算新的候選位移,然後再試一次。The change is to recompute a new candidate offset when this situation occurs, and try again. (這是垂直捲動目前運作的方式)。(This is how vertical scrolling works already.)

此變更會為使用者產生更為可預測且直覺式的體驗,但它會影響依賴 System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset 於水平捲動後 (無論是由使用者叫用或是明確呼叫 SetHorizontalOffset(Double)) 之確切值的所有應用程式。The change produces a more predictable and intuitive experience for the end user, but it could also affect any app that depends on the exact value of System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset after a horizontal scroll, whether invoked by the end user or by an explicit call to SetHorizontalOffset(Double).

建議Suggestion

在因為取消虛擬化而可能變更 System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth 的任何水平捲動之後,為 System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset 使用預測值的應用程式應該改為擷取實際值 (以及 System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth 的值)。An app that uses a predicted value for System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset should be changed to fetch the actual value (and the value of System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth) after any horizontal scroll that could change System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth due to de-virtualization.

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

受影響的 APIAffected APIs

Items.Clear 不會從 SelectedItems 移除重複項目Items.Clear does not remove duplicates from SelectedItems

詳細資料Details

假設選取器 (啟用了多個選取項目) 在其 System.Windows.Controls.Primitives.MultiSelector.SelectedItems 集合中有重複項目 - 相同的項目出現一次以上。Suppose a Selector (with multiple selection enabled) has duplicates in its System.Windows.Controls.Primitives.MultiSelector.SelectedItems collection - the same item appears more than once. 從資料來源移除這些項目 (例如,藉由呼叫 Items.Clear) 無法從 System.Windows.Controls.Primitives.MultiSelector.SelectedItems 中加以移除;只會移除第一個執行個體。Removing those items from the data source (e.g. by calling Items.Clear) fails to remove them from System.Windows.Controls.Primitives.MultiSelector.SelectedItems; only the first instance is removed. 此外,後續使用 System.Windows.Controls.Primitives.MultiSelector.SelectedItems (例如 SelectedItems.Clear()) 可能會發生像是 System.ArgumentException 的問題,因為 System.Windows.Controls.Primitives.MultiSelector.SelectedItems 包含已不在資料來源中的項目。Furthermore, subsequent use of System.Windows.Controls.Primitives.MultiSelector.SelectedItems (e.g. SelectedItems.Clear()) can encounter problems such as System.ArgumentException, because System.Windows.Controls.Primitives.MultiSelector.SelectedItems contains items that are no longer in the data source.

建議Suggestion

如有可能,請升級至 .NET Framework 4.6.2。Upgrade if possible to .NET Framework 4.6.2.

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

受影響的 APIAffected APIs

在具有不同像素高度之項目的簡單列表中進行項目捲動Item-scrolling a flat list with items of different pixel-height

詳細資料Details

System.Windows.Controls.ItemsControl 使用虛擬化 (IsVirtualizing=true) 及項目捲動 (ScrollUnit=Item) 顯示集合時,以及捲動控制項以顯示高度 (以像素為單位) 與其相鄰項目不同的項目時,System.Windows.Controls.VirtualizingStackPanel 會逐一查看集合中的所有項目。When an System.Windows.Controls.ItemsControl displays a collection using virtualization (IsVirtualizing=true) and item- scrolling (ScrollUnit=Item), and when the control scrolls to display an item whose height in pixels differs from its neighbors, the System.Windows.Controls.VirtualizingStackPanel iterates over all items in the collection. UI 在此反覆運算期間沒有回應;如果集合很大,這可視為停止回應。The UI is unresponsive during this iteration; if the collection is large, this can be perceived as a hang. 即使在先前的 .NET Framework 版本中,也會在其他情況下進行反復專案。The iteration occurs in other circumstances, even in previous .NET Framework releases. 例如,在下列情況會發生這種情況:如果在發現像素高度不同的項目時進行像素捲動 (ScrollUnit=Pixel),以及如果在發現子系項目數與其相鄰項目不同的項目時進行階層式資料項目捲動 (例如,在已啟用群組的 System.Windows.Controls.TreeViewSystem.Windows.Controls.ItemsControl 中)。針對項目捲動和不同像素高度的情況,.NET Framework 4.6.1 中引進了逐一查看,以修正階層式資料配置中的 Bug。For example, it occurs when pixel-scrolling (ScrollUnit=Pixel) upon encountering an item with different pixel height, and when item-scrolling hierarchical data (such as a System.Windows.Controls.TreeView or an System.Windows.Controls.ItemsControl with grouping enabled) upon encountering an item with a different number of descendant items than its neighbors.For the case of item-scrolling and different pixel height, the iteration was introduced in .NET Framework 4.6.1 to fix bugs in the layout of hierarchical data. 如果是單層式資料 (沒有階層),則不需要逐一查看,而且 .NET Framework 4.6.2 在此情況下不會這麼做。It is not needed if the data is flat (no hierarchy), and .NET Framework 4.6.2 does not do it in that case.

建議Suggestion

如果在 .NET Framework 4.6.1 中出現逐一查看行為,但舊版本中並未出現 (亦即,如果 System.Windows.Controls.ItemsControl 是在具有不同像素高度之項目的簡單列表中進行項目捲動),則有兩種解決方式:If the iteration occurs in .NET Framework 4.6.1 but not in earlier releases - that is, if the System.Windows.Controls.ItemsControl is item- scrolling a flat list with items of different pixel height - there are two remedies:

  1. 安裝 .NET Framework 4.6.2。Install .NET Framework 4.6.2.
  2. 安裝 .NET Framework 4.6.1 的 Hotfix HR 1605。Install hotfix HR 1605 for .NET Framework 4.6.1.

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

受影響的 APIAffected APIs

RibbonGroup 背景在當地語系化組建中設定為透明RibbonGroup background is set to transparent in localized builds

詳細資料Details

當地語系化組建中的 System.Windows.Controls.Ribbon.RibbonGroup 背景一律使用透明筆刷繪製,導致不良的 UI 使用體驗。System.Windows.Controls.Ribbon.RibbonGroup background on localized builds was always painted with Transparent brush, resulting in poor UI experience. 此問題已在 .NET Framework 4.7 WPF 修正程式中透過更新 System.Windows.Controls.Ribbon.RibbonGroup 的當地語系化資源來修正,而這可確保已選取正確的筆刷。This is fixed in .NET Framework 4.7 WPF fix by updating the localized resources for System.Windows.Controls.Ribbon.RibbonGroup, which in turn ensures that the correct brush is selected.

建議Suggestion

升級至 .NET Framework 4.7Upgrade to .NET Framework 4.7

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

受影響的 APIAffected APIs

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

WPF 拼字檢查以非預期的方式失敗WPF Spell Checking fails in unexpected ways

詳細資料Details

這包括一些 WPF 拼字檢查工具問題:This includes a number of WPF Spell Checker issues:

建議Suggestion

問題 #1 - 此問題已在 .NET Framework 4.6.2 中修正。問題 #2 - 使用 [以不同的使用者身分執行] 來啟動應用程式時,不再支援 WPF 拼字檢查工具。Issue #1 - This has been fixed in .NET Framework 4.6.2 Issue #2 - WPF Spell Checker is no longer supported when applications are launched using 'run as different user'. 從 .NET Framework 4.6.2 開始,以這種方式啟動的應用程式將不會再意外損毀 - 而是以無訊息的方式停用拼字檢查工具。Starting .NET Framework 4.6.2, applications launched in this manner will no longer crash unexpectedly - instead the Spell Checker will be silently disabled. 問題 #3 - 此問題已在 .NET Framework 4.6.2 中修正。Issue #3 - This has been fixed in .NET Framework 4.6.2.

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

受影響的 APIAffected APIs

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