移轉至 .NET Framework 4.7.x 時的執行階段變更
本文列出 .NET Framework 4.7、4.7.1 和 4.7.2 中介紹的應用程式相容性問題。
.NET Framework 4.7
JIT
傳遞和比較 UInt16 值時，產生不正確的程式碼
詳細資料
由於 .NET Framework 4.7 中引入的變更，在某些情況下，JIT 編譯器在執行於 .NET Framework 4.7 上的應用程式中所產生的程式碼會錯誤地比較兩個 T:System.UInt16 值。 如需詳細資訊，請參閱 GitHub.com 上的 Issue #11508: Silent bad codegen when passing and comparing ushort argss (問題 #11508：傳遞和比較 ushort 引數時無訊息的錯誤 codegen)。
建議
如果您在 .NET Framework 4.7 中比較 16 位元不帶正負號的值時遇到問題，請升級至 .NET Framework 4.7.1。
| 名稱 | 值 |
|---|---|
| 範圍 | Edge |
| 版本 | 4.7 |
| 類型 | 執行階段 |
受影響的 API
無法透過 API 分析偵測。
Windows Presentation Foundation (WPF)
從自訂 INCC 集合中移除項目時，選取器發生損毀
詳細資料
在下列狀況中可能發生 T:System.InvalidOperationException：
T:System.Windows.Controls.Primitives.Selector的 ItemsSource 是具有T:System.Collections.Specialized.INotifyCollectionChanged自訂實作的集合。- 已從集合中移除選取的項目。
T:System.Collections.Specialized.NotifyCollectionChangedEventArgs具有P:System.Collections.Specialized.NotifyCollectionChangedEventArgs.OldStartingIndex= -1 (表示未知的位置)。
例外狀況的呼叫堆疊會從 at System.Windows.Threading.Dispatcher.VerifyAccess() at System.Windows.DependencyObject.GetValue(DependencyProperty dp) at System.Windows.Controls.Primitives.Selector.GetIsSelected(DependencyObject element) 開始。 如果應用程式有多個 Dispatcher 執行緒，.NET Framework 4.5 可能會發生此例外狀況。 在 .NET Framework 4.7 中，具有單一發送器執行緒的應用程式也可能會發生此例外狀況。
此問題已在 .NET Framework 4.7.1 中修正。
建議
升級至 .NET Framework 4.7.1。
| 名稱 | 值 |
|---|---|
| 範圍 | Minor |
| 版本 | 4.7 |
| 類型 | 執行階段 |
受影響的 API
無法透過 API 分析偵測。
DataGridCellsPanel.BringIndexIntoView 擲回 ArgumentOutOfRangeException
詳細資料
啟用資料行虛擬化，但尚未決定資料行寬度時，ScrollIntoView(Object) 將以非同步方式運作。 如果資料行在非同步工作進行之前遭到移除，會發生 System.ArgumentOutOfRangeException。
建議
下列任一步驟：
- 升級至 .NET Framework 4.7。
- 為 .NET Framework 4.6.2 安裝最新的服務修補程式。
- 在 ScrollIntoView(Object) 的非同步回應完成之前，避免移除資料行。
| 名稱 | 值 |
|---|---|
| 範圍 | Edge |
| 版本 | 4.6.2 |
| 類型 | 執行階段 |
受影響的 API
WPF 拼字檢查功能所擲回的 ObjectDisposedException
詳細資料
在應用程式關閉期間，WPF 應用程式偶爾會因拼字檢查功能所擲回的 System.ObjectDisposedException 而損毀。 此問題已在 .NET Framework 4.7 WPF 中透過依正常程序處理例外狀況來修正，進而確保應用程式不會再受到負面影響。 請注意，在偵錯工具下執行的應用程式偶爾還是會發生第一個例外狀況。
建議
升級至 .NET Framework 4.7
| 名稱 | 值 |
|---|---|
| 範圍 | Edge |
| 版本 | 4.6.1 |
| 類型 | 執行階段 |
受影響的 API
無法透過 API 分析偵測。
調整格線大小可能會導致應用程式停止回應
詳細資料
在下列情況下，T:System.Windows.Controls.Grid 配置期間可能會發生無限迴圈：
- 資料列定義包含兩個 *-row，這兩個都會宣告 MinHeigh 和 MaxHeight。
- *-row 的內容不會超過對應的 MaxHeight。
- 第一個 MinHeight (加上任何其他固定或自動的資料列) 超過方格的可用高度。
- 應用程式將目標設為 .NET Framework 4.7，或藉由下列設定
Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=false加入 4.7 配置演算法。
有兩個以上的資料列時或在類似的資料行案例中也會發生此迴圈。 此問題已在 .NET Framework 4.7.1 中修正。
建議
升級至 .NET Framework 4.7.1。 或者，如果您不需要 4.7 配置演算法，可以使用下列組態設定：
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>
| 名稱 | 值 |
|---|---|
| 範圍 | Edge |
| 版本 | 4.7 |
| 類型 | 執行階段 |
受影響的 API
無法透過 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 列印堆疊更新
詳細資料
使用 System.Printing.PrintQueue 的 WPF 列印 API 現在會呼叫 Windows 的列印文件套件 API，以支援目前已淘汰的 XPS 列印 API。 進行這項變更是考慮到服務能力；使用者和開發人員都不應該會看到行為或 API 使用方式中有任何變更。 在 Windows 10 Creators Update 中執行時，預設會啟用新的列印堆疊。 舊版 Windows 上的舊列印堆疊仍會繼續如往常一般運作。
建議
若要在 Windows 10 Creators Update 中使用舊堆疊，請將 HKEY_CURRENT_USER\Software\Microsoft\.NETFramework\Windows Presentation Foundation\Printing 登錄機碼的 UseXpsOMPrinting REG_DWORD 值設為 1。
| 名稱 | 值 |
|---|---|
| 範圍 | Edge |
| 版本 | 4.7 |
| 類型 | 執行階段 |
受影響的 API
無法透過 API 分析偵測。
Windows Workflow Foundation (WF)
在某些情況下，工作流程現在會擲回原始例外狀況，而不是 NullReferenceException
詳細資料
在 .NET Framework 4.6.2 和舊版中，工作流程活動的 Execute 方法擲回 Message 屬性為 null 值的例外狀況時，System.Activities 工作流程執行階段會擲回 System.NullReferenceException，進而遮罩原始的例外狀況。在 .NET Framework 4.7 中，會擲回之前遮罩的例外狀況。
建議
如果您的程式碼依賴處理 System.NullReferenceException，請將它變更為攔截可能會從自訂活動擲回的例外狀況。
| 名稱 | 值 |
|---|---|
| 範圍 | Minor |
| 版本 | 4.7 |
| 類型 | 執行階段 |
受影響的 API
- CodeActivity.Execute(CodeActivityContext)
- AsyncCodeActivity.BeginExecute(AsyncCodeActivityContext, AsyncCallback, Object)
- AsyncCodeActivity<TResult>.BeginExecute(AsyncCodeActivityContext, AsyncCallback, Object)
- WorkflowInvoker.Invoke()
工作流程 SQL 持續性會新增叢集主索引鍵，且在某些資料行中不允許有 Null 值
詳細資料
從 .NET Framework 4.7 開始，SqlWorkflowInstanceStoreSchema.sql 指令碼針對 SQL 工作流程執行個體存放區 (SWIS) 所建立的資料表使用叢集主索引鍵。 因此，識別不支援 null 值。 SWIS 的作業不會受到這項變更影響。 已進行更新以支援 SQL Server 異動複寫。
建議
必須將 SQL 檔案 SqlWorkflowInstanceStoreSchemaUpgrade.sql 套用到現有安裝，才能體驗這項變更。 新的資料庫安裝將會自動進行此變更。
| 名稱 | 值 |
|---|---|
| 範圍 | Edge |
| 版本 | 4.7 |
| 類型 | 執行階段 |
受影響的 API
無法透過 API 分析偵測。
.NET Framework 4.7.1
JIT
傳遞和比較 UInt16 值時，產生不正確的程式碼
詳細資料
由於 .NET Framework 4.7 中引入的變更，在某些情況下，JIT 編譯器在執行於 .NET Framework 4.7 上的應用程式中所產生的程式碼會錯誤地比較兩個 T:System.UInt16 值。 如需詳細資訊，請參閱 GitHub.com 上的 Issue #11508: Silent bad codegen when passing and comparing ushort argss (問題 #11508：傳遞和比較 ushort 引數時無訊息的錯誤 codegen)。
建議
如果您在 .NET Framework 4.7 中比較 16 位元不帶正負號的值時遇到問題，請升級至 .NET Framework 4.7.1。
| 名稱 | 值 |
|---|---|
| 範圍 | Edge |
| 版本 | 4.7 |
| 類型 | 執行階段 |
受影響的 API
無法透過 API 分析偵測。
安全性
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)
Windows Communication Foundation (WCF)
如果 addressHeader 項目為 Null，WCF AddressHeaderCollection 現在會擲回 ArgumentException
詳細資料
從 .NET Framework 4.7.1 開始，如果其中一個項目是 null，AddressHeaderCollection(IEnumerable<AddressHeader>) 建構函式會擲回 ArgumentException。 在 .NET Framework 4.7 和舊版中，不會擲回任何例外狀況。
建議
如果在 .NET Framework 4.7.1 或更新版本上遇到這項變更的相容性問題，您可以在 app.config 檔案的 <runtime> 區段中新增下列程式行來退出變更：
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableAddressHeaderCollectionValidation=true" />
</runtime>
</configuration>
| 名稱 | 值 |
|---|---|
| 範圍 | Minor |
| 版本 | 4.7.1 |
| 類型 | 執行階段 |
受影響的 API
WCF MsmqSecureHashAlgorithm 預設值現在是 SHA256
詳細資料
從 .NET Framework 4.7.1 開始，WCF 中用於 Msmq 訊息的預設訊息簽署演算法是 SHA256。 在 .NET Framework 4.7 和舊版中，預設的訊息簽署演算法是 SHA1。
建議
如果在 .NET Framework 4.7.1 或更新版本上遇到這項變更的相容性問題，您可以在 app.config 檔案的 <runtime> 區段中新增下列程式行來退出變更：
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.UseSha1InMsmqEncryptionAlgorithm=true" />
</runtime>
</configuration>
| 名稱 | 值 |
|---|---|
| 範圍 | Minor |
| 版本 | 4.7.1 |
| 類型 | 執行階段 |
受影響的 API
無法透過 API 分析偵測。
WCF PipeConnection.GetHashAlgorithm 現在會使用 SHA256
詳細資料
從 .NET Framework 4.7.1 開始，Windows Communication Foundation 會使用 SHA256 雜湊來產生具名管道的隨機名稱。 在 .NET Framework 4.7 和舊版中，它已使用 SHA1 雜湊。
建議
如果在 .NET Framework 4.7.1 或更新版本上遇到這項變更的相容性問題，您可以在 app.config 檔案的 <runtime> 區段中新增下列程式行來退出變更：
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.UseSha1InPipeConnectionGetHashAlgorithm=true" />
</runtime>
</configuration>
| 名稱 | 值 |
|---|---|
| 範圍 | Minor |
| 版本 | 4.7.1 |
| 類型 | 執行階段 |
受影響的 API
無法透過 API 分析偵測。
Windows Presentation Foundation (WPF)
StaysOpen=False 時的鏈結快顯視窗
詳細資料
當您按一下 StaysOpen=False 快顯視窗的外部時，該快顯視窗應該要關閉。 當兩個或多個這類快顯視窗鏈結在一起 (也就是其中一個包含另一個) 時，會發生許多問題，包括：
- 開啟兩個層級，按一下 P2 外部 (但在 P1 內部)。 不會發生任何情況。
- 開啟兩個層級，按一下 P1 外部。 這兩個快顯視窗會關閉。
- 開啟及關閉兩個層級。 然後嘗試再次開啟 P2。 不會發生任何情況。
- 嘗試開啟三個層級。 你無此權限。 (根據您在其中按一下的位置，不會執行任何動作或是會關閉前兩個層級。)
這些案例 (以及其他變化) 現在可如預期般運作。
| 名稱 | 值 |
|---|---|
| 範圍 | Edge |
| 版本 | 4.7.1 |
| 類型 | 執行階段 |
受影響的 API
從自訂 INCC 集合中移除項目時，選取器發生損毀
詳細資料
在下列狀況中可能發生 T:System.InvalidOperationException：
T:System.Windows.Controls.Primitives.Selector的 ItemsSource 是具有T:System.Collections.Specialized.INotifyCollectionChanged自訂實作的集合。- 已從集合中移除選取的項目。
T:System.Collections.Specialized.NotifyCollectionChangedEventArgs具有P:System.Collections.Specialized.NotifyCollectionChangedEventArgs.OldStartingIndex= -1 (表示未知的位置)。
例外狀況的呼叫堆疊會從 at System.Windows.Threading.Dispatcher.VerifyAccess() at System.Windows.DependencyObject.GetValue(DependencyProperty dp) at System.Windows.Controls.Primitives.Selector.GetIsSelected(DependencyObject element) 開始。 如果應用程式有多個 Dispatcher 執行緒，.NET Framework 4.5 可能會發生此例外狀況。 在 .NET Framework 4.7 中，具有單一發送器執行緒的應用程式也可能會發生此例外狀況。
此問題已在 .NET Framework 4.7.1 中修正。
建議
升級至 .NET Framework 4.7.1。
| 名稱 | 值 |
|---|---|
| 範圍 | Minor |
| 版本 | 4.7 |
| 類型 | 執行階段 |
受影響的 API
無法透過 API 分析偵測。
調整格線大小可能會導致應用程式停止回應
詳細資料
在下列情況下，T:System.Windows.Controls.Grid 配置期間可能會發生無限迴圈：
- 資料列定義包含兩個 *-row，這兩個都會宣告 MinHeigh 和 MaxHeight。
- *-row 的內容不會超過對應的 MaxHeight。
- 第一個 MinHeight (加上任何其他固定或自動的資料列) 超過方格的可用高度。
- 應用程式將目標設為 .NET Framework 4.7，或藉由下列設定
Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=false加入 4.7 配置演算法。
有兩個以上的資料列時或在類似的資料行案例中也會發生此迴圈。 此問題已在 .NET Framework 4.7.1 中修正。
建議
升級至 .NET Framework 4.7.1。 或者，如果您不需要 4.7 配置演算法，可以使用下列組態設定：
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>
| 名稱 | 值 |
|---|---|
| 範圍 | Edge |
| 版本 | 4.7 |
| 類型 | 執行階段 |
受影響的 API
無法透過 API 分析偵測。
.NET Framework 4.7.2
核心
允許在與 UNC 共用相似的 URI 中使用 Unicode
詳細資料
在 System.Uri 中，若您建構的檔案 URI 同時包含 UNC 共用名稱和 Unicode 字元時，不會再導致 URI 出現無效的內部狀態。 這項行為只有在下列所有條件都符合時才會變更：
- URI 具有
file:配置，且後接 4 條以上的斜線。 - 主機名稱開頭為底線或其他非保留符號。
- URI 包含 Unicode 字元。
建議
如果應用程式使用的 URI 始終包含 Unicode，可想而知，該應用程式會使用這項行為來禁止參考 UNC 共用。 因此，這類應用程式應該改用 IsUnc。
| 名稱 | 值 |
|---|---|
| 範圍 | Edge |
| 版本 | 4.7.2 |
| 類型 | 執行階段 |
受影響的 API
Unicode 存在時，支援特殊的相對 URI 標記法
詳細資料
在包含 Unicode 的特定相對 URI 呼叫 TryCreate 時，Uri 不再擲回 NullReferenceException。 NullReferenceException 最簡單的重現如下，其中兩個陳述式相等：
bool success = Uri.TryCreate("http:%C3%A8", UriKind.RelativeOrAbsolute, out Uri href);
bool success = Uri.TryCreate("http:è", UriKind.RelativeOrAbsolute, out Uri href);
若要重現 NullReferenceException，必須符合下列項目：
- 若要指定 URI 為相對，前面必須加上 'http:'，且其後不加 '//'。
- URI 必須包含百分比編碼的 Unicode 或未保留的符號。
建議
根據此行為不允許相對 URI 的使用者，在建立 URI 時應該改指定 UriKind.Absolute。
| 名稱 | 值 |
|---|---|
| 範圍 | Edge |
| 版本 | 4.7.2 |
| 類型 | 執行階段 |
受影響的 API
執行階段
針對 Net.Tcp 憑證驗證改善的 WCF 鏈結信任憑證驗證
詳細資料
.NET Framework 4.7.2 若以傳輸安全性搭配 WCF 使用憑證驗證，就可以改善鏈結信任憑證驗證。 利用這項改善，必須針對用戶端驗證設定用來驗證伺服器的用戶端憑證。 同樣地，必須針對伺服器驗證設定用來驗證伺服器的伺服器憑證。 利用這項變更，如果已停用根憑證，憑證鏈結驗證就會失敗。 同時，已透過 Windows 安全性彙總對 .NET Framework 3.5 和更新版本進行了相同的變更。 您可以在這裡找到更多資訊。這項變更預設為開啟，而且可以透過組態設定加以關閉。
建議
驗證您的伺服器和用戶端憑證是否具有必要的 EKU OID。 如果沒有，請更新您的憑證。
驗證您的根憑證是否無效。 如果是，請更新根憑證。
如果您無法更新憑證，您可使用下列組態設定暫時繞過中斷性變更。 不過，退出變更會使您的系統容易受到安全性問題的影響。
<appSettings> <add key="wcf:useLegacyCertificateUsagePolicy" value="true" /> </appSettings>
| 名稱 | 值 |
|---|---|
| 範圍 | Minor |
| 版本 | 4.7.2 |
| 類型 | 執行階段 |
受影響的 API
無法透過 API 分析偵測。
Web 應用程式
"dataAnnotations:dataTypeAttribute:disableRegEx" 應用程式設定，在 .NET Framework 4.7.2 中預設會開啟
詳細資料
在 .NET Framework 4.6.1 中，提供了應用程式設定 (dataAnnotations:dataTypeAttribute:disableRegEx)，可讓使用者能停用在資料類型屬性 (例如 System.ComponentModel.DataAnnotations.EmailAddressAttribute、System.ComponentModel.DataAnnotations.UrlAttribute 及 System.ComponentModel.DataAnnotations.PhoneAttribute) 中使用規則運算式。 如此有助於降低安全性弱點，例如避免發生使用特定規則運算式的拒絕服務攻擊之可能性。
在 .NET Framework 4.6.1 中，停用使用 RegEx 的此應用程式設定，預設會設為 false。 從 .NET Framework 4.7.2 開始，此組態參數預設會設為 true，以進一步降低鎖定 .NET Framework 4.7.2 及更新版本為目標的 Web 應用程式之安全弱點。
建議
若您發現您 Web 應用程式中的規則運算式，在升級至 .NET Framework 4.7.2 之後無法運作，可將 dataAnnotations:dataTypeAttribute:disableRegEx 設定的值，更新為 false，以還原為先前的行為。
<configuration>
<appSettings>
...
<add key="dataAnnotations:dataTypeAttribute:disableRegEx" value="false"/>
...
</appSettings>
</configuration>
| 名稱 | 值 |
|---|---|
| 範圍 | Minor |
| 版本 | 4.7.2 |
| 類型 | 執行階段 |
受影響的 API
無法透過 API 分析偵測。
Windows Presentation Foundation (WPF)
已改進 WPF 中的按鍵提示行為
詳細資料
按鍵提示行為已經過修改，讓 Microsoft Word 與 Windows 檔案總管之間的行為趨於一致。 WPF 會藉由查看是否已啟用按鍵提示狀態，或是並非按下 SystemKey (特別是 Key 或 F11) 的情況，正確地處理按鍵提示的按鍵。 現在即使滑鼠已開啟了按鍵提示，其仍會關閉功能表。
建議
N/A
| 名稱 | 值 |
|---|---|
| 範圍 | Edge |
| 版本 | 4.7.2 |
| 類型 | 執行階段 |
受影響的 API
無法透過 API 分析偵測。
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應