.NET Framework 4.5.x への移行に関するランタイム変更

  • [アーティクル]

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

.NET Framework 4.5

ASP.NET

AllowCustomPaging が true に設定された GridView では、ビューの最終ページから他に移動するときに、PageIndexChanging イベントが発生する場合がある

説明

.NET Framework 4.5 でのバグのため、System.Web.UI.WebControls.GridView.AllowCustomPaging が有効になっている System.Web.UI.WebControls.GridView に対して System.Web.UI.WebControls.GridView.PageIndexChanging が発生しないことがあります。

提案される解決策

この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。 回避策として、アプリでは、これらの条件 (System.Web.UI.WebControls.GridView が最終ページで、最後の System.Web.UI.WebControls.GridView.PageSize が System.Web.UI.WebControls.GridView.PageSize と異なる) を満たす Page_Load で明示的に BindGrid を行うことができます。 または、(カスタム ページングではなく) ページングを許可するようにアプリを変更することもできます。このシナリオでは問題は発生していません。

名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

HttpRequest.ContentEncoding プロパティで UTF7 が禁止される

説明

.NET Framework 4.5 以降では、System.Web.HttpRequest の本文では UTF-7 エンコードが禁止されます。 UTF-7 データの受信を必要とするアプリケーションのデータが、正しくデコードされない場合があります。

提案される解決策

理想的には、System.Web.HttpRequest で UTF-7 エンコードを使用しないようにアプリケーションを更新する必要があります。 または、 appSettings 要素の aspnet:AllowUtf7RequestContentEncoding 属性を使用して、レガシ動作に戻すことができます。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

HttpUtility.JavaScriptStringEncode でアンパサンドがエスケープされる

詳細

.NET Framework 4.5 以降では、System.Web.HttpUtility.JavaScriptStringEncode(String) でアンパサンド (&) 文字がエスケープされます。

推奨事項

アプリがこのメソッドの以前の動作に依存している場合、構成ファイルの ASP.NET appSettings 要素 に aspnet:JavaScriptDoNotEncodeAmpersand 設定を追加できます。

名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

iPad はブラウザー機能になったため、カスタム機能ファイルでは使用できない

説明

.NET Framework 4.5 以降では、iPad は既定の ASP.NET ブラウザー機能ファイルの識別子であるため、カスタム機能ファイルでは使用できません

提案される解決策

iPad 固有の機能が必要な場合は、ユーザー エージェントのマッチングで新しい "IPad" ID を生成するのではなく、定義済みのゲートウェイ refID "IPad" で機能を設定して、iPad の動作を変更する必要があります。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

Page.LoadComplete イベントによって、System.Web.UI.WebControls.EntityDataSource コントロールがデータ バインディングを呼び出さなくなりました

説明

LoadComplete イベントが原因で、System.Web.UI.WebControls.EntityDataSource のコントロールがパラメーターの作成/更新/削除に変更を加えるためにデータ バインディングを呼び出すことがなくなりました。 この変更により、データベースへの不要なアクセスが排除され、コントロールの値がリセットされるのを防ぐことができるほか、System.Web.UI.WebControls.SqlDataSource や System.Web.UI.WebControls.ObjectDataSourceなどのように他のデータ コントロールと一貫性の取れた動作が生成されます。 この変更により、アプリケーションが LoadComplete イベントのデータ バインディングの呼び出しに依存するような珍しい状況において、異なる動作が生成されるようになりました。

提案される解決策

データバインドの必要がある場合は、ポストバックの前半であるイベントでデータバインドを手動で呼び出します。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

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

ASP.NET MVC4 アプリのプロファイリングにより、致命的な実行エンジン エラーが発生する可能性がある

説明

NGEN/プロファイル アセンブリを使用するプロファイラーにより、起動時にプロファイルされた ASP.NET MVC4 アプリケーションがクラッシュし、"致命的な実行エンジン例外" が示される場合があります。

提案される解決策

この問題は、.NET Framework 4.5.2 で修正されます。 プロファイラーは、イベント マスクで COR_PRF_DISABLE_ALL_NGEN_IMAGES を指定することで、この問題を回避することもできます。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

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

ASP.NET StateServer とセッション状態を共有するには、Web ファーム内のすべてのサーバーが同じ .NET Framework バージョンを使用する必要がある

説明

System.Web.SessionState.SessionStateMode.StateServer セッション状態を有効にする場合、状態を正しく共有するには、指定の Web ファーム内のすべてのサーバーが同じバージョンの .NET Framework を使用する必要があります。

提案される解決策

同時に状態を共有する Web サーバー上で必ず .NET Framework バージョンのアップグレードを行います。

Value
スコープ エッジ
Version 4.5
Type ランタイム

影響を受ける API

WebUtility.HtmlDecode が無効な入力シーケンスをデコードしなくなった

説明

既定では、デコード メソッドによって無効な入力シーケンスが無効な UTF-16 文字列にデコードされることがなくなりました。 代わりに、元の入力が返されます。

提案される解決策

デコーダーの出力の変更は、UTF-16 データではなくバイナリ データを文字列に格納した場合にのみ影響があります。 明示的にこの動作を制御するには、appSettings 要素の aspnet:AllowRelaxedUnicodeDecoding 属性を true に設定して従来の動作を有効にするか、false に設定して現在の動作を有効にします。

Value
スコープ マイナー
Version 4.5
Type ランタイム

影響を受ける API

コア

Regex.CompileToAssembly でコンパイルされたアセンブリは 4.0 と 4.5 の間で区別されます

説明

コンパイル済みの正規表現のアセンブリが .NET Framework 4.5 でビルドされ、.NET Framework 4 を対象としている場合、.NET Framework 4 がインストールされているシステム上でそのアセンブリの正規表現の 1 つを使用しようとすると、例外をスローします。

提案される解決策

この問題を回避するには、次のいずれかの方法を実行します。

  • .NET Framework 4 を使用して正規表現を含むアセンブリをビルドします。
  • 解釈される正規表現を使用します。
名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

BlockingCollection<T>.TryTakeFromAny がスローしなくなった

説明

入力コレクションの 1 つに完了のマークが付けられた場合、TryTakeFromAny(BlockingCollection<T>[], T) -1 を返さず、TakeFromAny(BlockingCollection<T>[], T)例外をスローしなくなりました。 この変更の結果、コレクションの 1 つが空であったり完了していても、他のコレクションに取得できる項目がある場合にコレクションで作業をすることができるようになりました。

提案される解決策

-1 を返す TryTakeFromAny またはスローする TakeFromAny が制御フロー目的で使用されていた場合、ブロッキング コレクションが完了する場合、そのようなコードは、その条件を検出するように .Any(b =&gt; b.IsCompleted) を使用するように変更される必要があります。

名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

タイムアウト引数を持つ Task.WaitAll メソッドの動作の変更

説明

.NET Framework 4.5 では、Task.WaitAll の動作が、より一貫性のあるものになりました。 .NET Framework 4 では、これらのメソッドの動作に一貫性がありませんでした。 タイムアウトの期限が切れたときに、メソッドを呼び出す前に完了した、またはキャンセルされたタスクが 1 つ以上ある場合、メソッドでは System.AggregateException 例外がスローされていました。 タイムアウトの期限が切れると、メソッド呼び出しの前に完了またはキャンセルされたタスクはなかったが、メソッド呼び出し後に 1 つ以上のタスクがこれらの状態になると、メソッドは false を返しました。

.NET Framework 4.5 では、これらのメソッドのオーバーロードは、タイムアウト期限が切れたときにタスクがまだ実行中であった場合は false を返し、入力タスクがキャンセルされ (メソッド呼び出しの前か後かに関わらず)、他に実行中のタスクがなかった場合に限り、System.AggregateException 例外をスローします。

推奨事項

WaitAll 呼び出しが呼び出される前にキャンセルされたタスクを検出する手段として System.AggregateException がキャッチされていた場合、.NET Framework 4.6 は、すべての待機中タスクがタイムアウトの前に完了した場合に限ってスローするため、そのコードは、代わりに IsCanceled プロパティによって同じ検出を行う必要があります (例: .Any(t => t.IsCanceled))。

Value
スコープ マイナー
Version 4.5
Type ランタイム

影響を受ける API

mscorlib の複数バージョン対応時の型転送のコンパイラ サポート

説明

新しい CodeDOM の機能を使用すると、mscorlib.dll の .NET Framework 4.5 バージョンではなく、mscorlib.dll の対象バージョンに対してコンパイルできるようになります。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

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

ConcurrentQueue<T>.TryPeek は、出力パラメーターを介して誤った null を返すことがあります

説明

一部のマルチ スレッド シナリオでは、System.Collections.Concurrent.ConcurrentQueue<T>.TryPeek(T) は true を返すことができますが、出力パラメーターに (正しいピーク値の代わりに) null 値を入れることがあります。

提案される解決策

この問題は、.NET Framework 4.5.1 で修正されます。 この Framework にアップグレードすると、問題が解決されます。

名前 値
スコープ Major
バージョン 4.5
種類 ランタイム

影響を受ける API

ETW EventListeners は、明示的なキーワードを持つプロバイダーからのイベント (TPL プロバイダーなど) をキャプチャしません

説明

空白のキーワード マスクを持つ ETW EventListeners は、明示的なキーワードを持つプロバイダーからのイベントを正しくキャプチャしません。 .NET Framework 4.5 では、TPL プロバイダーは、明示的なキーワードを提供するようになり、この問題が発生しました。 .NET Framework 4.6 では、EventListeners が更新され、この問題は修正されました。

提案される解決策

この問題を回避するには、EnableEvents(EventSource, EventLevel) の呼び出しを、使用する "any keywords" マスクを明示的に指定する EnableEvents オーバーロードの呼び出し (EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff))) に置き換えます。

または、この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

System.Threading.Tasks.Task で監視されていない処理中の例外が、ファイナライザー スレッドに伝播されなくなった

説明

System.Threading.Tasks.Task クラスは非同期操作を表すため、非同期処理中に発生する重大ではない例外がすべてキャッチされます。 .NET Framework 4.5 では、例外が監視されていず、コードがタスクを待機していない場合、例外はファイナライザー スレッドに伝播されなくなり、ガベージ コレクション時にプロセスをクラッシュします。 この変更により、Task クラスを使用して、監視されていない非同期処理を実行するアプリケーションの信頼性が向上します。

提案される解決策

アプリが、監視されていない非同期例外のファイナライザー スレッドへの伝播に依存している場合、UnobservedTaskException イベントの適切なハンドラーを提供することによって、またはランタイム構成要素を設定することによって、以前の動作を復元できます。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

List.Sort アルゴリズムが変更された

説明

.NET Framework 4.5 以降では、System.Collections.Generic.List<T> の並べ替えアルゴリズムが (クイック並べ替えではなく、内省的な並べ替えになるように) 変更されました。 System.Collections.Generic.List<T> の並べ替えは安定しますが、この変更により、さまざまなシナリオが不安定な方法で並べ替えられる可能性があります。 これは単に、同等の項目が API の後続の呼び出しで異なる順序で並べ替えられる可能性があることを意味します。

提案される解決策

以前の並べ替えアルゴリズムも不安定であるため (ただし、方法は若干異なる)、特定の順序で常に並べ替える同等の項目に依存するコードがあってはなりません。 それに依存していて、以前の動作で問題がないコードのインスタンスが存在する場合は、適切な順序で項目を決定論的に並べ替える比較子を使用するようにそのコードを更新する必要があります。

名前 値
スコープ 透明
バージョン 4.5
種類 ランタイム

影響を受ける API

ターゲット フレームワーク モニカーがないと、4.0 の動作になる

説明

アセンブリ レベルで System.Runtime.Versioning.TargetFrameworkAttribute が適用されていないアプリケーションは、自動的に .NET Framework 4.0 のセマンティクス (quirks) を使用して実行します。 高い品質を確保するには、すべてのバイナリを、ビルドされた .NET Framework のバージョンを示す System.Runtime.Versioning.TargetFrameworkAttribute で明示的に属性指定することをお勧めします。 プロジェクト ファイルでターゲット フレームワーク モニカーを使用すると、MSBuid は System.Runtime.Versioning.TargetFrameworkAttribute を自動的に適用します。

提案される解決策

System.Runtime.Versioning.TargetFrameworkAttribute は、属性をアセンブリに直接追加するか、プロジェクト ファイルで、または Visual Studio のプロジェクト プロパティ GUI でターゲット フレームワークを指定することによって指定する必要があります。

名前 値
スコープ Major
バージョン 4.5
種類 ランタイム

影響を受ける API

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

一部の .NET API がファースト チャンス (処理済み) EntryPointNotFoundExceptions の原因になります

説明

.NET Framework 4.5 では、少数の .NET メソッドが、ファースト チャンス System.EntryPointNotFoundException をスローするようになりました。 これらの例外は .NET Framework 内で処理されますが、ファースト チャンス例外を予期していないテスト自動化を中断することがありました。 これらと同じ API は、HighVersionLie が有効なとき、一部の ApiVerifier シナリオを中断させます。

提案される解決策

このバグは、.NET Framework 4.5.1 にアップグレードすることによって回避できます。 または、ファースト チャンス System.EntryPointNotFoundException 例外で中断しないように、テスト自動化を更新できます。

Value
スコープ エッジ
Version 4.5
Type ランタイム

影響を受ける API

System.Threading.Tasks.Task は、オブジェクトが破棄された後、ObjectDisposedException をスローしなくなりました

説明

IAsyncResult.AsyncWaitHandleを除き、System.Threading.Tasks.Task メソッドでオブジェクトが破棄された後も System.ObjectDisposedException の例外がスローされることがなくなりました。この変更により、キャッシュされたタスクを使用できるようになりました。 たとえば、メソッドで新しいタスクを割り当てる代わりに、既に完了した操作を表す、キャッシュされたタスクを返すことができます。 これは、タスクの任意のコンシューマーによって破棄されてしまうと、使用不可能になってしまう以前の .NET Framework のバージョンでは不可能でした。

提案される解決策

オブジェクトが破棄されたとき、Task メソッドが System.ObjectDisposedException をスローしなくなったことに注意してください。 アプリが、タスクが破棄されたことを確認するために、この例外に依存していた場合は、Status を使用してタスクのステータスを明示的に確認するように、アプリを更新する必要があります。

名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

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

System.Uri エスケープで RFC 3986 がサポート対象に

説明

URI エスケープは、.NET Framework 4.5 で、RFC 3986 をサポートするように変更されました。 具体的な変更内容:

提案される解決策

  • 無効なエスケープ シーケンスの場合、System.Uri.UnescapeDataString(String) のスローに依存しないように、アプリケーションを更新します。 このようなシーケンスは、直接削除する必要があります。
  • 同様に、エスケープおよびエスケープ解除された URI とデータ文字列は、.NET Framework 4.0 と .NET Framework 4.5 で異なる場合があるため、.NET のバージョン間で直接比較しないでください。 代わりに、1 つの .NET バージョンで解析と正規化を行ってから比較してください。
名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

Data

sql_variant データはデータベースの照合順序ではなく、sql_variant の照合順序を使用する

説明

sql_variant データはデータベースの照合順序ではなく sql_variant の照合順序を使用します。

提案される解決策

この変更により、データベースの照合順序が sql_variant の照合順序と異なる場合にデータ破損が生じる可能性に対応できます。 破損したデータに依存するアプリケーションでは、エラーが発生する場合があります。

名前 値
スコープ 透明
バージョン 4.5
種類 ランタイム

影響を受ける API

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

SqlBulkCopy で文字列に挿入先の列エンコードが使用される

説明

データを列に挿入する場合、System.Data.SqlClient.SqlBulkCopy は VARCHAR と CHAR の型の既定エンコードではなく、挿入先の列のエンコードを使用します。 この変更により、挿入先の列が既定のエンコードを使用しない場合に、既定のエンコードを使用することによって発生するデータ破損の可能性がなくなります。 まれに、エンコードに変更を加えることによって、挿入先の列に収まりきらない大きいデータが生成された場合に、既存のアプリケーションで SqlException の例外がスローされることがあります。

提案される解決策

System.Data.SqlClient.SqlBulkCopy では、エンコードが異なるため、データは破損しなくなると予想します。 挿入先の列のサイズ制限に近づいている文字列がコピーされている場合、データの事前エンコード (コピーして挿入先の行にデータが収まることを確認するため) や System.Data.SqlClient.SqlException のキャッチが必要になることがあります。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

SqlConnection は VIA アダプターを使用して SQL Server 1997 またはデータベースに接続できなくなりました

説明

仮想インターフェイス アダプター (VIA) プロトコルを使用した SQL Server データベースへの接続はサポートされなくなりました。 SQL Server データベースへの接続に使用されるプロトコルは、接続文字列で表示されます。 VIA 接続には via:<servername> が含まれます。 このアプリが VIA 以外のプロトコル (tcp: や np: など) を介して SQL に接続している場合、破壊的変更は発生しません。 また、SQL Server 7 (1997) への接続はサポートされなくなりました。

提案される解決策

VIA プロトコルは推奨されていないので、SQL データベースに接続するには別のプロトコルを使用する必要があります。 最も一般的に使用されるプロトコルは TCP/IP です。 TCP/IP での接続の詳細については、「方法: データベース インスタンスの TCP/IP プロトコルを有効にする」を参照してください。 データベースへのアクセスがイントラネット内からに限定されていて、ネットワーク速度が遅い場合は、共有パイプ プロトコルがより優れたパフォーマンスを提供する可能性があります。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

IFS 以外の Winsock BSP または LSP が存在する Windows 7 で SqlConnection.Open が失敗する

説明

Open() および OpenAsync(CancellationToken) は、コンピューター上に IFS 以外の Winsock BSP または LSP が存在する Windows 7 コンピューターで実行している場合、.NET Framework 4.5 では失敗します。IFS 以外の BSP または LSP がインストールされているかどうかを確認するには、netsh WinSock Show Catalog コマンドを使用して、返される Winsock Catalog Provider Entry 項目をすべて調べてください。 Service Flags 値の 0x20000 ビットがセットされている場合、プロバイダーは IFS ハンドルを使用していて、正しく機能します。 0x20000 ビットがクリアされている (セットされていない) 場合は、IFS 以外の BSP または LSP です。

提案される解決策

このバグは .NET framework 4.5.2 で修正されたため、.NET Framework をアップグレードすることによって回避できます。 または、インストールされている IFS 以外の Winsock LSP を削除することによって回避できます。

名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

デバッガー

デバッガーですぐに null コアレッサー値が表示されない

説明

.NET Framework 4.5 のバグにより、64 ビット版の Framework で実行中に代入演算が実行された直後に、デバッガーで null 合体演算で設定された値が表示されません。

提案される解決策

デバッガーでの操作に時間がかかると、ローカル/フィールドの値が正しく更新されなくなります。 この問題は .NET Framework 4.6 で修正されました。このバージョンの .NET Framework にアップグレードすれば、問題は解決します。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

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

Entity Framework

データ定義言語 (DDL: Data Definition Language) API の動作の変更

説明

AttachDBFilename が指定されたときの DDL API の動作が、次のように変更されました。

  • 接続文字列で初期カタログ値を指定する必要がなくなりました。 以前は、AttachDBFilename と初期カタログの両方が必要でした。
  • AttachDBFilename と初期カタログの両方が指定され、指定された MDF ファイルが存在した場合、DatabaseExists メソッドは true を返します。 以前は、falseが返されていました。
  • AttachDBFilename と初期カタログの両方が指定され、指定された MDF ファイルが存在した場合、DeleteDatabase メソッドを呼び出すと、ファイルが削除されます。
  • 接続文字列で存在しない MDF の AttachDBFilename 値および存在しない初期カタログが指定されたときに DeleteDatabase が呼び出されると、メソッドでは InvalidOperationException 例外がスローされます。 以前は、SqlException の例外がスローされていました。

提案される解決策

これらの変更により、DDL API を使用するアプリケーションおよびツールの構築が簡単になりました。 これらの変更は、次のシナリオでアプリケーションの互換性に影響を及ぼす可能性があります。

  • DROP DATABASE で DeleteDatabase が返されたときに、DatabaseExists を呼び出す代わりに直接 true コマンドを実行するコードをユーザーが作成した場合。 データベースがアタッチされておらず、MDF ファイルが存在する場合、これによって既存のコードが破損します。
  • 初期カタログと MDF ファイルが存在しない場合に、InvalidOperationException ではなく SqlException をスローするように、DeleteDatabase メソッドを要求するコードをユーザーが作成した場合。
名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

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

ObjectContext.CreateDatabase メソッドと DbProviderServices.CreateDatabase メソッドで異なる例外処理

説明

.NET Framework 4.5 から、データベースの作成が失敗した場合、CreateDatabase メソッドは、空のデータベースの削除を試みます。 その操作が成功した場合、元の System.Data.SqlClient.SqlException は伝播されます (.NET Framework 4.0 で常にスローされていた System.InvalidOperationException の代わりに)

提案される解決策

CreateDatabase() または CreateDatabase(DbConnection, Nullable<Int32>, StoreItemCollection) の実行中に System.InvalidOperationException をキャッチするときには、SQLExceptions もキャッチする必要があります。

名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

EntityFramework 6.0 は、Visual Studio から起動されたアプリを読み込むとき、非常に遅くなる

説明

Entity Framework 6.0 を使用するアプリを Visual Studio 2013 から起動すると、非常に遅くなることがあります。

提案される解決策

この問題は、EntityFramework 6.0.2 で修正されます。 パフォーマンス問題を回避するには、EntityFramework を更新します。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

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

ObjectContext.CreateDatabase メソッドによって作成されたログ ファイル名が、SQL Server の仕様に一致するように変更された

説明

System.Data.Objects.ObjectContext.CreateDatabase() メソッドが、直接、または SqlClient プロバイダーと共に Code First と接続文字列の AttachDBFilename 値を使用して呼び出されると、filename.ldf (filename は AttachDBFilename 値によって指定されたファイルの名前) ではなく、filename_log.ldf という名前のログ ファイルを作成します。 この変更により、SQL Server の仕様に従ってログ ファイル名が提供されるため、デバッグ機能が向上します。

提案される解決策

ログ ファイル名がアプリケーションにとって重要な場合、標準の _log.ldf ファイル名形式を予期するように、アプリケーションを更新する必要があります。

Value
スコープ エッジ
Version 4.5
Type ランタイム

影響を受ける API

ObjectContext.Translate と ObjectContext.ExecuteStoreQuery で列挙型がサポートされるようになった

説明

.NET Framework 4.0 では、ObjectContext.Translate および ObjectContext.ExecuteStoreQuery メソッドのジェネリック パラメーター T を列挙型にすることはできませんでした。 このシナリオがサポートされるようになりました。

提案される解決策

.NET Framework 4.0 では、列挙型に対して Translate または ExecuteStoreQuery が呼び出された場合、"0" が返されました。 この動作が望ましい場合は、呼び出しを定数 0 (または同等の列挙型) に置き換えてください。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

LINQ

Enumerable.Empty<TResult> は、常にキャッシュされたインスタンスを返します

説明

.NET Framework 4.5 以降では、Empty<TResult>() は、常にキャッシュされた内部インスタンス IEnumerable<T> を返します。以前は、Empty<TResult>() は、API が呼び出された時点で空の IEnumerable<T> をキャッシュしました。つまり、Empty<TResult>() が迅速かつ同時に呼び出されるような条件では、API の別の呼び出しに対して、型の別のインスタンスが返される可能性がありました。

提案される解決策

以前の動作は非確定的なため、コードがそれに依存している可能性は低いです。 ただし、ありそうにないことですが、空の列挙が比較され、ときには等しくないことが予期されている場合には、Empty<TResult>() を使用する代わりに、明示的に空の配列を作成する (new T[0]) 必要があります。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

MEF (Managed Extensibility Framework)

MEF カタログは IEnumerable を実装するため、シリアライザーの作成には使用できなくなった

説明

.NET Framework 4.5 以降では、MEF カタログは IEnumerable を実装するため、シリアライザー (System.Xml.Serialization.XmlSerializer オブジェクト) の作成には使用できなくなりました。 MEF カタログをシリアル化しようとすると、例外がスローされます。

提案される解決策

シリアライザーの作成に MEF を使用できなくなりました。

名前 値
スコープ Major
バージョン 4.5
種類 ランタイム

影響を受ける API

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

ネットワーキング

.NET Framework 4.5 でシリアル化された MailMessage オブジェクトの逆シリアル化が失敗する可能性がある

説明

.NET Framework 4.5 以降では、MailMessage オブジェクトに非 ASCII 文字を含めることができます。 .NET Framework 4 では、ASCII 文字しかサポートされていません。 非 ASCII 文字が含まれ、.NET Framework 4.5 以降でシリアル化された MailMessage オブジェクトは、.NET Framework 4 で逆シリアル化することはできません。

提案される解決策

MailMessage オブジェクトの逆シリアル化時に、コードで例外処理が提供されることを確認します。

名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

Windows 8 で System.Net.PeerToPeer.Collaboration が使用できない

説明

System.Net.PeerToPeer.Collaboration 名前空間は、Windows 8 以上では使用できません。

提案される解決策

Windows 8 以上をサポートするアプリは、この名前空間またはそのメンバーに依存しないように更新する必要があります。

名前 値
スコープ Major
バージョン 4.5
種類 ランタイム

影響を受ける API

印刷

PrintSystemJobInfo.JobStream に書き込まれるデータは XPS 形式とする必要があります

説明

JobStream プロパティにより印刷ジョブのストリームが公開されます。 ユーザーが基になるオペレーティング システム印刷コンポーネントに生のデータを送信するには、このストリームにデータを書き込みを行います。 .NET Framework 4.5 以降、Windows 8 より後のバージョンの Windows オペレーティング システムでは、このストリームに書き込むデータは XPS 形式のパッケージ ストリームにする必要があります。

提案される解決策

印刷内容を出力するには、次のいずれかの操作を行います。

  • XpsDocumentWriter クラスを使用して印刷内容を出力します。 これが、推奨される方法です。
  • JobStream プロパティによって返されるストリームに送信されるデータを、XPS 形式のパッケージ ストリームにします。
名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

シリアル化

BinaryFormatter による LoadFrom コンテキストからの型の検索が失敗する場合がある

説明

.NET Framework 4.5 の時点で、System.Xml.Serialization.XmlSerializer の複数の変更により、LoadFrom コンテキストに読み込まれた型の System.Runtime.Serialization.Formatters.Binary.BinaryFormatter を使った逆シリアル化に違いが発生する場合があります。 これらの変更は System.Xml.Serialization.XmlSerializer が型を読み込む新しい方法によるものであり、後で System.Runtime.Serialization.Formatters.Binary.BinaryFormatter がその型に逆シリアル化しようとするときに異なる動作が発生します。 既定のシリアル化バインダーは LoadFrom コンテキストを自動的に検索しませんが、状況によっては XmlSerializer の以前の動作に基づいて機能する可能性があります。 変更のため、異なるコンテキストで読み込まれたアセンブリから型が読み込まれるときに、System.IO.FileNotFoundException がスローされる可能性があります。

警告

BinaryFormatter によるバイナリ シリアル化は危険が伴う場合があります。 詳しくは、「BinaryFormatter セキュリティ ガイド」をご覧ください。

提案される解決策

この例外が発生する場合は、System.Runtime.Serialization.Formatters.Binary.BinaryFormatter の Binder プロパティを、正しい型を検索するカスタム バインダーに設定することができます。

var formatter = new BinaryFormatter { Binder = new TypeFinderBinder() }

そして、カスタム バインダーで次のようにします。

public class TypeFinderBinder : SerializationBinder
{
    private static readonly string s_assemblyName = Assembly.GetExecutingAssembly().FullName;

    public override Type BindToType(string assemblyName, string typeName)
    {
        return Type.GetType(String.Format(CultureInfo.InvariantCulture, "{0}, {1}", typeName, s_assemblyName));
    }
}
名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

SoapFormatter は、ハッシュテーブルなどの順序付けられたコレクション オブジェクトを逆シリアル化できない

説明

System.Runtime.Serialization.Formatters.Soap.SoapFormatter は、特定のバージョンの .NET Framework でシリアル化されたオブジェクトが別のバージョンで正常に逆シリアル化されることを保証しません。 具体的には、(System.Collections.Hashtable のような) 順序付けられたコレクションの中には、4.0 と 4.5 の間でメンバーが追加されたものがあり、このような種類のオブジェクトが .NET Framework 4.5 でシリアル化された場合、.NET Framework 4.0 では逆シリアル化できません。 シリアル化データのシリアル化と逆シリアル化の両方が同じバージョンの .NET Framework で行われた場合、問題は発生しないことに注意してください。

提案される解決策

System.Runtime.Serialization.Formatters.Soap.SoapFormatter のシリアル化は、.NET Framework の変更に対応できる System.Runtime.Serialization.Formatters.Binary.BinaryFormatter のシリアル化または System.Runtime.Serialization.NetDataContractSerializer に置き換える必要があります。

警告

BinaryFormatter によるバイナリ シリアル化は危険が伴う場合があります。 詳しくは、「BinaryFormatter セキュリティ ガイド」をご覧ください。

名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

アクセス可能なメンバーを非表示にする型をアクセス不可のメンバーでシリアル化すると、XmlSerializer が失敗する

説明

基本型で (パブリックなど) 以前はアクセス可能だった同じ名前のフィールドまたはプロパティを ("新しい" キーワードを使用して) 非表示にするアクセス不可のフィールドまたはプロパティが型に含まれている場合、派生型をシリアル化すると、System.Xml.Serialization.XmlSerializer が失敗する可能性があります。

サジェスチョン

この問題は、新しい非表示メンバーを System.Xml.Serialization.XmlSerializer にアクセス可能にすることで解決できます (たとえば、パブリック マークをつけるなど)。 または、次の構成の設定で 4.0 System.Xml.Serialization.XmlSerializer 動作に戻され、これによって問題が解決されます。

<system.xml.serialization>
<xmlSerializer useLegacySerializerGeneration="true" />
</system.xml.serialization>
名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

Web アプリケーション

.NET Framework 1.1 および 2.0 からのマネージド ブラウザーでのコントロールのホストがブロックされる

説明

これらのコントロールのホストは、Internet Explorer でブロックされます。

提案される解決策

Internet Explorer では、マネージド ブラウザーを使用してコントロールをホストするアプリケーションは起動できません。 以前の動作を復元するには、レジストリ サブキー HKLM/SOFTWARE/MICROSOFT/.NETFramework の EnableIEHosting 値を、x86 システム用および x64 システム上の 32 ビット プロセス用に 1 に設定し、レジストリ サブキー HKLM/SOFTWARE/Wow6432Node/Microsoft/.NETFramework の EnableIEHosting 値を x64 システム上の 64 ビット プロセス用に 1 に設定します。

名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

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

Windows Communication Foundation (WCF)

maxRequestLength または maxReceivedMessageSize のエラー コードが異なる

説明

Internet Information Services (IIS) または ASP.NET 開発サーバーでホストされており、maxRequestLength (ASP.NET の場合) または maxReceivedMessageSize (WCF の場合) を超える WCF Web サービスのメッセージに異なるエラー コードがあります。HTTP 状態コードは 400 (正しくない要求) から 413 (要求したエンティティが大きすぎます) に変更され、maxRequestLength または maxReceivedMessageSize 設定を超えるメッセージでは System.ServiceModel.ProtocolException 例外がスローされます。 これには、転送モードが Streamed である場合も含まれます。

提案される解決策

この変更により、メッセージ長が ASP.NET または WCF で許可されている制限を超えたときのデバッグが簡単になります。HTTP 400 状態コードに基づいて処理を実行するコードはすべて変更する必要があります。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

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

System.ServiceModel.Web.WebServiceHost オブジェクトは、既定のエンドポイントを追加しなくなりました

説明

WebServiceHost オブジェクトでは、アプリケーション コードによって明示的なエンドポイントが追加された場合に、既定のエンドポイントが追加されなくなりました。

提案される解決策

ユーザーが既定のエンドポイントに接続できることを期待していて、他の明示的なエンドポイントが System.ServiceModel.Web.WebServiceHost に追加されている場合は、既定のエンドポイントも明示的に追加する必要があります (System.ServiceModel.ServiceHostBase.AddDefaultEndpoints() を使用して)。

名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

OData URL の Replace メソッドが既定で無効になる

説明

.NET Framework 4.5 以降では、OData URL の Replace メソッドは既定では無効です。 OData Replace が無効のとき (既定)、replace 関数を含むユーザー要求 (一般的ではない) は失敗します。

提案される解決策

Replace メソッドが必要な場合 (一般的ではない)、構成設定 (System.Data.Services.Configuration.DataServicesFeaturesSection.ReplaceFunction) によって再び有効にできます。 ただし、有効になった replace メソッドはセキュリティの脆弱性を開くことがあり、慎重にレビューしてから使用する必要があります。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

Windows フォーム

PreviewLostKeyboardFocus は、そのハンドラーが Windows フォーム メッセージ ボックスを表示する場合、繰り返し呼び出される

説明

.NET Framework 4.5 以降では、PreviewLostKeyboardFocus ハンドラーから MessageBox.Show を呼び出すと、メッセージ ボックスが閉じられたとき、ハンドラーが再実行して、メッセージ ボックスの無限ループになる可能性があります。

提案される解決策

この問題を回避するには、2 つの方法があります。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

WinForm の CheckForOverflowUnderflow プロパティが System.Drawing に対して true に設定されるようになった

説明

System.Drawing.dll アセンブリの CheckForOverflowUnderflow プロパティが true に設定されます。

提案される解決策

これまではオーバーフローが発生すると、その結果は自動的に切り捨てられました。 現在では、System.OverflowException 例外がスローされます。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

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

Windows Presentation Foundation (WPF)

DataGrid の UnloadingRow イベントのハンドラーから WPF DataGrid の選択された項目にアクセスすると、NullReferenceException が発生する可能性がある

説明

.NET Framework 4.5 のバグが原因で、行の削除に関連する DataGrid イベントのイベント ハンドラーにより、DataGrid の System.Windows.Controls.Primitives.Selector.SelectedItem または System.Windows.Controls.Primitives.MultiSelector.SelectedItems プロパティにアクセスする場合に System.NullReferenceException がスローされる可能性があります。

提案される解決策

この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。

名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

CellEditEnding ハンドラーから DataGrid.CommitEdit を呼び出すと、フォーカスが削除される

説明

System.Windows.Controls.DataGrid の System.Windows.Controls.DataGrid.CellEditEnding イベント ハンドラーのいずれかから CommitEdit() を呼び出すと、System.Windows.Controls.DataGrid からフォーカスが失われます。

提案される解決策

このバグは .NET framework 4.5.2 で修正されたため、.NET Framework をアップグレードすることによって回避できます。 または、System.Windows.Controls.DataGrid.CommitEdit() を呼び出した後で System.Windows.Controls.DataGrid を明示的に再選択することによって回避できます。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

項目が選択されている WPF ListBox、ListView、または DataGrid に対して Items.Refresh を呼び出すと、重複した項目が要素に表示されることがある

説明

.NET Framework 4.5 では、System.Windows.Controls.ListBox で項目が選択されているときにコードから ListBox.Items.Refresh を呼び出すと、選択された項目がリストに複製されることがあります。 同様の問題が System.Windows.Controls.ListView と System.Windows.Controls.DataGrid で発生します。 これは、.NET Framework 4.6 で修正されます。

提案される解決策

この問題は、System.Windows.Data.CollectionView.Refresh() が呼び出される前に、プログラムで項目を選択解除して、呼び出しの完了後に再び選択することによって回避できます。 または、この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。

Value
スコープ マイナー
Version 4.5
Type ランタイム

影響を受ける API

FlowDocument でテキストの余分な行が表示される場合がある

説明

.NET Framework 4.0 での実行時の表示と比べて、.NET Framework 4.5 での実行時に FlowDocument 要素でテキストの余分な行が表示されることがあります。 変更によってテキストが正しく表示されなくなったり、読みにくくなったりするようなことはありませんが、以前は FlowDocument のビューから除外されていたテキストが表示される可能性があります。

提案される解決策

場合によっては、表示要素の PageHeight プロパティを 1 ずつ減らすことで、表示行の以前の数を復元できます。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

GlyphRun.ComputeInkBoundingBox() と FormattedText.Extent が、.NET Framework 4.5 以降では、異なる値を返す

説明

.NET Framework 4.5 では、ComputeInkBoundingBox() と Extent が改善され、場合によっては含まれるグリフに対してボックスが小さすぎるという .NET Framework 4.0 での問題に対応しました。 この結果、.NET Framework 4.5 以降では、いくつかの境界ボックスが大きくなり、UI のレイアウトにわずかな違いが生じます。

提案される解決策

いくつかのグリフの境界ボックスのサイズが大きくなったことに注意してください。 このような変更は、通常、プレゼンテーションおよびヒット ボックス テストを向上させますが、以前の (.NET 4.5 より前の) 動作が望ましい場合は、次のエントリをアプリの構成ファイルに追加することによって実現できます。

<appsettings>
<add key="IncludeAllInkInBoundingBox" value="false">
</appsettings>
名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

カスタム DataTemplate を使用しているとき、断続的に、ItemsControl (ListBox や DataGrid など) 内の最後の項目までスクロールできない

説明

場合によっては、.NET Framework 4.5 のバグにより、カスタム DataTemplate を使用していると、ItemsControl (System.Windows.Controls.ListBox、System.Windows.Controls.ComboBox、System.Windows.Controls.DataGrid など) の最後の項目までスクロールできません。 (上へスクロールした後で) もう一度スクロールを試みると、今度はスクロールできます。

提案される解決策

この問題は .NET Framework 4.5.2 で修正されたため、このバージョン (またはそれ以降のバージョン) の .NET Framework にアップグレードすることによって対処できます。 または、ユーザーは、スクロール バーをこれらのコレクションの最後の項目までドラッグできますが、2 回試みなければならないことがあります。

名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

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

Items.Clear で SelectedItems から重複部分が削除されない

説明

セレクター (複数選択が有効になっている) の System.Windows.Controls.Primitives.MultiSelector.SelectedItems コレクションに重複部分があるとします。その場合、同じ項目が複数回表示されます。 データ ソースからこれらの項目を削除すると (たとえば、Items.Clear を呼び出すことにより)、System.Windows.Controls.Primitives.MultiSelector.SelectedItems からそれらの項目を削除できなくなります。最初のインスタンスのみが削除されます。 さらに、System.Windows.Controls.Primitives.MultiSelector.SelectedItems (SelectedItems.Clear() など) を引き続き使用すると、System.ArgumentException などの問題が発生する可能性があります。これは、System.Windows.Controls.Primitives.MultiSelector.SelectedItems に、データ ソース内にはもう存在しない項目が含まれているためです。

提案される解決策

可能であれば、.NET Framework 4.6.2 にアップグレードします。

名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

ObservableCollection<T>.Move に対する ListBoxItem IsSelected のバインディングの問題

説明

項目が選択された System.Windows.Controls.ListBox にバインドされるコレクションで Move(Int32, Int32) または MoveItem(Int32, Int32) を呼び出すと、System.Windows.Controls.ListBox 項目の今後の選択または選択解除で不規則な動作が発生する可能性があります。

提案される解決策

Move(Int32, Int32) ではなく System.Collections.ObjectModel.Collection<T>.Remove(T) と System.Collections.ObjectModel.Collection<T>.Insert(Int32, T) を呼び出すことで、この問題は解決されます。 または、この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。

名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

WPF の PageRangeSelection の新しい列挙値

説明

新しい 2 つのメンバー (System.Windows.Controls.PageRangeSelection.CurrentPage および System.Windows.Controls.PageRangeSelection.SelectedPages) が System.Windows.Controls.PageRangeSelection 列挙型に追加されました。

提案される解決策

ほとんどの場合、これらの変更はユーザー コードに影響しません。 ただし、System.Windows.Controls.PageRangeSelection 型に対する GetNames(Type) または GetValues(Type) 呼び出しに特定の数の要素が存在することに依存するコードは、修正する必要があります。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

PreviewLostKeyboardFocus は、そのハンドラーが Windows フォーム メッセージ ボックスを表示する場合、繰り返し呼び出される

説明

.NET Framework 4.5 以降では、PreviewLostKeyboardFocus ハンドラーから MessageBox.Show を呼び出すと、メッセージ ボックスが閉じられたとき、ハンドラーが再実行して、メッセージ ボックスの無限ループになる可能性があります。

提案される解決策

この問題を回避するには、2 つの方法があります。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

WPF DataGrid 行ヘッダーを右クリックすると、DataGrid の選択が変更される

説明

複数行が選択されている状態で、選択した System.Windows.Controls.DataGrid 行ヘッダーを右クリックすると、その行のみで System.Windows.Controls.DataGrid の選択が変更されます。

提案される解決策

この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

VirtualizingStackPanel 内の WPF TreeView またはグループ化された ListBox をスクロールすると、アプリケーションが応答を停止することがある

詳細

.NET Framework v4.5 では、仮想化されたスタック パネル内の WPF System.Windows.Controls.TreeView をスクロールすると、ビューポートに余白があった場合 (たとえば、System.Windows.Controls.TreeView 内の項目間や、ItemsPresenter 要素上)、アプリケーションが応答を停止するすることがあります。 さらに、場合によっては、ビュー内にサイズの異なる項目があると、余白がない場合でも、不安定になることがあります。

提案される解決策

このバグは、.NET Framework 4.5.1 にアップグレードすることによって回避できます。 または、含まれているすべての項目が同じサイズである場合は、仮想化されたスタック パネル内のビュー コレクション (System.Windows.Controls.TreeView など) から余白を削除できます。

名前 値
スコープ Major
バージョン 4.5
種類 ランタイム

影響を受ける API

WPF DataTemplate 要素が UIA に表示されるようになった

説明

以前は、System.Windows.DataTemplate 要素は UI オートメーションには表示されませんでした。 4\.5 から、UI オートメーションは、これらの要素を検出します。 これは、多くの場合に便利ですが、System.Windows.DataTemplate 要素を含まない UIA ツリーに依存するテストは中断することがあります。

提案される解決策

このアプリの UI オートメーション テストを更新して、以前は非表示の System.Windows.DataTemplate 要素を含んでいる UIA ツリーに対応できるようにしなければならないことがあります。 たとえば、いくつかの要素が互いに隣り合っていることを予期しているテストでは、以前は非表示であった UIA 要素が間にあることを予期する必要があります。 または、UIA 要素の特定のカウントまたはインデックスに依存するテストは、新しい値で更新しなければならないことがあります。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

WPF DispatcherSynchronizationContext.CreateCopy は、現在のインスタンスの代わりに新しいコピーを返すようになった

説明

.NET Framework 4 では、CreateCopy() は、主にパフォーマンスの最適化として、現在のインスタンスへの参照を返しました。 .NET Framework 4.5 では、これが新しいインスタンスになり、参照が等しければ、実行中のスレッドが正しい同期コンテキストにあると結論付けることが初めて可能になりました。 これらの参照の ID をチェックするコードが影響を受ける可能性は低いですが、この変更により、CreateCopy() を呼び出すコードは、.NET Framework 4.5 以降への移行の一部としてテストする必要があります。

提案される解決策

CreateCopy() が新しい System.Threading.SynchronizationContext オブジェクトを返すようになったことに注意してください。 以前は、このように生成された参照の等価性を使用するコードは、実際には、正しいコンテキストにあるかどうかを確認していませんでしたが、.NET Framework 4.5 以降でのビルド時には確認を行います。 問題になる可能性は低いですが、影響を受けるコードのパスをよく調べて、何か問題が生じないかどうか確認する必要があります。

名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

WPF TextBox は既定で元に戻す上限が 100 に設定される

説明

.NET Framework 4.5 では、WPF テキスト ボックスの既定の元に戻す上限は 100 です (.NET Framework 4.0 では無制限でした)。

提案される解決策

元に戻す上限が 100 では低すぎる場合、UndoLimit を使用して上限を明示的に設定できます。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

WPF TextBox で選択されているテキストが、テキスト ボックスがアクティブでないときに異なる色で表示される

説明

.NET Framework 4.5 では、WPF テキスト ボックス コントロールがアクティブでないとき (フォーカスがないとき)、ボックス内で選択されているテキストは、コントロールがアクティブなときとは別の色で表示されます。

提案される解決策

AreInactiveSelectionHighlightBrushKeysSupported プロパティを false に設定することで、以前 (.NET Framework 4.0) の動作が復元される可能性があります。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

WPF TreeViewItem は TreeView 内で使用する必要がある

説明

System.Windows.Controls.TreeView の外部での System.Windows.Controls.TreeViewItem 要素の使用を制限する変更が 4.5 で導入されました。 これは、次のような条件で発生します。

言い換えると、これは、System.Windows.Controls.TreeViewItem が System.Windows.Controls.TreeView の外部で使用されるときに見られ、ユーザーは System.Windows.Controls.TreeViewItem の子孫をクリックして表示させます。 System.Windows.Controls.TreeViewItem にフォーカスを取得できる子孫がない場合、この問題は見られません。 これが該当する状況の例は、System.Windows.Controls.TreeViewItem が DataTemplate のルートであるときです。 この問題に遭遇したときには、WPF フレームワーク内で InvalidCastException が発生しています。

提案される解決策

このための修正プログラムが使用可能になります。

名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

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

Windows Workflow Foundation (WF)

System.Activities が APTCA に

説明

アセンブリは System.Security.AllowPartiallyTrustedCallersAttribute 属性でマークされています。

提案される解決策

派生クラスに System.Security.SecurityCriticalAttributeのマークを付けることはできません。 以前は、派生型に System.Security.SecurityCriticalAttributeマークを付ける必要がありました。 ただし、この変更によって生じる実質的な影響はないはずです。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

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

WF による Expressions.Literal<T> DateTimes のシリアル化の方法が変わった (カスタム XAML パーサーが機能しなくなる)

説明

関連する ValueSerializer オブジェクトは、Second コンポーネントと System.DateTime.Millisecond コンポーネントが非ゼロで (System.DateTime 値の場合)、Kind プロパティが Unspecified ではない System.DateTime オブジェクトまたは System.DateTimeOffset オブジェクトを文字列ではなくプロパティ要素構文に変換します。 この変更により、System.DateTime 値と System.DateTimeOffset 値を往復させることができるようになります。 入力 XAML が属性構文であると想定するカスタム XAML パーサーは正しく機能しません。

提案される解決策

この変更により、System.DateTime 値と System.DateTimeOffset 値を往復させることができるようになります。 入力 XAML が属性構文であると想定するカスタム XAML パーサーは正しく機能しません。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

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

XML、XSLT

XmlSchemaException で行位置が正しく設定されるようになった

説明

SetLineInfo 値が Load メソッドに渡されたときに検証エラーが発生すると、LineNumber プロパティと LinePosition プロパティに行情報が含まれるようになりました。

提案される解決策

XML の読み込み中に SetLineInfo が使用されるとき、LineNumber と LinePosition は正しく設定されるようになったので、これらのプロパティが設定されないことを想定している例外処理コードは、更新する必要があります。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

XmlTextReader DTD エンティティの拡張が、10,000, 000 文字に制限される

説明

DTD エンティティの拡張は 10,000,000 文字までに制限されるようになりました。 DTD エンティティの展開を使用しない XML ファイルの読み込みや、制限された DTD エンティティの展開を使用した XML ファイルの読み込みは、影響を受けません。 DTD エンティティの展開が 10,000,000 文字を超えるファイルは読み込みに失敗し、例外をスローします。

提案される解決策

DTD エンティティの拡張の制限が 10,000, 000 では低すぎる場合には、MaxCharactersFromEntities プロパティで値をオーバーライドできます。 適切な System.Xml.XmlReaderSettings.MaxCharactersFromEntities 値を持つ System.Xml.XmlReaderSettings を、System.Xml.XmlReaderSettings を受け取る XmlReader.Create に渡すことができます (例: Create(String, XmlReaderSettings))

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

XSLT 上位互換が機能するようになった

説明

.NET Framework 4 では、XSLT 1.0 の上位互換性に、次の問題がありました。

  • バージョンが 2.0 に設定されているときに、パーサーが認識できない XSLT 1.0 コンストラクトに遭遇すると、スタイル シートの読み込みが失敗していました。
  • スタイル シートのバージョンが 1.1 に設定されている場合に、xsl:sort コンストラクトでデータを並べ替えることができませんでした。.NET Framework 4.5 では、これらの問題は修正され、XSLT 1.0 の上位互換モードが正常に機能するようになりました。

提案される解決策

ほとんどのアプリには影響しませんが、xsl:sort が優先される場合は異なる方法でデータが並べ替えられます。 xsl:sort が 1.1 スタイル シートで使用されている場合は、アプリが並べ替えられていないデータの順序に依存していないことを確認してください。 アプリが 4.0 の並べ替え動作に依存している場合は、スタイル シートから xsl:sort を削除してください。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

XSLT スタイル シートの例外メッセージが変更された

説明

.NET Framework 4.5 では、XSLT ファイルが複雑すぎるときのエラー メッセージのテキストが "スタイル シートが複雑すぎます" になります。以前のバージョンのエラー メッセージは "XSLT コンパイル エラー" でした。エラー メッセージのテキストに依存するアプリケーション コードは機能しなくなります。 ただし、例外の種類は同じなので、この変更による実質的な影響はありません。

提案される解決策

このエラー条件からの例外メッセージに依存しているアプリケーション コードを、新しいメッセージを予期するように更新するか、(さらに望ましくは) 変更されていない例外の種類 (System.Xml.Xsl.XsltException) のみに依存するようにコードを更新します。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

.NET Framework 4.5.1

ADO.NET

ADO.NET では、切断された SQL 接続の再接続が自動的に試行されるようになりました

説明

.NET Framework 4.5.1 以降、.NET Framework では、切断された SQL 接続の再接続が自動的に試行されます。 通常、これはアプリの安定性を高めますが、再接続時に行動できるよう、接続が失われたことをアプリに認識させる必要があるという極端な状況があります。

提案される解決策

互換性の問題からこの機能が望ましくない場合、接続文字列 (または System.Data.SqlClient.SqlConnectionStringBuilder) の System.Data.SqlClient.SqlConnectionStringBuilder.ConnectRetryCount プロパティを 0 に設定することで無効にできます。

名前 値
スコープ エッジ
バージョン 4.5.1
種類 ランタイム

影響を受ける API

コア

NetDataContractSerializer を使用して .NET Framework 4.5 でシリアル化された ConcurrentDictionary は、.NET Framework 4.5.1 または 4.5.2 で逆シリアル化できない

説明

型に対する内部的な変更のため、System.Runtime.Serialization.NetDataContractSerializer を使って .NET Framework 4.5 でシリアル化された ConcurrentDictionary<TKey,TValue> オブジェクトは、.NET Framework 4.5.1 または .NET Framework 4.5.2 では逆シリアル化できません。反対の方向 (.NET Framework 4.5.x でシリアル化して、.NET Framework 4.5 で逆シリアル化する) は動作することに注意してください。 同様に、すべての 4.x バージョン間のシリアル化は、.NET Framework 4.6 で機能します。 .NET Framework の 1 つのバージョンでのシリアル化と逆シリアル化は影響を受けません。

提案される解決策

.NET Framework 4.5 と .NET Framework 4.5.1/4.5.2 の間で System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> をシリアル化および逆シリアル化する必要がある場合は、System.Runtime.Serialization.NetDataContractSerializer の代わりに、System.Runtime.Serialization.DataContractSerializer のような別のシリアライザーを使用する必要があります。 または、この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって解決できます。

名前 値
スコープ マイナー
バージョン 4.5.1
種類 ランタイム

影響を受ける API

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

ConcurrentQueue<T>.TryPeek は、出力パラメーターを介して誤った null を返すことがあります

説明

一部のマルチ スレッド シナリオでは、System.Collections.Concurrent.ConcurrentQueue<T>.TryPeek(T) は true を返すことができますが、出力パラメーターに (正しいピーク値の代わりに) null 値を入れることがあります。

提案される解決策

この問題は、.NET Framework 4.5.1 で修正されます。 この Framework にアップグレードすると、問題が解決されます。

名前 値
スコープ Major
バージョン 4.5
種類 ランタイム

影響を受ける API

COR_PRF_GC_ROOT_HANDLE がプロファイラーで列挙されていない

説明

.NET Framework v4.5.1 では、プロファイル API RootReferences2() が正しく COR_PRF_GC_ROOT_HANDLE を返しません (代わりに、COR_PRF_GC_ROOT_OTHER として返される)。 この問題は、.NET Framework 4.6 以降で修正されています。

提案される解決策

この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。

名前 値
スコープ マイナー
バージョン 4.5.1
種類 ランタイム

影響を受ける API

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

アプリ ドメイン全体でのオブジェクトの逆シリアル化に失敗する可能性がある

説明

場合によっては、アプリが異なるアプリケーション ベースを持つ複数のアプリ ドメインを使用すると、アプリ ドメイン間で論理呼び出しコンテキストのオブジェクトを逆シリアル化しようとして、例外がスローされます。

提案される解決策

「軽減策:アプリ ドメイン全体でのオブジェクトの逆シリアル化」を参照してください。

名前 値
スコープ エッジ
バージョン 4.5.1
種類 ランタイム

影響を受ける API

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

EventListener は、null が埋め込まれた文字列を切り捨てる

説明

System.Diagnostics.Tracing.EventListener は、埋め込まれた null のある文字列を切り捨てます。 null 文字は System.Diagnostics.Tracing.EventSource クラスでサポートされません。 変更は、プロセスの System.Diagnostics.Tracing.EventListener データを読み取るために System.Diagnostics.Tracing.EventSource を使用し、区切り記号として null 文字を使用するアプリにのみ影響します。

提案される解決策

可能な場合は、埋め込まれた null 文字を使用しないように System.Diagnostics.Tracing.EventSource データを更新する必要があります。

名前 値
スコープ エッジ
バージョン 4.5.1
種類 ランタイム

影響を受ける API

EventSource.WriteEvent impls は、受け取ったのと同じパラメーター (と ID) を WriteEvent に渡す必要がある

説明

ランタイムは次の内容を指定するコントラクトを強制するようになりました。ETW イベント メソッドを定義する System.Diagnostics.Tracing.EventSource から派生するクラスは、ETW イベント メソッドが渡された同じ引数が続くイベント ID の基底クラス EventSource.WriteEvent メソッドを呼び出す必要があります。

提案される解決策

System.IndexOutOfRangeException 例外は、System.Diagnostics.Tracing.EventListener がこのコントラクトに違反するイベント ソースのプロセスの System.Diagnostics.Tracing.EventSource データを読み取るときに、スローされます。

名前 値
スコープ マイナー
バージョン 4.5.1
種類 ランタイム

影響を受ける API

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

Marshal.SizeOf および Marshal.PtrToStructure オーバー ロードがダイナミック コードを中断する

説明

.NET Framework 4.5.1 以降では、メソッド SizeOf<T>()、SizeOf<T>(T)、PtrToStructure(IntPtr, Object)、PtrToStructure(IntPtr, Type)、PtrToStructure<T>(IntPtr)、または PtrToStructure<T>(IntPtr, T) への動的なバインドを (たとえば、Windows PowerShell、IronPython、または C# のダイナミック キーワードを使用して) 行うと、これらのメソッドの新しいオーバーロードが追加され、スクリプト エンジンにとってあいまいなことがあるため、MethodInvocationExceptions になります。

提案される解決策

使用するオーバーロードを明確に示すように、スクリプトを更新します。 これは、一般に、メソッドの型パラメーターを Type として明示的にキャストすることによって行われます。 この問題の回避方法の詳細と例については、このリンク を参照してください。

名前 値
スコープ マイナー
バージョン 4.5.1
種類 ランタイム

影響を受ける API

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

一部の .NET API がファースト チャンス (処理済み) EntryPointNotFoundExceptions の原因になります

説明

.NET Framework 4.5 では、少数の .NET メソッドが、ファースト チャンス System.EntryPointNotFoundException をスローするようになりました。 これらの例外は .NET Framework 内で処理されますが、ファースト チャンス例外を予期していないテスト自動化を中断することがありました。 これらと同じ API は、HighVersionLie が有効なとき、一部の ApiVerifier シナリオを中断させます。

提案される解決策

このバグは、.NET Framework 4.5.1 にアップグレードすることによって回避できます。 または、ファースト チャンス System.EntryPointNotFoundException 例外で中断しないように、テスト自動化を更新できます。

Value
スコープ エッジ
Version 4.5
Type ランタイム

影響を受ける API

終了時に WinRT ストリーム アダプターで FlushAsync が自動的に呼び出されなくなりました

説明

Windows ストア アプリの Windows ランタイム ストリーム アダプターで、Dispose メソッドから FlushAsync メソッドが呼び出されなくなりました。

提案される解決策

この変更は透過的である必要があります。 開発者は次のようなコードを記述して以前の動作を復元できます。

using (var stream = GetWindowsRuntimeStream() as Stream)
{
// do something
await stream.FlushAsync();
}
名前 値
スコープ 透明
バージョン 4.5.1
種類 ランタイム

影響を受ける API

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

Data

ADO.NET では、切断された SQL 接続の再接続が自動的に試行されるようになりました

説明

.NET Framework 4.5.1 以降、.NET Framework では、切断された SQL 接続の再接続が自動的に試行されます。 通常、これはアプリの安定性を高めますが、再接続時に行動できるよう、接続が失われたことをアプリに認識させる必要があるという極端な状況があります。

提案される解決策

互換性の問題からこの機能が望ましくない場合、接続文字列 (または System.Data.SqlClient.SqlConnectionStringBuilder) の System.Data.SqlClient.SqlConnectionStringBuilder.ConnectRetryCount プロパティを 0 に設定することで無効にできます。

名前 値
スコープ エッジ
バージョン 4.5.1
種類 ランタイム

影響を受ける API

シリアル化

異なる .NET バージョンでシリアル化された ConcurrentDictionary を NetDataContractSerializer で逆シリアル化できない

説明

設計上、System.Runtime.Serialization.NetDataContractSerializer は、シリアル化と逆シリアル化の両方で、同一の CLR 型を共有する結果になる場合にのみ使用できます。 そのため、.NET Framework の 1 つのバージョンでシリアル化されたオブジェクトは、異なるバージョンで逆シリアル化できるない可能性があります。 .NET Framework 4.5 以前でシリアル化され、.NET Framework 4.5.1 以降で逆シリアル化された場合、System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> の型は正しく逆シリアル化されないと認識されています。

提案される解決策

この問題の考えられるいくつかの回避策を以下に示します。

名前 値
スコープ マイナー
バージョン 4.5.1
種類 ランタイム

影響を受ける API

Windows Communication Foundation (WCF)

MinFreeMemoryPercentageToActiveService が順守されるようになった

説明

この設定は、WCF サービスをアクティブにするためにサーバー上で使用できなければならない最小メモリを設定します。 System.OutOfMemoryException 例外が発生しないようにデザインされています。 .NET Framework 4.5 では、この設定には効果はありません。 .NET Framework 4.5.1 では、この設定が守られます。

提案される解決策

Web サーバーで使用できる空きメモリが構成設定によって定義されたパーセンテージよりも小さい場合、例外が発生します。 制約されたメモリ環境で正常に開始し、実行された WCF サービスが今度は失敗することがあります。

名前 値
スコープ マイナー
バージョン 4.5.1
種類 ランタイム

影響を受ける API

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

Windows Presentation Foundation (WPF)

VirtualizingStackPanel 内の WPF TreeView またはグループ化された ListBox をスクロールすると、アプリケーションが応答を停止することがある

詳細

.NET Framework v4.5 では、仮想化されたスタック パネル内の WPF System.Windows.Controls.TreeView をスクロールすると、ビューポートに余白があった場合 (たとえば、System.Windows.Controls.TreeView 内の項目間や、ItemsPresenter 要素上)、アプリケーションが応答を停止するすることがあります。 さらに、場合によっては、ビュー内にサイズの異なる項目があると、余白がない場合でも、不安定になることがあります。

提案される解決策

このバグは、.NET Framework 4.5.1 にアップグレードすることによって回避できます。 または、含まれているすべての項目が同じサイズである場合は、仮想化されたスタック パネル内のビュー コレクション (System.Windows.Controls.TreeView など) から余白を削除できます。

名前 値
スコープ Major
バージョン 4.5
種類 ランタイム

影響を受ける API

.NET Framework 4.5.2

ASP.NET

ASP.NET MVC は、ルート パラメーターで渡された文字列内のスペースをエスケープするようになりました

説明

RFC 2396 に準拠するために、ルートからアクション パラメーターを設定するときに、ルートのパスに含まれるスペースがエスケープされるようになりました。 そのため、/controller/action/some data は以前はルート /controller/action/{data} と一致し、some data をデータ パラメーターとして提供していましたが、代わりに some%20data を提供するようになります。

提案される解決策

ルートからの文字列パラメーターをエスケープ解除するように、コードを更新する必要があります。 元の URI が必要な場合は、RequestUri.OriginalString API でアクセスできます。

名前 値
スコープ マイナー
バージョン 4.5.2
種類 ランタイム

影響を受ける API

EnableViewStateMac を false に設定できなくなった

説明

ASP.NET では、開発者は <pages enableViewStateMac=&quot;false&quot;/> または <@Page EnableViewStateMac=&quot;false&quot; %> を指定できなくなりました。 ビュー ステートのメッセージ認証コード (MAC) は、ビュー ステートが埋め込まれたすべての要求に強制されています。 EnableViewStateMac プロパティを明示的に false に設定するアプリのみが影響を受けます。

提案される解決策

EnableViewStateMac は true であると想定する必要があり、結果としての MAC エラーを解決する必要があります (このガイダンスで説明されているように、MAC エラーの原因の詳細によって複数の解決策があります)。

名前 値
スコープ Major
バージョン 4.5.2
種類 ランタイム

影響を受ける API

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

ASP.NET MVC4 アプリのプロファイリングにより、致命的な実行エンジン エラーが発生する可能性がある

説明

NGEN/プロファイル アセンブリを使用するプロファイラーにより、起動時にプロファイルされた ASP.NET MVC4 アプリケーションがクラッシュし、"致命的な実行エンジン例外" が示される場合があります。

提案される解決策

この問題は、.NET Framework 4.5.2 で修正されます。 プロファイラーは、イベント マスクで COR_PRF_DISABLE_ALL_NGEN_IMAGES を指定することで、この問題を回避することもできます。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

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

Data

IFS 以外の Winsock BSP または LSP が存在する Windows 7 で SqlConnection.Open が失敗する

説明

Open() および OpenAsync(CancellationToken) は、コンピューター上に IFS 以外の Winsock BSP または LSP が存在する Windows 7 コンピューターで実行している場合、.NET Framework 4.5 では失敗します。IFS 以外の BSP または LSP がインストールされているかどうかを確認するには、netsh WinSock Show Catalog コマンドを使用して、返される Winsock Catalog Provider Entry 項目をすべて調べてください。 Service Flags 値の 0x20000 ビットがセットされている場合、プロバイダーは IFS ハンドルを使用していて、正しく機能します。 0x20000 ビットがクリアされている (セットされていない) 場合は、IFS 以外の BSP または LSP です。

提案される解決策

このバグは .NET framework 4.5.2 で修正されたため、.NET Framework をアップグレードすることによって回避できます。 または、インストールされている IFS 以外の Winsock LSP を削除することによって回避できます。

名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

Entity Framework

EF で特定の特性を持つ QueryViews がスローされなくなった

説明

クエリの一部として関連エンティティを含めようとする 0..1 ナビゲーション プロパティを使用して QueryViews に関係するクエリをアプリが実行する場合、Entity Framework で System.StackOverflowException 例外がスローされなくなりました。 たとえば、.Include(e =&gt; e.RelatedNavProp) を呼び出す場合です。

提案される解決策

この変更は、.Include を呼び出すクエリの実行時に 1 - 0..1 の関係にある QueryViews を使用するコードにのみ影響します。 これにより信頼性が向上し、ほとんどすべてのアプリに対して透過的になります。 ただし、予期しない動作が発生する場合、次のエントリをアプリの構成ファイルの <appSettings> セクションに追加することにより、この変更を無効にできます。

<add key="EntityFramework_SimplifyUserSpecifiedViews" value="false" />
名前 値
スコープ エッジ
バージョン 4.5.2
種類 ランタイム

影響を受ける API

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

異なる 4.5 SQL 生成からより単純な 4.0 SQL 生成に戻す

説明

最初に OrderBy を使用せずに JOIN ステートメントを生成し、制限操作への呼び出しを含むクエリで、より単純な SQL が生成されるようになりました。 .NET Framework 4.5 へのアップグレード後、これらのクエリは以前のバージョンよりも複雑な SQL を生成しました。

提案される解決策

既定では、この機能は無効です。 Entity Framework がパフォーマンスを低下させる追加の JOIN ステートメントを生成する場合は、アプリケーション構成 (app.config) ファイルの <appSettings> セクションへ次のエントリを追加してこの機能を有効にできます。

<add key="EntityFramework_SimplifyLimitOperations" value="true" />
名前 値
スコープ 透明
バージョン 4.5.2
種類 ランタイム

影響を受ける API

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

Windows Presentation Foundation (WPF)

CellEditEnding ハンドラーから DataGrid.CommitEdit を呼び出すと、フォーカスが削除される

説明

System.Windows.Controls.DataGrid の System.Windows.Controls.DataGrid.CellEditEnding イベント ハンドラーのいずれかから CommitEdit() を呼び出すと、System.Windows.Controls.DataGrid からフォーカスが失われます。

提案される解決策

このバグは .NET framework 4.5.2 で修正されたため、.NET Framework をアップグレードすることによって回避できます。 または、System.Windows.Controls.DataGrid.CommitEdit() を呼び出した後で System.Windows.Controls.DataGrid を明示的に再選択することによって回避できます。

名前 値
スコープ エッジ
バージョン 4.5
種類 ランタイム

影響を受ける API

カスタム DataTemplate を使用しているとき、断続的に、ItemsControl (ListBox や DataGrid など) 内の最後の項目までスクロールできない

説明

場合によっては、.NET Framework 4.5 のバグにより、カスタム DataTemplate を使用していると、ItemsControl (System.Windows.Controls.ListBox、System.Windows.Controls.ComboBox、System.Windows.Controls.DataGrid など) の最後の項目までスクロールできません。 (上へスクロールした後で) もう一度スクロールを試みると、今度はスクロールできます。

提案される解決策

この問題は .NET Framework 4.5.2 で修正されたため、このバージョン (またはそれ以降のバージョン) の .NET Framework にアップグレードすることによって対処できます。 または、ユーザーは、スクロール バーをこれらのコレクションの最後の項目までドラッグできますが、2 回試みなければならないことがあります。

名前 値
スコープ マイナー
バージョン 4.5
種類 ランタイム

影響を受ける API

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

WPF が wisptis.exe プロセスを生成し、マウスがフリーズする可能性がある

説明

この問題は 4.5.2 から発生するようになり、wisptis.exe が生成され、マウス入力がフリーズする可能性があります。

提案される解決策

この問題はサービス リリースの .NET Framework 4.5.2 (修正プログラム ロールアップ 3026376) で、あるいは .NET Framework 4.6 にアップグレードすることで解決できます。

名前 値
スコープ Major
バージョン 4.5.2
種類 ランタイム

影響を受ける API

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

XML

XML 解析の変更

名前 値
スコープ マイナー
バージョン 4.5.2
種類 ランタイム

詳細

セキュリティ上の理由から、次の変更が XML 解析 API に導入されました。

Note

XmlReaderSettings はすべての XML パーサーによって使用されるため、この変更は XmlReader のケースでは役に立ちますが、他のシナリオにも影響します。

提案される解決策

以前の動作に戻すには、レジストリで値を設定します。 EnableLegacyXmlSettings という名前のダブルワード値を HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\XML レジストリ キーに追加し、その値を 1 に設定します。 代わりに、HKEY_CURRENT_USER ハイブでレジストリ値を追加することもできます。

影響を受ける API

また、直接的または間接的に XmlResolver に依存するすべての XML API が影響を受けます。