.NET Framework 4.0 から 4.5.2 への移行に関するランタイム変更Runtime Changes for Migration from .NET Framework 4.0 to 4.5.2

Introduction

Runtime changes affect all apps that are running under a .NET Framework it was not compiled against and that use a particular feature.

In the topics that describe runtime changes, we have classified individual items by their expected impact, as follows:

Major This is a significant change that affects a large number of apps or that requires substantial modification of code.

Minor This is a change that affects a small number of apps or that requires minor modification of code.

Edge case This is a change that affects apps under very specific scenarios that are not common.

Transparent This is a change that has no noticeable effect on the app's developer or user. The app should not require modification because of this change.

.NET Framework 4.0 から 4.5.2 に移行する場合は、アプリに影響する可能性があるアプリケーションの互換性の問題に関する次のトピックを確認してください。If you are migrating from the .NET Framework 4.0 to 4.5.2, review the following topics for application compatibility issues that may affect your app:

ADO.NETADO.NET

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

説明Details .NET Framework 4.5.1 以降、.NET Framework では、切断された SQL 接続の再接続が自動的に試行されます。Beginning in the .NET Framework 4.5.1, the .NET Framework will attempt to automatically reconnect broken SQL connections. 通常、これはアプリの安定性を高めますが、再接続時に行動できるよう、接続が失われたことをアプリに認識させる必要があるという極端な状況があります。Although this will typically make apps more reliable, there are edge cases in which an app needs to know that the connection was lost so that it can take some action upon reconnection.
提案される解決策Suggestion 互換性の問題からこの機能が望ましくない場合、接続文字列 (または SqlConnectionStringBuilder) の ConnectRetryCount プロパティを 0 に設定することで無効にできます。If this feature is undesirable due to compatibility concerns, it can be disabled by setting the ConnectRetryCount property of a connection string (or SqlConnectionStringBuilder) to 0.
スコープScope エッジEdge
VersionVersion 4.5.14.5.1
Type ランタイムRuntime
影響を受ける APIAffected APIs

ASP.NETASP.NET

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

説明Details RFC 2396 に準拠するために、ルートからアクション パラメーターを設定するときに、ルートのパスに含まれるスペースがエスケープされるようになりました。In order to conform to RFC 2396, spaces in route paths are now escaped when populating action parameters from a route. そのため、/controller/action/some data は以前はルート /controller/action/{data} し、some data をデータ パラメーターとして与えましたが、代わりに some%20data を与えるようになります。So, whereas /controller/action/some data would previously match the route /controller/action/{data} and provide some data as the data parameter, it will now provide some%20data instead.
提案される解決策Suggestion ルートからの文字列パラメーターをエスケープ解除するように、コードを更新する必要があります。Code should be updated to unescape string parameters from a route. 元の URI が必要な場合は、RequestUri.OriginalString API でアクセスできます。If the original URI is needed, it can be accessed with the RequestUri.OriginalString API.
スコープScope マイナーMinor
VersionVersion 4.5.24.5.2
Type ランタイムRuntime
影響を受ける APIAffected APIs

AllowCustomPaging が true に設定された GridView では、ビューの最終ページから他に移動するときに、PageIndexChanging イベントが発生する場合があるGridViews with AllowCustomPaging set to true may fire the PageIndexChanging event when leaving the final page of the view

説明Details .NET Framework 4.5 でのバグのため、AllowCustomPaging が有効になっている GridView に対して PageIndexChanging が発生しないことがあります。A bug in the .NET Framework 4.5 causes PageIndexChanging to sometimes not fire for GridViews that have enabled AllowCustomPaging.
提案される解決策Suggestion この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。This issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework. 回避策として、アプリでは、これらの条件 (GridView が最終ページで、最後の PageSizePageSize と異なる) を満たす Page_Load で明示的に BindGrid を行うことができます。As a work-around, the app can do an explicit BindGrid on any Page_Load that would hit these conditions (the GridView is on the last page and LastPageSize is different from PageSize). または、(カスタム ページングではなく) ページングを許可するようにアプリを変更することもできます。このシナリオでは問題は発生していません。Alternatively, the app can be modified to allow paging (instead of custom paging), as that scenario does not demonstrate the problem.
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

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

説明Details .NET Framework 4.5 以降では、HttpRequest の本文では UTF-7 エンコードが禁止されます。Beginning in .NET Framework 4.5, UTF-7 encoding is prohibited in HttpRequests' bodies. UTF-7 データの受信を必要とするアプリケーションのデータが、正しくデコードされない場合があります。Data for applications that depend on incoming UTF-7 data will not decode properly in some cases.
提案される解決策Suggestion 理想的には、HttpRequest で UTF-7 エンコードを使用しないようにアプリケーションを更新する必要があります。Ideally, applications should be updated to not use UTF-7 encoding in HttpRequests. または、 要素の aspnet:AllowUtf7RequestContentEncoding 属性を使用して、レガシ動作に戻すことができます。Alternatively, legacy behavior can be restored by using the aspnet:AllowUtf7RequestContentEncoding attribute of the appSettings element.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

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

説明Details .NET Framework 4.5 以降では、JavaScriptStringEncode(String) でアンパサンド (&) 文字がエスケープされます。Starting with the .NET Framework 4.5, JavaScriptStringEncode(String) escapes the ampersand (&) character.
提案される解決策Suggestion アプリがこのメソッドの以前の動作に依存している場合、構成ファイルの ASP.NET appSettings 要素 に aspnet:JavaScriptDoNotEncodeAmpersand 設定を追加できます。If your app depends on the previous behavior of this method, you can add an aspnet:JavaScriptDoNotEncodeAmpersand setting to the ASP.NET appSettings element in your configuration file.
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

iPad はブラウザー機能になったため、カスタム機能ファイルでは使用できないIPad should not be used in custom capabilities file because it is now a browser capability

説明Details .NET Framework 4.5 以降では、iPad は既定の ASP.NET ブラウザー機能ファイルの識別子であるため、カスタム機能ファイルでは使用できませんBeginning in .NET Framework 4.5, iPad is an identifier in the default ASP.NET browser capabilities file, so it should not be used in a custom capabilities file
提案される解決策Suggestion iPad 固有の機能が必要な場合は、ユーザー エージェントのマッチングで新しい "IPad" ID を生成するのではなく、定義済みのゲートウェイ refID "IPad" で機能を設定して、iPad の動作を変更する必要があります。If iPad-specific capabilities are required, it is necessary to modify iPad behavior by setting capabilities on the pre-defined gateway refID "IPad" instead of by generating a new "IPad" ID by user agent matching.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime

EnableViewStateMac を false に設定できなくなったNo longer able to set EnableViewStateMac to false

説明Details ASP.NET では、開発者は <pages enableViewStateMac="false"/> または <@Page EnableViewStateMac="false" %> を指定できなくなりました。ASP.NET no longer allows developers to specify <pages enableViewStateMac="false"/> or <@Page EnableViewStateMac="false" %>. ビュー ステートのメッセージ認証コード (MAC) は、ビュー ステートが埋め込まれたすべての要求に強制されています。The view state message authentication code (MAC) is now enforced for all requests with embedded view state. EnableViewStateMac プロパティを明示的に false に設定するアプリのみが影響を受けます。Only apps that explicitly set the EnableViewStateMac property to false are affected.
提案される解決策Suggestion EnableViewStateMac は true であると想定する必要があり、結果としての MAC エラーを解決する必要があります (このガイダンスで説明されているように、MAC エラーの原因の詳細によって複数の解決策があります)。EnableViewStateMac must be assumed to be true, and any resulting MAC errors must be resolved (as explained in this guidance, which contains multiple resolutions depending on the specifics of what is causing MAC errors).
スコープScope MajorMajor
VersionVersion 4.5.24.5.2
Type ランタイムRuntime

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

説明Details LoadComplete イベントが原因で、EntityDataSource のコントロールがパラメーターの作成/更新/削除に変更を加えるためにデータ バインディングを呼び出すことがなくなりました。The LoadComplete event no longer causes the EntityDataSource control to invoke data binding for changes to create/update/delete parameters. この変更により、データベースへの不要なアクセスが排除され、コントロールの値がリセットされるのを防ぐことができるほか、SqlDataSourceObjectDataSourceなどのように他のデータ コントロールと一貫性の取れた動作が生成されます。This change eliminates an extraneous trip to the database, prevents the values of controls from being reset, and produces behavior that is consistent with other data controls, such as SqlDataSource and ObjectDataSource. この変更により、アプリケーションが LoadComplete イベントのデータ バインディングの呼び出しに依存するような珍しい状況において、異なる動作が生成されるようになりました。This change produces different behavior in the unlikely event that applications rely on invoking data binding in the LoadComplete event.
提案される解決策Suggestion データバインドの必要がある場合は、ポストバックの前半であるイベントでデータバインドを手動で呼び出します。If there is a need for databinding, manually invoke databind in an event that is earlier in the post-back.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime

Asp.Net StateServer とセッション状態を共有するには、Web ファーム内のすべてのサーバーが同じ .NET Framework バージョンを使用する必要がありますSharing session state with Asp.Net StateServer requires all servers in the web farm to use the same .NET Framework version

説明Details StateServer セッション状態を有効にする場合、状態を正しく共有するには、指定の Web ファーム内のすべてのサーバーが同じバージョンの .NET Framework を使用する必要があります。When enabling StateServer session state, all of the servers in the given web farm must use the same version of the .NET Framework in order for state to be properly shared.
提案される解決策Suggestion 同時に状態を共有する Web サーバー上で必ず .NET Framework バージョンのアップグレードを行います。Be sure to upgrade .NET Framework versions on web servers that share state at the same time.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

WebUtility.HtmlDecode が無効な入力シーケンスをデコードしなくなったWebUtility.HtmlDecode no longer decodes invalid input sequences

説明Details 既定では、デコード メソッドによって無効な入力シーケンスが無効な UTF-16 文字列にデコードされることがなくなりました。By default, decoding methods no longer decode an invalid input sequence into an invalid UTF-16 string. 代わりに、元の入力が返されます。Instead, they return the original input.
提案される解決策Suggestion デコーダーの出力の変更は、UTF-16 データではなくバイナリ データを文字列に格納した場合にのみ影響があります。The change in decoder output should matter only if you store binary data instead of UTF-16 data in strings. 明示的にこの動作を制御するには、appSettings 要素の aspnet:AllowRelaxedUnicodeDecoding 属性を true に設定して従来の動作を有効にするか、false に設定して現在の動作を有効にします。To explicitly control this behavior, set the aspnet:AllowRelaxedUnicodeDecoding attribute of the appSettings element to true to enable legacy behavior or to false to enable the current behavior.
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

コアCore

NetDataContractSerializer を使用して .NET Framework 4.5 でシリアル化された ConcurrentDictionary は、.NET Framework 4.5.1 または 4.5.2 で逆シリアル化できないA ConcurrentDictionary serialized in .NET Framework 4.5 with NetDataContractSerializer cannot be deserialized by .NET Framework 4.5.1 or 4.5.2

説明Details 型に対する内部的な変更のため、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 で逆シリアル化する) は動作することに注意してください。Due to internal changes to the type, ConcurrentDictionary<TKey,TValue> objects that are serialized with the .NET Framework 4.5 using the NetDataContractSerializer cannot be deserialized in the .NET Framework 4.5.1 or in the .NET Framework 4.5.2.Note that moving in the other direction (serializing with the .NET Framework 4.5.x and deserializing with the .NET Framework 4.5) works. 同様に、すべての 4.x バージョン間のシリアル化は、.NET Framework 4.6 で機能します。 .NET Framework の 1 つのバージョンでのシリアル化と逆シリアル化は影響を受けません。Similarly, all 4.x cross-version serialization works with the .NET Framework 4.6.Serializing and deserializing with a single version of the .NET Framework is not affected.
提案される解決策Suggestion .NET Framework 4.5 と .NET Framework 4.5.1/4.5.2 の間で ConcurrentDictionary<TKey,TValue> のシリアル化と逆シリアル化を行う必要がある場合は、NetDataContractSerializer の代わりに、DataContractSerializer または BinaryFormatter シリアライザーなど、代替のシリアライザーを使う必要があります。または、この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって解決できます。If it is necessary to serialize and deserialize a ConcurrentDictionary<TKey,TValue> between the .NET Framework 4.5 and .NET Framework 4.5.1/4.5.2, an alternate serializer like the DataContractSerializer or BinaryFormatter serializer should be used instead of the NetDataContractSerializer.Alternatively, because this issue is addressed in the .NET Framework 4.6, it may be solved by upgrading to that version of the .NET Framework.
スコープScope マイナーMinor
VersionVersion 4.5.14.5.1
Type ランタイムRuntime

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

説明Details コンパイル済みの正規表現のアセンブリが .NET Framework 4.5 でビルドされ、.NET Framework 4 を対象としている場合、.NET Framework 4 がインストールされているシステム上でそのアセンブリの正規表現の 1 つを使用しようとすると、例外をスローします。If an assembly of compiled regular expressions is built with the .NET Framework 4.5 but targets the .NET Framework 4, attempting to use one of the regular expressions in that assembly on a system with .NET Framework 4 installed throws an exception.
提案される解決策Suggestion この問題を回避するには、次のいずれかの方法を実行します。To work around this problem, you can do either of the following:
  • .NET Framework 4 を使用して正規表現を含むアセンブリをビルドします。Build the assembly that contains the regular expressions with the .NET Framework 4.
  • 解釈される正規表現を使用します。Use an interpreted regular expression.
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

BlockingCollection<T>.TryTakeFromAny がスローしなくなったBlockingCollection<T>.TryTakeFromAny does not throw anymore

説明Details 入力コレクションの 1 つに完了のマークが付けられた場合、TryTakeFromAny(BlockingCollection<T>[], T) -1 を返さず、TakeFromAny(BlockingCollection<T>[], T)例外をスローしなくなりました。If one of the input collections is marked completed, TryTakeFromAny(BlockingCollection<T>[], T) no longer returns -1 and TakeFromAny(BlockingCollection<T>[], T) no longer throws an exception. この変更の結果、コレクションの 1 つが空であったり完了していても、他のコレクションに取得できる項目がある場合にコレクションで作業をすることができるようになりました。This change makes it possible to work with collections when one of the collections is either empty or completed, but the other collection still has items that can be retrieved.
提案される解決策Suggestion -1 を返す TryTakeFromAny またはスローする TakeFromAny が制御フロー目的で使用されていた場合、ブロッキング コレクションが完了する場合、そのようなコードは、その条件を検出するように .Any(b => b.IsCompleted) を使用するように変更される必要があります。If TryTakeFromAny returning -1 or TakeFromAny throwing were used for control-flow purposes in cases of a blocking collection being completed, such code should now be changed to use .Any(b => b.IsCompleted) to detect that condition.
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

タイムアウト引数を持つ Task.WaitAll メソッドの動作の変更Change in behavior for Task.WaitAll methods with time-out arguments

説明Details .NET Framework 4.5 では、Task.WaitAll の動作が、より一貫性のあるものになりました。 .NET Framework 4 では、これらのメソッドの動作に一貫性がありませんでした。Task.WaitAll behavior was made more consistent in .NET Framework 4.5.In the .NET Framework 4, these methods behaved inconsistently. タイムアウトの期限が切れたときに、メソッドを呼び出す前に完了した、またはキャンセルされたタスクが 1 つ以上ある場合、メソッドでは AggregateException 例外がスローされていました。When the time-out expired, if one or more tasks were completed or canceled before the method call, the method threw an AggregateException exception. タイムアウトの期限が切れると、メソッド呼び出しの前に完了またはキャンセルされたタスクはなかったが、メソッド呼び出し後に 1 つ以上のタスクがこれらの状態になると、メソッドは false を返しました。When the time-out expired, if no tasks were completed or canceled before the method call, but one or more tasks entered these states after the method call, the method returned false.

.NET Framework 4.5 では、これらのメソッドのオーバーロードは、タイムアウト期限が切れたときにタスクがまだ実行中であった場合は false を返し、入力タスクがキャンセルされ (メソッド呼び出しの前か後かに関わらず)、他に実行中のタスクがなかった場合に限り、AggregateException 例外をスローします。In the .NET Framework 4.5, these method overloads now return false if any tasks are still running when the time-out interval expired, and they throw an AggregateException exception only if an input task was cancelled (regardless of whether it was before or after the method call) and no other tasks are still running.
提案される解決策Suggestion WaitAll 呼び出しが呼び出される前にキャンセルされたタスクを検出する手段として AggregateException がキャッチされていた場合、.NET Framework 4.6 は、すべての待機中タスクがタイムアウトの前に完了した場合に限ってスローするため、そのコードは、代わりに IsCanceled プロパティによって同じ検出を行う必要があります (例: .Any(t => t.IsCanceled))。If an AggregateException was being caught as a means of detecting a task that was cancelled prior to the WaitAll call being invoked, that code should instead do the same detection via the IsCanceled property (for example: .Any(t => t.IsCanceled)) since .NET Framework 4.6 will only throw in that case if all awaited tasks are completed prior to the timeout.
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

mscorlib の複数バージョン対応時の型転送のコンパイラ サポートCompiler support for type forwarding when multi-targeting mscorlib

説明Details 新しい CodeDOM の機能を使用すると、mscorlib.dll の .NET Framework 4.5 バージョンではなく、mscorlib.dll の対象バージョンに対してコンパイルできるようになります。A new CodeDOM feature allows a compiler to compile against the targeted version of mscorlib.dll instead of the .NET Framework 4.5 version of mscorlib.dll.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime

COR_PRF_GC_ROOT_HANDLE がプロファイラーで列挙されていないCOR_PRF_GC_ROOT_HANDLEs are not being enumerated by profilers

説明Details .NET Framework v4.5.1 では、プロファイル API RootReferences2() が正しく COR_PRF_GC_ROOT_HANDLE を返しません (代わりに、COR_PRF_GC_ROOT_OTHER として返される)。In the .NET Framework v4.5.1, the profiling API RootReferences2() is incorrectly never returning COR_PRF_GC_ROOT_HANDLE (they are returned as COR_PRF_GC_ROOT_OTHER instead). この問題は、.NET Framework 4.6 以降で修正されています。This issue is fixed beginning in the .NET Framework 4.6.
提案される解決策Suggestion この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。This issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.
スコープScope マイナーMinor
VersionVersion 4.5.14.5.1
Type ランタイムRuntime

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

説明Details 場合によっては、アプリが異なるアプリケーション ベースを持つ複数のアプリ ドメインを使用すると、アプリ ドメイン間で論理呼び出しコンテキストのオブジェクトを逆シリアル化しようとして、例外がスローされます。In some cases, when an app uses two or more app domains with different application bases, trying to deserialize objects in the logical call context across app domains throws an exception.
提案される解決策Suggestion 軽減策:アプリ ドメイン全体でのオブジェクトの逆シリアル化」を参照してください。See Mitigation: Deserialization of Objects Across App Domains
スコープScope エッジEdge
VersionVersion 4.5.14.5.1
Type ランタイムRuntime

ETW EventListeners は、明示的なキーワードを持つプロバイダーからのイベント (TPL プロバイダーなど) をキャプチャしませんETW EventListeners do not capture events from providers with explicit keywords (like the TPL provider)

説明Details 空白のキーワード マスクを持つ ETW EventListeners は、明示的なキーワードを持つプロバイダーからのイベントを正しくキャプチャしません。ETW EventListeners with a blank keyword mask do not properly capture events from providers with explicit keywords. .NET Framework 4.5 では、TPL プロバイダーは、明示的なキーワードを提供するようになり、この問題が発生しました。In the .NET Framework 4.5, the TPL provider began providing explicit keywords and triggered this issue. .NET Framework 4.6 では、EventListeners が更新され、この問題は修正されました。In the .NET Framework 4.6, EventListeners have been updated to no longer have this issue.
提案される解決策Suggestion この問題を回避するには、EnableEvents(EventSource, EventLevel) の呼び出しを、使用する "任意のキーワード" マスクを明示的に指定する EnableEvents オーバーロード (EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff))) の呼び出しに置換します。または、この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。To work around this problem, replace calls to EnableEvents(EventSource, EventLevel) with calls to the EnableEvents overload that explicitly specifies the "any keywords" mask to use: EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff)).Alternatively, this issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

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

説明Details EventListener は、埋め込まれた null のある文字列を切り捨てます。EventListener truncates strings with embedded nulls. null 文字は EventSource クラスでサポートされません。Null characters are not supported by the EventSource class. 変更は、プロセスの EventListener データを読み取るために EventSource を使用し、区切り記号として null 文字を使用するアプリにのみ影響します。The change only affects apps that use EventListener to read EventSource data in process and that use null characters as delimiters.
提案される解決策Suggestion 可能な場合は、埋め込まれた null 文字を使用しないように EventSource データを更新する必要があります。EventSource data should be updated, if possible, to not use embedded null characters.
スコープScope エッジEdge
VersionVersion 4.5.14.5.1
Type ランタイムRuntime
影響を受ける APIAffected APIs

EventSource.WriteEvent impls は、受け取ったのと同じパラメーター (と ID) を WriteEvent に渡す必要があるEventSource.WriteEvent impls must pass WriteEvent the same parameters that it received (plus ID)

説明Details ランタイムは次の内容を指定するコントラクトを強制するようになりました。ETW イベント メソッドを定義する EventSource から派生するクラスは、ETW イベント メソッドが渡された同じ引数が続くイベント ID の基底クラス EventSource.WriteEvent メソッドを呼び出す必要があります。The runtime now enforces the contract that specifies the following: A class derived from EventSource that defines an ETW event method must call the base class EventSource.WriteEvent method with the event ID followed by the same arguments that the ETW event method was passed.
提案される解決策Suggestion IndexOutOfRangeException 例外は、EventListener がこのコントラクトに違反するイベント ソースのプロセスの EventSource データを読み取るときに、スローされます。An IndexOutOfRangeException exception is thrown if an EventListener reads EventSource data in process for an event source that violates this contract.
スコープScope マイナーMinor
VersionVersion 4.5.14.5.1
Type ランタイムRuntime

System.Threading.Tasks.Task で監視されていない処理中の例外が、ファイナライザー スレッドに伝播されなくなったExceptions during unobserved processing in System.Threading.Tasks.Task no longer propagate on finalizer thread

説明Details Task クラスは非同期操作を表すため、非同期処理中に発生する重大ではない例外がすべてキャッチされます。Because the Task class represents an asynchronous operation, it catches all non-severe exceptions that occur during asynchronous processing. .NET Framework 4.5 では、例外が監視されていず、コードがタスクを待機していない場合、例外はファイナライザー スレッドに伝播されなくなり、ガベージ コレクション時にプロセスをクラッシュします。In the .NET Framework 4.5, if an exception is not observed and your code never waits on the task, the exception will no longer propagate on the finalizer thread and crash the process during garbage collection. この変更により、Task クラスを使用して、監視されていない非同期処理を実行するアプリケーションの信頼性が向上します。This change enhances the reliability of applications that use the Task class to perform unobserved asynchronous processing.
提案される解決策Suggestion アプリが、監視されていない非同期例外のファイナライザー スレッドへの伝播に依存している場合、UnobservedTaskException イベントの適切なハンドラーを提供することによって、またはランタイム構成要素を設定することによって、以前の動作を復元できます。If an app depends on unobserved asynchronous exceptions propagating to the finalizer thread, the previous behavior can be restored by providing an appropriate handler for the UnobservedTaskException event, or by setting a runtime configuration element.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

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

説明Details .NET Framework 4.5 以降では、List<T> の並べ替えアルゴリズムが (クイック並べ替えではなく、内省的な並べ替えになるように) 変更されました。Beginning in .NET Framework 4.5, List<T>'s sort algorithm has changed (to be an introspective sort instead of a quick sort). List<T> の並べ替えは安定しますが、この変更により、さまざまなシナリオが不安定な方法で並べ替えられる可能性があります。List<T>'s sort has never been stable, but this change may cause different scenarios to sort in unstable ways. これは単に、同等の項目が API の後続の呼び出しで異なる順序で並べ替えられる可能性があることを意味します。That simply means that equivalent items may sort in different orders in subsequent calls of the API.
提案される解決策Suggestion 以前の並べ替えアルゴリズムも不安定であるため (ただし、方法は若干異なる)、特定の順序で常に並べ替える同等の項目に依存するコードがあってはなりません。Because the old sort algorithm was also unstable (though in slightly different ways), there should be no code that depends on equivalent items always sorting in a particular order. それに依存していて、以前の動作で問題がないコードのインスタンスが存在する場合は、適切な順序で項目を決定論的に並べ替える比較子を使用するようにそのコードを更新する必要があります。If there are instances of code depending upon that and being lucky with the old behavior, that code should be updated to use a comparer that will deterministically sort the items in the desired order.
スコープScope 透明Transparent
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

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

説明Details .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 になります。Beginning in the .NET Framework 4.5.1, dynamically binding to the methods SizeOf<T>(), SizeOf<T>(T), PtrToStructure(IntPtr, Object), PtrToStructure(IntPtr, Type), PtrToStructure<T>(IntPtr), or PtrToStructure<T>(IntPtr, T), (via Windows PowerShell, IronPython, or the C# dynamic keyword, for example) can result in MethodInvocationExceptions because new overloads of these methods have been added that may be ambiguous to the scripting engines.
提案される解決策Suggestion 使用するオーバーロードを明確に示すように、スクリプトを更新します。Update scripts to clearly indicate which overload should be used. これは、一般に、メソッドの型パラメーターを Type として明示的にキャストすることによって行われます。This can typically done by explicitly casting the methods' type parameters as Type. この問題の回避方法の詳細と例については、このリンク を参照してください。See this link for more detail and examples of how to workaround the issue.
スコープScope マイナーMinor
VersionVersion 4.5.14.5.1
Type ランタイムRuntime

ターゲット フレームワーク モニカーがないと、4.0 の動作になるMissing Target Framework Moniker results in 4.0 behavior

説明Details アセンブリ レベルで TargetFrameworkAttribute が適用されていないアプリケーションは、自動的に .NET Framework 4.0 のセマンティクス (quirks) を使用して実行します。Applications without a TargetFrameworkAttribute applied at the assembly level will automatically run using the semantics (quirks) of the .NET Framework 4.0. 高い品質を確保するには、すべてのバイナリを、ビルドされた .NET Framework のバージョンを示す TargetFrameworkAttribute で明示的に属性指定することをお勧めします。To ensure high quality, it is recommended that all binaries be explicitly attributed with a TargetFrameworkAttribute indicating the version of the .NET Framework they were built with. プロジェクト ファイルでターゲット フレームワーク モニカーを使用すると、MSBuid は TargetFrameworkAttribute を自動的に適用します。Note that using a target framework moniker in a project file will cause MSBuild to automatically apply a TargetFrameworkAttribute.
提案される解決策Suggestion TargetFrameworkAttribute は、属性をアセンブリに直接追加するか、プロジェクト ファイルで、または Visual Studio のプロジェクト プロパティ GUI でターゲット フレームワークを指定することによって指定する必要があります。A TargetFrameworkAttribute should be supplied, either through adding the attribute directly to the assembly or by specifying a target framework in the project file or through Visual Studio's project properties GUI.
スコープScope MajorMajor
バージョンVersion 4.54.5
Type ランタイムRuntime

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

説明Details IAsyncResult.AsyncWaitHandleを除き、Task メソッドでオブジェクトが破棄された後も ObjectDisposedException の例外がスローされることがなくなりました。この変更により、キャッシュされたタスクを使用できるようになりました。Except for IAsyncResult.AsyncWaitHandle, Task methods no longer throw an ObjectDisposedException exception after the object is disposed.This change supports the use of cached tasks. たとえば、メソッドで新しいタスクを割り当てる代わりに、既に完了した操作を表す、キャッシュされたタスクを返すことができます。For example, a method can return a cached task to represent an already completed operation instead of allocating a new task. これは、タスクの任意のコンシューマーによって破棄されてしまうと、使用不可能になってしまう以前の .NET Framework のバージョンでは不可能でした。This was impossible in previous .NET Framework versions, because any consumer of the task could dispose of it, which rendered it unusable.
提案される解決策Suggestion オブジェクトが破棄されたとき、Task メソッドが ObjectDisposedException をスローしなくなったことに注意してください。Be aware that Task methods may no longer throw ObjectDisposedException in cases when the object is disposed. アプリが、タスクが破棄されたことを確認するために、この例外に依存していた場合は、Status を使用してタスクのステータスを明示的に確認するように、アプリを更新する必要があります。If an app was depending on this exception to know that a task was disposed, it should be updated to explicitly check the task's status using Status.
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime

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

説明Details URI エスケープは、.NET Framework 4.5 で、RFC 3986 をサポートするように変更されました。URI escaping has changed in .NET Framework 4.5 to support RFC 3986. 具体的な変更内容:Specific changes include:
提案される解決策Suggestion
  • 無効なエスケープ シーケンスの場合、UnescapeDataString(String) のスローに依存しないように、アプリケーションを更新します。Update applications to not rely on UnescapeDataString(String) to throw in the case of an invalid escape sequence. このようなシーケンスは、直接削除する必要があります。Such sequences must be detected directly now.
  • 同様に、エスケープおよびエスケープ解除された URI とデータ文字列は、.NET Framework 4.0 と .NET Framework 4.5 で異なる場合があるため、.NET のバージョン間で直接比較しないでください。Similarly, expect that Escaped and Unescaped URI and Data strings may vary from .NET Framework 4.0 and .NET Framework 4.5 and should not be compared across .NET versions directly. 代わりに、1 つの .NET バージョンで解析と正規化を行ってから比較してください。Instead, they should be parsed and normalized in a single .NET version before any comparisons are made.
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

終了時に WinRT ストリーム アダプターで FlushAsync が自動的に呼び出されなくなりましたWinRT stream adapters no long call FlushAsync automatically on close

説明Details Windows ストア アプリの Windows ランタイム ストリーム アダプターで、Dispose メソッドから FlushAsync メソッドが呼び出されなくなりました。In Windows Store apps, Windows Runtime stream adapters no longer call the FlushAsync method from the Dispose method.
提案される解決策Suggestion この変更は透過的である必要があります。This change should be transparent. 開発者は次のようなコードを記述して以前の動作を復元できます。Developers can restore the previous behavior by writing code like this:
using (var stream = GetWindowsRuntimeStream() as Stream)
{
// do something
await stream.FlushAsync();
}
スコープScope 透明Transparent
VersionVersion 4.5.14.5.1
Type ランタイムRuntime

データData

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

説明Details .NET Framework 4.5.1 以降、.NET Framework では、切断された SQL 接続の再接続が自動的に試行されます。Beginning in the .NET Framework 4.5.1, the .NET Framework will attempt to automatically reconnect broken SQL connections. 通常、これはアプリの安定性を高めますが、再接続時に行動できるよう、接続が失われたことをアプリに認識させる必要があるという極端な状況があります。Although this will typically make apps more reliable, there are edge cases in which an app needs to know that the connection was lost so that it can take some action upon reconnection.
提案される解決策Suggestion 互換性の問題からこの機能が望ましくない場合、接続文字列 (または SqlConnectionStringBuilder) の ConnectRetryCount プロパティを 0 に設定することで無効にできます。If this feature is undesirable due to compatibility concerns, it can be disabled by setting the ConnectRetryCount property of a connection string (or SqlConnectionStringBuilder) to 0.
スコープScope エッジEdge
VersionVersion 4.5.14.5.1
Type ランタイムRuntime
影響を受ける APIAffected APIs

sql_variant データはデータベースの照合順序ではなく、sql_variant の照合順序を使用するSql_variant data uses sql_variant collation rather than database collation

説明Details sql_variant データはデータベースの照合順序ではなく sql_variant の照合順序を使用します。sql_variant data uses sql_variant collation rather than database collation.
提案される解決策Suggestion この変更により、データベースの照合順序が sql_variant の照合順序と異なる場合にデータ破損が生じる可能性に対応できます。This change addresses possible data corruption if the database collation differs from the sql_variant collation. 破損したデータに依存するアプリケーションでは、エラーが発生する場合があります。Applications that rely on the corrupted data may experience failure.
スコープScope 透明Transparent
VersionVersion 4.54.5
Type ランタイムRuntime

SqlBulkCopy で文字列に挿入先の列エンコードが使用されるSqlBulkCopy uses destination column encoding for strings

説明Details データを列に挿入する場合、SqlBulkCopyVARCHARCHAR の型の既定エンコードではなく、挿入先の列のエンコードを使用します。When inserting data into a column, SqlBulkCopy uses the encoding of the destination column rather than the default encoding for VARCHAR and CHAR types. この変更により、挿入先の列が既定のエンコードを使用しない場合に、既定のエンコードを使用することによって発生するデータ破損の可能性がなくなります。This change eliminates the possibility of data corruption caused by using the default encoding when the destination column does not use the default encoding. まれに、エンコードに変更を加えることによって、挿入先の列に収まりきらない大きいデータが生成された場合に、既存のアプリケーションで SqlException の例外がスローされることがあります。In rare cases, an existing application may throw a SqlException exception if the change in encoding produces data that is too big to fit into the destination column.
提案される解決策Suggestion SqlBulkCopy では、エンコードが異なるため、データは破損しなくなると予想します。Expect that SqlBulkCopy will no longer corrupt data due to encoding differences. 挿入先の列のサイズ制限に近づいている文字列がコピーされている場合、データの事前エンコード (コピーして挿入先の行にデータが収まることを確認するため) や SqlException のキャッチが必要になることがあります。If strings near the destination column's size limit are being copied, it may be necessary to either pre-encode data (to be copied to check that the data will fit in the destination column) or catch SqlExceptions.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

SqlConnection は VIA アダプターを使用して SQL Server 1997 またはデータベースに接続できなくなりましたSqlConnection can no longer connect to SQL Server 1997 or databases using the VIA adapter

説明Details 仮想インターフェイス アダプター (VIA) プロトコルを使用した SQL Server データベースへの接続はサポートされなくなりました。Connections to SQL Server databases using the Virtual Interface Adapter (VIA) protocol are no longer supported. SQL Server データベースへの接続に使用されるプロトコルは、接続文字列で表示されます。The protocol used to connect to a SQL Server database is visible in the connection string. VIA 接続には via:<servername> が含まれます。A VIA connection will contain via:<servername>. このアプリが VIA 以外のプロトコル (tcp: や np: など) を介して SQL に接続される場合、破壊的変更は検出されません。また、SQL Server 7 (1997) への接続がサポートされなくなります。If this app is connecting to SQL via a protocol other than VIA (tcp: or np: for example), then no breaking change will be encountered.Also, connections to SQL Server 7 (1997) are no longer supported.
提案される解決策Suggestion VIA プロトコルは推奨されていないので、SQL データベースに接続するには別のプロトコルを使用する必要があります。The VIA protocol is deprecated, so an alternative protocol should be used to connect to SQL databases. 最も一般的に使用されるプロトコルは TCP/IP です。The most common protocol used is TCP/IP. TCP/IP での接続の詳細については、「方法: データベース インスタンスの TCP/IP プロトコルを有効にする」を参照してください。For more information about connecting through TCP/IP, see Enable the TCP/IP protocol for a database instance. データベースへのアクセスがイントラネット内からに限定されていて、ネットワーク速度が遅い場合は、共有パイプ プロトコルがより優れたパフォーマンスを提供する可能性があります。If the database is only accessed from within an intranet, the shared pipes protocol may provide better performance if the network is slow.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

デバッガーDebugger

デバッガーですぐに null コアレッサー値が表示されないNull coalescer values are not visible in debugger until one step later

説明Details .NET Framework 4.5 のバグにより、64 ビット版の Framework で実行中に代入演算が実行された直後に、デバッガーで null 合体演算で設定された値が表示されません。A bug in the .NET Framework 4.5 causes values set via a null coalescing operation to not be visible in the debugger immediately after the assignment operation is executed when running on the 64-bit version of the Framework.
提案される解決策Suggestion デバッガーでの操作に時間がかかると、ローカル/フィールドの値が正しく更新されなくなります。Stepping one additional time in the debugger will cause the local/field's value to be correctly updated. この問題は .NET Framework 4.6 で修正されました。このバージョンの .NET Framework にアップグレードすれば、問題は解決します。Also, this issue has been fixed in the .NET Framework 4.6; upgrading to that version of the Framework should solve the issue.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime

Entity FrameworkEntity Framework

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

説明Details AttachDBFilename が指定されたときの DDL API の動作が、次のように変更されました。The behavior of DDL APIs when AttachDBFilename is specified has changed as follows:
  • 接続文字列で初期カタログ値を指定する必要がなくなりました。Connection strings need not specify an Initial Catalog value. 以前は、AttachDBFilename と初期カタログの両方が必要でした。Previously, both AttachDBFilename and Initial Catalog were required.
  • AttachDBFilename と初期カタログの両方が指定され、指定された MDF ファイルが存在した場合、DatabaseExists メソッドは true を返します。If both AttachDBFilename and Initial Catalog are specified and the given MDF file exists, the DatabaseExists method returns true. 以前は、falseが返されていました。Previously, it returned false.
  • AttachDBFilename と初期カタログの両方が指定され、指定された MDF ファイルが存在した場合、DeleteDatabase メソッドを呼び出すと、ファイルが削除されます。If both AttachDBFilename and Initial Catalog are specified and the given MDF file exists, calling the DeleteDatabase method deletes the files.
  • 接続文字列で存在しない MDF の AttachDBFilename 値および存在しない初期カタログが指定されたときに DeleteDatabase が呼び出されると、メソッドでは InvalidOperationException 例外がスローされます。If DeleteDatabase is called when the connection string specifies an AttachDBFilename value with an MDF that doesn't exist and an Initial Catalog that doesn't exist, the method throws an InvalidOperationException exception. 以前は、SqlException の例外がスローされていました。Previously, it threw a SqlException exception.
提案される解決策Suggestion これらの変更により、DDL API を使用するアプリケーションおよびツールの構築が簡単になりました。These changes make it easier to build tools and applications that use the DDL APIs. これらの変更は、次のシナリオでアプリケーションの互換性に影響を及ぼす可能性があります。These changes can affect application compatibility in the following scenarios:
  • DROP DATABASEDeleteDatabase が返されたときに、DatabaseExists を呼び出す代わりに直接 true コマンドを実行するコードをユーザーが作成した場合。The user writes code that executes a DROP DATABASE command directly instead of calling DeleteDatabase if DatabaseExists returns true. データベースがアタッチされておらず、MDF ファイルが存在する場合、これによって既存のコードが破損します。This breaks existing code If the database is not attached but the MDF file exists.
  • 初期カタログと MDF ファイルが存在しない場合に、InvalidOperationException ではなく SqlException をスローするように、DeleteDatabase メソッドを要求するコードをユーザーが作成した場合。The user writes code that expects the DeleteDatabase method to throw a SqlException rather than an InvalidOperationException when the Initial Catalog and MDF file don't exist.
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime

ObjectContext.CreateDatabase メソッドと DbProviderServices.CreateDatabase メソッドで異なる例外処理Different exception handling for ObjectContext.CreateDatabase and DbProviderServices.CreateDatabase methods

説明Details .NET Framework 4.5 から、データベースの作成が失敗した場合、CreateDatabase メソッドは、空のデータベースの削除を試みます。Beginning in .NET Framework 4.5, if database creation fails, CreateDatabase methods will attempt to drop the empty database. その操作が成功した場合、元の SqlException は伝播されます (.NET Framework 4.0 で常にスローされていた InvalidOperationException の代わりに)If that operation succeeds, the original SqlException will be propagated (instead of the InvalidOperationException that was always thrown in .NET Framework 4.0)
提案される解決策Suggestion CreateDatabase() または CreateDatabase(DbConnection, Nullable<Int32>, StoreItemCollection) の実行中に InvalidOperationException をキャッチするときには、SQLExceptions もキャッチする必要があります。When catching an InvalidOperationException while executing CreateDatabase() or CreateDatabase(DbConnection, Nullable<Int32>, StoreItemCollection), SQLExceptions should now also be caught.
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

EF で特定の特性を持つ QueryViews がスローされなくなったEF no longer throws for QueryViews with specific characteristics

説明Details クエリの一部として関連エンティティを含めようとする 0..1 ナビゲーション プロパティを使用して QueryViews に関係するクエリをアプリが実行する場合、Entity Framework で StackOverflowException 例外がスローされなくなりました。Entity Framework no longer throws a StackOverflowException exception when an app executes a query that involves a QueryView with a 0..1 navigation property that attempts to include the related entities as part of the query. たとえば、.Include(e => e.RelatedNavProp) を呼び出す場合です。For example, by calling .Include(e => e.RelatedNavProp).
提案される解決策Suggestion この変更は、.Include を呼び出すクエリの実行時に 1 - 0..1 の関係にある QueryViews を使用するコードにのみ影響します。This change only affects code that uses QueryViews with 1-0..1 relationships when running queries that call .Include. これにより信頼性が向上し、ほとんどすべてのアプリに対して透過的になります。It improves reliability and should be transparent to almost all apps. ただし、予期しない動作が発生する場合、次のエントリをアプリの構成ファイルの <appSettings> セクションに追加することにより、この変更を無効にできます。However, if it causes unexpected behavior, you can disable it by adding the following entry to the <appSettings> section of the app's configuration file:
<add key="EntityFramework_SimplifyUserSpecifiedViews" value="false" />
スコープScope エッジEdge
VersionVersion 4.5.24.5.2
Type ランタイムRuntime

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

説明Details Entity Framework 6.0 を使用するアプリを Visual Studio 2013 から起動すると、非常に遅くなることがあります。Launching an app from Visual Studio 2013 that uses EntityFramework 6.0 can be very slow.
提案される解決策Suggestion この問題は、EntityFramework 6.0.2 で修正されます。This issue is fixed in EntityFramework 6.0.2. パフォーマンス問題を回避するには、EntityFramework を更新します。Update EntityFramework to avoid the performance issue.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime

ObjectContext.CreateDatabase メソッドによって作成されたログ ファイル名が、SQL Server の仕様に一致するように変更されたLog file name created by the ObjectContext.CreateDatabase method has changed to match SQL Server specifications

説明Details CreateDatabase() メソッドが、直接、または SqlClient プロバイダーと共に Code First と接続文字列の AttachDBFilename 値を使用して呼び出されると、filename.ldf (filename は AttachDBFilename 値によって指定されたファイルの名前) ではなく、filename_log.ldf という名前のログ ファイルを作成します。When the CreateDatabase() method is called either directly or by using Code First with the SqlClient provider and an AttachDBFilename value in the connection string, it creates a log file named filename_log.ldf instead of filename.ldf (where filename is the name of the file specified by the AttachDBFilename value). この変更により、SQL Server の仕様に従ってログ ファイル名が提供されるため、デバッグ機能が向上します。This change improves debugging by providing a log file named according to SQL Server specifications.
提案される解決策Suggestion ログ ファイル名がアプリケーションにとって重要な場合、標準の _log.ldf ファイル名形式を予期するように、アプリケーションを更新する必要があります。If the log file name is important for an app, the app should be updated to expect the standard _log.ldf file name format.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

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

説明Details .NET Framework 4.0 では、ObjectContext.Translate および ObjectContext.ExecuteStoreQuery メソッドのジェネリック パラメーター T を列挙型にすることはできませんでした。In .NET Framework 4.0, the generic parameter T of ObjectContext.Translate and ObjectContext.ExecuteStoreQuery methods could not be an enum. このシナリオがサポートされるようになりました。That scenario is now supported.
提案される解決策Suggestion .NET Framework 4.0 では、列挙型に対して Translate または ExecuteStoreQuery が呼び出された場合、"0" が返されました。If Translate or ExecuteStoreQuery was called on an enum type in .NET Framework 4.0, '0' was returned. この動作が望ましい場合は、呼び出しを定数 0 (または同等の列挙型) に置き換えてください。If that behavior was desirable, the calls should be replaced with a constant 0 (or the enum equivalent of it).
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

異なる 4.5 SQL 生成からより単純な 4.0 SQL 生成に戻すOpt-in break to revert from different 4.5 SQL generation to simpler 4.0 SQL generation

説明Details 最初に OrderBy を使用せずに JOIN ステートメントを生成し、制限操作への呼び出しを含むクエリで、より単純な SQL が生成されるようになりました。Queries that produce JOIN statements and contain a call to a limiting operation without first using OrderBy now produce simpler SQL. .NET Framework 4.5 へのアップグレード後、これらのクエリは以前のバージョンよりも複雑な SQL を生成しました。After upgrading to .NET Framework 4.5, these queries produced more complicated SQL than previous versions.
提案される解決策Suggestion 既定では、この機能は無効です。This feature is disabled by default. Entity Framework がパフォーマンスを低下させる追加の JOIN ステートメントを生成する場合は、アプリケーション構成 (app.config) ファイルの <appSettings> セクションへ次のエントリを追加してこの機能を有効にできます。If Entity Framework generates extra JOIN statements that cause performance degradation, you can enable this feature by adding the following entry to the <appSettings> section of the application configuration (app.config) file:
<add key="EntityFramework_SimplifyLimitOperations" value="true" />
スコープScope 透明Transparent
VersionVersion 4.5.24.5.2
Type ランタイムRuntime

LINQLINQ

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

説明Details .NET Framework 4.5 以降では、Empty<TResult>() は、常にキャッシュされた内部インスタンス IEnumerable<T> を返します。以前は、Empty<TResult>() は、API が呼び出された時点で空の IEnumerable<T> をキャッシュしました。つまり、Empty<TResult>() が迅速かつ同時に呼び出されるような条件では、API の別の呼び出しに対して、型の別のインスタンスが返される可能性がありました。Beginning in .NET Framework 4.5, Empty<TResult>() always returns a cached internal instance IEnumerable<T>.Previously, Empty<TResult>() would cache an empty IEnumerable<T> at the time the API was called, meaning that in some conditions in which Empty<TResult>() was called rapidly and concurrently, different instances of the type could be returned for different calls to the API.
提案される解決策Suggestion 以前の動作は非確定的なため、コードがそれに依存している可能性は低いです。Because the previous behavior was non-deterministic, code is unlikely to depend on it. ただし、ありそうにないことですが、空の列挙が比較され、ときには等しくないことが予期されている場合には、Empty<TResult>() を使用する代わりに、明示的に空の配列を作成する (new T[0]) 必要があります。However, in the unlikely case that empty enumerables are being compared and expected to sometimes be unequal, explicit empty arrays should be created (new T[0]) instead of using Empty<TResult>().
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

MEF (Managed Extensibility Framework)Managed Extensibility Framework (MEF)

MEF カタログは IEnumerable を実装するため、シリアライザーの作成には使用できなくなったMEF catalogs implement IEnumerable and therefore can no longer be used to create a serializer

説明Details .NET Framework 4.5 以降では、MEF カタログは IEnumerable を実装するため、シリアライザー (XmlSerializer オブジェクト) の作成には使用できなくなりました。Starting with the .NET Framework 4.5, MEF catalogs implement IEnumerable and therefore can no longer be used to create a serializer (XmlSerializer object). MEF カタログをシリアル化しようとすると、例外がスローされます。Trying to serialize a MEF catalog throws an exception.
提案される解決策Suggestion シリアライザーの作成に MEF を使用できなくなりました。Can no longer use MEF to create a serializer
スコープScope MajorMajor
バージョンVersion 4.54.5
Type ランタイムRuntime

ネットワーキングNetworking

.NET Framework 4.5 でシリアル化された MailMessage オブジェクトの逆シリアル化が失敗する可能性があるDeserialization of MailMessage objects serialized under the .NET Framework 4.5 may fail

説明Details .NET Framework 4.5 以降では、MailMessage オブジェクトに非 ASCII 文字を含めることができます。Starting with the .NET Framework 4.5, MailMessage objects can include non-ASCII characters. .NET Framework 4 では、ASCII 文字しかサポートされていません。In the .NET Framework 4, only ASCII characters are supported. 非 ASCII 文字が含まれ、.NET Framework 4.5 以降でシリアル化された MailMessage オブジェクトは、.NET Framework 4 で逆シリアル化することはできません。MailMessage objects that contain non-ASCII characters and that are serialized under the .NET Framework 4.5 or later cannot be deserialized under the .NET Framework 4.
提案される解決策Suggestion MailMessage オブジェクトの逆シリアル化時に、コードで例外処理が提供されることを確認します。Ensure that your code provides exception handling when deserializing a MailMessage object.
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

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

説明Details System.Net.PeerToPeer.Collaboration 名前空間は、Windows 8 以上では使用できません。The System.Net.PeerToPeer.Collaboration namespace is unavailable on Windows 8 or above.
提案される解決策Suggestion Windows 8 以上をサポートするアプリは、この名前空間またはそのメンバーに依存しないように更新する必要があります。Apps that support Windows 8 or above must be updated to not depend on this namespace or its members.
スコープScope MajorMajor
バージョンVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

印刷Printing

PrintSystemJobInfo.JobStream に書き込まれるデータは XPS 形式とする必要がありますData written to PrintSystemJobInfo.JobStream must be in XPS format

説明Details JobStream プロパティにより印刷ジョブのストリームが公開されます。The JobStream property exposes the stream of a print job. ユーザーが基になるオペレーティング システム印刷コンポーネントに生のデータを送信するには、このストリームにデータを書き込みを行います。 .NET Framework 4.5 以降、Windows 8 より後のバージョンの Windows オペレーティング システムでは、このストリームに書き込むデータは XPS 形式のパッケージ ストリームにする必要があります。The user can send raw data to the underlying operating system printing components by writing to this stream.Starting with the .NET Framework 4.5 on Windows 8 and later versions of the Windows operating system, data written to this stream must be in XPS format as a package stream.
提案される解決策Suggestion 印刷内容を出力するには、次のいずれかの操作を行います。To output print content, you can do either of the following:
  • XpsDocumentWriter クラスを使用して印刷内容を出力します。Use the XpsDocumentWriter class to output print content. これが、推奨される方法です。This is the recommended alternative.
  • JobStream プロパティによって返されるストリームに送信されるデータを、XPS 形式のパッケージ ストリームにします。Ensure that the data sent to the stream returned by the JobStream property is in XPS format as a package stream.
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

シリアル化Serialization

BinaryFormatter による LoadFrom コンテキストからの型の検索が失敗する場合があるBinaryFormatter can fail to find type from LoadFrom context

説明Details .NET Framework 4.5 の時点で、XmlSerializer の複数の変更により、LoadFrom コンテキストに読み込まれた型の BinaryFormatter を使った逆シリアル化に違いが発生する場合があります。As of .NET Framework 4.5, a number of XmlSerializer changes may cause differences in deserialization when using BinaryFormatter to deserialize types that had been loaded in the LoadFrom context. これらの変更は XmlSerializer が型を読み込む新しい方法によるものであり、後で BinaryFormatter がその型に逆シリアル化しようとするときに異なる動作が発生します。These changes are due to the new ways XmlSerializer now loads a type which causes different behavior when a BinaryFormatter attempts to deserialize to that type later on. 既定のシリアル化バインダーは LoadFrom コンテキストを自動的に検索しませんが、状況によっては XmlSerializer の以前の動作に基づいて機能する可能性があります。The default serialization binder does not automatically search the LoadFrom context, although it may have worked in some circumstances based on the old behavior of XmlSerializer. 変更のため、異なるコンテキストで読み込まれたアセンブリから型が読み込まれるときに、FileNotFoundException がスローされる可能性があります。Due to the changes, when a type is being loaded from an assembly loaded in a different context, a FileNotFoundException may be thrown.
提案される解決策Suggestion この例外が発生する場合は、BinaryFormatterBinder プロパティを、正しい型を検索するカスタム バインダーに設定することができます。If this exception is seen, the Binder property of the BinaryFormatter can be set to a custom binder that will find the correct type.
var formatter = new BinaryFormatter { Binder = new TypeFinderBinder() }
そして、カスタム バインダーで次のようにします。And then the custom binder:
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));
}
}
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

異なる .NET バージョンでシリアル化された ConcurrentDictionary を NetDataContractSerializer で逆シリアル化できないNetDataContractSerializer fails to deserialize a ConcurrentDictionary serialized with a different .NET version

説明Details 設計上、NetDataContractSerializer は、シリアル化と逆シリアル化の両方で、同一の CLR 型を共有する結果になる場合にのみ使用できます。By design, the NetDataContractSerializer can be used only if both the serializing and deserializing ends share the same CLR types. したがって、あるバージョンの .NET Framework でシリアル化されたオブジェクトを別のバージョンで逆シリアル化することは保証されません。ConcurrentDictionary<TKey,TValue> Therefore, it is not guaranteed that an object serialized with one version of the .NET Framework can be deserialized by a different version.ConcurrentDictionary<TKey,TValue> 型は、.NET Framework 4.5 以前でシリアル化された場合、.NET Framework 4.5.1 以降では正しく逆シリアル化されないことがわかっています。is a type that is known to not to deserialize correctly if serialized with the .NET Framework 4.5 or earlier and deserialized with the .NET Framework 4.5.1 or later.
提案される解決策Suggestion この問題の考えられるいくつかの回避策を以下に示します。There are a number of possible work-arounds for this issue:
スコープScope マイナーMinor
VersionVersion 4.5.14.5.1
Type ランタイムRuntime
影響を受ける APIAffected APIs

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

説明Details SoapFormatter は、特定のバージョンの .NET Framework でシリアル化されたオブジェクトが別のバージョンで正常に逆シリアル化されることを保証しません。The SoapFormatter does not guarantee that objects serialized under one .NET Framework version will successfully deserialize under a different version. 具体的には、(Hashtable のような) 順序付けられたコレクションの中には、4.0 と 4.5 の間でメンバーが追加されたものがあり、このような種類のオブジェクトが .NET Framework 4.5 でシリアル化された場合、.NET Framework 4.0 では逆シリアル化できません。Specifically, some ordered collections (like Hashtable) added members between 4.0 and 4.5 such that objects of these types cannot deserialize with .NET Framework 4.0 if they were serialized with .NET Framework 4.5. シリアル化データのシリアル化と逆シリアル化の両方が同じバージョンの .NET Framework で行われた場合、問題は発生しないことに注意してください。Note that if the serialized data is both serialized and deserialized with the same .NET Framework version, no issue will occur.
提案される解決策Suggestion SoapFormatter のシリアル化は、.NET Framework の変更に対応できる BinaryFormatter のシリアル化または NetDataContractSerializer に置き換える必要があります。SoapFormatter serialization should be replaced with BinaryFormatter serialization or NetDataContractSerializer to be resilient to .NET Framework changes.
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

アクセス可能なメンバーを非表示にする型をアクセス不可のメンバーでシリアル化すると、XmlSerializer が失敗するXmlSerializer fails while serializing a type that hides an accessible member with an inaccessible one

説明Details 基本型で (パブリックなど) 以前はアクセス可能だった同じ名前のフィールドまたはプロパティを ("新しい" キーワードを使用して) 非表示にするアクセス不可のフィールドまたはプロパティが型に含まれている場合、派生型をシリアル化すると、XmlSerializer が失敗する可能性があります。When serializing a derived type, the XmlSerializer can fail if the type contains an inaccessible field or property that hides (via the 'new' keyword) a field or property of the same name that was previously accessible (public, for example) on the base type.
提案される解決策Suggestion この問題は、新しい非表示メンバーを XmlSerializer にアクセスできるようにする (パブリックにするなど) ことで解決できます。または、次の構成設定で 4.0 XmlSerializer の動作に戻します。これにより、問題が解決されます。This problem can be solved by making the new, hiding member accessible to the XmlSerializer (by marking it public, for example).Alternatively, the following config setting will revert to 4.0 XmlSerializer behavior, which will fix the problem:
<system.xml.serialization>
<xmlSerializer useLegacySerializerGeneration="true" />
</system.xml.serialization>
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

Web アプリケーションWeb Applications

.NET Framework 1.1 および 2.0 からのマネージド ブラウザーでのコントロールのホストがブロックされるManaged browser hosting controls from the .NET Framework 1.1 and 2.0 are blocked

説明Details これらのコントロールのホストは、Internet Explorer でブロックされます。Hosting these controls is blocked in Internet Explorer.
提案される解決策Suggestion Internet Explorer では、マネージド ブラウザーを使用してコントロールをホストするアプリケーションは起動できません。Internet Explorer will fail to launch an application that uses managed browser hosting controls. 以前の動作を復元するには、レジストリ サブキー HKLM/SOFTWARE/MICROSOFT/.NETFramework の EnableIEHosting 値を、x86 システム用および x64 システム上の 32 ビット プロセス用に 1 に設定し、レジストリ サブキー HKLM/SOFTWARE/Wow6432Node/Microsoft/.NETFrameworkEnableIEHosting 値を x64 システム上の 64 ビット プロセス用に 1 に設定します。The previous behavior can be restored by setting the EnableIEHosting value of the registry subkey HKLM/SOFTWARE/MICROSOFT/.NETFramework to 1 for x86 systems and for 32-bit processes on x64 systems, and by setting the EnableIEHosting value of the registry subkey HKLM/SOFTWARE/Wow6432Node/Microsoft/.NETFramework to 1 for 64-bit processes on x64 systems.
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime

Windows Communication Foundation (WCF)Windows Communication Foundation (WCF)

maxRequestLength または maxReceivedMessageSize のエラー コードが異なるError codes for maxRequestLength or maxReceivedMessageSize are different

説明Details Internet Information Services (IIS) または ASP.NET 開発サーバーでホストされており、maxRequestLength (ASP.NET の場合) または maxReceivedMessageSize (WCF の場合) を超える WCF Web サービスのメッセージに異なるエラー コードがあります。HTTP 状態コードは 400 (正しくない要求) から 413 (要求したエンティティが大きすぎます) に変更され、maxRequestLength または maxReceivedMessageSize 設定を超えるメッセージでは ProtocolException 例外がスローされます。Messages in WCF web services hosted in Internet Information Services (IIS) or ASP.NET Development Server that exceed maxRequestLength (in ASP.NET) or maxReceivedMessageSize (in WCF) have different error codeThe HTTP status code has changed from 400 (Bad Request) to 413 (Request Entity Too Large), and messages that exceed either the maxRequestLength or the maxReceivedMessageSize setting throw a ProtocolException exception. これには、転送モードが Streamed である場合も含まれます。This includes cases in which the transfer mode is Streamed.
提案される解決策Suggestion この変更により、メッセージ長が ASP.NET または WCF で許可されている制限を超えたときのデバッグが簡単になります。HTTP 400 状態コードに基づいて処理を実行するコードはすべて変更する必要があります。This change facilitates debugging in cases where the message length exceeds the limits allowed by ASP.NET or WCF.You must modify any code that performs processing based on an HTTP 400 status code.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime

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

説明Details この設定は、WCF サービスをアクティブにするためにサーバー上で使用できなければならない最小メモリを設定します。This setting establishes the minimum memory that must be available on the server before a WCF service can be activated. OutOfMemoryException 例外が発生しないようにデザインされています。It is designed to prevent OutOfMemoryException exceptions. .NET Framework 4.5 では、この設定には効果はありません。In the .NET Framework 4.5, this setting had no effect. .NET Framework 4.5.1 では、この設定が守られます。In the .NET Framework 4.5.1, the setting is observed.
提案される解決策Suggestion Web サーバーで使用できる空きメモリが構成設定によって定義されたパーセンテージよりも小さい場合、例外が発生します。An exception occurs if the free memory available on the web server is less than the percentage defined by the configuration setting. 制約されたメモリ環境で正常に開始し、実行された WCF サービスが今度は失敗することがあります。Some WCF services that successfully started and ran in a constrained memory environment may now fail.
スコープScope マイナーMinor
VersionVersion 4.5.14.5.1
Type ランタイムRuntime

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

説明Details WebServiceHost オブジェクトでは、アプリケーション コードによって明示的なエンドポイントが追加された場合に、既定のエンドポイントが追加されなくなりました。The WebServiceHost object no longer adds a default endpoint if an explicit endpoint has been added by application code.
提案される解決策Suggestion ユーザーが既定のエンドポイントに接続できることを期待していて、他の明示的なエンドポイントが WebServiceHost に追加されている場合は、既定のエンドポイントも明示的に追加する必要があります (AddDefaultEndpoints() を使用して)。If users will expect to be able to connect to a default endpoint and other explicit endpoints have been added to the WebServiceHost, default endpoints should also be added explicitly (using AddDefaultEndpoints()).
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

OData URL の Replace メソッドが既定で無効になるThe Replace method in OData URLs is disabled by default

説明Details .NET Framework 4.5 以降では、OData URL の Replace メソッドは既定では無効です。Beginning in the .NET Framework 4.5, the Replace method in OData URLs is disabled by default. OData Replace が無効のとき (既定)、replace 関数を含むユーザー要求 (一般的ではない) は失敗します。When OData Replace is disabled (now by default), any user requests including replace functions (which are uncommon) will fail.
提案される解決策Suggestion Replace メソッドが必要な場合 (一般的ではない)、構成設定 (ReplaceFunction) によって再び有効にできます。If the replace method is required (which is uncommon), it can be re-enabled through a config settings (ReplaceFunction). ただし、有効になった replace メソッドはセキュリティの脆弱性を開くことがあり、慎重にレビューしてから使用する必要があります。However, an enabled replace method can open security vulnerabilities and should only be used after careful review.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

Windows フォームWindows Forms

PreviewLostKeyboardFocus は、そのハンドラーが Windows フォーム メッセージ ボックスを表示する場合、繰り返し呼び出されるPreviewLostKeyboardFocus is called repeatedly if its handler shows a Windows Forms message box

説明Details .NET Framework 4.5 以降では、PreviewLostKeyboardFocus ハンドラーから MessageBox.Show を呼び出すと、メッセージ ボックスが閉じられたとき、ハンドラーが再実行して、メッセージ ボックスの無限ループになる可能性があります。Beginning in the .NET Framework 4.5, calling MessageBox.Show from a PreviewLostKeyboardFocus handler will cause the handler to re-fire when the message box is closed, potentially resulting in an infinite loop of message boxes.
提案される解決策Suggestion この問題を回避するには、2 つの方法があります。There are two options to work around this issue:
  1. MessageBox.Show の代わりに MessageBox.Show を呼び出すことによって回避できます。It may be avoided by calling MessageBox.Show instead of MessageBox.Show.
  2. UIElement.LostKeyboardFocus イベント ハンドラーから (PreviewLostKeyboardFocus イベント ハンドラーではなく) メッセージ ボックスを表示することによって回避できます。It may be avoided by showing the message box from a UIElement.LostKeyboardFocus event handler (as opposed to a PreviewLostKeyboardFocus event handler).
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

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

説明Details System.Drawing.dll アセンブリの CheckForOverflowUnderflow プロパティが true に設定されます。The CheckForOverflowUnderflow property for the System.Drawing.dll assembly is set to true.
提案される解決策Suggestion これまではオーバーフローが発生すると、その結果は自動的に切り捨てられました。Previously when overflows occurred, the result would be silently truncated. 現在では、OverflowException 例外がスローされます。Now an OverflowException exception is thrown.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime

Windows Presentation Foundation (WPF)Windows Presentation Foundation (WPF)

DataGrid の UnloadingRow イベントのハンドラーから WPF DataGrid の選択された項目にアクセスすると、NullReferenceException が発生する可能性があるAccessing a WPF DataGrid's selected items from a handler of the DataGrid's UnloadingRow event can cause a NullReferenceException

説明Details .NET Framework 4.5 のバグが原因で、行の削除に関連する DataGrid イベントのイベント ハンドラーにより、DataGridSelectedItem または SelectedItems プロパティにアクセスする場合に NullReferenceException がスローされる可能性があります。Due to a bug in the .NET Framework 4.5, event handlers for DataGrid events involving the removal of a row can cause a NullReferenceException to be thrown if they access the DataGrid's SelectedItem or SelectedItems properties.
提案される解決策Suggestion この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。This issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

項目が選択されている WPF ListBox、ListView、または DataGrid に対して Items.Refresh を呼び出すと、重複した項目が要素に表示されることがあるCalling Items.Refresh on a WPF ListBox, ListView, or DataGrid with items selected can cause duplicate items to appear in the element

説明Details .NET Framework 4.5 では、ListBox で項目が選択されているときにコードから ListBox.Items.Refresh を呼び出すと、選択された項目がリストに複製されることがあります。In the .NET Framework 4.5, calling ListBox.Items.Refresh from code while items are selected in a ListBox can cause the selected items to be duplicated in the list. 同様の問題が ListViewDataGrid で発生します。A similar issue occurs with ListView and DataGrid. これは、.NET Framework 4.6 で修正されます。This is fixed in the .NET Framework 4.6.
提案される解決策Suggestion この問題は、Refresh() が呼び出される前に、プログラムで項目を選択解除して、呼び出しの完了後に再び選択することによって回避できます。This issue may be worked around by programatically unselecting items before Refresh() is called and then re-selecting them after the call is completed. または、この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。Alternatively, this issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

FlowDocument でテキストの余分な行が表示される場合があるFlowDocument may show an extra line of text

説明Details .NET Framework 4.0 での実行時の表示と比べて、.NET Framework 4.5 での実行時に FlowDocument 要素でテキストの余分な行が表示されることがあります。In some cases, a FlowDocument element will display an extra line of text when running on the .NET Framework 4.5 compared to how it displayed when run on the .NET Framework 4.0. 変更によってテキストが正しく表示されなくなったり、読みにくくなったりするようなことはありませんが、以前は FlowDocument のビューから除外されていたテキストが表示される可能性があります。There are no known cases of the change causing any text to be displayed poorly or illegibly, but it could cause text to appear that previously was omitted from a FlowDocument's view.
提案される解決策Suggestion 場合によっては、表示要素の PageHeight プロパティを 1 ずつ減らすことで、表示行の以前の数を復元できます。In some cases, decreasing the display element's PageHeight property by one can restore the previous number of displayed lines.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

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

説明Details .NET Framework 4.5 では、ComputeInkBoundingBox()Extent が改善され、場合によっては含まれるグリフに対してボックスが小さすぎるという .NET Framework 4.0 での問題に対応しました。Improvements were made to ComputeInkBoundingBox() and Extent in the .NET Framework 4.5 to address issues where the boxes were too small for the contained glyphs in some cases in the .NET Framework 4.0. この結果、.NET Framework 4.5 以降では、いくつかの境界ボックスが大きくなり、UI のレイアウトにわずかな違いが生じます。As a result of this, some bounding boxes will be larger beginning in the .NET Framework 4.5, resulting in subtle differences in UI layout.
提案される解決策Suggestion いくつかのグリフの境界ボックスのサイズが大きくなったことに注意してください。Be aware that some glyph bounding box sizes have increased. このような変更は、通常、プレゼンテーションおよびヒット ボックス テストを向上させますが、以前の (.NET 4.5 より前の) 動作が望ましい場合は、次のエントリをアプリの構成ファイルに追加することによって実現できます。These changes will usually improve presentation and hit box testing, but if the older (pre-.NET 4.5) behavior is desired, it can be opted into by adding the following entry to the app.config file:
<appsettings>
<add key="IncludeAllInkInBoundingBox" value="false">
</appsettings>
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

Items.Clear で SelectedItems から重複部分が削除されないItems.Clear does not remove duplicates from SelectedItems

説明Details セレクター (複数選択が有効になっている) の SelectedItems コレクションに重複部分があるとします。その場合、同じ項目が複数回表示されます。Suppose a Selector (with multiple selection enabled) has duplicates in its SelectedItems collection - the same item appears more than once. データ ソースからこれらの項目を削除すると (たとえば、Items.Clear を呼び出すことにより)、SelectedItems からそれらの項目を削除できなくなります。最初のインスタンスのみが削除されます。Removing those items from the data source (e.g. by calling Items.Clear) fails to remove them from SelectedItems; only the first instance is removed. さらに、SelectedItems (SelectedItems.Clear() など) を引き続き使用すると、ArgumentException などの問題が発生する可能性があります。これは、SelectedItems に、データ ソース内にはもう存在しない項目が含まれているためです。Furthermore, subsequent use of SelectedItems (e.g. SelectedItems.Clear()) can encounter problems such as ArgumentException, because SelectedItems contains items that are no longer in the data source.
提案される解決策Suggestion 可能であれば、.NET Framework 4.6.2 にアップグレードします。Upgrade if possible to .NET Framework 4.6.2.
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

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

説明Details 項目が選択された ListBox にバインドされるコレクションで Move(Int32, Int32) または MoveItem(Int32, Int32) を呼び出すと、ListBox 項目の今後の選択または選択解除で不規則な動作が発生する可能性があります。Calling Move(Int32, Int32) or MoveItem(Int32, Int32) on a collection bound to a ListBox with items selected can lead to erratic behavior with future selection or unselection of ListBox items.
提案される解決策Suggestion Move(Int32, Int32) ではなく Remove(T)Insert(Int32, T) を呼び出すことで、この問題は解決されます。Calling Remove(T) and Insert(Int32, T) instead of Move(Int32, Int32) will work around this issue. または、この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。Alternatively, this issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

WPF の PageRangeSelection の新しい列挙値New enum values in WPF's PageRangeSelection

説明Details 新しい 2 つのメンバー (CurrentPage および SelectedPages) が PageRangeSelection 列挙型に追加されました。Two new members (CurrentPage and SelectedPages) have been added to the PageRangeSelection enum.
提案される解決策Suggestion ほとんどの場合、これらの変更はユーザー コードに影響しません。In most cases, these changes won't impact user code. ただし、PageRangeSelection 型に対する GetNames(Type) または GetValues(Type) 呼び出しに特定の数の要素が存在することに依存するコードは、修正する必要があります。Code that depends on a particular number of elements existing in GetNames(Type) or GetValues(Type) calls on the PageRangeSelection type should be modified, though.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

PreviewLostKeyboardFocus は、そのハンドラーが Windows フォーム メッセージ ボックスを表示する場合、繰り返し呼び出されるPreviewLostKeyboardFocus is called repeatedly if its handler shows a Windows Forms message box

説明Details .NET Framework 4.5 以降では、PreviewLostKeyboardFocus ハンドラーから MessageBox.Show を呼び出すと、メッセージ ボックスが閉じられたとき、ハンドラーが再実行して、メッセージ ボックスの無限ループになる可能性があります。Beginning in the .NET Framework 4.5, calling MessageBox.Show from a PreviewLostKeyboardFocus handler will cause the handler to re-fire when the message box is closed, potentially resulting in an infinite loop of message boxes.
提案される解決策Suggestion この問題を回避するには、2 つの方法があります。There are two options to work around this issue:
  1. MessageBox.Show の代わりに MessageBox.Show を呼び出すことによって回避できます。It may be avoided by calling MessageBox.Show instead of MessageBox.Show.
  2. UIElement.LostKeyboardFocus イベント ハンドラーから (PreviewLostKeyboardFocus イベント ハンドラーではなく) メッセージ ボックスを表示することによって回避できます。It may be avoided by showing the message box from a UIElement.LostKeyboardFocus event handler (as opposed to a PreviewLostKeyboardFocus event handler).
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

WPF DataGrid 行ヘッダーを右クリックすると、DataGrid の選択が変更されるRight clicking on a WPF DataGrid row header changes the DataGrid selection

説明Details 複数行が選択されている状態で、選択した DataGrid 行ヘッダーを右クリックすると、その行のみで DataGrid の選択が変更されます。Right-clicking a selected DataGrid row header while multiple rows are selected results in the DataGrid's selection changing to only that row.
提案される解決策Suggestion この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。This issue has been fixed in the .NET Framework 4.6 and may be addressed by upgrading to that version of the .NET Framework.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

WPF DataTemplate 要素が UIA に表示されるようになったWPF DataTemplate elements are now visible to UIA

説明Details 以前は、DataTemplate 要素は UI オートメーションには表示されませんでした。Previously, DataTemplate elements were invisible to UI Automation. 4.5 から、UI オートメーションは、これらの要素を検出します。Beginning in 4.5, UI Automation will detect these elements. これは、多くの場合に便利ですが、DataTemplate 要素を含まない UIA ツリーに依存するテストは中断することがあります。This is useful in many cases, but can break tests that depend on UIA trees not containing DataTemplate elements.
提案される解決策Suggestion このアプリの UI オートメーション テストを更新して、以前は非表示の DataTemplate 要素を含んでいる UIA ツリーに対応できるようにしなければならないことがあります。UI Automation tests for this app may need updated to account for the UIA tree now including previously invisible DataTemplate elements. たとえば、いくつかの要素が互いに隣り合っていることを予期しているテストでは、以前は非表示であった UIA 要素が間にあることを予期する必要があります。For example, tests that expect some elements to be next to each other may now need to expect previously invisible UIA elements in between. または、UIA 要素の特定のカウントまたはインデックスに依存するテストは、新しい値で更新しなければならないことがあります。Or tests that rely on certain counts or indexes for UIA elements may need updated with new values.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

WPF DispatcherSynchronizationContext.CreateCopy は、現在のインスタンスの代わりに新しいコピーを返すようになったWPF DispatcherSynchronizationContext.CreateCopy now returns a new copy instead of the current instance

説明Details .NET Framework 4 では、CreateCopy() は、主にパフォーマンスの最適化として、現在のインスタンスへの参照を返しました。In the .NET Framework 4, CreateCopy() returned a reference to the current instance, primarily as a performance optimization. .NET Framework 4.5 では、これが新しいインスタンスになり、参照が等しければ、実行中のスレッドが正しい同期コンテキストにあると結論付けることが初めて可能になりました。In the .NET Framework 4.5, it returns a new instance which makes it possible for the first time to conclude that equal references indicate the executing thread is in the correct synchronization context. これらの参照の ID をチェックするコードが影響を受ける可能性は低いですが、この変更により、CreateCopy() を呼び出すコードは、.NET Framework 4.5 以降への移行の一部としてテストする必要があります。It is unlikely that code that checks the identity of these references will be affected, but because of the change, code that calls CreateCopy() should be tested as part of migration to the .NET Framework 4.5 or newer.
提案される解決策Suggestion CreateCopy() が新しい SynchronizationContext オブジェクトを返すようになったことに注意してください。Be aware that CreateCopy() will now return a new SynchronizationContext object. 以前は、このように生成された参照の等価性を使用するコードは、実際には、正しいコンテキストにあるかどうかを確認していませんでしたが、.NET Framework 4.5 以降でのビルド時には確認を行います。Previously, code that used equivalence of references generated this way was not actually checking whether it was in the proper context, but does when built against .NET Framework 4.5 or later. 問題になる可能性は低いですが、影響を受けるコードのパスをよく調べて、何か問題が生じないかどうか確認する必要があります。While unlikely to cause issues, exercising the affected code paths should be enough to determine if this poses any problem.
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

WPF が wisptis.exe プロセスを生成し、マウスがフリーズする可能性があるWPF spawns a wisptis.exe process which can freeze the mouse

説明Details この問題は 4.5.2 から発生するようになり、wisptis.exe が生成され、マウス入力がフリーズする可能性があります。An issue was introduced in 4.5.2 that causes wisptis.exe to be spawned that can freeze mouse input.
提案される解決策Suggestion この問題はサービス リリースの .NET Framework 4.5.2 (修正プログラム ロールアップ 3026376) で、あるいは .NET Framework 4.6 にアップグレードすることで解決できます。A fix for this issue is available in a servicing release of the .NET Framework 4.5.2 (hotfix rollup 3026376), or by upgrading to the .NET Framework 4.6
スコープScope MajorMajor
VersionVersion 4.5.24.5.2
Type ランタイムRuntime

WPF TextBox は既定で元に戻す上限が 100 に設定されるWPF TextBox defaults to undo limit of 100

説明Details .NET Framework 4.5 では、WPF テキスト ボックスの既定の元に戻す上限は 100 です (.NET Framework 4.0 では無制限でした)。In .NET Framework 4.5, the default undo limit for a WPF textbox is 100 (as opposed to being unlimited in .NET Framework 4.0)
提案される解決策Suggestion 元に戻す上限が 100 では低すぎる場合、UndoLimit を使用して上限を明示的に設定できます。If an undo limit of 100 is too low, the limit can be set explicitly with UndoLimit
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

WPF TextBox で選択されているテキストが、テキスト ボックスがアクティブでないときに異なる色で表示されるWPF TextBox selected text appears a different color when the text box is inactive

説明Details .NET Framework 4.5 では、WPF テキスト ボックス コントロールがアクティブでないとき (フォーカスがないとき)、ボックス内で選択されているテキストは、コントロールがアクティブなときとは別の色で表示されます。In .NET Framework 4.5, when a WPF text box control is inactive (it doesn't have focus), the selected text inside the box will appear a different color than when the control is active.
提案される解決策Suggestion AreInactiveSelectionHighlightBrushKeysSupported プロパティを false に設定することで、以前 (.NET Framework 4.0) の動作が復元される可能性があります。The previous (.NET Framework 4.0) behavior may be restored by setting the AreInactiveSelectionHighlightBrushKeysSupported property to false.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

WPF TreeViewItem は TreeView 内で使用する必要があるWPF TreeViewItem must be used within a TreeView

説明Details TreeView の外部での TreeViewItem 要素の使用を制限する変更が 4.5 で導入されました。A change was introduced in 4.5 that restricts usage of TreeViewItem elements outside of a TreeView. これは、次のような条件で発生します。This manifests under the following conditions:
  • TreeViewItem のビジュアルの親がパネルではありません。TreeViewItem's visual parent is not a panel. (TreeView に対して生成された TreeViewItem は、親としてパネルを持ちます)(A TreeViewItem generated for a TreeView will have a panel as its parent)
  • TreeViewItem は、リスト コントロール (ListBox、DataGrid、ListView など) の "項目ホスト" として機能する VirtualizingStackPanel の子孫です。The TreeViewItem is a descendant of a VirtualizingStackPanel acting as the "items host" for a list control (ListBox, DataGrid, ListView, etc.). 仮想化を有効にする必要はありません。Virtualization doesn't need to be enabled.
  • VirtualizingStackPanel は、項目のスクロールです (ScrollUnit="Item")。The VirtualizingStackPanel is item-scrolling (ScrollUnit="Item").
  • 誰かが要素 v をスクロールして表示させるために VirtualizingStackPanel.MakeVisible(v) を呼び出します。Someone calls VirtualizingStackPanel.MakeVisible(v) to scroll an element v into view. これは、明示的に行うか、さまざまな方法で暗黙的に行うことができます。おそらく、最も一般的な方法は、v をクリックして、キーボードのフォーカスを与えることです。This can be done explicitly, or implicitly in a number of ways; perhaps the most common way is simply clicking on v to give it the keyboard focus.
  • v から VirtualizingStackPanel までのビジュアル親チェーンが TreeViewItem を通過します。The visual-parent chain from v to the VirtualizingStackPanel passes through the TreeViewItem.
言い換えると、これは、TreeViewItemTreeView の外部で使用されるときに見られ、ユーザーは TreeViewItem の子孫をクリックして表示させます。In other words, this is seen when a TreeViewItem is used outside of a TreeView, and the user clicks on a descendant of the TreeViewItem to bring it into view. TreeViewItem にフォーカスを取得できる子孫がない場合、この問題は見られません。If the TreeViewItem has no focusable descendants, you'll never see this issue. これが該当する状況の例は、TreeViewItem が DataTemplate のルートであるときです。An example of a situation where this is hit is when a TreeViewItem is the root of a DataTemplate. この問題に遭遇したときには、WPF フレームワーク内で InvalidCastException が発生しています。When this issue is hit, there is an InvalidCastException that occurs within the WPF framework.
提案される解決策Suggestion このための修正プログラムが使用可能になります。A hotfix will be made available for this.
スコープScope マイナーMinor
VersionVersion 4.54.5
Type ランタイムRuntime

Windows Workflow Foundation (WF)Windows Workflow Foundation (WF)

System.Activities が APTCA にSystem.Activities is now APTCA

説明Details アセンブリは AllowPartiallyTrustedCallersAttribute 属性でマークされています。The assembly is marked with the AllowPartiallyTrustedCallersAttribute attribute.
提案される解決策Suggestion 派生クラスに SecurityCriticalAttributeのマークを付けることはできません。Derived classes cannot be marked with the SecurityCriticalAttribute. 以前は、派生型に SecurityCriticalAttributeマークを付ける必要がありました。Previously, derived types had to be marked with the SecurityCriticalAttribute. ただし、この変更によって生じる実質的な影響はないはずです。However, this change should have no real impact.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime

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

説明Details 関連する ValueSerializer オブジェクトは、Second コンポーネントと Millisecond コンポーネントが非ゼロで (DateTime 値の場合)、Kind プロパティが Unspecified ではない DateTime オブジェクトまたは DateTimeOffset オブジェクトを文字列ではなくプロパティ要素構文に変換します。The associated ValueSerializer object will convert a DateTime or DateTimeOffset object whose Second and Millisecond components are non-zero and (for a DateTime value) whose Kind property is not Unspecified to property element syntax instead of a string. この変更により、DateTime 値と DateTimeOffset 値を往復させることができるようになります。This change allows DateTime and DateTimeOffset values to be round-tripped. 入力 XAML が属性構文であると想定するカスタム XAML パーサーは正しく機能しません。Custom XAML parsers that assume that input XAML is in the attribute syntax will not function correctly.
提案される解決策Suggestion この変更により、DateTime 値と DateTimeOffset 値を往復させることができるようになります。This change allows DateTime and DateTimeOffset values to be round-tripped. 入力 XAML が属性構文であると想定するカスタム XAML パーサーは正しく機能しません。Custom XAML parsers that assume that input XAML is in the attribute syntax will not function correctly.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime

XML、XSLTXML, XSLT

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

説明Details SetLineInfo 値が Load メソッドに渡されたときに検証エラーが発生すると、LineNumber プロパティと LinePosition プロパティに行情報が含まれるようになりました。If the SetLineInfo value is passed to the Load method and a validation error occurs, the LineNumber and LinePosition properties now contain line information.
提案される解決策Suggestion XML の読み込み中に SetLineInfo が使用されるとき、LineNumberLinePosition は正しく設定されるようになったので、これらのプロパティが設定されないことを想定している例外処理コードは、更新する必要があります。Exception-handling code that assumes LineNumber and LinePosition will not be set should be updated since these properties will now be set properly when SetLineInfo is used while loading XML.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

XmlTextReader DTD エンティティの拡張が、10,000, 000 文字に制限されるXmlTextReader DTD entity expansion is limited to 10,000,000 characters

説明Details DTD エンティティの拡張は 10,000,000 文字までに制限されるようになりました。DTD entity expansion is now limited to 10,000,000 characters. DTD エンティティの展開を使用しない XML ファイルの読み込みや、制限された DTD エンティティの展開を使用した XML ファイルの読み込みは、影響を受けません。Loading XML files without DTD entity expansion or with limited DTD entity expansion is unaffected. DTD エンティティの展開が 10,000,000 文字を超えるファイルは読み込みに失敗し、例外をスローします。Files with DTD entities that expand to more than 10,000,000 characters fail to load, and now throw an exception.
提案される解決策Suggestion DTD エンティティの拡張の制限が 10,000, 000 では低すぎる場合には、MaxCharactersFromEntities プロパティで値をオーバーライドできます。If the limit of DTD entity expansion is too low 10,000,000, the value can be overridden with the MaxCharactersFromEntities property. 適切な MaxCharactersFromEntities 値を持つ XmlReaderSettings を、XmlReaderSettings を受け取る XmlReader.Create に渡すことができます (Create(String, XmlReaderSettings) など)An XmlReaderSettings with the proper MaxCharactersFromEntities value can be passed to XmlReader.Create that takes XmlReaderSettings (ie. Create(String, XmlReaderSettings))
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

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

説明Details .NET Framework 4 では、XSLT 1.0 の上位互換性に、次の問題がありました。In the .NET Framework 4, XSLT 1.0 forward compatibility had the following issues:
  • バージョンが 2.0 に設定されているときに、パーサーが認識できない XSLT 1.0 コンストラクトに遭遇すると、スタイル シートの読み込みが失敗していました。Loading a style sheet failed if its version was set to 2.0 and the parser encountered an unrecognized XSLT 1.0 construct.
  • スタイル シートのバージョンが 1.1 に設定されている場合、xsl:sort コンストラクトでデータを並べ替えることができませんでした。The xsl:sort construct failed to sort data if the style sheet version was set to 1.1.
.NET Framework 4.5 では、これらの問題は修正され、XSLT 1.0 の上位互換モードが正常に機能するようになりました。In the .NET Framework 4.5, these issues have been fixed, and XSLT 1.0 forward compatibility mode works properly.
提案される解決策Suggestion ほとんどのアプリには影響しませんが、xsl:sort が優先される場合は異なる方法でデータが並べ替えられます。Most apps should be unaffected, however data will be sorted differently in some cases now that xsl:sort is respected. xsl:sort が 1.1 スタイル シートで使用されている場合は、アプリが並べ替えられていないデータの順序に依存していないことを確認してください。If xsl:sort is used in 1.1 style sheets, confirm that apps were not depending on the unsorted order of data. アプリが 4.0 の並べ替え動作に依存している場合は、スタイル シートから xsl:sort を削除してください。If apps rely on the 4.0 sorting behavior, remove xsl:sort from the style sheet.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs

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

説明Details .NET Framework 4.5 では、XSLT ファイルが複雑すぎるときのエラー メッセージのテキストが "スタイル シートが複雑すぎます" になります。以前のバージョンのエラー メッセージは "XSLT コンパイル エラー" でした。エラー メッセージのテキストに依存するアプリケーション コードは機能しなくなります。In the .NET Framework 4.5, the text of the error message when an XSLT file is too complex is "The style sheet is too complex." In previous versions, the error message was "XSLT compile error." Application code that depends on the text of the error message will no longer work. ただし、例外の種類は同じなので、この変更による実質的な影響はありません。However, the exception types remain the same, so this change should have no real impact.
提案される解決策Suggestion このエラー条件からの例外メッセージに依存しているアプリケーション コードを、新しいメッセージを予期するように更新するか、(さらに望ましくは) 変更されていない例外の種類 (XsltException) のみに依存するようにコードを更新します。Update any app code depending on the exception message from this error condition to expect the new message, or (even better) update the code to depend only on the exception type (XsltException), which has not changed.
スコープScope エッジEdge
VersionVersion 4.54.5
Type ランタイムRuntime
影響を受ける APIAffected APIs