.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の問題 #11508: ushort 引数を渡して比較するときに発生するサイレントの不良なコード生成をご覧ください。

提案

.NET Framework 4.7 で 16 ビット符号なし値の比較で問題が発生した場合は、.NET Framework 4.7.1 にアップグレードします。

影響を受ける API

API 分析では検出できません。

Windows プレゼンテーション ファンデーション (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 では、単一のディスパッチャー スレッドを持つアプリケーションでも例外が発生する可能性があります。

この問題は、.NET Framework 4.7.1 で修正されています。

提案

.NET Framework 4.7.1 にアップグレードします。

影響を受ける API

API 分析では検出できません。

DataGridCellsPanel.BringIndexIntoView が ArgumentOutOfRangeException をスローする

詳細

ScrollIntoView(Object) は、列の仮想化が有効になっているが、列の幅がまだ決定されていない場合に非同期的に動作します。 非同期処理が行われる前に列が削除されると、 System.ArgumentOutOfRangeException が発生する可能性があります。

提案

次のいずれか 1 つ。

• .NET Framework 4.7 にアップグレードします。
• .NET Framework 4.6.2 の最新のサービス パッチをインストールします。
• ScrollIntoView(Object)への非同期応答が完了するまで、列の削除は避けてください。

影響を受ける API

• DataGrid.ScrollIntoView(Object)
• DataGrid.ScrollIntoView(Object, DataGridColumn)

WPF スペルチェックによってスローされる ObjectDisposedException

詳細

WPF アプリケーションは、アプリケーションのシャットダウン中に、スペルチェックによってスローされた System.ObjectDisposedException によりクラッシュすることがあります。 これは、例外を適切に処理し、アプリケーションが悪影響を受けなくなったことを確認することで、.NET Framework 4.7 WPF で修正されています。 デバッガーで実行されているアプリケーションでは、不定期の初回例外が引き続き観察される点に注意してください。

提案

.NET Framework 4.7 へのアップグレード

影響を受ける API

API 分析では検出できません。

Grid のサイズを変更すると、アプリケーションが応答しなくなる可能性があります

詳細

無限ループは、次の状況で T:System.Windows.Controls.Grid のレイアウト中に発生する可能性があります。

• 行定義には、MinHeight と MaxHeight の両方を宣言する 2 つの *-rows が含まれています。
• *-rows の内容は、対応する MaxHeight を超えません。
• グリッドの使用可能な高さは、最初の MinHeight (および他の固定行または自動行) を超えています。
• アプリは .NET Framework 4.7 を対象としているか、 Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=false設定して 4.7 割り当てアルゴリズムにオプトインします。

ループは、2 行を超える場合、または列の場合と同様に発生します。 この問題は、.NET Framework 4.7.1 で修正されています。

提案

.NET Framework 4.7.1 にアップグレードします。 または、4.7 割り当てアルゴリズムが必要ない場合は、次の構成設定を使用できます。

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>

影響を受ける API

API 分析では検出できません。

ローカライズされたビルドで RibbonGroup の背景が透明に設定されている

詳細

System.Windows.Controls.Ribbon.RibbonGroup ローカライズされたビルドの背景は常に Transparent ブラシで描画され、UI エクスペリエンスが低下しました。 これは、.NET Framework 4.7 WPF の修正プログラムで修正されます。 System.Windows.Controls.Ribbon.RibbonGroupのローカライズされたリソースを更新することで、正しいブラシが確実に選択されます。

提案

.NET Framework 4.7 へのアップグレード

影響を受ける API

API 分析では検出できません。

WPF 印刷スタックの更新

詳細

System.Printing.PrintQueueを使用する WPF の印刷 API は、現在非推奨の XPS 印刷 API を優先して Window の印刷ドキュメント パッケージ API を呼び出すようになりました。 変更は保守性を念頭に置いて行われました。ユーザーも開発者も、動作や API の使用に変更を加えてはなりません。 Windows 10 Creators Update で実行すると、新しい印刷スタックが既定で有効になります。 古い Windows バージョンでは、以前の印刷スタックは引き続き以前と同様に動作します。

提案

Windows 10 Creators Update で古いスタックを使用するには、UseXpsOMPrinting レジストリ キーのHKEY_CURRENT_USER\Software\Microsoft\.NETFramework\Windows Presentation Foundation\Printing REG_DWORD値を1に設定します。

影響を受ける 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の処理に依存している場合は、カスタム アクティビティからスローされる可能性がある例外をキャッチするように変更します。

影響を受ける 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 Workflow Instance Store (SWIS) 用に作成されたテーブルでは、クラスター化された主キーが使用されます。 このため、ID は null 値をサポートしていません。 SWIS の操作は、この変更の影響を受けません。 SQL Server トランザクション レプリケーションをサポートするために更新が行われました。

提案

この変更を行うには、SQL ファイル SqlWorkflowInstanceStoreSchemaUpgrade.sqlを既存のインストールに適用する必要があります。 新しいデータベースのインストールでは、自動的に変更が行われます。

影響を受ける API

API 分析では検出できません。

.NET Framework 4.7.1

JIT

UInt16 値を渡して比較するときの不適切なコード生成

詳細

.NET Framework 4.7 で導入された変更により、.NET Framework 4.7 で実行されているアプリケーションで JIT コンパイラによって生成されたコードで、2 つの T:System.UInt16 値が誤って比較される場合があります。 詳細については、GitHub.comの問題 #11508: ushort 引数を渡して比較するときに発生するサイレントの不良なコード生成をご覧ください。

提案

.NET Framework 4.7 で 16 ビット符号なし値の比較で問題が発生した場合は、.NET Framework 4.7.1 にアップグレードします。

影響を受ける 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 にアップグレードします。

影響を受ける 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 以降では、要素のいずれかがAddressHeaderCollection(IEnumerable<AddressHeader>)場合、ArgumentException コンストラクターはnullをスローします。 .NET Framework 4.7 以前のバージョンでは、例外はスローされません。

提案

.NET Framework 4.7.1 以降のバージョンでこの変更に関する互換性の問題が発生した場合は、app.config ファイルの <runtime> セクションに次の行を追加することで、この変更をオプトアウトできます。

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableAddressHeaderCollectionValidation=true" />
  </runtime>
</configuration>

影響を受ける API

• AddressHeaderCollection(IEnumerable<AddressHeader>)

WCF MsmqSecureHashAlgorithm の既定値が SHA256 になりました

詳細

.NET Framework 4.7.1 以降、WCF for 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>

影響を受ける 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>

影響を受ける API

API 分析では検出できません。

Windows プレゼンテーション ファンデーション (WPF)

StaysOpen=Falseの連鎖ポップアップ

詳細

StaysOpen=False のポップアップは、その外側をクリックすると閉じるはずです。 このようなポップアップが 2 つ以上連結されている場合 (つまり、1 つには別のポップアップが含まれています)、次のような多くの問題がありました。

• 2つのレベルを開き、P2の外側をクリックし、P1内をクリックします。 何も起こりません。
• 2 つのレベルを開き、P1 の外側をクリックします。 両方のポップアップが閉じます。
• 2 つのレベルを開いたり閉じたりします。 その後、もう一度 P2 を開いてみます。 何も起こりません。
• 3つのレベルを開いてみてください。 できません。 (クリックした場所に応じて、何も起こりませんか、最初の 2 つのレベルが閉じます。

これらのケース (およびその他のバリアント) が想定どおりに動作するようになりました。

影響を受ける API

• Popup.StaysOpen

カスタム 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 では、単一のディスパッチャー スレッドを持つアプリケーションでも例外が発生する可能性があります。

この問題は、.NET Framework 4.7.1 で修正されています。

提案

.NET Framework 4.7.1 にアップグレードします。

影響を受ける API

API 分析では検出できません。

Grid のサイズを変更すると、アプリケーションが応答しなくなる可能性があります

詳細

無限ループは、次の状況で T:System.Windows.Controls.Grid のレイアウト中に発生する可能性があります。

• 行定義には、MinHeight と MaxHeight の両方を宣言する 2 つの *-rows が含まれています。
• *-rows の内容は、対応する MaxHeight を超えません。
• グリッドの使用可能な高さは、最初の MinHeight (および他の固定行または自動行) を超えています。
• アプリは .NET Framework 4.7 を対象としているか、 Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=false設定して 4.7 割り当てアルゴリズムにオプトインします。

ループは、2 行を超える場合、または列の場合と同様に発生します。 この問題は、.NET Framework 4.7.1 で修正されています。

提案

.NET Framework 4.7.1 にアップグレードします。 または、4.7 割り当てアルゴリズムが必要ない場合は、次の構成設定を使用できます。

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>

影響を受ける 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 を使用する必要があります。

影響を受ける API

• System.Uri

Unicode が存在する場合の特別な相対 URI 表記のサポート

詳細

Unicode を含む特定の相対 URI でUriを呼び出しても、NullReferenceExceptionはもうTryCreateをスローしません。 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 を指定する必要があります。

影響を受ける API

• Uri.TryCreate(Uri, Uri, Uri)
• Uri.TryCreate(String, UriKind, Uri)
• Uri.TryCreate(Uri, String, Uri)

ランタイム

Net.Tcp 証明書認証の WCF チェーン信頼証明書検証の強化

詳細

.NET Framework 4.7.2 では、WCF でのトランスポート セキュリティで証明書認証を使用する場合のチェーン信頼証明書の検証が向上します。 この改善により、サーバーに対する認証に使用されるクライアント証明書は、クライアント認証用に構成する必要があります。 同様に、サーバー認証用のサーバー証明書は、サーバー認証用に構成する必要があります。 この変更により、ルート証明書が無効になっている場合、証明書チェーンの検証は失敗します。 Windows セキュリティ ロールアップを使用して、.NET Framework 3.5 以降のバージョンにも同じ変更が加えられた。 詳細については、 KB 4055269を参照してください。この変更は既定でオンになり、構成設定でオフにすることができます。

提案

• サーバーとクライアントの認定に必要な EKU OID があるかどうかを検証します。 そうでない場合は、認定を更新します。

• ルート証明書が無効かどうかを検証します。 その場合は、ルート証明書を更新します。

• 証明書を更新できない場合は、次の構成設定を使用して、破壊的変更を一時的に回避できます。 ただし、変更をオプトアウトすると、システムはセキュリティの問題に対して脆弱になります。

  <appSettings>
    <add key="wcf:useLegacyCertificateUsagePolicy" value="true" />
  </appSettings>
  

影響を受ける API

API 分析では検出できません。

Web アプリケーション

.NET Framework 4.7.2 では、"dataAnnotations:dataTypeAttribute:disableRegEx" アプリ設定が既定でオンになっています

詳細

.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 アプリケーションのセキュリティで保護された脆弱性をさらに軽減します。

提案

.NET Framework 4.7.2 にアップグレードした後に Web アプリケーションの正規表現が機能しない場合は、 dataAnnotations:dataTypeAttribute:disableRegEx 設定の値を false に更新して、前の動作に戻すことができます。

<configuration>
<appSettings>
...
<add key="dataAnnotations:dataTypeAttribute:disableRegEx" value="false"/>
...
</appSettings>
</configuration>

影響を受ける API

API 分析では検出できません。

Windows プレゼンテーション ファンデーション (WPF)

WPF でのキーヒントの動作の改善

詳細

キーヒントの動作が変更され、Microsoft Word および Windows エクスプローラーでの動作と同等になりました。 SystemKey (特に、KeyまたはF11) が押された場合にキーヒントの状態が有効になっているかどうかを確認することで、WPF はキーヒント キーを適切に処理します。 キーヒントがマウスで開かれた場合でもメニューを閉じるようになりました。

提案

なし

影響を受ける API

API 分析では検出できません。