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

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

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.

名前Name [値]Value
スコープScope マイナーMinor
バージョンVersion 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 でのバグのため、System.Web.UI.WebControls.GridView.AllowCustomPaging が有効になっている System.Web.UI.WebControls.GridView に対して System.Web.UI.WebControls.GridView.PageIndexChanging が発生しないことがあります。A bug in the .NET Framework 4.5 causes System.Web.UI.WebControls.GridView.PageIndexChanging to sometimes not fire for System.Web.UI.WebControls.GridViews that have enabled System.Web.UI.WebControls.GridView.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. 回避策として、アプリでは、これらの条件 (System.Web.UI.WebControls.GridView が最終ページで、最後の System.Web.UI.WebControls.GridView.PageSizeSystem.Web.UI.WebControls.GridView.PageSize と異なる) を満たす Page_Load で明示的に BindGrid を行うことができます。As a work-around, the app can do an explicit BindGrid on any Page_Load that would hit these conditions (the System.Web.UI.WebControls.GridView is on the last page and LastSystem.Web.UI.WebControls.GridView.PageSize is different from System.Web.UI.WebControls.GridView.PageSize). または、(カスタム ページングではなく) ページングを許可するようにアプリを変更することもできます。このシナリオでは問題は発生していません。Alternatively, the app can be modified to allow paging (instead of custom paging), as that scenario does not demonstrate the problem.

名前Name [値]Value
スコープScope マイナーMinor
バージョンVersion 4.54.5
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

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).

名前Name [値]Value
スコープScope MajorMajor
バージョンVersion 4.5.24.5.2
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

API 分析では検出できません。Not detectable via API analysis.

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

説明Details

NGEN/プロファイル アセンブリを使用するプロファイラーにより、起動時にプロファイルされた ASP.NET MVC4 アプリケーションがクラッシュし、"致命的な実行エンジン例外" が示される場合があります。Profilers using NGEN /Profile assemblies may crash profiled ASP.NET MVC4 applications on startup with a 'Fatal Execution Engine Exception'

提案される解決策Suggestion

この問題は、.NET Framework 4.5.2 で修正されます。This issue is fixed in the .NET Framework 4.5.2. プロファイラーは、イベント マスクで COR_PRF_DISABLE_ALL_NGEN_IMAGES を指定することで、この問題を回避することもできます。Alternatively, the profiler may avoid this issue by specifying COR_PRF_DISABLE_ALL_NGEN_IMAGES in its event mask.

名前Name [値]Value
スコープScope エッジEdge
バージョンVersion 4.54.5
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

API 分析では検出できません。Not detectable via API analysis.

コア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

型に対する内部的な変更のため、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 で逆シリアル化する) は動作することに注意してください。Due to internal changes to the type, ConcurrentDictionary<TKey,TValue> objects that are serialized with the .NET Framework 4.5 using the System.Runtime.Serialization.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 の間で System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> のシリアル化と逆シリアル化を行う必要がある場合は、System.Runtime.Serialization.NetDataContractSerializer の代わりに、System.Runtime.Serialization.DataContractSerializer または System.Runtime.Serialization.Formatters.Binary.BinaryFormatter シリアライザーなど、代替のシリアライザーを使う必要があります。または、この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって解決できます。If it is necessary to serialize and deserialize a System.Collections.Concurrent.ConcurrentDictionary<TKey,TValue> between the .NET Framework 4.5 and .NET Framework 4.5.1/4.5.2, an alternate serializer like the System.Runtime.Serialization.DataContractSerializer or System.Runtime.Serialization.Formatters.Binary.BinaryFormatter serializer should be used instead of the System.Runtime.Serialization.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.

名前Name [値]Value
スコープScope マイナーMinor
バージョンVersion 4.5.14.5.1
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

API 分析では検出できません。Not detectable via API analysis.

AppDomainSetup.DynamicBase が UseRandomizedStringHashAlgorithm でランダム化されなくなったAppDomainSetup.DynamicBase is no longer randomized by UseRandomizedStringHashAlgorithm

説明Details

.NET Framework 4.6 より前では、UseRandomizedStringHashAlgorithm がアプリの構成ファイルで有効になっている場合、DynamicBase の値がアプリケーション ドメイン間、またはプロセス間でランダム化されます。Prior to the .NET Framework 4.6, the value of DynamicBase would be randomized between application domains, or between processes, if UseRandomizedStringHashAlgorithm was enabled in the app's config file. .NET Framework 4.6 以降では、DynamicBase は実行されているアプリの異なるインスタンス間、および異なるアプリ ドメイン間で安定した結果を返します。Beginning in the .NET Framework 4.6, DynamicBase will return a stable result between different instances of an app running, and between different app domains. それでも動的ベースはアプリによって異なります。この変更では、同じアプリの異なるインスタンスのランダムな名前付け要素のみが削除されます。Dynamic bases will still differ for different apps; this change only removes the random naming element for different instances of the same app.

提案される解決策Suggestion

UseRandomizedStringHashAlgorithm を有効にすると、DynamicBase がランダム化されなくなることに注意してください。Be aware that enabling UseRandomizedStringHashAlgorithm will not result in DynamicBase being randomized. ランダム ベースが必要な場合は、この API を使用するのではなく、アプリのコードで生成する必要があります。If a random base is needed, it must be produced in your app's code rather than via this API.

名前Name Value
スコープScope エッジEdge
バージョンVersion 4.64.6
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

インデクサー プロパティに対して Attribute.GetCustomAttributes を呼び出しても、インデックスの型によって、あいまいさを解決できる場合、AmbiguousMatchException はスローされなくなったCalling Attribute.GetCustomAttributes on an indexer property no longer throws AmbiguousMatchException if the ambiguity can be resolved by index's type

説明Details

.NET Framework 4.6 より以前には、インデックスの型のみが別のプロパティと異なるインデクサ― プロパティに対して GetCustomAttribute(s) を呼び出すと、System.Reflection.AmbiguousMatchException になりました。Prior to the .NET Framework 4.6, calling GetCustomAttribute(s) on an indexer property which differed from another property only by the type of the index would result in an System.Reflection.AmbiguousMatchException. .NET Framework 4.6 からは、プロパティの属性が正しく返されます。Beginning in the .NET Framework 4.6, the property's attributes will be correctly returned.

提案される解決策Suggestion

GetCustomAttribute(s) が、より頻繁に機能するようになったことに注意してください。Be aware that GetCustomAttribute(s) will work more frequently now. アプリが System.Reflection.AmbiguousMatchException に依存していた場合は、代わりにリフレクションを使用して、複数のインデクサーを明示的に検索する必要があります。If an app was previously relying on the System.Reflection.AmbiguousMatchException, reflection should now be used to explicitly look for multiple indexers, instead.

名前Name Value
スコープScope エッジEdge
バージョンVersion 4.64.6
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

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.

名前Name [値]Value
スコープScope マイナーMinor
バージョンVersion 4.5.14.5.1
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

API 分析では検出できません。Not detectable via API analysis.

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.

名前Name [値]Value
スコープScope エッジEdge
バージョンVersion 4.54.5
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

ペルシャ暦でイスラム暦の太陽アルゴリズムが使用されるようになったPersian calendar now uses the Hijri solar algorithm

説明Details

.NET Framework 4.6 以降では、System.Globalization.PersianCalendar クラスでイスラム暦の太陽アルゴリズムが使用されます。Starting with the .NET Framework 4.6, the System.Globalization.PersianCalendar class uses the Hijri solar algorithm. System.Globalization.PersianCalendar と他のカレンダーの間で日付を変換すると、.NET Framework 4.6 以降では、1800 年より前か 2023 年 (グレゴリオ暦) よりも後の日付について、わずかに異なる結果になることがあります。また、PersianCalendar.MinSupportedDateTimeMarch 21, 0622 ではなく March 22, 0622 になります。Converting dates between the System.Globalization.PersianCalendar and other calendars may produce a slightly different result beginning with the .NET Framework 4.6 for dates earlier than 1800 or later than 2023 (Gregorian).Also, PersianCalendar.MinSupportedDateTime is now March 22, 0622 instead of March 21, 0622.

提案される解決策Suggestion

.NET Framework 4.6 で PersianCalendar を使用するときには、一部の早い日付または遅い日付に若干の差が生じる場合があることに注意してください。Be aware that some early or late dates may be slightly different when using the PersianCalendar in .NET Framework 4.6. また、異なるバージョンの .NET Framework で実行する可能性のあるプロセス間で日付をシリアル化するときには、PersianCalendar の日付文字列として格納しないでください (これらの値が異なる場合があるため)。Also, when serializing dates between processes which may run on different .NET Framework versions, do not store them as PersianCalendar date strings (since those values may be different).

名前Name Value
スコープScope マイナーMinor
バージョンVersion 4.64.6
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

リフレクション オブジェクトが、マネージド コードからアウト プロセス DCOM クライアントに渡されなくなったReflection objects can no longer be passed from managed code to out-of-process DCOM clients

説明Details

リフレクション オブジェクトはマネージド コードからアウト プロセス DCOM クライアントに渡されなくなりました。Reflection objects can no longer be passed from managed code to out-of-process DCOM clients. 影響を受ける型は次のとおりです。The following types are affected:

オブジェクトの IMarshal の呼び出しは E_NOINTERFACE を返します。Calls to IMarshal for the object return E_NOINTERFACE.

提案される解決策Suggestion

非リフレクション オブジェクトで動作するように、マーシャリング コードを更新します。Update marshaling code to work with non-reflection objects.

名前Name Value
スコープScope マイナーMinor
バージョンVersion 4.64.6
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

既定のアプリケーション ドメインの TargetFrameworkName は、設定されなかった場合、既定で null に設定されなくなったTargetFrameworkName for default app domain no longer defaults to null if not set

説明Details

System.AppDomainSetup.TargetFrameworkName は、以前は、明示的に設定されない限り、既定のアプリケーション ドメインでは null でした。The System.AppDomainSetup.TargetFrameworkName was previously null in the default app domain, unless it was explicitly set. 4.6 以降では、既定のアプリケーション ドメインの System.AppDomainSetup.TargetFrameworkName プロパティは、TargetFrameworkAttribute (ある場合) から派生された既定値を持ちます。Beginning in 4.6, the System.AppDomainSetup.TargetFrameworkName property for the default app domain will have a default value derived from the TargetFrameworkAttribute (if one is present). 既定以外のアプリケーション ドメインは、明示的にオーバーライドされない限り、既定のアプリケーション ドメイン (4.6 では既定で null に設定されない) から System.AppDomainSetup.TargetFrameworkName を継承し続けます。Non-default app domains will continue to inherit their System.AppDomainSetup.TargetFrameworkName from the default app domain (which will not default to null in 4.6) unless it is explicitly overridden.

提案される解決策Suggestion

TargetFrameworkName が既定で null に設定されることに依然しないように、コードを更新する必要があります。Code should be updated to not depend on TargetFrameworkName defaulting to null. このプロパティが引き続き null として評価される必要がある場合、明示的にその値に設定できます。If it is required that this property continue to evaluate to null, it can be explicitly set to that value.

名前Name Value
スコープScope エッジEdge
バージョンVersion 4.64.6
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

.NET で証明書を処理できないときに、X509Certificate2.ToString(Boolean) がスローしなくなったX509Certificate2.ToString(Boolean) does not throw now when .NET cannot handle the certificate

説明Details

.NET Framework 4.5.2 およびそれより前のバージョンでは、このメソッドは、verbose パラメーターとして true が渡され、.NET Framework ではサポートされない証明書がインストールされていた場合、スローしました。In .NET Framework 4.5.2 and earlier versions, this method would throw if true was passed for the verbose parameter and there were certificates installed that weren't supported by the .NET Framework. 現在は、メソッドは成功し、証明書のアクセス不能部分を省いた有効な文字列を返します。Now, the method will succeed and return a valid string that omits the inaccessible portions of the certificate.

提案される解決策Suggestion

X509Certificate2.ToString(Boolean) に依存しているコードは、以前は API がスローしていたような場合には、返される文字列から一部の証明書データ (公開鍵、秘密鍵、拡張子など) が除外されることを予期するように更新する必要があります。Any code depending on X509Certificate2.ToString(Boolean) should be updated to expect that the returned string may exclude some certificate data (such as public key, private key, and extensions) in some cases in which the API would have previously thrown.

名前Name Value
スコープScope エッジEdge
バージョンVersion 4.64.6
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

データData

localhost に解決される SQL Server データベースへの TCP/IP 接続の試みが失敗しますAttempting a TCP/IP connection to a SQL Server database that resolves to localhost fails

説明Details

.NET Framework 4.6 および 4.6.1 で、localhost に解決される SQL Server データベースへの TCP/IP 接続の試みが次のエラーで失敗していました: "SQL Server への接続を確立しているときにネットワーク関連またはインスタンス固有のエラーが発生しました。In the .NET Framework 4.6 and 4.6.1, attempting a TCP/IP connection to a SQL Server database that resolves to localhost fails with the error, "A network-related or instance-specific error occurred while establishing a connection to SQL Server. サーバーが見つからないかアクセスできません。The server was not found or was not accessible. インスタンス名が正しいこと、および SQL Server がリモート接続を許可するように構成されていることを確認してください。Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (プロバイダー:SQL ネットワーク インターフェイス、エラー:26 - 指定されたサーバーまたはインスタンスの位置を特定しているときにエラーが発生しました)"(provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)"

提案される解決策Suggestion

この問題は修正済みであり、.NET Framework 4.6.2 では以前の動作に戻っています。This issue has been addressed and the previous behavior restored in the .NET Framework 4.6.2. localhost に解決される SQL Server データベースに接続するには、.NET Framework 4.6.2 にアップグレードします。To connect to a SQL Server database that resolves to localhost, upgrade to the .NET Framework 4.6.2.

名前Name [値]Value
スコープScope マイナーMinor
バージョンVersion 4.64.6
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

API 分析では検出できません。Not detectable via API analysis.

IFS 以外の Winsock BSP または LSP が存在する Windows 7 で SqlConnection.Open が失敗するSqlConnection.Open fails on Windows 7 with non-IFS Winsock BSP or LSP present

説明Details

Open() および OpenAsync(CancellationToken) は、コンピューター上に IFS 以外の Winsock BSP または LSP が存在する Windows 7 コンピューターで実行している場合、.NET Framework 4.5 では失敗します。IFS 以外の BSP または LSP がインストールされているかどうかを確認するには、netsh WinSock Show Catalog コマンドを使用して、返される Winsock Catalog Provider Entry 項目をすべて調べてください。Open() and OpenAsync(CancellationToken) fail in the .NET Framework 4.5 if running on a Windows 7 machine with a non-IFS Winsock BSP or LSP are present on the computer.To determine whether a non-IFS BSP or LSP is installed, use the netsh WinSock Show Catalog command, and examine every Winsock Catalog Provider Entry item that is returned. Service Flags 値の 0x20000 ビットがセットされている場合、プロバイダーは IFS ハンドルを使用していて、正しく機能します。If the Service Flags value has the 0x20000 bit set, the provider uses IFS handles and will work correctly. 0x20000 ビットがクリアされている (セットされていない) 場合は、IFS 以外の BSP または LSP です。If the 0x20000 bit is clear (not set), it is a non-IFS BSP or LSP.

提案される解決策Suggestion

このバグは .NET framework 4.5.2 で修正されたため、.NET Framework をアップグレードすることによって回避できます。This bug has been fixed in the .NET Framework 4.5.2, so it can be avoided by upgrading the .NET Framework. または、インストールされている IFS 以外の Winsock LSP を削除することによって回避できます。Alternatively, it can be avoided by removing any installed non-IFS Winsock LSPs.

名前Name [値]Value
スコープScope マイナーMinor
バージョンVersion 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.

名前Name [値]Value
スコープScope エッジEdge
バージョンVersion 4.54.5
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

API 分析では検出できません。Not detectable via API analysis.

Entity FrameworkEntity Framework

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

説明Details

クエリの一部として関連エンティティを含めようとする 0..1 ナビゲーション プロパティを使用して QueryViews に関係するクエリをアプリが実行する場合、Entity Framework で System.StackOverflowException 例外がスローされなくなりました。Entity Framework no longer throws a System.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" />

名前Name [値]Value
スコープScope エッジEdge
バージョンVersion 4.5.24.5.2
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

API 分析では検出できません。Not detectable via API analysis.

異なる 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" />

名前Name [値]Value
スコープScope 透明Transparent
バージョンVersion 4.5.24.5.2
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

API 分析では検出できません。Not detectable via API analysis.

ネットワーキングNetworking

ContentDisposition DateTimes で少し異なる文字列が返されるContentDisposition DateTimes returns slightly different string

説明Details

System.Net.Mime.ContentDisposition の文字列表現が更新され、4.6 以降では、常に System.DateTime の時間コンポーネントが 2 桁で表されます。String representations of System.Net.Mime.ContentDisposition's have been updated, beginning in 4.6, to always represent the hour component of a System.DateTime with two digits. これは、RFC822RFC2822 に準拠しています。This is to comply with RFC822 and RFC2822. これにより、4.6 では、配置の時間要素の 1 つが午前 10 時より前のシナリオでは、ToString() は少し異なる文字列を返します。This causes ToString() to return a slightly different string in 4.6 in scenarios where one of the disposition's time elements was before 10:00 AM. ContentDispositions は文字列への変換によってシリアル化される場合があるため、ToString() 操作、シリアル化、または GetHashCode 呼び出しを見直す必要があることに注意してください。Note that ContentDispositions are sometimes serialized via converting them to strings, so any ToString() operations, serialization, or GetHashCode calls should be reviewed.

提案される解決策Suggestion

異なるバージョンの .NET Framework からの ContentDispotisions の文字列表現が互いに正しく対応することを期待しないでください。Do not expect that string representations of ContentDispositions from different .NET Framework versions will correctly compare to one another. 可能な場合は、比較を行う前に、文字列を ContentDispositions に戻してください。Convert the strings back to ContentDispositions, if possible, before conducting a comparison.

名前Name Value
スコープScope マイナーMinor
バージョンVersion 4.64.6
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

シリアル化Serialization

不明な型の場合に失敗した DataContract シリアル化の例外メッセージが変更されたException message has changed for failed DataContract serialization in case of an unknown type

説明Details

.NET Framework 4.6 以降では、"既知の型" がないために System.Runtime.Serialization.DataContractSerializer または System.Runtime.Serialization.Json.DataContractJsonSerializer のシリアル化または逆シリアル化が失敗した場合に提供される例外メッセージが明確化されました。Beginning in the .NET Framework 4.6, the exception message given if a System.Runtime.Serialization.DataContractSerializer or System.Runtime.Serialization.Json.DataContractJsonSerializer fails to serialize or deserialize due to missing 'known types' has been clarified.

提案される解決策Suggestion

アプリは、特定の例外メッセージに依存しないようにする必要があります。Apps should not depend on specific exception messages. アプリがこのメッセージに依存している場合は、新しいメッセージを使うように更新するか、(可能であれば) 例外の種類のみに依存するように変更します。If an app depends on this message, either update it to expect the new message or (preferably) change it to depend only on the exception type.

名前Name Value
スコープScope エッジEdge
バージョンVersion 4.64.6
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

セットアップと配置Setup and Deployment

.NET Framework 4.6 以降のバージョンでの製品のバージョン管理に関する変更点Product versioning changes in the .NET Framework 4.6 and later versions

説明Details

製品のバージョン管理が、.NET Framework の以前のリリース (特に .NET Framework 4、4.5、4.5.1、4.5.2) から変更されました。Product versioning has changed from the previous releases of the .NET Framework, and particularly from the .NET Framework 4, 4.5, 4.5.1, and 4.5.2. 変更の詳細は次のとおりです。The following are the detailed changes:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full キーの Version エントリの値が、.NET Framework 4.6 とそのポイント リリースの場合は 4.6.xxxxx に、.NET Framework 4.7 と 4.7.1 の場合は 4.7.xxxxx に、それぞれ変更されました。The value of the Version entry in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full key has changed to 4.6.xxxxx for the .NET Framework 4.6 and its point releases, and to 4.7.xxxxx for the .NET Framework 4.7 and 4.7.1. .NET Framework 4.5、4.5.1、および 4.5.2 では、4.5.xxxxx という形式でした。In the .NET Framework 4.5, 4.5.1, and 4.5.2, it had the format 4.5.xxxxx.
  • .NET Framework ファイルにおけるファイルおよび製品のバージョン管理は、以前のバージョン管理方式である 4.0.30319.x から、.NET Framework 4.6 とそのポイント リリースの場合は 4.6.X.0 に、.NET Framework 4.7 と 4.7.1 の場合は 4.7.X.0 に、それぞれ変更されました。The file and product versioning for .NET Framework files has changed from the earlier versioning scheme of 4.0.30319.x to 4.6.X.0 for the .NET Framework 4.6 and its point releases, and to 4.7.X.0 for the .NET Framework 4.7 and 4.7.1. ファイルを右クリックしてファイルの [プロパティ] を表示すると、これらの新しい値を確認できます。You can see these new values when you view the file's Properties after right-clicking on a file.
  • マネージド アセンブリの AssemblyFileVersionAttribute 属性と AssemblyInformationalVersionAttribute 属性の Version 値は、.NET Framework 4.6 とそのポイント リリースの場合は 4.6.X.0 という形式に、.NET Framework 4.7 と 4.7.1 の場合は 4.7.X.0 という形式になります。The AssemblyFileVersionAttribute and AssemblyInformationalVersionAttribute attributes for managed assemblies have Version values in the form 4.6.X.0 for the .NET Framework 4.6 and its point releases, and 4.7.X.0 for the .NET Framework 4.7 and 4.7.1.
  • .NET Framework 4.6、4.6.1、4.6.2、4.7、4.7.1 では、Environment.Version プロパティは固定のバージョン文字列 4.0.30319.42000 を返します。In the .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, and 4.7.1, the Environment.Version property returns the fixed version string 4.0.30319.42000. .NET Framework 4、4.5、4.5.1、および 4.5.2 では、4.0.30319.xxxxx という形式のバージョン文字列が返されます (例: "4.0.30319.18010")。In the .NET Framework 4, 4.5, 4.5.1, and 4.5.2, it returns version strings in the format 4.0.30319.xxxxx (for example, "4.0.30319.18010"). アプリケーションのコードで Environment.Version プロパティに新しい依存関係を設定することは推奨されていないことに注意してください。Note that we do not recommend application code taking any new dependency on the Environment.Version property.
詳しくは、「方法: インストールされている .NET Framework バージョンを確認する」をご覧ください。For more information, see How to: Determine which .NET Framework Versions Are Installed.

提案される解決策Suggestion

一般に、.NET Framework のランタイムのバージョンやインストール ディレクトリを検出する際、アプリケーションは推奨される技法に従う必要があります。In general, applications should depend on the recommended techniques for detecting such things as the runtime version of the .NET Framework and the installation directory:

[!IMPORTANT] サブキー名は、.NET Framework Setup ではなく NET Framework Setup です。The subkey name is NET Framework Setup, not .NET Framework Setup.
  • .NET Framework の共通言語ランタイムへのディレクトリ パスを確認するには、RuntimeEnvironment.GetRuntimeDirectory() メソッドを呼び出します。To determine the directory path to the .NET Framework common language runtime, call the RuntimeEnvironment.GetRuntimeDirectory() method.
  • CLR のバージョンを取得するには、RuntimeEnvironment.GetSystemVersion() メソッドを呼び出します。To get the CLR version, call the RuntimeEnvironment.GetSystemVersion() method. .NET Framework 4 とそのポイント リリース (.NET Framework 4.5、4.5.1、4.5.2、および .NET Framework 4.6、4.6.1、4.6.2、4.7、4.7.1) の場合、このメソッドは文字列 v4.0.30319 を返します。For the .NET Framework 4 and its point releases (the .NET Framework 4.5, 4.5.1, 4.5.2, and .NET Framework 4.6, 4.6.1, 4.6.2, 4.7, and 4.7.1), it returns the string v4.0.30319.

名前Name Value
スコープScope マイナーMinor
バージョンVersion 4.64.6
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

API 分析では検出できません。Not detectable via API analysis.

.NET Framework 4.6 は、自分自身をレジストリに登録するときに 4.5.x.x バージョンを使用しないThe .NET Framework 4.6 does not use a 4.5.x.x version when registering itself in the registry

説明Details

予想されるように、.NET Framework 4.6 に対してレジストリ (HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full) に設定されるバージョン キーは、"4.5" ではなく "4.6" で始まります。As one might expect, the version key set in the registry (at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full) for the .NET Framework 4.6 begins with '4.6', not '4.5'. これらのレジストリ キーに依存してコンピューターにインストールされている .NET Framework のバージョンを特定するアプリは、4.6 が可能な新しいバージョンであり、前の 4.5.x リリースと互換性があることを認識するように、更新する必要があります。Apps that depend on these registry keys to know which .NET Framework versions are installed on a machine should be updated to understand that 4.6 is a new possible version, and one that is compatible with previous 4.5.x releases.

提案される解決策Suggestion

4.5 のレジストリ キーを検索することによって .NET Framework 4.5 のインストールを調べるアプリを、4.6 も受け付けるように更新します。Update apps probing for a .NET Framework 4.5 install by looking for 4.5 registry keys to also accept 4.6.

名前Name Value
スコープScope エッジEdge
バージョンVersion 4.64.6
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

API 分析では検出できません。Not detectable via API analysis.

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

SSL セキュリティと MD5 証明書認証で NETTCP を使用する WCF サービスWCF services that use NETTCP with SSL security and MD5 certificate authentication

説明Details

.NET Framework 4.6 では、WCF SSL の既定のプロトコル一覧に TLS 1.1 および TLS 1.2 が追加されます。The .NET Framework 4.6 adds TLS 1.1 and TLS 1.2 to the WCF SSL default protocol list. クライアントとサーバーの両方のコンピューターに .NET Framework 4.6 以降がインストールされている場合は、TLS 1.2 がネゴシエーションに使用されます。TLS 1.2 では MD5 証明書認証がサポートされません。When both client and server machines have the .NET Framework 4.6 or later installed, TLS 1.2 is used for negotiation.TLS 1.2 does not support MD5 certificate authentication. このため、顧客が MD5 証明書を使用する場合、WCF クライアントでは WCF サービスへ接続できません。As a result, if a customer uses an MD5 certificate, the WCF client will fail to connect to the WCF service.

提案される解決策Suggestion

次のいずれかの操作を実行することで、この問題を回避して、WCF クライアントを WCF サーバーに接続できるようになります。You can work around this issue so that a WCF client can connect to a WCF server by doing any of the following:

  • MD5 アルゴリズムを使用しないように証明書を更新します。Update the certificate to not use the MD5 algorithm. この解決策をお勧めします。This is the recommended solution.
  • バインドがソース コードで動的に構成されていない場合は、TLS 1.1 または以前のバージョンのプロトコルを使用するようにアプリケーションの構成ファイルを更新します。If the binding is not dynamically configured in source code, update the application's configuration file to use TLS 1.1 or an earlier version of the protocol. これにより、引き続き MD5 ハッシュ アルゴリズムによる証明書を使用することができます。This allows you to continue to use a certificate with the MD5 hash algorithm.

警告

MD5 ハッシュ アルゴリズムによる証明書は安全でないと見なされるため、この回避策はお勧めできません。This workaround is not recommended, since a certificate with the MD5 hash algorithm is considered insecure.

次の構成ファイルでこれを行います。The following configuration file does this:

<configuration>
  <system.serviceModel>
    <bindings>
      <netTcpBinding>
        <binding>
          <security mode= "None/Transport/Message/TransportWithMessageCredential" >
            <transport clientCredentialType="None/Windows/Certificate"
                       protectionLevel="None/Sign/EncryptAndSign"
                       sslProtocols="Ssl3/Tls1/Tls11">
            </transport>
          </security>
        </binding>
      </netTcpBinding>
    </bindings>
  </system.ServiceModel>
</configuration>

警告

MD5 ハッシュ アルゴリズムによる証明書は安全でないと見なされるため、この回避策はお勧めできません。This workaround is not recommended, since a certificate with the MD5 hash algorithm is considered insecure.

名前Name Value
スコープScope マイナーMinor
バージョンVersion 4.64.6
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

API 分析では検出できません。Not detectable via API analysis.

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 イベントのイベント ハンドラーにより、DataGridSystem.Windows.Controls.Primitives.Selector.SelectedItem または System.Windows.Controls.Primitives.MultiSelector.SelectedItems プロパティにアクセスする場合に System.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 System.NullReferenceException to be thrown if they access the DataGrid's System.Windows.Controls.Primitives.Selector.SelectedItem or System.Windows.Controls.Primitives.MultiSelector.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.

名前Name [値]Value
スコープScope マイナーMinor
バージョンVersion 4.54.5
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

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

説明Details

System.Windows.Controls.DataGridSystem.Windows.Controls.DataGrid.CellEditEnding イベント ハンドラーのいずれかから CommitEdit() を呼び出すと、System.Windows.Controls.DataGrid からフォーカスが失われます。Calling CommitEdit() from one of the System.Windows.Controls.DataGrid's System.Windows.Controls.DataGrid.CellEditEnding event handlers causes the System.Windows.Controls.DataGrid to lose focus.

提案される解決策Suggestion

このバグは .NET framework 4.5.2 で修正されたため、.NET Framework をアップグレードすることによって回避できます。This bug has been fixed in the .NET Framework 4.5.2, so it can be avoided by upgrading the .NET Framework. または、System.Windows.Controls.DataGrid.CommitEdit() を呼び出した後で System.Windows.Controls.DataGrid を明示的に再選択することによって回避できます。Alternatively, it can be avoided by explicitly re-selecting the System.Windows.Controls.DataGrid after calling System.Windows.Controls.DataGrid.CommitEdit().

名前Name [値]Value
スコープScope エッジEdge
バージョンVersion 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 では、System.Windows.Controls.ListBox で項目が選択されているときにコードから ListBox.Items.Refresh を呼び出すと、選択された項目がリストに複製されることがあります。In the .NET Framework 4.5, calling ListBox.Items.Refresh from code while items are selected in a System.Windows.Controls.ListBox can cause the selected items to be duplicated in the list. 同様の問題が System.Windows.Controls.ListViewSystem.Windows.Controls.DataGrid で発生します。A similar issue occurs with System.Windows.Controls.ListView and System.Windows.Controls.DataGrid. これは、.NET Framework 4.6 で修正されます。This is fixed in the .NET Framework 4.6.

提案される解決策Suggestion

この問題は、System.Windows.Data.CollectionView.Refresh() が呼び出される前に、プログラムで項目を選択解除して、呼び出しの完了後に再び選択することによって回避できます。This issue may be worked around by programmatically unselecting items before System.Windows.Data.CollectionView.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.

名前Name [値]Value
スコープScope マイナーMinor
バージョンVersion 4.54.5
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

CoerceIsSelectionBoxHighlightedCoerceIsSelectionBoxHighlighted

説明Details

System.Windows.Controls.ComboBox とそのデータ ソースに関連するアクションの特定のシーケンスで System.NullReferenceException が発生する可能性があります。Certain sequences of actions involving a System.Windows.Controls.ComboBox and its data source can result in a System.NullReferenceException.

提案される解決策Suggestion

可能な場合は、.NET Framework 4.6.2 にアップグレードします。If possible, upgrade to .NET Framework 4.6.2.

名前Name Value
スコープScope マイナーMinor
バージョンVersion 4.64.6
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

カスタム DataTemplate を使用しているとき、断続的に、ItemsControl (ListBox や DataGrid など) 内の最後の項目までスクロールできないIntermittently unable to scroll to bottom item in ItemsControls (like ListBox and DataGrid) when using custom DataTemplates

説明Details

場合によっては、.NET Framework 4.5 のバグにより、カスタム DataTemplate を使用していると、ItemsControl (System.Windows.Controls.ListBoxSystem.Windows.Controls.ComboBoxSystem.Windows.Controls.DataGrid など) の最後の項目までスクロールできません。In some instances, a bug in the .NET Framework 4.5 is causing ItemsControls (like System.Windows.Controls.ListBox, System.Windows.Controls.ComboBox, System.Windows.Controls.DataGrid, etc.) to not scroll to their bottom item when using custom DataTemplates. (上へスクロールした後で) もう一度スクロールを試みると、今度はスクロールできます。If the scrolling is attempted a second time (after scrolling back up), it will work then.

提案される解決策Suggestion

この問題は .NET Framework 4.5.2 で修正されたため、このバージョン (またはそれ以降のバージョン) の .NET Framework にアップグレードすることによって対処できます。This issue has been fixed in the .NET Framework 4.5.2 and may be addressed by upgrading to that version (or a later version) of the .NET Framework. または、ユーザーは、スクロール バーをこれらのコレクションの最後の項目までドラッグできますが、2 回試みなければならないことがあります。Alternatively, users can still drag scroll bars to the final items in these collections, but may need to try twice to do so successfully.

名前Name [値]Value
スコープScope マイナーMinor
バージョンVersion 4.54.5
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

API 分析では検出できません。Not detectable via API analysis.

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

説明Details

項目が選択された System.Windows.Controls.ListBox にバインドされるコレクションで Move(Int32, Int32) または MoveItem(Int32, Int32) を呼び出すと、System.Windows.Controls.ListBox 項目の今後の選択または選択解除で不規則な動作が発生する可能性があります。Calling Move(Int32, Int32) or MoveItem(Int32, Int32) on a collection bound to a System.Windows.Controls.ListBox with items selected can lead to erratic behavior with future selection or unselection of System.Windows.Controls.ListBox items.

提案される解決策Suggestion

Move(Int32, Int32) ではなく System.Collections.ObjectModel.Collection<T>.Remove(T)System.Collections.ObjectModel.Collection<T>.Insert(Int32, T) を呼び出すことで、この問題は解決されます。Calling System.Collections.ObjectModel.Collection<T>.Remove(T) and System.Collections.ObjectModel.Collection<T>.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.

名前Name [値]Value
スコープScope マイナーMinor
バージョンVersion 4.54.5
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

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

説明Details

複数行が選択されている状態で、選択した System.Windows.Controls.DataGrid 行ヘッダーを右クリックすると、その行のみで System.Windows.Controls.DataGrid の選択が変更されます。Right-clicking a selected System.Windows.Controls.DataGrid row header while multiple rows are selected results in the System.Windows.Controls.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.

名前Name [値]Value
スコープScope エッジEdge
バージョンVersion 4.54.5
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

OS の入力言語リストにない言語の場合、Windows 10 でテキスト対応コントロールの WPF スペル チェックが動作しなくなるWPF spell checking in text-enabled controls will not work in Windows 10 for languages not in the OS's input language list

説明Details

プラットフォームのスペル チェック機能は入力言語リストに存在する言語でしか使用できないため、 Windows 10 での実行時には、WPF テキスト対応コントロール向けのスペル チェック機能が動作しないことがあります。Windows 10 では、使用可能なキーボードのリストに言語を追加すると、対応するオンデマンド機能 (FOD) パッケージが自動的にダウンロードおよびインストールされ、スペル チェック機能が提供されます。When running on Windows 10, the spell checker may not work for WPF text-enabled controls because platform spell-checking capabilities are available only for languages present in the input languages list.In Windows 10, when a language is added to the list of available keyboards, Windows automatically downloads and installs a corresponding Feature on Demand (FOD) package that provides spell-checking capabilities. 入力言語リストに言語を追加することで、スペル チェック機能がサポートされます。By adding the language to the input languages list, the spell checker will be supported.

提案される解決策Suggestion

Windows 10 でスペルチェックを動作させるには、スペルチェック対象の言語またはテキストを入力言語として追加する必要があることに注意してください。Be aware that the language or text to be spell-checked must be added as an input language for spell-checking to work in Windows 10.

名前Name Value
スコープScope エッジEdge
バージョンVersion 4.64.6
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

API 分析では検出できません。Not detectable via API analysis.

1 つのモニターの外部に拡張すると、クリッピングなしで WPF ウィンドウがレンダリングされるWPF windows are rendered without clipping when extending outside a single monitor

説明Details

Windows 8 以上で実行している .NET Framework 4.6 では、マルチ モニターのシナリオで 1 つのディスプレイの外部にウィンドウを拡張すると、ウィンドウ全体がクリッピングなしでレンダリングされます。In the .NET Framework 4.6 running on Windows 8 and above, the entire window is rendered without clipping when it extends outside of single display in a multi-monitor scenario. これは、1 つのディスプレイを超える WPF ウィンドウをクリッピングする、以前のバージョンの .NET Framework とは異なります。This is different from previous versions of the .NET Framework which would clip WPF windows that extended beyond a single display.

提案される解決策Suggestion

この動作 (クリッピングするかどうか) は、アプリケーションの構成ファイルの <appSettings><EnableMultiMonitorDisplayClipping> 要素を使用するか、アプリの起動時に EnableMultiMonitorDisplayClipping プロパティを設定することで明示的に設定できます。This behavior (whether to clip or not) can be explicitly set using the <EnableMultiMonitorDisplayClipping> element in <appSettings> in an application's configuration file, or by setting the EnableMultiMonitorDisplayClipping property at app startup.

名前Name Value
スコープScope マイナーMinor
バージョンVersion 4.64.6
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

API 分析では検出できません。Not detectable via API analysis.