.NET Framework 4.6.x への移行に関する変更の再ターゲット

  • [アーティクル]

この記事では、.NET Framework 4.6、 4.6.1、および 4.6.2 で生じたアプリの互換性の問題について説明します。

.NET Framework 4.6

ASP.NET

HtmlTextWriter によって <br/> 要素が正しく表示されない

説明

.NET Framework 4.6 以降では、<BR /> 要素を指定して RenderBeginTag(String) と RenderEndTag() を呼び出すと、<BR /> が 1 つのみ (2 つではなく) 正しく挿入されます。

提案される解決策

アプリが余分な <BR /> タグに依存している場合は、RenderBeginTag(String) をもう一度呼び出す必要があります。 この動作の変更は、.NET Framework 4.6 以降を対象とするアプリにのみ影響するので、以前の動作を得るためには、以前のバージョンの .NET Framework を対象とするという方法もあります。

名前 値
スコープ エッジ
バージョン 4.6
種類 再ターゲット中

影響を受ける API

ClickOnce

SHA-256 コード署名証明書を使用する ClickOnce で発行されたアプリケーションは、Windows 2003 では失敗することがある

説明

この実行可能ファイルは SHA256 で署名されます。 以前は、コード署名証明書が SHA-1 か SHA-256 に関係なく、SHA 1 で署名されました。 この方法は、次の対象に適用されます。

  • Visual Studio 2012 以降でビルドされたすべてのアプリケーション。
  • .NET Framework 4.5 がインストールされているシステム上で、Visual Studio 2010 以前でビルドされたアプリケーション。 さらに、.NET Framework 4.5 以降が存在する場合、コンパイル対象となった .NET Framework のバージョンに関係なく、ClickOnce マニフェストはSHA-256 証明書の SHA 256 で署名されます。

提案される解決策

ClickOnce 実行可能ファイルの署名方法に関するこの変更は、Windows Server 2003 システムにのみ影響を及ぼします。これらのシステムには、KB 938397 をインストールする必要があります。 アプリが .NET Framework 4.0 以前のバージョンをターゲットとしている場合でも、SHA-256 を使用したマニフェストの署名方法の変更により、.NET Framework 4.5 以降のバージョンに対するランタイム依存関係が導入されます。

名前 値
スコープ エッジ
バージョン 4.5
種類 再ターゲット中

4\.0 を対象とするアプリの ClickOnce が SHA-256 に対応

説明

以前は、SHA-256 で署名された証明書が与えられた ClickOnce アプリには、アプリの対象が 4.0 の場合でも、.NET Framework 4.5 以降が必要でした。 それが今では、SHA-256 で署名されている場合でも、.NET Framework 4.0 を対象とする ClickOnce アプリを .NET Framework 4.0 で実行できるようになりました。

提案される解決策

この変更により、その依存関係がなくなったので、.NET Framework 4 以前のバージョンを対象とする ClickOnce アプリの署名に SAH-256 証明書が使用できるようになりました。

名前 値
スコープ マイナー
バージョン 4.6
種類 再ターゲット中

コア

タスク全体の CurrentCulture と CurrentUICulture のフロー

説明

.NET Framework 4.6 より、非同期操作全体をフローする、スレッドの System.Threading.ExecutionContext に System.Globalization.CultureInfo.CurrentCulture と System.Globalization.CultureInfo.CurrentUICulture が格納されます。その結果、System.Globalization.CultureInfo.CurrentCulture または System.Globalization.CultureInfo.CurrentUICulture に対する変更は、後で非同期実行されるタスクで反映されます。 これは、すべての非同期タスクで System.Globalization.CultureInfo.CurrentCulture と System.Globalization.CultureInfo.CurrentUICulture がリセットされていた、以前のバージョンの .NET Framework の動作とは異なります。

提案される解決策

この変更の影響を受けるアプリでは、非同期タスクの最初の操作として任意の System.Globalization.CultureInfo.CurrentCulture または System.Globalization.CultureInfo.CurrentUICulture を明示的に設定することで問題を回避できます。 あるいは、次の互換性スイッチを設定することで、System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture をフローしない以前の動作を選択できます。

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

この問題は、.NET Framework 4.6.2 の WPF で修正されました。 また、.NET Frameworks 4.6、4.6.1 では KB 3139549 を通じて修正されました。 .NET Framework 4.6 以降を対象とするアプリケーションでは WPF アプリケーション (System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) の正しい動作が自動的に取得されます。これは、ディスパッチャー操作にわたって維持されます。

名前 値
スコープ マイナー
バージョン 4.6
種類 再ターゲット中

影響を受ける API

サフィックスの "Start" または "Stop" のみで ETW イベント名を使い分けることができない

説明

.NET Framework 4.6 と4.6.1 では、2 つの Windows イベント トレーシング (ETW) のイベント名の違いが、"Start" または "Stop" のサフィックスのみである場合 (あるイベントの名前が LogUser で、別のイベントの名前が LogUserStart の場合など)、ランタイムにより ArgumentException がスローされます。 この場合、ランタイムはイベント ソースを作成できないため、ログ記録は生成できません。

提案される解決策

この例外を回避するには、"Start" または "Stop" のサフィックスだけが異なる 2 つのイベント名が存在しないようにします。この要件は、.NET Framework 4.6.2 以降では削除されています。ランタイムは、"Start" と "Stop" のサフィックスだけが異なるイベント名を明確に区別できます。

名前 値
スコープ エッジ
バージョン 4.6
種類 再ターゲット中

Entity Framework

Visual Studio 2013 で Entity Framework edmx をビルドすると、EntityDeploySplit または EntityClean タスクを使用している場合、エラー MSB4062 で失敗することがある

説明

MSBuild 12.0 ツール (Visual Studio 2013 に含まれる) は、MSBuild ファイルの位置を変更したため、古い Entity Framework のターゲット ファイルは無効になります。 その結果、EntityDeploySplit および EntityClean タスクは、Microsoft.Data.Entity.Build.Tasks.dll を見つけられないために失敗します。 このエラーは、ツールセット (MSBuild/VS) の変更によるものであり、.NET Framework の変更によるものではないことに注意してください。 開発者ツールをアップグレードしたときにのみ発生し、.NET Framework をアップグレード下だけでは発生しません。

提案される解決策

Entity Framework のターゲット ファイルは、.NET Framework 4.6 以降の新しい MSBuild レイアウトで機能するように修正されます。 このバージョンの Framework にアップグレードすることで、この問題は修正されます。 または、この回避策を使用して、ターゲット ファイルに直接パッチを当てることができます。

名前 値
スコープ Major
バージョン 4.5.1
種類 再ターゲット中

JIT

try 領域で IL ret が許可されない

説明

JIT64 Just-In-Time コンパイラとは異なり、(.NET Framework 4.6 で使用される) RyuJIT では、try 領域で IL ret 命令が許可されません。 ECMA-335 仕様により try 領域から戻ることは許可されておらず、そうした IL を生成する既知のマネージド コンパイラはありません。 ただし、JIT64 コンパイラは、リフレクション出力を使用して生成される場合にはこうした IL を実行します。

提案される解決策

try 領域に ret オペコードを含む IL をアプリが生成する場合、そのアプリでは .NET Framework 4.5 を対象にして以前の JIT を使用し、この中断を回避できます。 あるいは、try 領域の後に戻るように生成後の IL を更新できます。

名前 値
スコープ エッジ
バージョン 4.6
種類 再ターゲット中

.NET Framework 4.6 の新しい 64 ビット JIT コンパイラ

説明

.NET Framework 4.6 以降では、Just-In-Time コンパイルには新しい 64 ビット JIT コンパイラが使用されます。 場合によっては、予期しない例外がスローされるか、32 ビット コンパイラまたは以前の 64 ビット JIT コンパイラを使用してアプリを実行したときとは動作が異なる可能性があります。 この変更は、32 ビット JIT コンパイラには影響しません。 既知の相違には次のようなものがあります。

  • 特定の条件下では、最適化が有効なリリース ビルドの NullReferenceException がボックス化解除操作でスローされる場合があります。
  • 場合によっては、大きなメソッド本文の実働コードの実行時に StackOverflowException がスローされることがあります。
  • 特定の条件下では、メソッドに渡された構造体が、リリース ビルドの値の型ではなく、参照型として扱われます。 この問題の兆候の 1 つは、コレクション内の個々の項目が予期しない順序で表示されることです。
  • 特定の条件下では、最適化が有効な場合、高ビットが設定された UInt16 値が正しく比較されません。
  • 特定の条件下では、特に、配列値の初期化中に、OpCodes.Initblk IL 命令でのメモリ初期化により、正しくない値でメモリが初期化される場合があります。 その結果、ハンドルされない例外または正しくない出力が発生する場合があります。
  • 特定のまれな条件下では、コンパイラの最適化が有効な場合に、条件付きのビット テストで正しくない Boolean 値が返されたり、例外がスローされたりすることがあります。
  • 特定の条件下では、if ステートメントを使用して、try ブロックの開始前と try ブロックの終了時の条件をテストし、同じ条件を catch または finally ブロックで評価する場合、新しい 64 ビット JIT コンパイラが、コードの最適化の際に catch または finally ブロックから if 条件を削除します。 その結果、catch または finally ブロックの if ステートメント内のコードは無条件で実行されます。

提案される解決策

既知の問題の軽減策
上記の問題が発生する場合は、次のいずれかの方法で解決できます。

  • .NET Framework 4.6.2 にアップグレードします。 .NET Framework 4.6.2 に含まれている新しい 64 ビット コンパイラは、これらの既知の問題のそれぞれに対処します。

  • Windows Update を実行して、Windows のバージョンが最新のものであることを確認します。 .NET Framework 4.6 および 4.6.1 へのサービス更新により、ボックス化解除操作での NullReferenceException を除き、これらの問題のそれぞれに対処することができます。

  • 古い 64 ビット JIT コンパイラでコンパイルします。 この方法の詳細については、「その他の問題の軽減策」を参照してください。 その他の問題の軽減策
    古い 64 ビット コンパイラと新しい 64 ビット JIT コンパイラでコンパイルされたコードの動作、またはアプリのデバッグ バージョンとリリース バージョン (両方とも新しい 64 ビット JIT コンパイラでコンパイル) の動作に違いが見られる場合は、次のようにして、古い 64 ビット JIT コンパイラでアプリをコンパイルすることができます。

  • アプリケーションごとに、アプリケーションの構成ファイルに < 要素を追加できます。 次のように新しい 64 ビット JIT コンパイラでのコンパイルを無効にし、代わりに従来の 64 ビット JIT コンパイラを使用します。

    <?xml version ="1.0"?>
<configuration>
  <runtime>
   <useLegacyJit enabled="1" />
  </runtime>
</configuration>

  • ユーザーごとに、useLegacyJit という REG_DWORD 値をレジストリの HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework キーに追加できます。 値を 1 にすると、従来の 64 ビット JIT コンパイラが有効になり、値を 0 にすると、従来の 64 ビット JIT コンパイラが無効になり、新しい 64 ビット JIT コンパイラが有効になります。

  • コンピューターごとに、useLegacyJit という名前の REG_DWORD 値をレジストリの HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework キーに追加できます。 値を 1 にすると、従来の 64 ビット JIT コンパイラが有効になり、値を 0 にすると、従来の 64 ビット JIT コンパイラが無効になり、新しい 64 ビット JIT コンパイラが有効になります。 Microsoft Connect でバグを報告し、問題を弊社に知らせることもできます。

名前 値
スコープ エッジ
バージョン 4.6
種類 再ターゲット中

ネットワーキング

証明書 EKU OID の検証

説明

.NET Framework 4.6 以降、SslStream または ServicePointManager クラスで EKU (拡張キー使用法) の OID (オブジェクト識別子) が検証されます。 EKU (拡張キー使用法) 拡張は、キーを使用するアプリケーションを示すオブジェクト識別子 (OID) の集まりです。 EKU OID 検証では、リモート証明書に意図している目的にかなった OID が与えられるようにリモート証明書コールバックが使用されます。

提案される解決策

この変更が望ましくない場合、アプリの構成ファイルの ` の <AppContextSwitchOverrides> に次のスイッチを追加することで証明書 EKU OID 検証を無効にできます。

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontCheckCertificateEKUs=true" />
</runtime>

重要

この設定は下位互換性のためにのみ提供されます。 それ以外の目的での使用はお勧めしません。

名前 値
スコープ マイナー
バージョン 4.6
種類 再ターゲット中

影響を受ける API

System.Net.ServicePointManager と System.Net.Security.SslStream で TLS 1.0、1.1、1.2 プロトコルのみサポート

説明

.NET Framework 4.6 から、ServicePointManager クラスと SslStream クラスには、Tls1.0、Tls1.1、Tls 1.2 という 3 つのプロトコルのいずれかを使用することのみが許可されます。 SSL3.0 プロトコルと RC4 の暗号化はサポートされていません。

提案される解決策

推奨される軽減策はサーバー側のアプリを Tls1.0、Tls1.1、または Tls1.2 にアップグレードすることです。 これが現実的でない場合、またはクライアント アプリが破損している場合は、次の 2 つの方法のいずれかにより、System.AppContext クラスを使用してこの機能を除外できます。

  • プログラムで System.AppContext の互換性スイッチを設定する (説明はこちらにあります)。
  • app.config ファイルの <runtime> セクションに以下の行を追加する。
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>
名前 値
スコープ マイナー
バージョン 4.6
種類 再ターゲット中

影響を受ける API

TLS 1.x は既定で SCH_SEND_AUX_RECORD フラグを基になる SCHANNEL API に渡す

説明

TLS 1.x を使用するとき、.NET Framework は基になる Windows SCHANNEL API に依存します。 .NET Framework 4.6 以降、SCH_SEND_AUX_RECORD フラグは既定で SCHANNEL に渡されます。 SCHANNEL によって、暗号化するデータが 2 つの別個のレコードに分割されます。1 つ目のレコードはシングル バイトで、2 つ目のレコードは n-1 バイトです。 その結果、まれに、データがシングル レコードに置かれていると想定する既存サーバーとクライアントの間の通信が途切れることがあります。

提案される解決策

この変更によって既存サーバーとの接続が途切れる場合、SCH_SEND_AUX_RECORD フラグの送信を無効にし、アプリ構成ファイルの <runtime> セクションで次のスイッチを <AppContextSwitchOverrides> 要素に追加することで、データを別個のレコードに分割しない、以前の動作に復元できます。

<runtime>
  <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchSendAuxRecord=true" />
</runtime>

重要

この設定は下位互換性のためにのみ提供されます。 それ以外の目的での使用はお勧めしません。

名前 値
スコープ エッジ
バージョン 4.6
種類 再ターゲット中

影響を受ける API

Windows Communication Foundation (WCF)

null 引数を指定した CreateDefaultAuthorizationContext の呼び出しが変更されました

説明

null の authorizationPolicies 引数を指定した System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) の呼び出しによって返される System.IdentityModel.Policy.AuthorizationContext の実装が、.NET Framework 4.6 で変更されました。

提案される解決策

まれに、カスタム認証を使用する WCF アプリの動作に違いが生じる可能性があります。 このような場合は、2 つの方法のいずれかで、以前の動作を復元できます。

  • 4\.6 よりも前のバージョンの .NET Framework を対象とするようにアプリを再コンパイルする。 IIS でホストされるサービスでは、<httpRuntime targetFramework="x.x"> の要素を使用して、以前のバージョンの .NET Framework を対象とするようにします。

  • app.config ファイルの <appSettings> セクションに以下の行を追加します。

    <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />
名前 値
スコープ マイナー
バージョン 4.6
種類 再ターゲット中

影響を受ける API

Windows フォーム

PNG フレームを含んだアイコンが Icon.ToBitmap によって、Bitmap オブジェクトに正常に変換されます

詳細

.NET Framework 4.6 以降を対象にしたアプリでは、Icon.ToBitmap メソッドで、PNG フレームを含んだアイコンを正常に Bitmap オブジェクトに変換できます。

.NET Framework 4.5.2 以前のバージョンを対象としたアプリでは、Icon オブジェクトに PNG フレームが含まれていると、Icon.ToBitmap メソッドが ArgumentOutOfRangeException の例外をスローします。

この変更は、.NET Framework 4.6 を対象として再コンパイルされたアプリのうち、Icon オブジェクトに PNG フレームが含まれている場合は ArgumentOutOfRangeException をスローするように特別な処理が実装されているアプリに影響します。 .NET Framework 4.6 で実行している場合は、正常に変換が行われ、 ArgumentOutOfRangeException がスローされることはないため、例外ハンドラーは呼び出されません。

提案される解決策

この動作に不都合がある場合は、次に示す要素を app.config ファイルの <runtime> セクションに追加することで、以前の動作を維持できます。

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true" />

app.config ファイルに既に AppContextSwitchOverrides 要素が含まれている場合は、次に示すように新しい値を value 属性にマージする必要があります。

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true;<previous key>=<previous value>" />
名前 値
スコープ マイナー
バージョン 4.6
種類 再ターゲット中

影響を受ける API

Windows Presentation Foundation (WPF)

CurrentCulture が、複数の WPF ディスパッチャー操作にわたって維持されない

説明

.NET Framework 4.6 以降では、System.Windows.Threading.Dispatcher 内で System.Globalization.CultureInfo.CurrentCulture または System.Globalization.CultureInfo.CurrentUICulture に加えられた変更は、そのディスパッチャー操作の終了時に失われます。 同様に、ディスパッチャー操作の外部で System.Globalization.CultureInfo.CurrentCulture または System.Globalization.CultureInfo.CurrentUICulture に加えられた変更は、その操作の実行時には反映されない場合があります。具体的に言うと、System.Globalization.CultureInfo.CurrentCulture と System.Globalization.CultureInfo.CurrentUICulture の変更は、WPF UI コールバックと WPF アプリケーション内の他のコードの間でフローされない場合があるということです。これは、System.Threading.ExecutionContext の変更によるものであり、この変更により、.NET Framework 4.6 以降を対象とするアプリでは、System.Globalization.CultureInfo.CurrentCulture および System.Globalization.CultureInfo.CurrentUICulture は実行コンテキストに格納されます。 WPF ディスパッチャー操作は、操作を開始するために使用された実行コンテキストを格納して、操作が完了したときに、以前のコンテキストを復元します。 System.Globalization.CultureInfo.CurrentCulture と System.Globalization.CultureInfo.CurrentUICulture がそのコンテキストの一部になったため、ディスパッチャー操作内でそれらに加えられた変更は、操作の外部では保持されません。

提案される解決策

この変更による影響を受けるアプリは、望ましい System.Globalization.CultureInfo.CurrentCulture または System.Globalization.CultureInfo.CurrentUICulture をフィールドに格納し、すべてのディスパッチャー操作の本体 (UI イベントのコールバック ハンドラーを含む) で、正しい System.Globalization.CultureInfo.CurrentCulture と System.Globalization.CultureInfo.CurrentUICulture が設定されていることを確認することによって回避できます。 または、この WPF の変更の元となっている ExecutionContext の変更は、.NET Framework 4.6 以降を対象とするアプリのみに影響するため、.NET Framework 4.5.2 を対象とすることによって、この問題を回避できます。また、.NET Framework 4.6 以降を対象とするアプリでは、以下の互換性スイッチを設定することでこの問題を回避することができます。

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

この問題は、.NET Framework 4.6.2 の WPF で修正されました。 また、.NET Frameworks 4.6、4.6.1 では KB 3139549 を通じて修正されました。 .NET Framework 4.6 以降を対象とするアプリケーションでは WPF アプリケーション (System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) の正しい動作が自動的に取得されます。これは、ディスパッチャー操作にわたって維持されます。

名前 値
スコープ マイナー
バージョン 4.6
種類 再ターゲット中

WPF レイアウトでの余白の丸め方の変更

説明

余白、境界線、およびそれらの内部の背景の丸め処理の方法が変更されました。 この変更の結果、以下のようになります。

  • 要素の幅または高さが最大で 1 ピクセル拡大または縮小することがあります。
  • オブジェクトの配置が最大で 1 ピクセル移動することがあります。
  • 中央揃えの要素が中央から最大で 1 ピクセル垂直まは水平方向にずれることがあります。 既定では、この新しいレイアウトは .NET Framework の 4.6 を対象とするアプリに対してのみ有効となります。

提案される解決策

この変更では、DPI が高いときにWPF コントロールの一番右または一番下でクリッピングの発生を除去する傾向があるため、app.config ファイルの <runtime> セクションに次の行を追加することによって、以前のバージョンの .NET Framework を対象としながら .NET Framework 4.6 上で実行されているアプリがこの新しい動作を選択ことができます。

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=false" />

.NET Framework 4.6 を対象としながら以前のレイアウト アルゴリズムを使用して WPF コントロールをレンダリングする必要があるアプリの場合、app.config ファイルの <runtime> セクションに次の行を追加することによってそれを行うことができます。

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=true" />
名前 値
スコープ マイナー
バージョン 4.6
種類 再ターゲット中

XML、XSLT

無効なサロゲート ペアで XmlWriter がスローされる

説明

.NET Framework 4.5.2 またはそれ以前のバージョンをターゲットとするアプリケーションの場合、例外フォールバック処理を使用した無効なサロゲート ペアを作成しても、必ず例外がスローされるとは限りません。 .NET Framework 4.6 を対象とするアプリでは、無効なサロゲート ペアを作成しようとすると、System.ArgumentException がスローされます。

提案される解決策

必要に応じて、.NET Framework 4.5.2 以前をターゲットとすることでこの問題を回避できます。 または、無効なサロゲート ペアを有効な xml に書き込む前に事前処理することもできます。

名前 値
スコープ エッジ
バージョン 4.6
種類 再ターゲット中

影響を受ける API

XSD スキーマ検証は、複合キーが使用され、1 つのキーが空の場合に、一意制約の違反を正しく検出するようになりました

説明

.NET Framework 4.6 より前のバージョンには、キーの 1 つが空であった場合、XSD 検証で複合キーの一意制約が検出されないというバグがありました。 .NET Framework 4.6 で、この問題は修正されました。 このため、より正しい検証が行われるようになりますが、以前は検証されていた XML の一部が検証されない可能性もあります。

提案される解決策

より緩やかな .NET Framework 4.0 の検証が必要な場合、検証アプリケーションはバージョン 4.5 (またはそれ以前) の .NET Framework をターゲットにできます。 ただし、.NET Framework 4.6 に再ターゲットするときには、コード レビューを行って、重複する複合キー (この問題の説明で述べられているように) の検証を予期していないことを確認する必要があります。

名前 値
スコープ エッジ
バージョン 4.6
種類 再ターゲット中

.NET Framework 4.6.1

コア

ZipArchiveEntry オブジェクトの FullName プロパティのパス区切り文字の変更

説明

.NET Framework 4.6.1 以降のバージョンを対象とするアプリでは、CreateFromDirectory メソッドのオーバーロードによって作成された ZipArchiveEntry オブジェクトの FullName プロパティで、パスの区切り文字がバックスラッシュ ("\") からスラッシュ ("/") に変更されています。 この変更によって、.NET の実装が .ZIP ファイル形式の仕様のセクション 4.4.17.1 に準拠するようになったほか、Windows 以外のシステムで ZIP アーカイブを圧縮解除できるようになりました。
Macintosh などの Windows 以外のオペレーティング システムで以前のバージョンの .NET Framework を対象とするアプリで作成された zip ファイルを圧縮解除すると、ディレクトリ構造を保持できません。 たとえば、Macintosh では、ディレクトリ パスと、バックスラッシュ ("\")、およびファイル名を連結した名前を持つ一連のファイルが作成されます。 その場合、圧縮解除されたファイルのディレクトリ構造は保持されません。

提案される解決策

.NET Framework System.IO 名前空間の API によって Windows オペレーティング システム上に展開される .zip ファイルでは、この変更の影響は最小限になるはずです。これらの API では、パスの区切り文字としてスラッシュ ("/") またはバックスラッシュ ("\") をシームレスに処理できるためです。
この変更が望ましくない場合、アプリケーション構成ファイルの <runtime> セクションに構成設定を追加して、無効にすることができます。 次の例では、<runtime> セクションと無効に切り替える処理 Switch.System.IO.Compression.ZipFile.UseBackslash の両方を確認できます。

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=true" />
</runtime>

また、以前のバージョンの .NET Framework を対象とするものの、.NET Framework 4.6.1 以降のバージョンで実行されているアプリでは、アプリケーション構成ファイルの <runtime> セクションに構成設定を追加して、この動作を有効にすることができます。 次では、<runtime> セクションと有効に切り替える処理 Switch.System.IO.Compression.ZipFile.UseBackslash の両方を確認できます。

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>
名前 値
スコープ エッジ
バージョン 4.6.1
種類 再ターゲット中

影響を受ける API

Windows Communication Foundation (WCF)

TransportWithMessageCredential セキュリティ モードを使用する WCF バインド

説明

.NET Framework 4.6.1 より、TransportWithMessageCredential セキュリティ モードを使用する WCF バインドで署名のない非対称セキュリティ キーの "to" ヘッダーを含むメッセージを取得するように設定できるようになりました。既定では、署名のない "to" ヘッダーは .NET Framework 4.6.1 でも引き続き拒否されます。 これは、アプリケーションが Switch.System.ServiceModel.AllowUnsignedToHeader 構成スイッチを使用するこの新しい動作モードをオプトインした場合にのみ許可されます。

提案される解決策

これはオプトイン機能であるため、既存のアプリの動作に影響はないはずです。
新しい動作を使用するかどうかを制御するには、次の構成設定を使用します。

<runtime>
  <AppContextSwitchOverrides value="Switch.System.ServiceModel.AllowUnsignedToHeader=true" />
</runtime>
名前 値
スコープ 透明
バージョン 4.6.1
種類 再ターゲット中

影響を受ける API

X509CertificateClaimSet.FindClaims は、すべての claimTypes を考慮します

説明

X509 クレーム セットがその SAN フィールド内の複数の DNS エントリを含む証明書から初期化される場合は、.NET Framework 4.6.1 を対象とするアプリで、System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String)メソッドをすべての DNS エントリの claimType 引数と一致を試みます。 .NET Framework の以前のバージョンを対象とするアプリに対して、System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String)メソッドは claimType 引数と最後の DNS エントリのみを一致させようとしています。

提案される解決策

この変更は、.NET Framework 4.6.1 を対象とするアプリケーションのみに影響します。 この変更は、DisableMultipleDNSEntries 互換性スイッチで無効にできます (または、4.6.1 より前を対象としている場合は、有効にできます)。

名前 値
スコープ マイナー
バージョン 4.6.1
種類 再ターゲット中

影響を受ける API

Windows フォーム

Application.FilterMessage は、IMessageFilter.PreFilterMessage の再入可能な実装についてスローしなくなりました

詳細

.NET Framework 4.6.1 以前は、System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) または System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter) (さらに DoEvents()) を呼び出すPreFilterMessage(Message) で FilterMessage(Message) を呼び出すと、System.IndexOutOfRangeException が発生していました。

.NET Framework 4.6.1 を対象とするアプリケーションからは、この例外がスローされなくなり、上述のリエントラント フィルターを使用できます。

提案される解決策

上述の再入可能な PreFilterMessage(Message) の動作に対して FilterMessage(Message) はスローされなくなります。 これは、.NET Framework 4.6.1 をターゲットとするアプリケーションにのみ影響します。 .NET Framework 4.6.1 を対象とするアプリは、DontSupportReentrantFilterMessage 互換性スイッチを使用することによって、この変更を解除できます (または、以前の Framework をターゲットとしているアプリは、変更を受け入れることができます)。

名前 値
スコープ エッジ
バージョン 4.6.1
種類 再ターゲット中

影響を受ける API

Windows Presentation Foundation (WPF)

タッチ対応システムで System.Windows.Input.PenContext.Disable を呼び出すと ArgumentException がスローされることがある

説明

一部の状況では、タッチ対応システムで内部 System.Windows.Intput.PenContext.Disable メソッドを呼び出すと、再入に起因して未処理の T:System.ArgumentException がスローされることがあります。

提案される解決策

この問題は、.NET Framework 4.7 では対処済みです。 例外を防ぐには、.NET Framework 4.7 以降のバージョンの .NET Framework にアップグレードします。

名前 値
スコープ エッジ
バージョン 4.6.1
種類 再ターゲット中

.NET Framework 4.6.2

ASP.NET

HttpRuntime.AppDomainAppPath で NullReferenceException がスローされる

説明

ランタイムによってスローされる、.NET Framework 4.6.2、T:System.NullReferenceException取得するときに、 P:System.Web.HttpRuntime.AppDomainAppPath null 文字を含む値です。 .NET Framework 4.6.1 と以前のバージョンでは、ランタイムによってスローされる、T:System.ArgumentNullExceptionです。

提案される解決策

次のいずれかでこの変更に対応できます。

  • アプリケーションが .NET Framework 4.6.2 で実行されている場合には T:System.NullReferenceException を処理します。
  • .NET Framework 4.7 にアップグレードします。以前の動作が復元され、T:System.ArgumentNullException がスローされます。
名前 値
スコープ エッジ
バージョン 4.6.2
種類 再ターゲット中

影響を受ける API

コア

AesCryptoServiceProvider の復号で変換が再利用可能に

説明

.NET Framework 4.6.2 以降を対象とするアプリでは、AesCryptoServiceProvider の復号で変換を再利用できます。 System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) の呼び出しの後、変換は初期化し直され、再利用することができます。 以前のバージョンの .NET Framework を対象とするアプリでは、System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(Byte[], Int32, Int32) の呼び出しの後に、System.Security.Cryptography.CryptoAPITransform.TransformBlock(Byte[], Int32, Int32, Byte[], Int32) を呼び出して、復号を再利用しようとすると、CryptographicException をスローするか、破損しているデータが生成されます。

提案される解決策

この動作は想定済みであり、この変更の影響は最小限に抑えられているはずです。この変更の影響は前の動作に依存するアプリケーションは、そのアプリケーションの構成ファイルの <runtime> セクションに次の構成設定を追加して、この動作の使用を無効にすることができます。

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=true"/>
</runtime>

また、以前のバージョンの .NET Framework を対象とするものの、.NET Framework 4.6.2 以降のバージョンの .NET Framework で実行されているアプリでは、そのアプリケーションの構成ファイルの <runtime> セクションに次の構成設定を追加して、この動作を有効にできます。

<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=false"/>
</runtime>
名前 値
スコープ マイナー
バージョン 4.6.2
種類 再ターゲット中

影響を受ける API

ClaimsIdentity コンストラクターを呼び出す

説明

.NET Framework 4.6.2 以降、ClaimsIdentity コンストラクターと System.Security.Principal.IIdentity パラメーターの組み合わせで System.Security.Claims.ClaimsIdentity.Actor プロパティが設定されるしくみに変更があります。 System.Security.Principal.IIdentity 引数が ClaimsIdentity オブジェクトで、その ClaimsIdentity オブジェクトの System.Security.Claims.ClaimsIdentity.Actor プロパティが null ではない場合、Clone() メソッドを使用して System.Security.Claims.ClaimsIdentity.Actor プロパティがアタッチされます。 Framework 4.6.1 以前のバージョンでは、System.Security.Claims.ClaimsIdentity.Actor プロパティは既存の参照として付けられます。この変更によって、.NET Framework 4.6.2 以降、新しい ClaimsIdentity オブジェクトの System.Security.Claims.ClaimsIdentity.Actor プロパティはコンストラクターの System.Security.Principal.IIdentity 引数の System.Security.Claims.ClaimsIdentity.Actor プロパティとは等しくなくなります。 .NET Framework 4.6.1 以前のバージョンでは、等しくなります。

提案される解決策

この動作が望ましくない場合、アプリケーション構成ファイルで Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity スイッチを true に設定して以前の動作を復元することができます。 この場合、web.config ファイルの <runtime> セクションに次を追加します。

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity=true" />
  </runtime>
</configuration>
名前 値
スコープ エッジ
バージョン 4.6.2
種類 再ターゲット中

影響を受ける API

パスの正規化の変更

説明

.NET Framework 4.6.2 を対象とするアプリより、ランタイムによってパスを正規化する方法が変わりました。パスの正規化では、パスまたはファイルを識別する文字列を変更し、対象のオペレーティング システムの有効なパスに準拠するようにします。 通常、正規化では次のことを行います。

  • コンポーネントとディレクトリの区切り記号を正規化する。
  • 現在のディレクトリを相対パスに適用する。
  • パスの相対ディレクトリ (.) または親ディレクトリ (..) を評価する。
  • 指定した文字をトリミングする。 .NET Framework 4.6.2 を対象とするアプリより、パス正規化の次の変更が既定で有効になっています。
    • ランタイムはオペレーティング システムの GetFullPathName 関数に従って、パスを正規化します。
  • 正規化では、ディレクトリ セグメントの末尾 (ディレクトリ名の末尾のスペースなど) がトリミングされなくなりました。
  • \\.\ や \\?\ (mscorlib.dll のファイル I/O API の場合) を含む、完全に信頼できるデバイス パス構文がサポートされます。
  • ランタイムではデバイス構文パスは検証されません。
  • 代替データ ストリームにアクセスするためのデバイス構文の使用はサポートされています。 これらの変更でパフォーマンスが向上すると同時に、以前はアクセス不可だったパスにメソッドでアクセスできるようになります。 .NET Framework 4.6.1 以前のバージョンを対象とするアプリが .NET Framework 4.6.2 以降で実行される場合、この変更の影響は受けません。

提案される解決策

.NET Framework 4.6.2 以降を対象とするアプリの場合、アプリケーション構成ファイルの <runtime> セクションに次の行を追加することでこの変更を無効にし、従来の正規化を使用できます。

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=true" />
</runtime>

.NET Framework 4.6.1 以前を対象とするが、.NET Framework 4.6.2 以降で実行されるアプリの場合、アプリケーション構成ファイルの <runtime> セクションに次の行を追加することで、パス正規化の変更を有効にできます。

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
</runtime>
名前 値
スコープ マイナー
バージョン 4.6.2
種類 再ターゲット中

タスク全体の CurrentCulture と CurrentUICulture のフロー

説明

.NET Framework 4.6 より、非同期操作全体をフローする、スレッドの System.Threading.ExecutionContext に System.Globalization.CultureInfo.CurrentCulture と System.Globalization.CultureInfo.CurrentUICulture が格納されます。その結果、System.Globalization.CultureInfo.CurrentCulture または System.Globalization.CultureInfo.CurrentUICulture に対する変更は、後で非同期実行されるタスクで反映されます。 これは、すべての非同期タスクで System.Globalization.CultureInfo.CurrentCulture と System.Globalization.CultureInfo.CurrentUICulture がリセットされていた、以前のバージョンの .NET Framework の動作とは異なります。

提案される解決策

この変更の影響を受けるアプリでは、非同期タスクの最初の操作として任意の System.Globalization.CultureInfo.CurrentCulture または System.Globalization.CultureInfo.CurrentUICulture を明示的に設定することで問題を回避できます。 あるいは、次の互換性スイッチを設定することで、System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture をフローしない以前の動作を選択できます。

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

この問題は、.NET Framework 4.6.2 の WPF で修正されました。 また、.NET Frameworks 4.6、4.6.1 では KB 3139549 を通じて修正されました。 .NET Framework 4.6 以降を対象とするアプリケーションでは WPF アプリケーション (System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) の正しい動作が自動的に取得されます。これは、ディスパッチャー操作にわたって維持されます。

名前 値
スコープ マイナー
バージョン 4.6
種類 再ターゲット中

影響を受ける API

サフィックスの "Start" または "Stop" のみで ETW イベント名を使い分けることができない

説明

.NET Framework 4.6 と4.6.1 では、2 つの Windows イベント トレーシング (ETW) のイベント名の違いが、"Start" または "Stop" のサフィックスのみである場合 (あるイベントの名前が LogUser で、別のイベントの名前が LogUserStart の場合など)、ランタイムにより ArgumentException がスローされます。 この場合、ランタイムはイベント ソースを作成できないため、ログ記録は生成できません。

提案される解決策

この例外を回避するには、"Start" または "Stop" のサフィックスだけが異なる 2 つのイベント名が存在しないようにします。この要件は、.NET Framework 4.6.2 以降では削除されています。ランタイムは、"Start" と "Stop" のサフィックスだけが異なるイベント名を明確に区別できます。

名前 値
スコープ エッジ
バージョン 4.6
種類 再ターゲット中

長いパスのサポート

説明

以降とするアプリをターゲットとする .NET Framework 4.6.2、長いパス (最大 32 K の文字) がサポートされている、および 260 文字 (またはMAX_PATH) パスの長さの制限がなくなりました。 .NET Framework 4.6.2 を対象として再コンパイルされたアプリの場合は、コードをスローした以前のパス、 System.IO.PathTooLongException 260 文字をスローがパスを超えたため、System.IO.PathTooLongException次の条件下でのみ。

  • パスの長さが MaxValue (32,767) 文字を超えている。
  • オペレーティング システムが COR_E_PATHTOOLONG またはそれと同等のものを返す。 .NET Framework 4.6.1 以前を対象とするアプリの場合、パスが 260 文字を超えるたびにランタイムで自動的に System.IO.PathTooLongException がスローされます。

提案される解決策

.NET Framework 4.6.2 を対象とするアプリケーションの場合、長いパスが望ましくないときは、app.config ファイルの <runtime> セクションに次を追加することで長いパスのサポートを無効にできます。

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=true" />
</runtime>

以前のバージョンの .NET Framework を対象とするが、.NET Framework 4.6.2 以降で実行するアプリの場合、app.config ファイルの <runtime> セクションに次を追加することで長いパスのサポートを選択できます。

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=false" />
</runtime>
名前 値
スコープ マイナー
バージョン 4.6.2
種類 再ターゲット中

パスのコロン確認が厳密化

説明

.NET Framework 4.6.2 では、以前はサポートされていなかったパスをサポートするために (長さと形式の両方で) 数多くの変更が加えられました。 ドライブの区切り (コロン) 構文がより厳密に確認されるようになった結果、それ以前は許容されていた、選ばれた少数のパス API の一部の URI パスがブロックされるようになりました。

提案される解決策

影響を受ける API に URI を渡す場合、まず、文字列を正規のパスに変更します。

  • URL から手動でスキームを削除します (たとえば、URL から file:// を削除します)。

  • Uri クラスに URI を渡し、LocalPath を使用します。

あるいは、Switch.System.IO.UseLegacyPathHandling AppContext スイッチを true に設定し、新しいパス正規化を無効にします。

名前 値
スコープ エッジ
バージョン 4.6.2
種類 再ターゲット中

影響を受ける API

セキュリティ

RSACng でキー サイズが非標準の RSA キーが正しく読み込まれるようになりました

説明

4\.6.2 より前の .NET Framework バージョンでは、RSA 証明書のキー サイズが標準ではない顧客は、拡張メソッドの System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(X509Certificate2) や System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(X509Certificate2) でそのキーにアクセスできません。 "要求されたキー サイズはサポートされていません" というメッセージと共に System.Security.Cryptography.CryptographicException がスローされます。 .NET Framework 4.6.2 では、この問題が修正されました。 同様に、ImportParameters(RSAParameters) と ImportParameters(RSAParameters) で System.Security.Cryptography.CryptographicException をスローすることなく非標準サイズのキーが処理されるようになりました。

提案される解決策

非標準サイズのキーが使用されるときに System.Security.Cryptography.CryptographicException がスローされるという以前の動作に依存する例外処理ロジックがある場合、そのロジックを除くことを検討してください。

名前 値
スコープ エッジ
バージョン 4.6.2
種類 再ターゲット中

影響を受ける API

変更の対象を変更せず、SignedXml.GetPublicKey が net462 (または Light-Up) で RSACng を返す

説明

.NET Framework 4.6.2 より、SignedXml.GetPublicKey メソッドによって返されるオブジェクトの具象型が CryptoServiceProvider 実装から Cng 実装に変わりました。これは突然の変更ではなく、 certificate.PublicKey.Key の使用から、certificate.GetAnyPublicKey に転送する内部 RSACertificateExtensions.GetRSAPublicKey の使用に実装が変わったためです。

提案される解決策

.NET Framework 4.7.1 で実行されるアプリから、アプリの構成ファイルの runtime セクションに次の構成スイッチを追加することで、.NET Framework 4.6.1 以前のバージョンで既定で使用されていた CryptoServiceProvider 実装を使用できます。

<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true" />
名前 値
スコープ エッジ
バージョン 4.6.2
種類 再ターゲット中

影響を受ける API

Windows Communication Foundation (WCF)

再入可能なサービスを使用していると、デッドロックが発生する可能性がある

説明

サービスのインスタンスの実行が一度に 1 つのスレッドに制限される再入可能なサービスでは、デッドロックが発生します。 この問題が発生しやすいサービスのコードには、次の ServiceBehaviorAttribute が含まれています。

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]

提案される解決策

この問題に対処するために、次の操作を行うことができます。

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
  • 最新の更新プログラムを .NET framework 4.6.2 にインストールするか、最新バージョンの .NET Framework にアップグレードします。 これにより、OperationContext.Current の ExecutionContext のフローが無効になります。 この動作は構成可能です。構成ファイルに次のアプリ設定を追加することと同じです。
<appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

Reentrant サービスの場合、Switch.System.ServiceModel.DisableOperationContextAsyncFlow の値は false に設定しないでください。

名前 値
スコープ マイナー
バージョン 4.6.2
種類 再ターゲット中

影響を受ける API

OperationContext.Current が using 句で呼びされたときに null を返す場合がある

説明

次のすべての条件が満たされている場合は、OperationContext.Current が null を返し、NullReferenceException が発生する可能性があります。

using (new OperationContextScope(OperationContext.Current))
{
    // OperationContext.Current is null.
    OperationContext context = OperationContext.Current;

    // ...
}

提案される解決策

この問題に対処するために、次の操作を行うことができます。

  • 次のようにコードを変更して、新しい null 以外の Current オブジェクトをインスタンス化します。

    OperationContext ocx = OperationContext.Current;
using (new OperationContextScope(OperationContext.Current))
{
    OperationContext.Current = new OperationContext(ocx.Channel);

    // ...
}

  • 最新の更新プログラムを .NET framework 4.6.2 にインストールするか、最新バージョンの .NET Framework にアップグレードします。 これにより、OperationContext.Current で ExecutionContext のフローが無効になり、.NET Framework 4.6.1 以前のバージョンで WCF アプリケーションの動作が復元されます。 この動作は構成可能です。構成ファイルに次のアプリ設定を追加することと同じです。

    <appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

    この変更が望ましくなく、アプリケーションが操作コンテキスト間の実行コンテキスト フローに依存している場合は、次のようにそのフローを有効にできます。

    <appSettings>
  <add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="false" />
</appSettings>
名前 値
スコープ エッジ
バージョン 4.6.2
種類 再ターゲット中

影響を受ける API

WCF トランスポート セキュリティで CNG を使用して格納される証明書をサポート

説明

.NET Framework 4.6.2 を対象とするアプリ以降では、WCF トランスポート セキュリティでは、Windows 暗号化ライブラリ (CNG) を使用して格納される証明書がサポートされます。 このサポートは、指数の長さが 32 ビット以下の公開キーを持つ証明書に限定されます。 アプリケーションが対象 .NET Framework 4.6.2、ときにこの機能は既定でオンです。 .NET Framework の以前のバージョンで X509 を使用しようとすると、証明書を CSG のキー記憶域プロバイダーが例外をスローします。

提案される解決策

.NET Framework 4.6.1 以前を対象とするものの、.NET Framework 4.6.2 で実行されているアプリの場合、app.config または web.config ファイルの <runtime> セクションに次の行を追加することで、CNG 証明書のサポートを有効にできます。

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IdentityModel.DisableCngCertificates=false" />
</runtime>

次のコードを使用してプログラムで行うこともできます。

private const string DisableCngCertificates = @"Switch.System.IdentityModel.DisableCngCertificate";

AppContext.SetSwitch(disableCngCertificates, false);

Const DisableCngCertificates As String = "Switch.System.IdentityModel.DisableCngCertificates"
AppContext.SetSwitch(disableCngCertificates, False)

この変更のため、CNG 証明書の失敗で、セキュリティで保護された通信を開始する試行に依存する例外処理コードは、実行されなくなることに注意してください。

名前 値
スコープ マイナー
バージョン 4.6.2
種類 再ターゲット中

Windows フォーム

MemberDescriptor.Equals の不適切な実装

説明

MemberDescriptor.Equals メソッドの元の実装によって、比較対象のオブジェクトからの 2 つの異なる文字列プロパティである、カテゴリ名と説明文字列が比較されます。 この修正は、最初のオブジェクトの Category と 2 番目のオブジェクトの Category を比較し、最初のオブジェクトの Description と 2 番目のオブジェクトの Description を比較するものです。

提案される解決策

記述子が等しいときに false を返すことがある MemberDescriptor.Equals にアプリケーションが依存しているとき、.NET Framework のバージョン 4.6.2 以降を対象とする場合、いくつかの選択肢があります。

  • コードを変更し、MemberDescriptor.Equals メソッドの呼び出しに加え、Category フィールドと Description フィールドを手動で比較します。
  • app.config ファイルに次の値を追加し、この変更を無効にします。
<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=true" />
</runtime>

アプリケーションの対象が .NET Framework 4.6.1 以前であるが .NET Framework 4.6.2 以降で実行しているとき、この変更を有効にする場合、app.config ファイルに次の値を追加することで互換性スイッチを false に設定します。

<runtime>
  <AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=false" />
</runtime>
名前 値
スコープ エッジ
バージョン 4.6.2
種類 再ターゲット中

影響を受ける API

Windows Presentation Foundation (WPF)

CurrentCulture が、複数の WPF ディスパッチャー操作にわたって維持されない

説明

.NET Framework 4.6 以降では、System.Windows.Threading.Dispatcher 内で System.Globalization.CultureInfo.CurrentCulture または System.Globalization.CultureInfo.CurrentUICulture に加えられた変更は、そのディスパッチャー操作の終了時に失われます。 同様に、ディスパッチャー操作の外部で System.Globalization.CultureInfo.CurrentCulture または System.Globalization.CultureInfo.CurrentUICulture に加えられた変更は、その操作の実行時には反映されない場合があります。具体的に言うと、System.Globalization.CultureInfo.CurrentCulture と System.Globalization.CultureInfo.CurrentUICulture の変更は、WPF UI コールバックと WPF アプリケーション内の他のコードの間でフローされない場合があるということです。これは、System.Threading.ExecutionContext の変更によるものであり、この変更により、.NET Framework 4.6 以降を対象とするアプリでは、System.Globalization.CultureInfo.CurrentCulture および System.Globalization.CultureInfo.CurrentUICulture は実行コンテキストに格納されます。 WPF ディスパッチャー操作は、操作を開始するために使用された実行コンテキストを格納して、操作が完了したときに、以前のコンテキストを復元します。 System.Globalization.CultureInfo.CurrentCulture と System.Globalization.CultureInfo.CurrentUICulture がそのコンテキストの一部になったため、ディスパッチャー操作内でそれらに加えられた変更は、操作の外部では保持されません。

提案される解決策

この変更による影響を受けるアプリは、望ましい System.Globalization.CultureInfo.CurrentCulture または System.Globalization.CultureInfo.CurrentUICulture をフィールドに格納し、すべてのディスパッチャー操作の本体 (UI イベントのコールバック ハンドラーを含む) で、正しい System.Globalization.CultureInfo.CurrentCulture と System.Globalization.CultureInfo.CurrentUICulture が設定されていることを確認することによって回避できます。 または、この WPF の変更の元となっている ExecutionContext の変更は、.NET Framework 4.6 以降を対象とするアプリのみに影響するため、.NET Framework 4.5.2 を対象とすることによって、この問題を回避できます。また、.NET Framework 4.6 以降を対象とするアプリでは、以下の互換性スイッチを設定することでこの問題を回避することができます。

AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);

この問題は、.NET Framework 4.6.2 の WPF で修正されました。 また、.NET Frameworks 4.6、4.6.1 では KB 3139549 を通じて修正されました。 .NET Framework 4.6 以降を対象とするアプリケーションでは WPF アプリケーション (System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) の正しい動作が自動的に取得されます。これは、ディスパッチャー操作にわたって維持されます。

名前 値
スコープ マイナー
バージョン 4.6
種類 再ターゲット中