.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 で変更が導入されたため、.NET Framework 4.7 で実行されているアプリケーションの JIT コンパイラによって生成されたコードが 2 つの T:System.UInt16 値を正しく比較しない場合があります。 詳細については、GitHub.com の「Issue #11508: Silent bad codegen when passing and comparing ushort args」 (問題 #11508: ushort の引数を渡して比較する場合のサイレントかつ不適切な codegen ) を参照してください。
提案される解決策
.NET Framework 4.7 で 16 ビットの符号なし値を比較したときに問題が検出された場合は、.NET Framework 4.7.1 にアップグレードしてください。
| 名前 | 値 |
|---|---|
| スコープ | エッジ |
| バージョン | 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) から始まります。 この例外は、アプリケーションに複数のディスパッチャー スレッドがある場合に、.NET Framework 4.5 で発生する可能性があります。 .NET Framework 4.7 では、1 つのディスパッチャー スレッドのアプリケーションでも例外が発生する場合があります。
この問題は .NET Framework 4.7.1 で修正されます。
提案される解決策
.NET Framework 4.7.1 にアップグレードします。
| 名前 | 値 |
|---|---|
| スコープ | マイナー |
| バージョン | 4.7 |
| 種類 | ランタイム |
影響を受ける API
API 分析では検出できません。
DataGridCellsPanel.BringIndexIntoView で ArgumentOutOfRangeException がスローされる
詳細
列の仮想化は有効になっているが、列の幅がまだ決定されていない場合、ScrollIntoView(Object) は非同期で動作します。 非同期動作が発生する前に列が削除されると、System.ArgumentOutOfRangeException が発生する場合があります。
推奨事項
以下のいずれかを実行してください。
- .NET Framework 4.7 にアップグレードします。
- .NET Framework 4.6.2 の最新のサービス パッチをインストールします。
- ScrollIntoView(Object) に対する非同期応答が完了するまでは列を削除しないようにする。
| 名前 | 値 |
|---|---|
| スコープ | エッジ |
| バージョン | 4.6.2 |
| 種類 | ランタイム |
影響を受ける API
ObjectDisposedException が WPF スペルチェックでスローされる
説明
スペルチェックで System.ObjectDisposedException がスローされ、WPF アプリケーションがシャットダウン時にクラッシュする場合があります。 これは .NET Framework 4.7 WPF で修正されます。例外は正しく処理されるため、アプリケーションが悪影響を受けることはなくなります。 ただし、デバッグ時に実行中のアプリケーションで初回例外が見られる場合があるので注意してください。
提案される解決策
.NET Framework 4.7 にアップグレードします
| 名前 | 値 |
|---|---|
| スコープ | エッジ |
| バージョン | 4.6.1 |
| 種類 | ランタイム |
影響を受ける API
API 分析では検出できません。
グリッドのサイズを変更するとアプリケーションが応答しなくなることがある
説明
次の状況では、T:System.Windows.Controls.Grid のレイアウト中に無限ループが発生する可能性があります。
- 行の定義に、MinHeight と MaxHeight の両方を宣言する、2 つの * 行が含まれている。
- *-row の内容が対応する MaxHeight を超えていない。
- 最初の MinHeight (その他の固定または自動の行を含む) がグリッドの利用可能な高さを超えている。
- アプリの対象を .NET Framework 4.7 とする、または
Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=falseを設定して、4.7 割り当てアルゴリズムを利用することを選択する。
また、3 つ以上の行または列でループが発生します。 この問題は .NET Framework 4.7.1 で修正されます。
提案される解決策
.NET Framework 4.7.1 にアップグレードします。 4\.7 割り当てアルゴリズムが必要でない場合は、次の構成設定を使用することもできます。
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>
| 名前 | 値 |
|---|---|
| スコープ | エッジ |
| バージョン | 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 にアップグレードします
| 名前 | 値 |
|---|---|
| スコープ | エッジ |
| バージョン | 4.6.2 |
| 種類 | ランタイム |
影響を受ける API
API 分析では検出できません。
WPF での印刷スタックの更新
詳細
System.Printing.PrintQueue を使う WPF の印刷 API は、非推奨になった XPS 印刷 API ではなく Windows ドキュメント印刷パッケージ 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 に設定します。
| 名前 | 値 |
|---|---|
| スコープ | エッジ |
| バージョン | 4.7 |
| 種類 | ランタイム |
影響を受ける API
API 分析では検出できません。
Windows Workflow Foundation (WF)
場合によって、ワークフローで NullReferenceException ではなく、元の例外がスローされるようになった
詳細
.NET Framework 4.6.2 ワークフロー アクティビティの Execute メソッドを使用して例外をスローした場合、以前のバージョンで、null値をMessageプロパティ、System.Activities ワークフロー ランタイムは、スロー、 System.NullReferenceException、マスク、元の例外。 .NET Framework 4.7 以前マスクは、例外がスローされます。
推奨事項
コードが System.NullReferenceException の処理に依存する場合は、カスタム アクティビティからスローされる可能性のある例外をキャッチするように変更します。
| 名前 | 値 |
|---|---|
| スコープ | マイナー |
| バージョン | 4.7 |
| 種類 | ランタイム |
影響を受ける API
- CodeActivity.Execute(CodeActivityContext)
- AsyncCodeActivity.BeginExecute(AsyncCodeActivityContext, AsyncCallback, Object)
- AsyncCodeActivity<TResult>.BeginExecute(AsyncCodeActivityContext, AsyncCallback, Object)
- WorkflowInvoker.Invoke()
Workflow SQL の永続化で主キー クラスターが追加され、一部の列の null 値が許可されない
詳細
.NET Framework 4.7 以降では、SqlWorkflowInstanceStoreSchema.sql スクリプトで SQL Workflow Instance Store (SWIS) に作成されたテーブルにはクラスター化された主キーが使用されます。 そのため、ID では null 値はサポートされません。 SWIS の操作には、この変更による影響はありません。 SQL Server トランザクション レプリケーションをサポートするように更新されました。
推奨事項
この変更では、SQL ファイルの SqlWorkflowInstanceStoreSchemaUpgrade.sql を既存のインストールに適用する必要があります。 新しいデータベースのインストールは自動的に変更されます。
| 名前 | 値 |
|---|---|
| スコープ | エッジ |
| バージョン | 4.7 |
| 種類 | ランタイム |
影響を受ける API
API 分析では検出できません。
.NET Framework 4.7.1
JIT
UInt16 値を渡して比較する場合にコード生成が正しく行われません
詳細
.NET Framework 4.7 で変更が導入されたため、.NET Framework 4.7 で実行されているアプリケーションの JIT コンパイラによって生成されたコードが 2 つの T:System.UInt16 値を正しく比較しない場合があります。 詳細については、GitHub.com の「Issue #11508: Silent bad codegen when passing and comparing ushort args」 (問題 #11508: ushort の引数を渡して比較する場合のサイレントかつ不適切な codegen ) を参照してください。
提案される解決策
.NET Framework 4.7 で 16 ビットの符号なし値を比較したときに問題が検出された場合は、.NET Framework 4.7.1 にアップグレードしてください。
| 名前 | 値 |
|---|---|
| スコープ | エッジ |
| バージョン | 4.7 |
| 種類 | ランタイム |
影響を受ける API
API 分析では検出できません。
セキュリティ
部分信頼のシナリオで RSACng と DSACng が再び使用可能に
詳細
CngLightup (System.Security.Cryptography.Xml.EncryptedXml などの複数の上位レベル暗号化 API で使われます) および 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 にアップグレードしてください。
| 名前 | 値 |
|---|---|
| スコープ | エッジ |
| バージョン | 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>
| 名前 | 値 |
|---|---|
| スコープ | マイナー |
| バージョン | 4.7.1 |
| 種類 | ランタイム |
影響を受ける API
WCF MsmqSecureHashAlgorithm の既定値が SHA256 になった
説明
.NET Framework 4.7.1 以降では、Msmq メッセージの WCF での既定のメッセージ署名アルゴリズムは 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>
| 名前 | 値 |
|---|---|
| スコープ | マイナー |
| バージョン | 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>
| 名前 | 値 |
|---|---|
| スコープ | マイナー |
| バージョン | 4.7.1 |
| 種類 | ランタイム |
影響を受ける API
API 分析では検出できません。
Windows Presentation Foundation (WPF)
StaysOpen=False でポップアップがチェーンされる
説明
ポップアップの外側をクリックすると、StaysOpen=False のポップアップが閉じられることが想定されます。 このような 2 つ以上のポップアップがチェーンされている (つまり、1 つに別のものが含まれている) 場合、次のような、多くの問題が発生します。
- 2 つのレベルを開き、P2 の外側と、P1 の内側をクリックします。 何も起こりません。
- 2 つのレベルを開き、P1 の外側をクリックします。 両方のポップアップが閉じます。
- 2 つのレベルを開いて閉じます。 次に、P2 をもう一度開いてみます。 何も起こりません。
- 3 つのレベルを開いてみます。 この操作を行うことはできません (クリックする場所に応じて、何も起こらないか、最初の 2 つのレベルが閉じます)。
このような場合 (および他のバリアント) は、予期したとおり動作します。
| 名前 | 値 |
|---|---|
| スコープ | エッジ |
| Version | 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) から始まります。 この例外は、アプリケーションに複数のディスパッチャー スレッドがある場合に、.NET Framework 4.5 で発生する可能性があります。 .NET Framework 4.7 では、1 つのディスパッチャー スレッドのアプリケーションでも例外が発生する場合があります。
この問題は .NET Framework 4.7.1 で修正されます。
提案される解決策
.NET Framework 4.7.1 にアップグレードします。
| 名前 | 値 |
|---|---|
| スコープ | マイナー |
| バージョン | 4.7 |
| 種類 | ランタイム |
影響を受ける API
API 分析では検出できません。
グリッドのサイズを変更するとアプリケーションが応答しなくなることがある
説明
次の状況では、T:System.Windows.Controls.Grid のレイアウト中に無限ループが発生する可能性があります。
- 行の定義に、MinHeight と MaxHeight の両方を宣言する、2 つの * 行が含まれている。
- *-row の内容が対応する MaxHeight を超えていない。
- 最初の MinHeight (その他の固定または自動の行を含む) がグリッドの利用可能な高さを超えている。
- アプリの対象を .NET Framework 4.7 とする、または
Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=falseを設定して、4.7 割り当てアルゴリズムを利用することを選択する。
また、3 つ以上の行または列でループが発生します。 この問題は .NET Framework 4.7.1 で修正されます。
提案される解決策
.NET Framework 4.7.1 にアップグレードします。 4\.7 割り当てアルゴリズムが必要でない場合は、次の構成設定を使用することもできます。
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>
| 名前 | 値 |
|---|---|
| スコープ | エッジ |
| バージョン | 4.7 |
| 種類 | ランタイム |
影響を受ける API
API 分析では検出できません。
.NET Framework 4.7.2
コア
UNC 共有に似た URI での Unicode の許可
説明
System.Uri では、UNC 共有名と Unicode 文字の両方を含むファイル URI の構築時に、URI が無効な内部状態にならなくなります。 以下のすべてに該当する場合にのみ、動作が変わります。
- URI にスキーム
file:があり、4 つ以上のスラッシュが続く。 - ホスト名がアンダースコアまたはその他の予約されていないシンボルで始まる。
- URI に Unicode 文字が含まれている。
提案される解決策
Unicode を含む URI を一貫して操作するアプリケーションでこの動作を使用して、UNC 共有への参照を許可しないようにした可能性があります。 これらのアプリケーションでは代わりに IsUnc を使用する必要があります。
| 名前 | 値 |
|---|---|
| スコープ | エッジ |
| バージョン | 4.7.2 |
| 種類 | ランタイム |
影響を受ける API
Unicode が存在する場合の特別な相対 URI 表記のサポート
説明
Uri では、Unicode を含む特定の相対 URI で TryCreate を呼び出したときに、NullReferenceException がスローされなくなります。 NullReferenceException の最も単純な再現を以下に示します。2 つのステートメントは同等です。
bool success = Uri.TryCreate("http:%C3%A8", UriKind.RelativeOrAbsolute, out Uri href);
bool success = Uri.TryCreate("http:è", UriKind.RelativeOrAbsolute, out Uri href);
NullReferenceException を再現するには、次の項目が true である必要があります。
- URI は、前に 'http:' を付加し、その後に '//' を付けずに相対として指定する必要があります。
- URI には、パーセントでエンコードされた Unicode または予約されていないシンボルを含める必要があります。
提案される解決策
相対 URI を許可しないようにするためにこの動作に依存しているユーザーは、URI の作成時に代わりに UriKind.Absolute を指定する必要があります。
| 名前 | 値 |
|---|---|
| スコープ | エッジ |
| バージョン | 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>
| 名前 | 値 |
|---|---|
| スコープ | マイナー |
| バージョン | 4.7.2 |
| 種類 | ランタイム |
影響を受ける API
API 分析では検出できません。
Web アプリケーション
.NET Framework 4.7.2 で "dataAnnotations:dataTypeAttribute:disableRegEx" アプリ設定が既定で有効になっている
説明
.NET framework 4.6.1 で、データ型属性 (System.ComponentModel.DataAnnotations.EmailAddressAttribute、System.ComponentModel.DataAnnotations.UrlAttribute、System.ComponentModel.DataAnnotations.PhoneAttribute など) で正規表現の使用を無効にするアプリ設定 (dataAnnotations:dataTypeAttribute:disableRegEx) が導入されました。 これにより、特定の正規表現を使用するサービス拒否攻撃の可能性を回避できるなど、セキュリティの脆弱性を軽減できます。
.NET Framework 4.6.1 で、正規表現の使用を無効にするこのアプリ設定が、既定で false に設定されました。 .NET Framework 4.7.2 からは、この構成スイッチが既定で true に設定され、.NET Framework 4.7.2 以降を対象とする Web アプリケーションのセキュリティの脆弱性がさらに軽減されています。
提案される解決策
.NET Framework 4.7.2 へのアップグレード後に Web アプリケーションの正規表現が動作しない場合は、dataAnnotations:dataTypeAttribute:disableRegEx 設定の値を false に更新して以前の動作に戻すことができます。
<configuration>
<appSettings>
...
<add key="dataAnnotations:dataTypeAttribute:disableRegEx" value="false"/>
...
</appSettings>
</configuration>
| 名前 | 値 |
|---|---|
| スコープ | マイナー |
| バージョン | 4.7.2 |
| 種類 | ランタイム |
影響を受ける API
API 分析では検出できません。
Windows Presentation Foundation (WPF)
WPF での KeyTip の動作が改良された
説明
KeyTip の動作が、Microsoft Word やエクスプローラーでの動作と同等に変更されています。 SystemKey (具体的には Key または F11) が押された場合に KeyTip の状態が有効かどうかを調べることによって、WPF は KeyTip キーを適切に処理します。 メニューがマウスによって開かれている場合でも、KeyTip はメニューを閉じるようになっています。
提案される解決策
N/A
| 名前 | 値 |
|---|---|
| スコープ | エッジ |
| バージョン | 4.7.2 |
| 種類 | ランタイム |
影響を受ける API
API 分析では検出できません。
.NET
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示