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

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

ASP.NETASP.NET

ASP.NET WebForms CheckBox コントロールの InputAttributes および LabelAttributes の処理の修正ASP.NET Fix handling of InputAttributes and LabelAttributes for WebForms CheckBox control

説明Details

.NET Framework 4.7.2 以前のバージョンをターゲットとするアプリケーションでは、WebForms CheckBox コントロールにプログラムで追加された CheckBox.InputAttributes および CheckBox.LabelAttributes がポストバック後に失われます。For applications that target .NET Framework 4.7.2 and earlier versions, CheckBox.InputAttributes and CheckBox.LabelAttributes that are programmatically added to a WebForms CheckBox control are lost after postback. .NET Framework 4.8 以降のバージョンをターゲットとするアプリケーションでは、これらはポストバック後に保持されます。For applications that target .NET Framework 4.8 or later versions, they are preserved after postback.

提案される解決策Suggestion

ポストバック時に属性を復元する動作を正しいものにするには、targetFrameworkVersion を 4.8 以降に設定します。For the correct behavior for restoring attributes on postback, set the targetFrameworkVersion to 4.8 or higher. 次に例を示します。For example:

<configuration>
<system.web>
<httpRuntime targetFramework="4.8"/>
</system.web>
</configuration>
これより小さい値に設定した場合、または、まったく設定しない場合、適切でない古い動作が維持されます。Setting it lower, or not at all, preserves the old incorrect behavior.

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

影響を受ける APIAffected APIs

ASP.NET 正しくないマルチパート処理により、フォーム データが失われる場合がある。ASP.NET Incorrect multipart handling may result in lost form data.

説明Details

.NET Framework 4.7.2 以前のバージョンをターゲットとするアプリケーションでは、ASP.NET でマルチパート境界の値が正しく解析されないために、要求の実行中にフォーム データが使用できなくなる場合があります。In applications that target .NET Framework 4.7.2 and earlier versions, ASP.NET might incorrectly parse multipart boundary values, resulting in form data being unavailable during request execution. .NET Framework 4.8 以降のバージョンをターゲットとするアプリケーションではマルチパート データが正しく解析されるため、要求の実行中にフォーム値を使用することができます。Applications that target .NET Framework 4.8 or later versions correctly parse multipart data, so form values are available during request execution.

提案される解決策Suggestion

.NET Framework 4.8 以降で実行されているアプリケーションで、Framework 4.8 以降をターゲットとする場合は、targetFrameworkVersion 要素を使用して、区切り記号を削除するように既定の動作を変更します。Starting with applications running on .NET Framework 4.8, when targeting .NET Framework 4.8 or later by using the targetFrameworkVersion element, the default behavior changes to strip delimiters. 以前のフレームワークのバージョンをターゲットとするか、targetFrameworkVersion を使用しない場合、一部の値の末尾の区切り記号が引き続き返されます。この動作は、appSetting で明示的に制御することもできます。When targeting previous framework versions or not using targetFrameworkVersion, trailing delimiters for some values are still returned.This behavior can also be explicitly controlled with an appSetting:

<configuration>
<appSettings>
...
<add key="aspnet:UseLegacyMultiValueHeaderHandling"  value="true"/>
...
</appSettings>
</configuration>

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

影響を受ける APIAffected APIs

ASP.NET カスタムの DataAnnotations.ValidationAttribute を使用すると、ValidationContext.MemberName が NULL にならないASP.NET ValidationContext.MemberName is not NULL when using custom DataAnnotations.ValidationAttribute

説明Details

.NET Framework 4.7.2 以前のバージョンでは、カスタムの System.ComponentModel.DataAnnotations.ValidationAttribute を使用すると、ValidationContext.MemberName プロパティで null が返されます。In .NET Framework 4.7.2 and earlier versions, when using a custom System.ComponentModel.DataAnnotations.ValidationAttribute, the ValidationContext.MemberName property returns null. October 2019 Update より前の .NET Framework 4.8 バージョンでは、メンバー名が返されます。In .NET Framework 4.8 version prior to the October 2019 update, it returns the member name. .NET Framework 4.8 の .NET Framework October 2019 Preview の品質ロールアップ以降、既定では null が返されますが、代わりにメンバー名を返すように設定することもできます。Starting with .NET Framework October 2019 Preview of Quality Rollup for .NET Framework 4.8, it returns null by default, but you can opt in to return the member name instead.

提案される解決策Suggestion

.NET Framework 4.8 以降のバージョン用の .NET Framework October 2019 Preview の品質ロールアップで、メンバー名を返すプロパティに対して次の設定を web.config ファイルに追加します。Add the following setting to your web.config file for the property to return the member name in .NET Framework October 2019 Preview of Quality Rollup for .NET Framework 4.8 and later versions:

<configuration>
<appSettings>
...
<add key="aspnet:GetValidationMemberName"  value="true"/>
...
</appSettings>
</configuration>
October 2019 Update より前の .NET Framework 4.8 バージョンでは、これを web.config ファイルに追加すると、以前の動作が復元され、プロパティで null が返されます。In .NET Framework 4.8 version prior to the October 2019 update, adding this to your web.config file restores the previous behavior and the property returns null.

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

影響を受ける APIAffected APIs

コアCore

.NET COM では、イベント時に ByRef SafeArray パラメーターを正常にマーシャリングします。.NET COM successfully marshals ByRef SafeArray parameters on events

説明Details

.NET Framework 4.7.2 以前のバージョンでは、COM イベントでの ByRef SafeArray パラメータ―は、ネイティブ コードに戻ってマーシャリングすることはできません。In the .NET Framework 4.7.2 and earlier versions, a ByRef SafeArray parameter on a COM event would fail to marshal back to native code. この変更により、SafeArray が正常にマーシャリングされるようになりました。With this change the SafeArray is now marshalled successfully.

  • [ x ] 後方互換[ x ] Quirked

提案される解決策Suggestion

COM イベント時に ByRef SafeArray パラメーターを正常にマーシャリングすると、実行が中断されてしまう場合は、アプリケーション構成に次の構成スイッチを追加して、このコードを無効にすることができます。If properly marshalling ByRef SafeArray parameters on COM Events breaks execution, you can disable this code by adding the following configuration switch to your application config:

<appSettings>
<add key="Switch.System.Runtime.InteropServices.DoNotMarshalOutByrefSafeArrayOnInvoke" value="true" />
</appSettings>

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

影響を受ける APIAffected APIs

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

.NET 相互運用で IAgileObject に対して QueryInterface が呼び出されるようになる (WinRT インターフェイス).NET Interop will now QueryInterface for IAgileObject (a WinRT interface)

説明Details

.NET デリゲートで WinRT イベントを使用する場合、.NET Framework 4.8 以降では、Windows で IAgileObject に対して QI が呼び出されます。When using a WinRT event with a .NET delegate, Windows will QI for IAgileObject starting with the .NET Framework 4.8. .NET Framework の以前のバージョンでは、ランタイムでその QI が失敗し、イベントをサブスクライブできませんでした。In previous versions of the .NET Framework, the runtime would fail that QI, and the event could not be subscribed.

  • [ x ] 後方互換[ x ] Quirked

提案される解決策Suggestion

IAgileObject に対して QI を有効にすると実行が中断される場合は、次の構成を設定し、このコードを無効にすることができます。If enabling the QI for IAgileObject breaks execution, you can disable this code by setting the following configuration.

方法 1:環境変数Method 1: Environment variable

環境変数を COMPLUS_DisableCCWSupportIAgileObject=1 に設定します。この方法は、この環境変数を継承するすべての環境に影響します。Set the following environment variable:COMPLUS_DisableCCWSupportIAgileObject=1This method affects any environment that inherits this environment variable. この場合、コンソール セッションが 1 つのみになる可能性があります。あるいは、環境変数をグローバルに設定した場合、コンピューター全体に影響する可能性があります。This might be just a single console session, or it might affect the entire machine if you set the environment variable globally. 環境変数の名前では大文字と小文字は区別されません。The environment variable name is not case-sensitive.

方法 2:レジストリMethod 2: Registry

レジストリ エディター (regedit.exe) を使用して、サブキーの HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework または HKEY_CURRENT_USER\SOFTWARE\Microsoft.NETFramework を見つけます。その後、次のように追加します。値の名前:DisableCCWSupportIAgileObject 種類:DWORD (32 ビット) 値 (REG_WORD ともいう) 値:1。Windows REG.EXE ツールを使用して、コマンド ラインまたはスクリプト環境から、この値を追加することができます。Using Registry Editor (regedit.exe), find either of the following subkeys:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework HKEY_CURRENT_USER\SOFTWARE\Microsoft.NETFrameworkThen add the following:Value name: DisableCCWSupportIAgileObject Type: DWORD (32-bit) Value (also called REG_WORD) Value: 1You can use the Windows REG.EXE tool to add this value from a command-line or scripting environment. 次に例を示します。For example:
reg add HKLM\SOFTWARE\Microsoft.NETFramework /v DisableCCWSupportIAgileObject /t REG_DWORD /d 1
ここでは、HKLMHKEY_LOCAL_MACHINE の代わりに使用されています。In this case, HKLM is used instead of HKEY_LOCAL_MACHINE. この構文のヘルプを表示するには、reg add /? を使用します。Use reg add /? to see help on this syntax. レジストリ値の名前では大文字と小文字は区別されません。The registry value name is not case-sensitive.

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

影響を受ける APIAffected APIs

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

UNC 共有に似た URI での Unicode の許可Allow Unicode in URIs that resemble UNC shares

説明Details

System.Uri では、UNC 共有名と Unicode 文字の両方を含むファイル URI の構築時に、URI が無効な内部状態にならなくなります。In System.Uri, constructing a file URI containing both a UNC share name and Unicode characters will no longer result in a URI with invalid internal state. 以下のすべてに該当する場合にのみ、動作が変わります。The behavior will change only when all of the following are true:

  • URI にスキーム file: があり、4 つ以上のスラッシュが続く。The URI has the scheme file: and is followed by four or more slashes.
  • ホスト名がアンダースコアまたはその他の予約されていないシンボルで始まる。The host name begins with an underscore or other non-reserved symbol.
  • URI に Unicode 文字が含まれている。The URI contains Unicode characters.

提案される解決策Suggestion

Unicode を含む URI を一貫して操作するアプリケーションでこの動作を使用して、UNC 共有への参照を許可しないようにした可能性があります。Applications working with URIs consistently containing Unicode could have conceivably used this behavior to disallow references to UNC shares. これらのアプリケーションでは代わりに IsUnc を使用する必要があります。Those applications should use IsUnc instead.

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

影響を受ける APIAffected APIs

Unicode が存在する場合の特別な相対 URI 表記のサポートSupport special relative URI notation when Unicode is present

説明Details

Uri では、Unicode を含む特定の相対 URI で TryCreate を呼び出したときに、NullReferenceException がスローされなくなります。Uri will no longer throw a NullReferenceException when calling TryCreate on certain relative URIs containing Unicode. NullReferenceException の最も単純な再現を以下に示します。2 つのステートメントは同等です。The simplest reproduction of the NullReferenceException is below, with the two statements being equivalent:

bool success = Uri.TryCreate("http:%C3%A8", UriKind.RelativeOrAbsolute, out Uri href);
bool success = Uri.TryCreate("http:è", UriKind.RelativeOrAbsolute, out Uri href);
NullReferenceException を再現するには、次の項目が true である必要があります。To reproduce the NullReferenceException, the following items must be true:
  • URI は、前に "http:" を付加し、その後に "//" を付けずに相対として指定する必要があります。The URI must be specified as relative by prepending it with ‘http:’ and not following it with ‘//’.
  • URI には、パーセントでエンコードされた Unicode または予約されていないシンボルを含める必要があります。The URI must contain percent-encoded Unicode or unreserved symbols.

提案される解決策Suggestion

相対 URI を許可しないようにするためにこの動作に依存しているユーザーは、URI の作成時に代わりに UriKind.Absolute を指定する必要があります。Users depending on this behavior to disallow relative URIs should instead specify UriKind.Absolute when creating a URI.

名前Name [値]Value
スコープScope エッジEdge
バージョンVersion 4.7.24.7.2
種類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.

Azure SQL データベースの接続プールのブロック期間が削除されるConnection pool blocking period for Azure SQL databases is removed

説明Details

.NET Framework 4.6.2 以降では、既知の Azure SQL データベースへの接続確立要求の場合 (*.database.windows.net、*.database.chinacloudapi.cn、*.database.usgovcloudapi.net、*.database.cloudapi.de)、接続プールのブロック期間が削除され、接続確立のエラーがキャッシュされません。Starting with the .NET Framework 4.6.2, for connection open requests to known Azure SQL databases (*.database.windows.net, *.database.chinacloudapi.cn, *.database.usgovcloudapi.net, *.database.cloudapi.de), the connection pool blocking period is removed, and connection open errors are not cached. 接続オープン要求の再試行は、一時的な接続エラーのほぼすぐ後に発生します。Attempts to retry connection open requests will occur almost immediately after transient connection errors. この変更により、Azure SQL データベースへの接続確立がすぐに再試行するされるため、クラウド対応アプリケーションのパフォーマンスが向上します。This change allows the connection open attempt to be retried immediately for Azure SQL databases, thereby improving the performance of cloud- enabled apps. 他のすべての接続を試みる場合は、接続プールのブロック期間が引き続き適用されます。For all other connection attempts, the connection pool blocking period continues to be enforced.

.NET Framework 4.6.1 以前のバージョンでは、データベースへの接続時にアプリで一時的な接続エラーが発生した場合、接続はすぐに再試行されません。接続プールがエラーをキャッシュし、5 秒 ~ 1 分の間にエラーを再スローするためです。In the .NET Framework 4.6.1 and earlier versions, when an app encounters a transient connection failure when connecting to a database, the connection attempt cannot be retried quickly, because the connection pool caches the error and re-throws it for 5 seconds to 1 minute. 詳しくは、「SQL Server の接続プール (ADO.NET)」をご覧ください。For more information, see SQL Server Connection Pooling (ADO.NET). この動作は、Azure SQL データベースへの接続時に問題となります。多くの場合、一時的なエラーが発生し、通常数秒内に回復します。This behavior is problematic for connections to Azure SQL databases, which often fail with transient errors that are typically recovered from within a few seconds. 接続プールのブロック機能を使うと、データベースが使用可能で、アプリが数秒以内にレンダリングする必要がある場合でも、アプリは長期間データベースに接続できません。The connection pool blocking feature means that the app cannot connect to the database for an extensive period, even though the database is available and the app needs to render within a few seconds.

提案される解決策Suggestion

この動作が望ましくない場合は、.NET Framework 4.6.2 で導入された System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod プロパティを設定することで、接続プールのブロック期間を構成できます。If this behavior is undesirable, the connection pool blocking period can be configured by setting the System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod property introduced in the .NET Framework 4.6.2. プロパティ値が System.Data.SqlClient.PoolBlockingPeriod 列挙型のメンバーである場合、次の 3 つの値のいずれかを使用できます。The value of the property is a member of the System.Data.SqlClient.PoolBlockingPeriod enumeration that can take either of three values:

System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod プロパティを AlwaysBlock に設定して、以前の動作を復元することができます。The previous behavior can be restored by setting the System.Data.SqlClient.SqlConnectionStringBuilder.PoolBlockingPeriod property to AlwaysBlock.

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

影響を受ける APIAffected APIs

グローバリゼーションGlobalization

Unicode 標準バージョン 8.0 のカテゴリのサポート開始Unicode standard version 8.0 categories now supported

説明Details

.NET Framework 4.6.2 で、Unicode データが Unicode 標準バージョン 6.3 からバージョン 8.0 にアップグレードされました。In .NET Framework 4.6.2, Unicode data has been upgraded from Unicode Standard version 6.3 to version 8.0. .NET Framework 4.6.2 で Unicode 文字カテゴリを要求すると、いくつかの結果が以前の .NET Framework バージョンの結果と一致しない可能性があります。When requesting Unicode character categories in .NET Framework 4.6.2, some results might not match the results in previous .NET Framework versions. この変更は、主にチェロキーの音節、新タイ ロ文字の母音記号および声調記号に影響します。This change mostly affects Cherokee syllables and New Tai Lue vowels signs and tone marks.

提案される解決策Suggestion

コードを確認し、ハードコーディングされた Unicode 文字カテゴリに依存するロジックを削除/変更します。Review code and remove/change logic that depends on hard-coded Unicode character categories.

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

影響を受ける APIAffected APIs

ランタイムRuntime

Net.Tcp 証明書認証の WCF チェーン信頼証明書の検証が向上したImproved WCF chain trust certificate validation for Net.Tcp certificate authentication

説明Details

.NET Framework 4.7.2 では、WCF とのトランスポート セキュリティで証明書認証を使用するときのチェーン信頼証明書の検証が向上しています。.NET Framework 4.7.2 improves chain trust certificate validation when using certificate authentication with transport security with WCF. この改善により、サーバーに対する認証に使用されるクライアント証明書を、クライアント認証用に構成する必要があります。With this improvement, client certificates that are used to authenticate to a server must be configured for client authentication. 同様に、サーバーを認証するためのサーバー証明書は、サーバー認証用に構成する必要があります。Similarly server certificates that are for the authenticating a server must be configured for server authentication. この変更では、ルート証明書が無効になっている場合、証明書チェーンの検証が失敗します。With this change, if the root certificate is disabled, the certificate chain validation fails. 同じ変更が、Windows セキュリティ ロールアップによって .NET Framework 3.5 以降のバージョンにも行われました。The same change was also made to .NET Framework 3.5 and later versions via Windows security roll-up. 詳細については、こちらをご覧ください。この変更は既定で有効になり、構成設定によって無効にできます。You can find more information here.This change is on by default and can be turned off by a configuration setting.

提案される解決策Suggestion

  • サーバー証明書とクライアント証明書に必要な EKU OID があるかどうかを確認します。Validate if your server and client certification has the required EKU OID. ない場合は、証明書を更新します。If not, update your certification.
  • ルート証明書が無効かどうかを確認します。Validate if your root certificate is invalid. 無効である場合は、ルート証明書を更新します。If so, update the root certificate.
  • 変更をオプトアウトする方法:証明書を更新できない場合は、次の構成設定により互換性に影響する変更を一時的に回避できます。ただし、変更をオプトアウトすると、システムはセキュリティの問題に対して脆弱なままになります。How to opt out of the change: If you can't update the certificate, you can work around the breaking change temporarily with the following configration setting, However, opting out of the change will leave your system vulnerable to the security issue.
<appSettings>
<add key="wcf:useLegacyCertificateUsagePolicy" value="true" />
</appSettings>
名前Name [値]Value
スコープScope マイナーMinor
バージョンVersion 4.7.24.7.2
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

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

セキュリティSecurity

RSACng.VerifyHash で検証が失敗した場合に False が返されるようになったRSACng.VerifyHash now returns False for any verification failure

説明Details

.NET Framework 4.6.2 以降では、署名自体の形式が正しくない場合、このメソッドでは False が返されます。Starting with the .NET Framework 4.6.2, this method returns False if the signature itself is badly formatted. 今すぐ false を返しますの検証に失敗しました。 .NET Framework 4.6 および 4.6.1 では、メソッドによってスローされる、System.Security.Cryptography.CryptographicException署名自体が正しくフォーマットされている場合。It now returns false for any verification failure.In the .NET Framework 4.6 and 4.6.1, the method throws a System.Security.Cryptography.CryptographicException if the signature itself is badly formatted.

提案される解決策Suggestion

検証が失敗し、メソッドで False が返される場合は、代わりにその実行が System.Security.Cryptography.CryptographicException の処理に依存するコードが実行される必要があります。Any code whose execution depends on handling the System.Security.Cryptography.CryptographicException should instead execute if validation fails and the method returns False.

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

影響を受ける APIAffected APIs

SignedXml と EncryptedXml の互換性に影響する変更点SignedXml and EncryptedXml Breaking Changes

説明Details

.NET Framework 4.6.2 では、System.Security.Cryptography.Xml.SignedXml および System.Security.Cryptography.Xml.EncryptedXml のセキュリティ修正プログラムにより、実行時の動作が変わります。In .NET Framework 4.6.2, Security fixes in System.Security.Cryptography.Xml.SignedXml and System.Security.Cryptography.Xml.EncryptedXml lead to different run-time behaviors. 次に例を示します。For example,

  • ドキュメントに id 属性が同じ値の複数の要素があり、署名でそれらの要素の 1 つが署名のルートとして指定されている場合、ドキュメントは無効と見なされるようになります。If a document has multiple elements with the same id attribute and a signature targets one of those elements as the root of the signature, the document will now be considered invalid.
  • 参照で非正規 XPath 変換アルゴリズムを使っているドキュメントは、無効と見なされるようになります。Documents using non-canonical XPath transform algorithms in references are now considered invalid.
  • 参照で非正規 XSLT 変換アルゴリズムを使っているドキュメントは、無効と見なされるようになります。Documents using non-canonical XSLT transform algorithms in references are now consider invalid.
  • 外部リソースのデタッチされた署名を利用しているプログラムは、利用できなくなります。Any program making use of external resource detached signatures will be unable to do so.

提案される解決策Suggestion

ドキュメントの受信者が処理できない可能性があるため、開発者は XmlDsigXsltTransformXmlDsigXsltTransform の使用、および Transform の派生型を確認することが必要な場合があります。Developers might want to review the usage of XmlDsigXsltTransform and XmlDsigXsltTransform, as well as types derived from Transform since a document receiver may not be able to process it.

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

影響を受ける APIAffected APIs

ツールTools

Contract.Invariant または Contract.Requires<TException> が String.IsNullOrEmpty の純粋性を考慮しないContract.Invariant or Contract.Requires<TException> do not consider String.IsNullOrEmpty to be pure

説明Details

.NET Framework 4.6.1 が対象のアプリでは、Contract.Invariant の不変コントラクトまたは Requires の実行前の状態のコントラクトが String.IsNullOrEmpty メソッドを呼び出した場合、リライターはコンパイラの警告 CC1036:"Detected call to method 'System.String.IsNullOrWhiteSpace(System.String)' without [Pure] in method." を生成します。これはコンパイラ エラーではなく、コンパイラ警告です。For apps that target the .NET Framework 4.6.1, if the invariant contract for Contract.Invariant or the precondition contract for Requires calls the String.IsNullOrEmpty method, the rewriter emits compiler warning CC1036: "Detected call to method 'System.String.IsNullOrWhteSpace(System.String)' without [Pure] in method." This is a compiler warning rather than a compiler error.

提案される解決策Suggestion

この動作については GitHubの問題 #339 で報告されています。This behavior was addressed in GitHub Issue #339. この警告が表示されないようにするには、コード コントラクト ツールのソース コードの更新バージョンを GitHub からダウンロードしてコンパイルします。To eliminate this warning, you can download and compile an updated version of the source code for the Code Contracts tool from GitHub. ページ下部から情報をダウンロードできます。Download information is found at the bottom of the page.

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

影響を受ける APIAffected APIs

Web アプリケーションWeb Applications

.NET Framework 4.7.2 で "dataAnnotations:dataTypeAttribute:disableRegEx" アプリ設定が既定で有効になっている"dataAnnotations:dataTypeAttribute:disableRegEx" app setting is on by default in .NET Framework 4.7.2

説明Details

.NET framework 4.6.1 で、データ型属性 (System.ComponentModel.DataAnnotations.EmailAddressAttributeSystem.ComponentModel.DataAnnotations.UrlAttributeSystem.ComponentModel.DataAnnotations.PhoneAttribute など) で正規表現の使用を無効にするアプリ設定 ("dataAnnotations:dataTypeAttribute:disableRegEx") が導入されました。In .NET Framework 4.6.1, an app setting ("dataAnnotations:dataTypeAttribute:disableRegEx") was introduced that allows users to disable the use of regular expressions in data type attributes (such as System.ComponentModel.DataAnnotations.EmailAddressAttribute, System.ComponentModel.DataAnnotations.UrlAttribute, and System.ComponentModel.DataAnnotations.PhoneAttribute). これにより、特定の正規表現を使用するサービス拒否攻撃の可能性を回避できるなど、セキュリティの脆弱性を軽減できます。This helps to reduce security vulnerability such as avoiding the possibility of a Denial of Service attack using specific regular expressions.
.NET Framework 4.6.1 で、正規表現の使用を無効にするこのアプリ設定が、既定で false に設定されました。In .NET Framework 4.6.1, this app setting to disable RegEx usage was set to false by default. .NET Framework 4.7.2 からは、この構成スイッチが既定で true に設定され、.NET Framework 4.7.2 以降を対象とする Web アプリケーションのセキュリティの脆弱性がさらに軽減されています。Starting with .NET Framework 4.7.2, this config switch is set to true by default to further reduce secure vulnerability for web applications that target .NET Framework 4.7.2 and above.

提案される解決策Suggestion

.NET Framework 4.7.2 へのアップグレード後に Web アプリケーションの正規表現が動作しない場合は、"dataAnnotations:dataTypeAttribute:disableRegEx" 設定の値を false に更新して以前の動作に戻すことができます。If you find that regular expressions in your web application do not work after upgrading to .NET Framework 4.7.2, you can update the value of the "dataAnnotations:dataTypeAttribute:disableRegEx" setting to false to revert to the previous behavior.

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

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

影響を受ける APIAffected APIs

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

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

WCF TransportDefaults からの Ssl3 の削除Remove Ssl3 from the WCF TransportDefaults

説明Details

トランスポート セキュリティで NetTcp を使用し、証明書の資格情報の種類を使用する場合、SSL 3 プロトコルは、安全な接続のネゴシエーションに使用される既定のプロトコルではなくなりました。When using NetTcp with transport security and a credential type of certificate, the SSL 3 protocol is no longer a default protocol used for negotiating a secure connection. TLS 1.0 は常に NetTcp のプロトコル一覧に含まれているため、ほとんどの場合、既存のアプリには影響はないと考えられます。In most cases there should be no impact to existing apps as TLS 1.0 has always been included in the protocol list for NetTcp. 既存のすべてのクライアントは TLS 1.0 以降を使用して接続をネゴシエートできるようになりました。All existing clients should be able to negotiate a connection using at least TLS1.0.

提案される解決策Suggestion

Ssl3 が必要な場合は、以下の構成メカニズムのいずれかを使用して、ネゴシエートされたプロトコルの一覧に Ssl3 を追加します。If Ssl3 is required, use one of the following configuration mechanisms to add Ssl3 to the list of negotiated protocols.

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

影響を受ける APIAffected APIs

svcTraceViewer ComboBox のハイ コントラストの変更svcTraceViewer ComboBox high contrast change

説明Details

Microsoft Service Trace Viewer ツールでは、特定のハイ コントラストのテーマで ComboBox コントロールが適切な色で表示されませんでした。In the Microsoft Service Trace Viewer tool, ComboBox controls were not displayed in the correct color in certain high contrast themes. この問題は .NET Framework 4.7.2 で修正されました。The issue was fixed in .NET Framework 4.7.2. しかし、.NET Framework SDK の下位互換性要件により、既定ではお客様に修正が示されませんでした。However, due to .NET Framework SDK backward compatibility requirements, the fix was not visible to customers by default. .NET 4.8 では、次の AppContext 構成スイッチを svcTraceViewer.exe.config ファイルに追加することで、この変更が示されます。.NET 4.8 surfaces this change by adding the following AppContext configuration switches to the svcTraceViewer.exe.config file:

<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false" />

提案される解決策Suggestion

ハイ コントラストの動作を変更したくない場合は、svcTraceViewer.exe.config ファイルから次のセクションを削除することで、無効にすることができます。If you don't want to have the high contrast behavior change, you can disable it by removing the following section from the svcTraceViewer.exe.config file:

<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false" />
名前Name [値]Value
スコープScope エッジEdge
バージョンVersion 4.84.8
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

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

addressHeader 要素が null の場合、WCF AddressHeaderCollection で ArgumentException がスローされるようになったWCF AddressHeaderCollection now throws an ArgumentException if an addressHeader element is null

説明Details

.NET Framework 4.7.1 以降では、要素のいずれかが null の場合、AddressHeaderCollection(IEnumerable<AddressHeader>) コンストラクターで ArgumentException がスローされます。Starting with the .NET Framework 4.7.1, the AddressHeaderCollection(IEnumerable<AddressHeader>) constructor throws an ArgumentException if one of the elements is null. .NET Framework 4.7 以前のバージョンでは、例外はスローされません。In the .NET Framework 4.7 and earlier versions, no exception is thrown.

提案される解決策Suggestion

.NET Framework 4.7.1 以降のバージョンでこの変更に関する互換性の問題が発生した場合は、次の行を app.config ファイルの <runtime> セクションに追加することで、無効にできます。If you encounter compatibility issues with this change on the .NET Framework 4.7.1 or a later version, you can opt-out of it by adding the following line to the <runtime> section of the app.config file:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableAddressHeaderCollectionValidation=true" />
  </runtime>
</configuration>
NameName Value
スコープScope マイナーMinor
バージョンVersion 4.7.14.7.1
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

WCF MsmqSecureHashAlgorithm の既定値が SHA256 になったWCF MsmqSecureHashAlgorithm default value is now SHA256

説明Details

.NET Framework 4.7.1 以降では、Msmq メッセージの WCF での既定のメッセージ署名アルゴリズムは SHA256 です。Starting with the .NET Framework 4.7.1, the default message signing algorithm in WCF for Msmq messages is SHA256. .NET Framework 4.7 以前のバージョンでは、既定のメッセージ署名アルゴリズムは SHA1 です。In the .NET Framework 4.7 and earlier versions, the default message signing algorithm is SHA1.

提案される解決策Suggestion

.NET Framework 4.7.1 以降でこの変更に関する互換性の問題が発生した場合は、次の行を app.config ファイルの <runtime> セクションに追加することで、変更を無効にできます。If you run into compatibility issues with this change on the .NET Framework 4.7.1 or later, you can opt-out the change by adding the following line to the <runtime> section of your app.config file:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value=&quot;Switch.System.ServiceModel.UseSha1InMsmqEncryptionAlgorithm=true&quot; />
  </runtime>
</configuration>
名前Name Value
スコープScope マイナーMinor
バージョンVersion 4.7.14.7.1
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

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

WCF PipeConnection.GetHashAlgorithm が SHA256 を使用するようになったWCF PipeConnection.GetHashAlgorithm now uses SHA256

説明Details

.NET Framework 4.7.1 以降の Windows Communication Foundation は、SHA256 ハッシュを使用して名前付きパイプ用のランダムな名前を生成します。Starting with the .NET Framework 4.7.1, Windows Communication Foundation uses a SHA256 hash to generate random names for named pipes. .NET Framework 4.7 以前のバージョンでは、SHA1 ハッシュを使っていました。In the .NET Framework 4.7 and earlier versions, it used a SHA1 hash.

提案される解決策Suggestion

.NET Framework 4.7.1 以降でこの変更に関する互換性の問題が発生した場合は、次の行を app.config ファイルの <runtime> セクションに追加することで、変更を無効にできます。If you run into compatibility issue with this change on the .NET Framework 4.7.1 or later, you can opt-out it by adding the following line to the <runtime> section of your app.config file:

<configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.ServiceModel.UseSha1InPipeConnectionGetHashAlgorithm=true" />
  </runtime>
</configuration>
NameName Value
スコープScope マイナーMinor
バージョンVersion 4.7.14.7.1
種類Type ランタイムRuntime

影響を受ける APIAffected APIs

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

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

StaysOpen=False でポップアップがチェーンされるChained Popups with StaysOpen=False

説明Details

ポップアップの外側をクリックすると、StaysOpen=False のポップアップが閉じられることが想定されます。A Popup with StaysOpen=False is supposed to close when you click outside the Popup. このような 2 つ以上のポップアップがチェーンされている (つまり、1 つに別のものが含まれている) 場合、次のような、多くの問題が発生します。When two or more such Popups are chained (i.e. one contains another), there were many problems, including:

  • 2 つのレベルを開き、P2 の外側と、P1 の内側をクリックします。Open two levels, click outside P2 but inside P1. 何も起こりません。Nothing happens.
  • 2 つのレベルを開き、P1 の外側をクリックします。Open two levels, click outside P1. 両方のポップアップが閉じます。Both popups close.
  • 2 つのレベルを開いて閉じます。Open and close two levels. 次に、P2 をもう一度開いてみます。Then try to open P2 again. 何も起こりません。Nothing happens.
  • 3 つのレベルを開いてみます。Try to open three levels. この操作を行うことはできませんYou can't. (クリックする場所に応じて、何も起こらないか、最初の 2 つのレベルが閉じます)。このような場合 (および他のバリアント) は、予期したとおり動作します。(Either nothing happens or the first two levels close, depending on where you click.) These cases (and other variants) now work as expected.

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

影響を受ける APIAffected APIs

TextBlock コントロールの親の IsEnabled プロパティの変更がすべての子コントロールに影響するChanging the IsEnabled property of the parent of a TextBlock control affects any child controls

説明Details

.NET Framework 4.6.2、変更以降のSystem.Windows.UIElement.IsEnabledの親のプロパティ、System.Windows.Controls.TextBlockコントロール (ハイパーリンクやボタンなど) などの子コントロールに影響を与える、System.Windows.Controls.TextBlockコントロール。 .NET Framework 4.6.1 以前のバージョンで、内部コントロール、System.Windows.Controls.TextBlockの状態を常に反映されませんでした、System.Windows.UIElement.IsEnabledのプロパティ、System.Windows.Controls.TextBlock親。Starting with the .NET Framework 4.6.2, changing the System.Windows.UIElement.IsEnabled property of the parent of a System.Windows.Controls.TextBlock control affects any child controls (such as hyperlinks and buttons) of the System.Windows.Controls.TextBlock control.In the .NET Framework 4.6.1 and earlier versions, controls inside a System.Windows.Controls.TextBlock did not always reflect the state of the System.Windows.UIElement.IsEnabled property of the System.Windows.Controls.TextBlock parent.

提案される解決策Suggestion

[なし] :None. この変更は、System.Windows.Controls.TextBlock コントロール内部のコントロールに期待される動作に準拠しています。This change conforms to the expected behavior for controls inside a System.Windows.Controls.TextBlock control.

名前Name Value
スコープScope マイナーMinor
バージョンVersion 4.6.24.6.2
種類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

KeyedCollection のデータ バインディングの機能強化Data Binding improvement for KeyedCollection

説明Details

ソース オブジェクトが同じシグネチャを持つカスタム インデクサーを宣言するときのBindingによる IList インデクサーの不適切な使用を修正しました (例: KeyedCollection<int,TItem>)。Fixed Binding incorrect use of IList indexer when the source object declares a custom indexer with the same signature (for example, KeyedCollection<int,TItem>).

提案される解決策Suggestion

古いバージョンを対象とするアプリケーションがこの変更の恩恵を受けるには、.NET Framework 4.8 以降上で実行する必要があります。また、次の AppContext スイッチをアプリ構成ファイルの <runtime> セクションに追加し、それを false に設定することで、変更を選択する必要があります。In order for an application that targets an older version to benefit from this change, it must run on the .NET Framework 4.8 or later, and it must opt in to the change by adding the following AppContext switch to the <runtime> section of the app config file and setting it to false:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7"/>
</startup>
<runtime>
<!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false  -->
<AppContextSwitchOverrides value="Switch.System.Windows.Data.Binding.IListIndexerHidesCustomIndexer=false" />
</runtime>
</configuration>

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

影響を受ける APIAffected APIs

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

ListBox に重複する値型が含まれている場合のハングの修正Fixed a hang when ListBox contains duplicate value-types

説明Details

Items コレクションに重複する値型オブジェクトが含まれていると、ItemsControl の仮想化がスクロール中にハングする場合がある問題を修正しました。Fixed a problem where a virtualizingItemsControl can hang during scrolling when its Items collection contains duplicate value-typed objects.

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

影響を受ける APIAffected APIs

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

水平方向スクロールと仮想化Horizontal scrolling and virtualization

説明Details

この変更は、メインのスクロール方向と直交する方向で独自に仮想化を行う System.Windows.Controls.ItemsControl に適用されます (代表的な例は、EnableColumnVirtualization="True" である System.Windows.Controls.DataGrid です)。This change applies to an System.Windows.Controls.ItemsControl that does its own virtualization in the direction orthogonal to the main scrolling direction (the chief example is System.Windows.Controls.DataGrid with EnableColumnVirtualization="True"). 特定の水平方向スクロール操作の結果が変更され、比較可能な垂直操作の結果により類似した、より直感的な結果が生成されるようになりました。The outcome of certain horizontal scrolling operations has been changed to produce results that are more intuitive and more analogous to the results of comparable vertical operations.

操作には "ここにスクロール" や "右端" などがあり、水平スクロール バーを右クリックすると表示されるメニューから名前を使用することができます。The operations include "Scroll Here" and "Right Edge", to use the names from the menu obtained by right-clicking a horizontal scrollbar. これらの両方でオフセット候補が計算され、SetHorizontalOffset(Double) が呼び出されます。Both of these compute a candidate offset and call SetHorizontalOffset(Double).

新しいオフセットにスクロールすると、"ここ" または "右端" の概念が変更されている場合があります。これは、新しく非仮想化されたコンテンツで System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth の値が変更されたためです。After scrolling to the new offset, the notion of "here" or "right edge" may have changed because newly de-virtualized content has changed the value of System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth.

.NET Framework 4.6.2 より前では、もう "ここ" や "右端" にない場合でも、スクロール操作では単にオフセット候補を使用します。Prior to .NET Framework 4.6.2, the scroll operation simply uses the candidate offset, even though it may not be "here" or at the "right edge" any more. その結果、スクロールつまみの "バウンス" などの効果が得られます。次に例を示します。This results in effects like "bouncing" the scroll thumb, best illustrated by example. たとえば、System.Windows.Controls.DataGrid で ExtentWidth=1000 および Width=200 であるものとします。Suppose a System.Windows.Controls.DataGrid has ExtentWidth=1000 and Width=200. "右端" へのスクロールでは、1000 - 200 = 800 という候補オフセットを使用します。A scroll to "Right Edge" uses candidate offset 1000 - 200 = 800. そのオフセットへのスクロール時に、新しい列が非仮想化されます。これらの列が非常に広いため、System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth を 2000 に変更したとします。While scrolling to that offset, new columns are de- virtualized; let's suppose they are very wide, so that the System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth changes to 2000. スクロールは HorizontalOffset=800 で終了し、つまみはスクロールバーの中央付近 (正確には 800/2000 = 40%) に "戻り" ます。The scroll ends with HorizontalOffset=800, and the thumb "bounces" back to near the middle of the scrollbar - precisely at 800/2000 = 40%.

変更するには、この状況が発生したら新しいオフセット候補を再計算してやり直しますThe change is to recompute a new candidate offset when this situation occurs, and try again. (垂直方向スクロールの動作は既にこのようになっています)。(This is how vertical scrolling works already.)

この変更により、エンド ユーザーにはより予測可能で直感的なエクスペリエンスが提供されるようになりますが、水平方向スクロール後の System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset の正確な値に依存するアプリに影響する可能性もあります。これは、エンド ユーザーによる呼び出しであるか、SetHorizontalOffset(Double) の明示的な呼び出しであるかに関係ありません。The change produces a more predictable and intuitive experience for the end user, but it could also affect any app that depends on the exact value of System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset after a horizontal scroll, whether invoked by the end user or by an explicit call to SetHorizontalOffset(Double).

提案される解決策Suggestion

System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset の予測値を使用するアプリを、非仮想化により System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth が変更される可能性のある水平方向スクロール後の実際の値 (および System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth の値) を取得するように変更する必要があります。An app that uses a predicted value for System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset should be changed to fetch the actual value (and the value of System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth) after any horizontal scroll that could change System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth due to de-virtualization.

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

影響を受ける APIAffected APIs

グリッド スター行領域の割り当てアルゴリズムの改善Improvements to Grid star-rows space allocating algorithm

説明Details

.NET Framework 4.7 で導入された Gridサイズを割り当てるためのアルゴリズム) のバグを修正しました。Fixed a bug in the algorithm for allocating sizes to) in a Grid introduced in .NET Framework 4.7. 空の行を含む Height="Auto" のグリッドなど、場合によっては、行が正しくない位置に配置され、すべてグリッドの外側に示されることがありました。In some cases, such as a Grid with Height="Auto" containing empty rows, rows were arranged at the wrong position, possibly outside the Grid altogether.

提案される解決策Suggestion

アプリケーションでこれらの変更を利用するには、.NET Framework 4.8 以降で実行する必要があります。In order for the application to benefit from these changes, it must run on the .NET Framework 4.8 or later.

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

影響を受ける APIAffected APIs

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

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

説明Details

セレクター (複数選択が有効になっている) の System.Windows.Controls.Primitives.MultiSelector.SelectedItems コレクションに重複部分があるとします。その場合、同じ項目が複数回表示されます。Suppose a Selector (with multiple selection enabled) has duplicates in its System.Windows.Controls.Primitives.MultiSelector.SelectedItems collection - the same item appears more than once. データ ソースからこれらの項目を削除すると (たとえば、Items.Clear を呼び出すことにより)、System.Windows.Controls.Primitives.MultiSelector.SelectedItems からそれらの項目を削除できなくなります。最初のインスタンスのみが削除されます。Removing those items from the data source (e.g. by calling Items.Clear) fails to remove them from System.Windows.Controls.Primitives.MultiSelector.SelectedItems; only the first instance is removed. さらに、System.Windows.Controls.Primitives.MultiSelector.SelectedItems (SelectedItems.Clear() など) を引き続き使用すると、System.ArgumentException などの問題が発生する可能性があります。これは、System.Windows.Controls.Primitives.MultiSelector.SelectedItems に、データ ソース内にはもう存在しない項目が含まれているためです。Furthermore, subsequent use of System.Windows.Controls.Primitives.MultiSelector.SelectedItems (e.g. SelectedItems.Clear()) can encounter problems such as System.ArgumentException, because System.Windows.Controls.Primitives.MultiSelector.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.

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

影響を受ける APIAffected APIs

説明Details

ItemsControl の選択項目ではない項目内のハイパーリンクにフォーカスがあるときに矢印キーを押すと不適切な結果になる問題を修正しました。Fixed incorrect result of pressing an arrow key when the focus is on a hyperlink within an item that is not the selected item of the parent ItemsControl.

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

影響を受ける APIAffected APIs

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

WPF での KeyTip の動作が改良されたKeytips behavior improved in WPF

説明Details

KeyTip の動作が、Microsoft Word やエクスプローラーでの動作と同等に変更されています。Keytips behavior has been modified to bring parity with behavior on Microsoft Word and Windows Explorer. SystemKey (具体的には Key または F11) が押された場合に KeyTip の状態が有効かどうかを調べることによって、WPF は KeyTip キーを適切に処理します。By checking whether keytip state is enabled or not in the case of a SystemKey (in particular, Key or F11) being pressed, WPF handles keytip keys appropriately. メニューがマウスによって開かれている場合でも、KeyTip はメニューを閉じるようになっています。Keytips now dismiss a menu even when it is opened by mouse.

提案される解決策Suggestion

N/AN/A

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

影響を受ける APIAffected APIs

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

ItemsControl をグループ化するためのオートメーション ツリーのパフォーマンス向上Performance improvement in Automation tree for grouping ItemsControls

説明Details

グループ化が有効な ListBox や DataGrid などの ItemsControl のオートメーション ツリーの再構築のパフォーマンスが向上しました。Improved the performance of rebuilding the automation tree of an ItemsControl, such as a ListBox or DataGrid, in which grouping is enabled.

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

影響を受ける APIAffected APIs

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

WPF での印刷スタックの更新WPF Printing Stack Update

説明Details

System.Printing.PrintQueue を使う WPF の印刷 API は、非推奨になった XPS 印刷 API ではなく Windows ドキュメント印刷パッケージ API を呼び出すようになりました。WPF's Printing APIs using System.Printing.PrintQueue now call Window's Print Document Package API in favor of the now deprecated XPS Print API. この変更はサービス性を考慮して行われたもので、ユーザーも開発者も、動作または API の使用の変化を目にすることはありません。The change was made with serviceability in mind; neither users nor developers should see any changes in behavior or API usage. Windows 10 Creators Update で実行すると、新しい印刷スタックは既定で有効になります。The new printing stack is enabled by default when running in Windows 10 Creators Update. 以前のバージョンの Windows では、以前の印刷スタックが引き続き同じように動作します。The old printing stack will still continue to work just as before in older Windows versions.

提案される解決策Suggestion

Windows 10 Creators Update で以前のスタックを使用するには、HKEY_CURRENT_USER\Software\Microsoft.NETFramework\Windows Presentation Foundation\Printing レジストリ キーの UseXpsOMPrinting REG_DWORD 値を 1 に設定します。To use the old stack in Windows 10 Creators Update, set the UseXpsOMPrinting REG_DWORD value of the HKEY_CURRENT_USER\Software\Microsoft.NETFramework\Windows Presentation Foundation\Printing registry key to 1.

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

影響を受ける APIAffected APIs

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

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

場合によって、ワークフローで NullReferenceException ではなく、元の例外がスローされるようになったWorkflow now throws original exception instead of NullReferenceException in some cases

説明Details

.NET Framework 4.6.2 ワークフロー アクティビティの Execute メソッドを使用して例外をスローした場合、以前のバージョンで、null値をMessageプロパティ、System.Activities ワークフロー ランタイムは、スロー、 System.NullReferenceException、マスク、元の例外。 .NET Framework 4.7 以前マスクは、例外がスローされます。In the .NET Framework 4.6.2 and earlier versions, when the Execute method of a workflow activity throws an exception with a null value for the Message property, the System.Activities Workflow runtime throws a System.NullReferenceException, masking the original exception.In the .NET Framework 4.7, the previously masked exception is thrown.

提案される解決策Suggestion

コードが System.NullReferenceException の処理に依存する場合は、カスタム アクティビティからスローされる可能性のある例外をキャッチするように変更します。If your code relies on handling the System.NullReferenceException, change it to catch the exceptions that could be thrown from your custom activities.

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

影響を受ける APIAffected APIs

Workflow SQL の永続化で主キー クラスターが追加され、一部の列の null 値が許可されないWorkflow SQL persistence adds primary key clusters and disallows null values in some columns

説明Details

.NET Framework 4.7 以降では、SqlWorkflowInstanceStoreSchema.sql スクリプトで SQL Workflow Instance Store (SWIS) に作成されたテーブルにはクラスター化された主キーが使用されます。Starting with the .NET Framework 4.7, the tables created for the SQL Workflow Instance Store (SWIS) by the SqlWorkflowInstanceStoreSchema.sql script use clustered primary keys. そのため、ID では null 値はサポートされません。Because of this, identities do not support null values. SWIS の操作には、この変更による影響はありません。The operation of SWIS is not impacted by this change. SQL Server トランザクション レプリケーションをサポートするように更新されました。The updates were made to support SQL Server Transactional Replication.

提案される解決策Suggestion

この変更では、SQL ファイルの SqlWorkflowInstanceStoreSchemaUpgrade.sql を既存のインストールに適用する必要があります。The SQL file SqlWorkflowInstanceStoreSchemaUpgrade.sql must be applied to existing installations in order to experience this change. 新しいデータベースのインストールは自動的に変更されます。New database installations will automatically have the change.

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

影響を受ける APIAffected APIs

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