.NET Framework 4.5 から 4.6.1 への移行に関する変更の再ターゲットRetargeting Changes for Migration from .NET Framework 4.5 to 4.6.1

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

ADO.NETADO.NET

DbParameter.Precision と DbParameter.Scale は、パブリック仮想メンバーになったDbParameter.Precision and DbParameter.Scale are now public virtual members

説明Details

Precision および Scale はパブリック仮想プロパティとして実装されます。Precision and Scale are implemented as public virtual properties. これらは、対応する明示的なインターフェイス実装、IDbDataParameter.PrecisionIDbDataParameter.Scale を置き換えます。They replace the corresponding explicit interface implementations, IDbDataParameter.Precision and IDbDataParameter.Scale.

提案される解決策Suggestion

ADO.NET データベース プロバイダーを再構築するとき、これらの違いにより、「override」キーワードが Precision および Scale プロパティに適用される必要があります。When re-building an ADO.NET database provider, these differences will require the 'override' keyword to be applied to the Precision and Scale properties. これは、コンポーネントを再構築するときにのみ必要です。既存のバイナリは引き続き機能します。This is only needed when re-building the components; existing binaries will continue to work.

名前Name [値]Value
スコープScope マイナーMinor
バージョンVersion 4.5.14.5.1
種類Type 再ターゲット中Retargeting

影響を受ける APIAffected APIs

ASP.NETASP.NET

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

説明Details

.NET Framework 4.6 以降では、<BR /> 要素を指定して RenderBeginTag(String)RenderEndTag() を呼び出すと、<BR /> が 1 つのみ (2 つではなく) 正しく挿入されます。Beginning in the .NET Framework 4.6, calling RenderBeginTag(String) and RenderEndTag() with a <BR /> element will correctly insert only one <BR /> (instead of two)

提案される解決策Suggestion

アプリが余分な <BR /> タグに依存している場合は、RenderBeginTag(String) をもう一度呼び出す必要があります。If an app depended on the extra <BR /> tag, RenderBeginTag(String) should be called a second time. この動作の変更は、.NET Framework 4.6 以降を対象とするアプリにのみ影響するので、以前の動作を得るためには、以前のバージョンの .NET Framework を対象とするという方法もあります。Note that this behavior change only affects apps that target the .NET Framework 4.6 or later, so another option is to target a previous version of the .NET Framework in order to get the old behavior.

名前Name Value
スコープScope エッジEdge
バージョンVersion 4.64.6
種類Type 再ターゲット中Retargeting

影響を受ける APIAffected APIs

ClickOnceClickOnce

SHA-256 コード署名証明書を使用する ClickOnce で発行されたアプリケーションは、Windows 2003 では失敗することがあるApps published with ClickOnce that use a SHA-256 code-signing certificate may fail on Windows 2003

説明Details

この実行可能ファイルは SHA256 で署名されます。The executable is signed with SHA256. 以前は、コード署名証明書が SHA-1 か SHA-256 に関係なく、SHA 1 で署名されました。Previously, it was signed with SHA1 regardless of whether the code-signing certificate was SHA-1 or SHA-256. この方法は、次の対象に適用されます。This applies to:

  • Visual Studio 2012 以降でビルドされたすべてのアプリケーション。All applications built with Visual Studio 2012 or later.
  • .NET Framework 4.5 がインストールされているシステム上で、Visual Studio 2010 以前でビルドされたアプリケーション。Applications built with Visual Studio 2010 or earlier on systems with the .NET Framework 4.5 present. さらに、.NET Framework 4.5 以降が存在する場合、コンパイル対象となった .NET Framework のバージョンに関係なく、ClickOnce マニフェストはSHA-256 証明書の SHA 256 で署名されます。In addition, if the .NET Framework 4.5 or later is present, the ClickOnce manifest is also signed with SHA-256 for SHA-256 certificates regardless of the .NET Framework version against which it was compiled.

提案される解決策Suggestion

ClickOnce 実行可能ファイルの署名方法に関するこの変更は、Windows Server 2003 システムにのみ影響を及ぼします。これらのシステムには、KB 938397 をインストールする必要があります。The change in signing the ClickOnce executable affects only Windows Server 2003 systems; they require that KB 938397 be installed. アプリが .NET Framework 4.0 以前のバージョンをターゲットとしている場合でも、SHA-256 を使用したマニフェストの署名方法の変更により、.NET Framework 4.5 以降のバージョンに対するランタイム依存関係が導入されます。The change in signing the manifest with SHA-256 even when an app targets the .NET Framework 4.0 or earlier versions introduces a runtime dependency on the .NET Framework 4.5 or a later version.

名前Name [値]Value
スコープScope エッジEdge
バージョンVersion 4.54.5
種類Type 再ターゲット中Retargeting

4.0 を対象とするアプリの ClickOnce が SHA-256 に対応ClickOnce supports SHA-256 on 4.0-targeted apps

説明Details

以前は、SHA-256 で署名された証明書が与えられた ClickOnce アプリには、アプリの対象が 4.0 の場合でも、.NET Framework 4.5 以降が必要でした。Previously, a ClickOnce app with a certificate signed with SHA-256 would require .NET Framework 4.5 or later to be present, even if the app targeted 4.0. それが今では、SHA-256 で署名されている場合でも、.NET Framework 4.0 を対象とする ClickOnce アプリを .NET Framework 4.0 で実行できるようになりました。Now, .NET Framework 4.0-targeted ClickOnce apps can run on .NET Framework 4.0, even if signed with SHA-256.

提案される解決策Suggestion

この変更により、その依存関係がなくなったので、.NET Framework 4 以前のバージョンを対象とする ClickOnce アプリの署名に SAH-256 証明書が使用できるようになりました。This change removes that dependency and allows SHA-256 certificates to be used to sign ClickOnce apps that target .NET Framework 4 and earlier versions.

名前Name Value
スコープScope マイナーMinor
バージョンVersion 4.64.6
種類Type 再ターゲット中Retargeting

コアCore

ZipArchiveEntry オブジェクトの FullName プロパティのパス区切り文字の変更Change in path separator character in FullName property of ZipArchiveEntry objects

説明Details

.NET Framework 4.6.1 以降のバージョンを対象とするアプリでは、CreateFromDirectory メソッドのオーバーロードによって作成された ZipArchiveEntry オブジェクトの FullName プロパティで、パスの区切り文字が円記号 ("\") からスラッシュ ("/") に変更されています。For apps that target the .NET Framework 4.6.1 and later versions, the path separator character has changed from a backslash ("\") to a forward slash ("/") in the FullName property of ZipArchiveEntry objects created by overloads of the CreateFromDirectory method. この変更によって、.NET の実装が .ZIP ファイル形式の仕様のセクション 4.4.17.1 に準拠するようになったほか、Windows 以外のシステムで ZIP アーカイブを圧縮解除できるようになりました。The change brings the .NET implementation into conformity with section 4.4.17.1 of the .ZIP File Format Specification and allows .ZIP archives to be decompressed on non-Windows systems.
Macintosh などの Windows 以外のオペレーティング システムで以前のバージョンの .NET Framework を対象とするアプリで作成された zip ファイルを圧縮解除すると、ディレクトリ構造を保持できません。Decompressing a zip file created by an app that targets a previous version of the .NET Framework on non-Windows operating systems such as the Macintosh fails to preserve the directory structure. たとえば、Macintosh で、ディレクトリ パスとファイル名が円記号 ("\") 文字で連結された名前を持つ一連のファイルを作成するとします。For example, on the Macintosh, it creates a set of files whose filename concatenates the directory path, along with any backslash ("\") characters, and the filename. その場合、圧縮解除されたファイルのディレクトリ構造は保持されません。As a result, the directory structure of decompressed files is not preserved.

提案される解決策Suggestion

.NET Framework System.IO 名前空間の API によって Windows オペレーティング システム上に展開される .zip ファイルでは、この変更の影響は最小限になるはずです。これらの API では、パスの区切り文字としてスラッシュ ("/") または円記号 ("\") をシームレスに処理できるためです。The impact of this change on .ZIP files that are decompressed on the Windows operating system by APIs in the .NET Framework System.IO namespace should be minimal, since these APIs can seamlessly handle either a forward slash ("/") or a backslash ("\") as the path separator character.
この変更が望ましくない場合、アプリケーション構成ファイルの <runtime> セクションに構成設定を追加して、無効にすることができます。If this change is undesirable, you can opt out of it by adding a configuration setting to the <runtime> section of your application configuration file. 次の例では、<runtime> セクションと無効に切り替える処理 Switch.System.IO.Compression.ZipFile.UseBackslash の両方を確認できます。The following example shows both the <runtime> section and the Switch.System.IO.Compression.ZipFile.UseBackslash opt-out switch:

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

また、以前のバージョンの .NET Framework を対象とするものの、.NET Framework 4.6.1 以降のバージョンで実行されているアプリでは、アプリケーション構成ファイルの <runtime> セクションに構成設定を追加して、この動作を有効にすることができます。In addition, apps that target previous versions of the .NET Framework but are running on the .NET Framework 4.6.1 and later versions can opt in to this behavior by adding a configuration setting to the <runtime> section of the application configuration file. 次では、<runtime> セクションと有効に切り替える処理 Switch.System.IO.Compression.ZipFile.UseBackslash の両方を確認できます。The following shows both the <runtime> section and the Switch.System.IO.Compression.ZipFile.UseBackslash opt-in switch.

<runtime>
  <AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>
名前Name [値]Value
スコープScope エッジEdge
バージョンVersion 4.6.14.6.1
種類Type 再ターゲット中Retargeting

影響を受ける APIAffected APIs

タスク全体の CurrentCulture と CurrentUICulture のフローCurrentCulture and CurrentUICulture flow across tasks

説明Details

.NET Framework 4.6 より、非同期操作全体をフローする、スレッドの System.Threading.ExecutionContextSystem.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture が格納されます。その結果、System.Globalization.CultureInfo.CurrentCulture または System.Globalization.CultureInfo.CurrentUICulture に対する変更は、後で非同期実行されるタスクで反映されます。Beginning in the .NET Framework 4.6, System.Globalization.CultureInfo.CurrentCulture and System.Globalization.CultureInfo.CurrentUICulture are stored in the thread's System.Threading.ExecutionContext, which flows across asynchronous operations.This means that changes to System.Globalization.CultureInfo.CurrentCulture or System.Globalization.CultureInfo.CurrentUICulture will be reflected in tasks which are later run asynchronously. これは、すべての非同期タスクで System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture がリセットされていた、以前のバージョンの .NET Framework の動作とは異なります。This is different from the behavior of previous .NET Framework versions (which would reset System.Globalization.CultureInfo.CurrentCulture and System.Globalization.CultureInfo.CurrentUICulture in all asynchronous tasks).

提案される解決策Suggestion

この変更の影響を受けるアプリでは、非同期タスクの最初の操作として任意の System.Globalization.CultureInfo.CurrentCulture または System.Globalization.CultureInfo.CurrentUICulture を明示的に設定することで問題を回避できます。Apps affected by this change may work around it by explicitly setting the desired System.Globalization.CultureInfo.CurrentCulture or System.Globalization.CultureInfo.CurrentUICulture as the first operation in an async Task. あるいは、次の互換性スイッチを設定することで、System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture をフローしない以前の動作を選択できます。Alternatively, the old behavior (of not flowing System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) may be opted into by setting the following compatibility switch:

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

この問題は、.NET Framework 4.6.2 の WPF で修正されました。This issue has been fixed by WPF in .NET Framework 4.6.2. また、.NET Frameworks 4.6、4.6.1 では KB 3139549 を通じて修正されました。It has also been fixed in .NET Frameworks 4.6, 4.6.1 through KB 3139549. .NET Framework 4.6 以降を対象とするアプリケーションでは WPF アプリケーション (System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) の正しい動作が自動的に取得されます。これは、ディスパッチャー操作にわたって維持されます。Applications targeting .NET Framework 4.6 or later will automatically get the right behavior in WPF applications - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) would be preserved across Dispatcher operations.

名前Name Value
スコープScope マイナーMinor
バージョンVersion 4.64.6
種類Type 再ターゲット中Retargeting

影響を受ける APIAffected APIs

サフィックスの "Start" または "Stop" のみで ETW イベント名を使い分けることができないETW event names cannot differ only by a "Start" or "Stop" suffix

説明Details

.NET Framework 4.6 と4.6.1 では、2 つの Windows イベント トレーシング (ETW) のイベント名の違いが、"Start" または "Stop" のサフィックスのみである場合 (あるイベントの名前が LogUser で、別のイベントの名前が LogUserStart の場合など)、ランタイムにより ArgumentException がスローされます。In the .NET Framework 4.6 and 4.6.1, the runtime throws an ArgumentException when two Event Tracing for Windows (ETW) event names differ only by a "Start" or "Stop" suffix (as when one event is named LogUser and another is named LogUserStart). この場合、ランタイムはイベント ソースを作成できないため、ログ記録は生成できません。In this case, the runtime cannot construct the event source, which cannot emit any logging.

提案される解決策Suggestion

この例外を回避するには、"Start" または "Stop" のサフィックスだけが異なる 2 つのイベント名が存在しないようにします。この要件は、.NET Framework 4.6.2 以降では削除されています。ランタイムは、"Start" と "Stop" のサフィックスだけが異なるイベント名を明確に区別できます。To prevent the exception, ensure that no two event names differ only by a "Start" or "Stop" suffix.This requirement is removed starting with the .NET Framework 4.6.2; the runtime can disambiguate event names that differ only by the "Start" and "Stop" suffix.

名前Name [値]Value
スコープScope エッジEdge
バージョンVersion 4.64.6
種類Type 再ターゲット中Retargeting

ObsoleteAttribute は、WinMD のシナリオで、ObsoleteAttribute と DeprecatedAttribute の両方としてエクスポートするObsoleteAttribute exports as both ObsoleteAttribute and DeprecatedAttribute in WinMD scenarios

説明Details

Windows メタデータ ライブラリ (.winmd ファイル) を作成するとき、System.ObsoleteAttribute 属性は System.ObsoleteAttribute および Windows.Foundation.DeprecatedAttribute の両方としてエクスポートされます。When you create a Windows Metadata library (.winmd file), the System.ObsoleteAttribute attribute is exported as both System.ObsoleteAttribute and Windows.Foundation.DeprecatedAttribute.

提案される解決策Suggestion

System.ObsoleteAttribute 属性を使用する既存のソース コードを再コンパイルするとき、C++/CX または JavaScript からそのコードを使用するとき、警告が生成されることがあります。マネージド アセンブリのコードを記述するとき、System.ObsoleteAttributeWindows.Foundation.DeprecatedAttribute の両方を適用することはお勧めしません。ビルドで警告が生成されることがあります。Recompilation of existing source code that uses the System.ObsoleteAttribute attribute may generate warnings when consuming that code from C++/CX or JavaScript.We do not recommend applying both System.ObsoleteAttribute and Windows.Foundation.DeprecatedAttribute to code in managed assemblies; it may result in build warnings.

名前Name [値]Value
スコープScope エッジEdge
バージョンVersion 4.5.14.5.1
種類Type 再ターゲット中Retargeting

JITJIT

try 領域で IL ret が許可されないIL ret not allowed in a try region

説明Details

JIT64 Just-In-Time コンパイラとは異なり、(.NET Framework 4.6 で使用される) RyuJIT では、try 領域で IL ret 命令が許可されません。Unlike the JIT64 just-in-time compiler, RyuJIT (used in .NET Framework 4.6) does not allow an IL ret instruction in a try region. ECMA-335 仕様により try 領域から戻ることは許可されておらず、そうした IL を生成する既知のマネージド コンパイラはありません。Returning from a try region is disallowed by the ECMA-335 specification, and no known managed compiler generates such IL. ただし、JIT64 コンパイラは、リフレクション出力を使用して生成される場合にはこうした IL を実行します。However, the JIT64 compiler will execute such IL if it is generated using reflection emit.

提案される解決策Suggestion

try 領域に ret オペコードを含む IL をアプリが生成する場合、そのアプリでは .NET Framework 4.5 を対象にして以前の JIT を使用し、この中断を回避できます。If an app is generating IL that includes a ret opcode in a try region, the app may target .NET Framework 4.5 to use the old JIT and avoid this break. あるいは、try 領域の後に戻るように生成後の IL を更新できます。Alternatively, the generated IL may be updated to return after the try region.

名前Name Value
スコープScope エッジEdge
バージョンVersion 4.64.6
種類Type 再ターゲット中Retargeting

.NET Framework 4.6 の新しい 64 ビット JIT コンパイラNew 64-bit JIT compiler in the .NET Framework 4.6

説明Details

.NET Framework 4.6 以降では、Just-In-Time コンパイルには新しい 64 ビット JIT コンパイラが使用されます。Starting with the .NET Framework 4.6, a new 64-bit JIT compiler is used for just-in-time compilation. 場合によっては、予期しない例外がスローされるか、32 ビット コンパイラまたは以前の 64 ビット JIT コンパイラを使用してアプリを実行したときとは動作が異なる可能性があります。In some cases, an unexpected exception is thrown or a different behavior is observed than if an app is run using the 32-bit compiler or the older 64-bit JIT compiler. この変更は、32 ビット JIT コンパイラには影響しません。This change does not affect the 32-bit JIT compiler. 既知の相違には次のようなものがあります。The known differences include the following:

  • 特定の条件下では、最適化が有効なリリース ビルドの NullReferenceException がボックス化解除操作でスローされる場合があります。Under certain conditions, an unboxing operation may throw a NullReferenceException in Release builds with optimization turned on.
  • 場合によっては、大きなメソッド本文の実働コードの実行時に StackOverflowException がスローされることがあります。In some cases, execution of production code in a large method body may throw a StackOverflowException.
  • 特定の条件下では、メソッドに渡された構造体が、リリース ビルドの値の型ではなく、参照型として扱われます。Under certain conditions, structures passed to a method are treated as reference types rather than as value types in Release builds. この問題の兆候の 1 つは、コレクション内の個々の項目が予期しない順序で表示されることです。One of the manifestations of this issue is that the individual items in a collection appear in an unexpected order.
  • 特定の条件下では、最適化が有効な場合、高ビットが設定された UInt16 値が正しく比較されません。Under certain conditions, the comparison of UInt16 values with their high bit set is incorrect if optimization is enabled.
  • 特定の条件下では、特に、配列値の初期化中に、OpCodes.Initblk IL 命令でのメモリ初期化により、正しくない値でメモリが初期化される場合があります。Under certain conditions, particularly when initializing array values, memory initialization by the OpCodes.Initblk IL instruction may initialize memory with an incorrect value. その結果、ハンドルされない例外または正しくない出力が発生する場合があります。This can result either in an unhandled exception or incorrect output.
  • 特定のまれな条件下では、コンパイラの最適化が有効な場合に、条件付きのビット テストで正しくない Boolean 値が返されたり、例外がスローされたりすることがあります。Under certain rare conditions, a conditional bit test can return the incorrect Boolean value or throw an exception if compiler optimizations are enabled.
  • 特定の条件下では、if ステートメントを使用して、try ブロックの開始前と try ブロックの終了時の条件をテストし、同じ条件を catch または finally ブロックで評価する場合、新しい 64 ビット JIT コンパイラが、コードの最適化の際に catch または finally ブロックから if 条件を削除します。Under certain conditions, if an if statement is used to test for a condition before entering a try block and in the exit from the try block, and the same condition is evaluated in the catch or finally block, the new 64-bit JIT compiler removes the if condition from the catch or finally block when it optimizes code. その結果、catch または finally ブロックの if ステートメント内のコードは無条件で実行されます。As a result, code inside the if statement in the catch or finally block is executed unconditionally.

提案される解決策Suggestion

既知の問題の軽減策Mitigation of known issues
上記の問題が発生する場合は、次のいずれかの方法で解決できます。If you encounter the issues listed above, you can address them by doing any of the following:

  • .NET Framework 4.6.2 にアップグレードします。Upgrade to the .NET Framework 4.6.2. .NET Framework 4.6.2 に含まれている新しい 64 ビット コンパイラは、これらの既知の問題のそれぞれに対処します。The new 64-bit compiler included with the .NET Framework 4.6.2 addresses each of these known issues.

  • Windows Update を実行して、Windows のバージョンが最新のものであることを確認します。Ensure that your version of Windows is up to date by running Windows Update. .NET Framework 4.6 および 4.6.1 へのサービス更新により、ボックス化解除操作での NullReferenceException を除き、これらの問題のそれぞれに対処することができます。Service updates to the .NET Framework 4.6 and 4.6.1 address each of these issues except the NullReferenceException in an unboxing operation.

  • 古い 64 ビット JIT コンパイラでコンパイルします。Compile with the older 64-bit JIT compiler. この方法の詳細については、「その他の問題の軽減策」を参照してください。See the Mitigation of other issues section for more information on how to do this. その他の問題の軽減策Mitigation of other issues
    古い 64 ビット コンパイラと新しい 64 ビット JIT コンパイラでコンパイルされたコードの動作、またはアプリのデバッグ バージョンとリリース バージョン (両方とも新しい 64 ビット JIT コンパイラでコンパイル) の動作に違いが見られる場合は、次のようにして、古い 64 ビット JIT コンパイラでアプリをコンパイルすることができます。If you encounter any other difference in behavior between code compiled with the older 64-bit compiler and the new 64-bit JIT compiler, or between the debug and release versions of your app that are both compiled with the new 64-bit JIT compiler, you can do the following to compile your app with the older 64-bit JIT compiler:

  • アプリケーションごとに、アプリケーションの構成ファイルに < 要素を追加できます。On a per-application basis, you can add the < element to your application's configuration file. 次のように新しい 64 ビット JIT コンパイラでのコンパイルを無効にし、代わりに従来の 64 ビット JIT コンパイラを使用します。The following disables compilation with the new 64-bit JIT compiler and instead uses the legacy 64-bit JIT compiler.

    <?xml version ="1.0"?>
    <configuration>
      <runtime>
       <useLegacyJit enabled="1" />
      </runtime>
    </configuration>
    
  • ユーザーごとに、useLegacyJit という REG_DWORD 値をレジストリの HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework キーに追加できます。On a per-user basis, you can add a REG_DWORD value named useLegacyJit to the HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework key of the registry. 値を 1 にすると、従来の 64 ビット JIT コンパイラが有効になり、値を 0 にすると、従来の 64 ビット JIT コンパイラが無効になり、新しい 64 ビット JIT コンパイラが有効になります。A value of 1 enables the legacy 64-bit JIT compiler; a value of 0 disables it and enables the new 64-bit JIT compiler.

  • コンピューターごとに、useLegacyJit という名前の REG_DWORD 値をレジストリの HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework キーに追加できます。On a per-machine basis, you can add a REG_DWORD value named useLegacyJit to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework key of the registry. 値を 1 にすると、従来の 64 ビット JIT コンパイラが有効になり、値を 0 にすると、従来の 64 ビット JIT コンパイラが無効になり、新しい 64 ビット JIT コンパイラが有効になります。A value of 1 enables the legacy 64-bit JIT compiler; a value of 0 disables it and enables the new 64-bit JIT compiler. Microsoft Connect でバグを報告し、問題を弊社に知らせることもできます。You can also let us know about the problem by reporting a bug on Microsoft Connect.

名前Name Value
スコープScope エッジEdge
バージョンVersion 4.64.6
種類Type 再ターゲット中Retargeting

MSBuildMSBuild

ResolveAssemblyReference タスクは、正しくないアーキテクチャとの依存関係に関する警告を表示するようになりましたResolveAssemblyReference task now warns of dependencies with the wrong architecture

説明Details

タスクは警告 MSB3270 を生成します。これは参照または依存関係がアプリのアーキテクチャと一致しないことを示します。The task emits a warning, MSB3270, which indicates that a reference or any of its dependencies does not match the app's architecture. たとえば、AnyCPU オプションでコンパイルされたアプリに x86 参照が含まれる場合に発生します。For example, this occurs if an app that was compiled with the AnyCPU option includes an x86 reference. このようなシナリオは、実行時にアプリでエラーが起こった場合に発生することがあります (この場合は、アプリが x64 プロセスとして配置されている場合)。Such a scenario could result in an app failure at run time (in this case, if the app is deployed as an x64 process).

提案される解決策Suggestion

影響には 2 つの領域があります。There are two areas of impact:

  • 再コンパイルすると、アプリが MSBuild の以前のバージョンでコンパイルされたときには現れなかった警告が生成されます。Recompilation generates warnings that did not appear when the app was compiled under a previous version of MSBuild. ただし、警告はランタイム エラーの可能性のある原因を特定するため、調査と対処が必要です。However, because the warning identifies a possible source of runtime failure, it should be investigated and addressed.
  • 警告がエラーとして扱われると、アプリはコンパイルされません。If warnings are treated as errors, the app will fail to compile.
名前Name [値]Value
スコープScope マイナーMinor
バージョンVersion 4.5.14.5.1
種類Type 再ターゲット中Retargeting

ネットワーキングNetworking

証明書 EKU OID の検証Certificate EKU OID validation

説明Details

.NET Framework 4.6 以降、SslStream または ServicePointManager クラスで EKU (拡張キー使用法) の OID (オブジェクト識別子) が検証されます。Starting with .NET Framework 4.6, the SslStream or ServicePointManager classes perform enhanced key use (EKU) object identifier (OID) validation. EKU (拡張キー使用法) 拡張は、キーを使用するアプリケーションを示すオブジェクト識別子 (OID) の集まりです。An enhanced key usage (EKU) extension is a collection of object identifiers (OIDs) that indicate the applications that use the key. EKU OID 検証では、リモート証明書に意図している目的にかなった OID が与えられるようにリモート証明書コールバックが使用されます。EKU OID validation uses remote certificate callbacks to ensure that the remote certificate has the correct OIDs for the intended purpose.

提案される解決策Suggestion

この変更が望ましくない場合は、アプリ構成ファイルの `<AppContextSwitchOverrides> に次のスイッチを追加することで、証明書 EKU OID の検証を無効にできます。If this change is undesirable, you can disable certificate EKU OID validation by adding the following switch to the <AppContextSwitchOverrides> in the ` of your app configuration file:

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

重要

この設定は下位互換性のためにのみ提供されます。This setting is provided for backward compatibility only. それ以外の目的での使用はお勧めしません。Its use is otherwise not recommended.

名前Name [値]Value
スコープScope マイナーMinor
バージョンVersion 4.64.6
種類Type 再ターゲット中Retargeting

影響を受ける APIAffected APIs

System.Net.ServicePointManager と System.Net.Security.SslStream で TLS 1.0、1.1、1.2 プロトコルのみサポートOnly Tls 1.0, 1.1 and 1.2 protocols supported in System.Net.ServicePointManager and System.Net.Security.SslStream

説明Details

.NET Framework 4.6 から、ServicePointManager クラスと SslStream クラスには、Tls1.0、Tls1.1、Tls 1.2 という 3 つのプロトコルのいずれかを使用することのみが許可されます。Starting with the .NET Framework 4.6, the ServicePointManager and SslStream classes are only allowed to use one of the following three protocols: Tls1.0, Tls1.1, or Tls1.2. SSL3.0 プロトコルと RC4 の暗号化はサポートされていません。The SSL3.0 protocol and RC4 cipher are not supported.

提案される解決策Suggestion

推奨される軽減策はサーバー側のアプリを Tls1.0、Tls1.1、または Tls1.2 にアップグレードすることです。The recommended mitigation is to upgrade the sever-side app to Tls1.0, Tls1.1, or Tls1.2. これが現実的でない場合、またはクライアント アプリが破損している場合は、次の 2 つの方法のいずれかにより、System.AppContext クラスを使用してこの機能を除外できます。If this is not feasible, or if client apps are broken, the System.AppContext class can be used to opt out of this feature in either of two ways:

  • プログラムで System.AppContext の互換性スイッチを設定する (説明はこちらにあります)。By programmatically setting compat switches on the System.AppContext, as explained here.
  • app.config ファイルの <runtime> セクションに以下の行を追加する。By adding the following line to the <runtime> section of the app.config file:
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>
名前Name Value
スコープScope マイナーMinor
バージョンVersion 4.64.6
種類Type 再ターゲット中Retargeting

影響を受ける APIAffected APIs

TLS 1.x は既定で SCH_SEND_AUX_RECORD フラグを基になる SCHANNEL API に渡すTLS 1.x by default passes the SCH_SEND_AUX_RECORD flag to the underlying SCHANNEL API

説明Details

TLS 1.x を使用するとき、.NET Framework は基になる Windows SCHANNEL API に依存します。When using TLS 1.x, the .NET Framework relies on the underlying Windows SCHANNEL API. .NET Framework 4.6 以降、SCH_SEND_AUX_RECORD フラグは既定で SCHANNEL に渡されます。Starting with .NET Framework 4.6, the SCH_SEND_AUX_RECORD flag is passed by default to SCHANNEL. SCHANNEL によって、暗号化するデータが 2 つの別個のレコードに分割されます。1 つ目のレコードはシングル バイトで、2 つ目のレコードは n-1 バイトです。その結果、まれに、データがシングル レコードに置かれていると想定する既存サーバーとクライアントの間の通信が途切れることがあります。This causes SCHANNEL to split data to be encrypted into two separate records, the first as a single byte and the second as n-1 bytes.In rare cases, this breaks communication between clients and existing servers that make the assumption that the data resides in a single record.

提案される解決策Suggestion

この変更によって既存サーバーとの接続が途切れる場合、SCH_SEND_AUX_RECORD フラグの送信を無効にし、アプリ構成ファイルの <runtime> セクションで次のスイッチを <AppContextSwitchOverrides> 要素に追加することで、データを別個のレコードに分割しない、以前の動作に復元できます。If this change breaks communication with an existing server, you can disable sending the SCH_SEND_AUX_RECORD flag and restore the previous behavior of not splitting data into separate records by adding the following switch to the <AppContextSwitchOverrides> element in the <runtime> section of your app configuration file:

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

重要

この設定は下位互換性のためにのみ提供されます。This setting is provided for backward compatibility only. それ以外の目的での使用はお勧めしません。Its use is otherwise not recommended.

名前Name Value
スコープScope エッジEdge
バージョンVersion 4.64.6
種類Type 再ターゲット中Retargeting

影響を受ける APIAffected APIs

Visual Basic .NETVisual Basic .NET

VB.NET は、System.Windows Api の部分的な名前空間の修飾をサポートしなくなりましたVB.NET no longer supports partial namespace qualification for System.Windows APIs

説明Details

.NET Framework 4.5.2 以降では、VB.NET プロジェクトは、部分的に修飾された名前空間で System.Windows API を指定できません。Beginning in .NET Framework 4.5.2, VB.NET projects cannot specify System.Windows APIs with partially-qualified namespaces. たとえば、Windows.Forms.DialogResult の参照は失敗します。For example, referring to Windows.Forms.DialogResult will fail. 代わりに、コードは、完全修飾名 (DialogResult) を参照するか、特定の名前空間をインポートして、System.Windows.Forms.DialogResult を参照する必要があります。Instead, code must refer to the fully qualified name (DialogResult) or import the specific namespace and refer simply to System.Windows.Forms.DialogResult.

提案される解決策Suggestion

System.Windows API を単純な名前で参照するか (および関連する名前空間をインポートする)、完全修飾名で参照するように、コードを更新する必要があります。Code should be updated to refer to System.Windows APIs either with simple names (and importing the relevant namespace) or with fully qualified names.

名前Name [値]Value
スコープScope マイナーMinor
バージョンVersion 4.5.24.5.2
種類Type 再ターゲット中Retargeting

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

null 引数を指定した CreateDefaultAuthorizationContext の呼び出しが変更されましたCalling CreateDefaultAuthorizationContext with a null argument has changed

説明Details

null の authorizationPolicies 引数を指定した System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) の呼び出しによって返される System.IdentityModel.Policy.AuthorizationContext の実装が、.NET Framework 4.6 で変更されました。The implementation of the System.IdentityModel.Policy.AuthorizationContext returned by a call to the System.IdentityModel.Policy.AuthorizationContext.CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) with a null authorizationPolicies argument has changed its implementation in the .NET Framework 4.6.

提案される解決策Suggestion

まれに、カスタム認証を使用する WCF アプリの動作に違いが生じる可能性があります。In rare cases, WCF apps that use custom authentication may see behavioral differences. このような場合は、2 つの方法のいずれかで、以前の動作を復元できます。In such cases, the previous behavior can be restored in either of two ways:

  • 4.6 よりも前のバージョンの .NET Framework を対象とするようにアプリを再コンパイルする。Recompile your app to target an earlier version of the .NET Framework than 4.6. IIS でホストされるサービスでは、<httpRuntime targetFramework="x.x"> の要素を使用して、以前のバージョンの .NET Framework を対象とするようにします。For IIS-hosted services, use the <httpRuntime targetFramework="x.x"> element to target an earlier version of the .NET Framework.

  • app.config ファイルの <appSettings> セクションに以下の行を追加します。Add the following line to the <appSettings> section of your app.config file:

    <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />
    
名前Name [値]Value
スコープScope マイナーMinor
バージョンVersion 4.64.6
種類Type 再ターゲット中Retargeting

影響を受ける APIAffected APIs

TransportWithMessageCredential セキュリティ モードを使用する WCF バインドWCF binding with the TransportWithMessageCredential security mode

説明Details

.NET Framework 4.6.1 より、TransportWithMessageCredential セキュリティ モードを使用する WCF バインドで署名のない非対称セキュリティ キーの "to" ヘッダーを含むメッセージを取得するように設定できるようになりました。既定では、署名のない "to" ヘッダーは .NET Framework 4.6.1 でも引き続き拒否されます。Beginning in the .NET Framework 4.6.1, WCF binding that uses the TransportWithMessageCredential security mode can be set up to receive messages with unsigned "to" headers for asymmetric security keys.By default, unsigned "to" headers will continue to be rejected in .NET Framework 4.6.1. これは、アプリケーションが Switch.System.ServiceModel.AllowUnsignedToHeader 構成スイッチを使用するこの新しい動作モードをオプトインした場合にのみ許可されます。They will only be accepted if an application opts into this new mode of operation using the Switch.System.ServiceModel.AllowUnsignedToHeader configuration switch.

提案される解決策Suggestion

これはオプトイン機能であるため、既存のアプリの動作に影響はないはずです。Because this is an opt-in feature, it should not affect the behavior of existing apps.
新しい動作を使用するかどうかを制御するには、次の構成設定を使用します。To control whether the new behavior is used or not, use the following configuration setting:

<runtime>
  <AppContextSwitchOverrides value="Switch.System.ServiceModel.AllowUnsignedToHeader=true" />
</runtime>
名前Name [値]Value
スコープScope 透明Transparent
バージョンVersion 4.6.14.6.1
種類Type 再ターゲット中Retargeting

影響を受ける APIAffected APIs

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

説明Details

X509 クレーム セットがその SAN フィールド内の複数の DNS エントリを含む証明書から初期化される場合は、.NET Framework 4.6.1 を対象とするアプリで、System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String)メソッドをすべての DNS エントリの claimType 引数と一致を試みます。 .NET Framework の以前のバージョンを対象とするアプリに対して、System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String)メソッドは claimType 引数と最後の DNS エントリのみを一致させようとしています。In apps that target the .NET Framework 4.6.1, if an X509 claim set is initialized from a certificate that has multiple DNS entries in its SAN field, the System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) method attempts to match the claimType argument with all the DNS entries.For apps that target previous versions of the .NET Framework, the System.IdentityModel.Claims.X509CertificateClaimSet.FindClaims(String, String) method attempts to match the claimType argument only with the last DNS entry.

提案される解決策Suggestion

この変更は、.NET Framework 4.6.1 を対象とするアプリケーションのみに影響します。This change only affects applications targeting the .NET Framework 4.6.1. この変更は、DisableMultipleDNSEntries 互換性スイッチで無効にできます (または、4.6.1 より前を対象としている場合は、有効にできます)。This change may be disabled (or enabled if targeting pre-4.6.1) with the DisableMultipleDNSEntries compatibility switch.

名前Name [値]Value
スコープScope マイナーMinor
バージョンVersion 4.6.14.6.1
種類Type 再ターゲット中Retargeting

影響を受ける APIAffected APIs

Windows フォームWindows Forms

Application.FilterMessage は、IMessageFilter.PreFilterMessage の再入可能な実装についてスローしなくなりましたApplication.FilterMessage no longer throws for re-entrant implementations of IMessageFilter.PreFilterMessage

説明Details

.NET Framework 4.6.1 以前は、System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) または System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter) (さらに DoEvents()) を呼び出すPreFilterMessage(Message)FilterMessage(Message) を呼び出すと、System.IndexOutOfRangeException が発生していました。Prior to the .NET Framework 4.6.1, calling FilterMessage(Message) with an PreFilterMessage(Message) which called System.Windows.Forms.Application.AddMessageFilter(IMessageFilter) or System.Windows.Forms.Application.RemoveMessageFilter(IMessageFilter) (while also calling DoEvents()) would cause an System.IndexOutOfRangeException.

.NET Framework 4.6.1 以降を対象とするアプリケーションでは、この例外がスローされなくなり、上述の再入可能フィルターを使用できます。Beginning with applications targeting the .NET Framework 4.6.1, this exception is no longer thrown, and re-entrant filters as described above may be used.

提案される解決策Suggestion

上述の再入可能な PreFilterMessage(Message) の動作に対して FilterMessage(Message) はスローされなくなります。Be aware that FilterMessage(Message) will no longer throw for the re-entrant PreFilterMessage(Message) behavior described above. これは、.NET Framework 4.6.1 をターゲットとするアプリケーションにのみ影響します。 .NET Framework 4.6.1 を対象とするアプリは、DontSupportReentrantFilterMessage 互換性スイッチを使用することによって、この変更を解除できます (または、以前の Framework をターゲットとしているアプリは、変更を受け入れることができます)。This only affects applications targeting the .NET Framework 4.6.1.Apps targeting the .NET Framework 4.6.1 can opt out of this change (or apps targeting older Frameworks may opt in) by using the DontSupportReentrantFilterMessage compatibility switch.

名前Name [値]Value
スコープScope エッジEdge
バージョンVersion 4.6.14.6.1
種類Type 再ターゲット中Retargeting

影響を受ける APIAffected APIs

DataObject.GetData は、データを UTF-8 として取得するようになりましたDataObject.GetData now retrieves data as UTF-8

説明Details

.NET Framework 4 を対象とするアプリまたは .NET Framework 4.5.1 以前のバージョンで実行されるアプリでは、DataObject.GetData は HTML 形式のデータを ASCII 文字列として取得します。For apps that target the .NET Framework 4 or that run on the .NET Framework 4.5.1 or earlier versions, DataObject.GetData retrieves HTML-formatted data as an ASCII string. 結果として、非 ASCII 文字 (ASCII コードが 0x7F よりも大きい文字) は 2 つのランダムな文字で表されます。As a result, non-ASCII characters (characters whose ASCII codes are greater than 0x7F) are represented by two random characters.

.NET Framework 4.5 以降を対象とするアプリ、および.NET Framework 4.5.2 で実行するアプリでは、DataObject.GetData は HTML 形式のデータを UTF-8 として取得し、これは、0x7F よりも大きい文字を正しく表します。For apps that target the .NET Framework 4.5 or later and run on the .NET Framework 4.5.2, DataObject.GetData retrieves HTML-formatted data as UTF-8, which represents characters greater than 0x7F correctly.

提案される解決策Suggestion

HTML 形式の文字列を使用するエンコーディングの問題に対する回避策 (例: クリップボードから取得した HTML 文字列を System.Text.UTF8Encoding.GetString(Byte[], Int32, Int32) に渡して明示的にエンコードすること) を実装し、アプリをバージョン 4 から 4.5 へ再ターゲットしている場合は、その回避策を削除する必要があります。何らかの理由で古い動作を必要とする場合は、アプリのターゲットを .NET Framework 4.0 にしてその動作を得ることができます。If you implemented a workaround for the encoding problem with HTML-formatted strings (for example, by explicitly encoding the HTML string retrieved from the Clipboard by passing it to System.Text.UTF8Encoding.GetString(Byte[], Int32, Int32)) and you're retargeting your app from version 4 to 4.5, that workaround should be removed.If the old behavior is needed for some reason, the app can target the .NET Framework 4.0 to get that behavior.

名前Name [値]Value
スコープScope エッジEdge
バージョンVersion 4.5.24.5.2
種類Type 再ターゲット中Retargeting

影響を受ける APIAffected APIs

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

説明Details

.NET Framework 4.6 以降を対象にしたアプリでは、Icon.ToBitmap メソッドで、PNG フレームを含んだアイコンを正常に Bitmap オブジェクトに変換できます。Starting with the apps that target the .NET Framework 4.6, the Icon.ToBitmap method successfully converts icons with PNG frames into Bitmap objects.

.NET Framework 4.5.2 以前のバージョンを対象としたアプリでは、Icon オブジェクトに PNG フレームが含まれていると、Icon.ToBitmap メソッドが ArgumentOutOfRangeException の例外をスローします。In apps that target the .NET Framework 4.5.2 and earlier versions, the Icon.ToBitmap method throws an ArgumentOutOfRangeException exception if the Icon object has PNG frames.

この変更は、.NET Framework 4.6 を対象として再コンパイルされたアプリのうち、Icon オブジェクトに PNG フレームが含まれている場合は ArgumentOutOfRangeException をスローするように特別な処理が実装されているアプリに影響します。This change affects apps that are recompiled to target the .NET Framework 4.6 and that implement special handling for the ArgumentOutOfRangeException that is thrown when an Icon object has PNG frames. .NET Framework 4.6 で実行している場合は、正常に変換が行われ、 ArgumentOutOfRangeException がスローされることはないため、例外ハンドラーは呼び出されません。When running under the .NET Framework 4.6, the conversion is successful, an ArgumentOutOfRangeException is no longer thrown, and therefore the exception handler is no longer invoked.

提案される解決策Suggestion

この動作に不都合がある場合は、次に示す要素を app.config ファイルの <runtime> セクションに追加することで、以前の動作を維持できます。If this behavior is undesirable, you can retain the previous behavior by adding the following element to the <runtime> section of your app.config file:

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

app.config ファイルに既に AppContextSwitchOverrides 要素が含まれている場合は、次に示すように新しい値を value 属性にマージする必要があります。If the app.config file already contains the AppContextSwitchOverrides element, the new value should be merged with the value attribute like this:

<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true;<previous key>=<previous value>" />
名前Name Value
スコープScope マイナーMinor
バージョンVersion 4.64.6
種類Type 再ターゲット中Retargeting

影響を受ける APIAffected APIs

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

タッチ対応システムで System.Windows.Input.PenContext.Disable を呼び出すと ArgumentException がスローされることがあるCalls to System.Windows.Input.PenContext.Disable on touch-enabled systems may throw an ArgumentException

説明Details

一部の状況では、タッチ対応システムで内部 System.Windows.Intput.PenContext.Disable メソッドを呼び出すと、再入に起因して未処理の T:System.ArgumentException がスローされることがあります。Under some circumstances, calls to the internal System.Windows.Intput.PenContext.Disable method on touch-enabled systems may throw an unhandled T:System.ArgumentException because of reentrancy.

提案される解決策Suggestion

この問題は、.NET Framework 4.7 では対処済みです。This issue has been addressed in the .NET Framework 4.7. 例外を防ぐには、.NET Framework 4.7 以降のバージョンの .NET Framework にアップグレードします。To prevent the exception, upgrade to a version of the .NET Framework starting with the .NET Framework 4.7.

名前Name [値]Value
スコープScope エッジEdge
バージョンVersion 4.6.14.6.1
種類Type 再ターゲット中Retargeting

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

説明Details

.NET Framework 4.6 以降では、System.Windows.Threading.Dispatcher 内で System.Globalization.CultureInfo.CurrentCulture または System.Globalization.CultureInfo.CurrentUICulture に加えられた変更は、そのディスパッチャー操作の終了時に失われます。Beginning in the .NET Framework 4.6, changes to System.Globalization.CultureInfo.CurrentCulture or System.Globalization.CultureInfo.CurrentUICulture made within a System.Windows.Threading.Dispatcher will be lost at the end of that dispatcher operation. 同様に、ディスパッチャー操作の外部で System.Globalization.CultureInfo.CurrentCulture または System.Globalization.CultureInfo.CurrentUICulture に加えられた変更は、その操作の実行時には反映されない場合があります。具体的に言うと、System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture の変更は、WPF UI コールバックと WPF アプリケーション内の他のコードの間でフローされない場合があるということです。これは、System.Threading.ExecutionContext の変更によるものであり、この変更により、.NET Framework 4.6 以降を対象とするアプリでは、System.Globalization.CultureInfo.CurrentCulture および System.Globalization.CultureInfo.CurrentUICulture は実行コンテキストに格納されます。Similarly, changes to System.Globalization.CultureInfo.CurrentCulture or System.Globalization.CultureInfo.CurrentUICulture made outside of a Dispatcher operation may not be reflected when that operation executes.Practically speaking, this means that System.Globalization.CultureInfo.CurrentCulture and System.Globalization.CultureInfo.CurrentUICulture changes may not flow between WPF UI callbacks and other code in a WPF application.This is due to a change in System.Threading.ExecutionContext that causes System.Globalization.CultureInfo.CurrentCulture and System.Globalization.CultureInfo.CurrentUICulture to be stored in the execution context beginning with apps targeting the .NET Framework 4.6. WPF ディスパッチャー操作は、操作を開始するために使用された実行コンテキストを格納して、操作が完了したときに、以前のコンテキストを復元します。WPF dispatcher operations store the execution context used to begin the operation and restore the previous context when the operation is completed. System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture がそのコンテキストの一部になったため、ディスパッチャー操作内でそれらに加えられた変更は、操作の外部では保持されません。Because System.Globalization.CultureInfo.CurrentCulture and System.Globalization.CultureInfo.CurrentUICulture are now part of that context, changes to them within a dispatcher operation are not persisted outside of the operation.

提案される解決策Suggestion

この変更による影響を受けるアプリは、望ましい System.Globalization.CultureInfo.CurrentCulture または System.Globalization.CultureInfo.CurrentUICulture をフィールドに格納し、すべてのディスパッチャー操作の本体 (UI イベントのコールバック ハンドラーを含む) で、正しい System.Globalization.CultureInfo.CurrentCultureSystem.Globalization.CultureInfo.CurrentUICulture が設定されていることを確認することによって回避できます。Apps affected by this change may work around it by storing the desired System.Globalization.CultureInfo.CurrentCulture or System.Globalization.CultureInfo.CurrentUICulture in a field and checking in all Dispatcher operation bodies (including UI event callback handlers) that the correct System.Globalization.CultureInfo.CurrentCulture and System.Globalization.CultureInfo.CurrentUICulture are set. または、この WPF の変更の元となっている ExecutionContext の変更は、.NET Framework 4.6 以降を対象とするアプリのみに影響するため、.NET Framework 4.5.2 を対象とすることによって、この問題を回避できます。また、.NET Framework 4.6 以降を対象とするアプリでは、以下の互換性スイッチを設定することでこの問題を回避することができます。Alternatively, because the ExecutionContext change underlying this WPF change only affects apps targeting the .NET Framework 4.6 or newer, this break can be avoided by targeting the .NET Framework 4.5.2.Apps that target .NET Framework 4.6 or later can also work around this by setting the following compatibility switch:

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

この問題は、.NET Framework 4.6.2 の WPF で修正されました。This issue has been fixed by WPF in .NET Framework 4.6.2. また、.NET Frameworks 4.6、4.6.1 では KB 3139549 を通じて修正されました。It has also been fixed in .NET Frameworks 4.6, 4.6.1 through KB 3139549. .NET Framework 4.6 以降を対象とするアプリケーションでは WPF アプリケーション (System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) の正しい動作が自動的に取得されます。これは、ディスパッチャー操作にわたって維持されます。Applications targeting .NET Framework 4.6 or later will automatically get the right behavior in WPF applications - System.Globalization.CultureInfo.CurrentCulture/System.Globalization.CultureInfo.CurrentUICulture) would be preserved across Dispatcher operations.

名前Name Value
スコープScope マイナーMinor
バージョンVersion 4.64.6
種類Type 再ターゲット中Retargeting

非パブリック セッターを持つプロパティへの双方向データ バインドはサポートされませんTwo-way data-binding to a property with a non-public setter is not supported

説明Details

パブリック セッターを持たないプロパティへのデータ バインドを試みることは、サポートされるシナリオではありません。Attempting to data bind to a property without a public setter has never been a supported scenario. .NET framework 4.5.1 以降では、このシナリオでは System.InvalidOperationException がスローされます。Beginning in the .NET Framework 4.5.1, this scenario will throw an System.InvalidOperationException. この新しい例外は、具体的に .NET Framework 4.5.1 を対象とするアプリでのみスローされることに注意してください。Note that this new exception will only be thrown for apps that specifically target the .NET Framework 4.5.1. アプリが .NET Framework 4.5 をターゲットとしている場合、この呼び出しは許されます。If an app targets the .NET Framework 4.5, the call will be allowed. アプリが特定のバージョンの .NET Framework をターゲットにしていない場合、バインドは一方向として扱われます。If the app does not target a particular .NET Framework version, the binding will be treated as one-way.

提案される解決策Suggestion

一方向のバインドを使用するか、プロパティのセッターを公開するように、アプリを更新する必要があります。The app should be updated to either use one-way binding, or expose the property's setter publicly. または、.NET Framework 4.5 をターゲットにすると、アプリは以前の動作を示すようになります。Alternatively, targeting the .NET Framework 4.5 will cause the app to exhibit the old behavior.

名前Name [値]Value
スコープScope マイナーMinor
バージョンVersion 4.5.14.5.1
種類Type 再ターゲット中Retargeting

影響を受ける APIAffected APIs

WPF レイアウトでの余白の丸め方の変更WPF layout rounding of margins has changed

説明Details

余白、境界線、およびそれらの内部の背景の丸め処理の方法が変更されました。The way in which margins are rounded and borders and the background inside of them has changed. この変更の結果、以下のようになります。As a result of this change:

  • 要素の幅または高さが最大で 1 ピクセル拡大または縮小することがあります。The width or height of elements may grow or shrink by at most one pixel.
  • オブジェクトの配置が最大で 1 ピクセル移動することがあります。The placement of an object can move by at most one pixel.
  • 中央揃えの要素が中央から最大で 1 ピクセル垂直まは水平方向にずれることがあります。Centered elements can be vertically or horizontally off center by at most one pixel. 既定では、この新しいレイアウトは .NET Framework の 4.6 を対象とするアプリに対してのみ有効となります。By default, this new layout is enabled only for apps that target the .NET Framework 4.6.

提案される解決策Suggestion

この変更では、DPI が高いときにWPF コントロールの一番右または一番下でクリッピングの発生を除去する傾向があるため、app.config ファイルの <runtime> セクションに次の行を追加することによって、以前のバージョンの .NET Framework を対象としながら .NET Framework 4.6 上で実行されているアプリがこの新しい動作を選択ことができます。Since this modification tends to eliminate clipping of the right or bottom of WPF controls at high DPIs, apps that target earlier versions of the .NET Framework but are running on the .NET Framework 4.6 can opt into this new behavior by adding the following line to the <runtime> section of the app.config file:

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

.NET Framework 4.6 を対象としながら以前のレイアウト アルゴリズムを使用して WPF コントロールをレンダリングする必要があるアプリの場合、app.config ファイルの <runtime> セクションに次の行を追加することによってそれを行うことができます。Apps that target the .NET Framework 4.6 but want WPF controls to render using the previous layout algorithm can do so by adding the following line to the <runtime> section of the app.config file:

<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=true" />'.
名前Name Value
スコープScope マイナーMinor
バージョンVersion 4.64.6
種類Type 再ターゲット中Retargeting

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

WorkflowDesigner.Load ではシンボル プロパティが削除されないWorkflowDesigner.Load doesn't remove symbol property

説明Details

ワークフロー デザイナーで .NET Framework 4.5 を対象とし、再ホストされた 3.5 ワークフローを Load() メソッドで読み込むと、ワークフローの保存中に System.Xaml.XamlDuplicateMemberException がスローされます。When targeting the .NET Framework 4.5 in the workflow designer, and loading a re-hosted 3.5 workflow with the Load() method, a System.Xaml.XamlDuplicateMemberException is thrown while saving the workflow.

提案される解決策Suggestion

このバグは、ワークフロー デザイナーで .NET Framework 4.5 を対象とするときにのみ現れるため、WorkflowDesigner.Context.Services.GetService&lt;DesignerConfigurationService&gt;().TargetFrameworkName を 4.0 の .NET Framework に設定することによって回避できます。あるいは、Load() の代わりに Load(String) メソッドを使用してワークフローを読み込むことで問題を回避できます。This bug only manifests when targeting .NET Framework 4.5 in the workflow designer, so it can be worked around by setting the WorkflowDesigner.Context.Services.GetService&lt;DesignerConfigurationService&gt;().TargetFrameworkName to the 4.0 .NET Framework.Alternatively, the issue may be avoided by using the Load(String) method to load the workflow, instead of Load().

名前Name [値]Value
スコープScope MajorMajor
バージョンVersion 4.54.5
種類Type 再ターゲット中Retargeting

影響を受ける APIAffected APIs

XML、XSLTXML, XSLT

無効なサロゲート ペアで XmlWriter がスローされるXmlWriter throws on invalid surrogate pairs

説明Details

.NET Framework 4.5.2 またはそれ以前のバージョンをターゲットとするアプリケーションの場合、例外フォールバック処理を使用した無効なサロゲート ペアを作成しても、必ず例外がスローされるとは限りません。For apps that target the .NET Framework 4.5.2 or previous versions, writing an invalid surrogate pair using exception fallback handling does not always throw an exception. .NET Framework 4.6 を対象とするアプリでは、無効なサロゲート ペアを作成しようとすると、System.ArgumentException がスローされます。For apps that target the .NET Framework 4.6, attempting to write an invalid surrogate pair throws an System.ArgumentException.

提案される解決策Suggestion

必要に応じて、.NET Framework 4.5.2 以前をターゲットとすることでこの問題を回避できます。If necessary, this break can be avoided by targeting the .NET Framework 4.5.2 or earlier. または、無効なサロゲート ペアを有効な xml に書き込む前に事前処理することもできます。Alternatively, invalid surrogate pairs can be pre-processed into valid xml prior to writing them.

名前Name Value
スコープScope エッジEdge
バージョンVersion 4.64.6
種類Type 再ターゲット中Retargeting

影響を受ける APIAffected APIs

XSD スキーマ検証は、複合キーが使用され、1 つのキーが空の場合に、一意制約の違反を正しく検出するようになりましたXSD Schema validation now correctly detects violations of unique constraints if compound keys are used and one key is empty

説明Details

.NET Framework 4.6 より前のバージョンには、キーの 1 つが空であった場合、XSD 検証で複合キーの一意制約が検出されないというバグがありました。Versions of the .NET Framework prior to 4.6 had a bug that caused XSD validation to not detect unique constraints on compound keys if one of the keys was empty. .NET Framework 4.6 で、この問題は修正されました。In the .NET Framework 4.6, this issue is corrected. このため、より正しい検証が行われるようになりますが、以前は検証されていた XML の一部が検証されない可能性もあります。This will result in more correct validation, but it may also result in some XML not validating which previously would have.

提案される解決策Suggestion

より緩やかな .NET Framework 4.0 の検証が必要な場合、検証アプリケーションはバージョン 4.5 (またはそれ以前) の .NET Framework をターゲットにできます。If looser .NET Framework 4.0 validation is needed, the validating application can target version 4.5 (or earlier) of the .NET Framework. ただし、.NET Framework 4.6 に再ターゲットするときには、コード レビューを行って、重複する複合キー (この問題の説明で述べられているように) の検証を予期していないことを確認する必要があります。When retargeting to .NET Framework 4.6, however, code review should be done to be sure that duplicate compound keys (as described in this issue's description) are not expected to validate.

名前Name Value
スコープScope エッジEdge
バージョンVersion 4.64.6
種類Type 再ターゲット中Retargeting