diff --git a/docs/visual-basic/misc/bc30954.md b/docs/visual-basic/misc/bc30954.md index 86ad61a15c0..82682761ad0 100644 --- a/docs/visual-basic/misc/bc30954.md +++ b/docs/visual-basic/misc/bc30954.md @@ -1,5 +1,5 @@ --- -title: 'メソッド & #39; に対して推定された型引数<procedurename>& #39; 結果、次のエラー:<errorlist>' +title: メソッド ' に対して推定された型引数<procedurename>' 結果、次のエラー:<errorlist> ms.date: 07/20/2015 ms.prod: .net ms.technology: @@ -20,7 +20,7 @@ ms.translationtype: MT ms.contentlocale: ja-JP ms.lasthandoff: 11/21/2017 --- -# メソッド & #39; に対して推定された型引数<procedurename>& #39; 結果、次のエラー:<errorlist> +# メソッド ' に対して推定された型引数<procedurename>' 結果、次のエラー:<errorlist> ジェネリック プロシージャが型引数を指定せずに呼び出され、推定された型引数は 1 つ以上の制約違反となります。 通常、ジェネリック型を呼び出す場合は、ジェネリック型が定義する型パラメーターごとに型引数を指定します。 型引数を指定しない場合、コンパイラは型パラメーターに渡される型を推定しようとします。 推定された型が 1 つ以上の型パラメーターの制約を満たすことができない場合、コンパイラはこのエラーを生成します。 diff --git a/docs/visual-basic/misc/bc31511.md b/docs/visual-basic/misc/bc31511.md index c663d515bd6..8876cfafb11 100644 --- a/docs/visual-basic/misc/bc31511.md +++ b/docs/visual-basic/misc/bc31511.md @@ -1,5 +1,5 @@ --- -title: '属性メンバー & #39;<membername>& #39; 宣言されていないため、代入式のターゲットにすることはできません (& a) #39 です。パブリック & #39;' +title: 属性メンバー '<membername>' 宣言されていないため、代入式のターゲットにすることはできません ' です。パブリック ' ms.date: 07/20/2015 ms.prod: .net ms.technology: @@ -20,7 +20,7 @@ ms.translationtype: MT ms.contentlocale: ja-JP ms.lasthandoff: 11/21/2017 --- -# 属性メンバー & #39;<membername>& #39; 宣言されていないため、代入式のターゲットにすることはできません (& a) #39 です。パブリック & #39; +# 属性メンバー '<membername>' 宣言されていないため、代入式のターゲットにすることはできません ' です。パブリック ' 属性のプライベート メンバーに値を代入しようとしました。 **エラー ID:** BC31511 diff --git a/docs/visual-basic/misc/bc32040.md b/docs/visual-basic/misc/bc32040.md index 6b97053d08e..2ace0a1ae0d 100644 --- a/docs/visual-basic/misc/bc32040.md +++ b/docs/visual-basic/misc/bc32040.md @@ -1,5 +1,5 @@ --- -title: '(& A) #39 です。<キーワード>& #39; 継承のオーバー ロード メンバーにキーワードが使用する以外の場合は使用しないでください、& #39;<キーワード>& #39 以外の場合はオーバー ロードするときに & #39;新しいサブ & #39;' +title: '' です。<キーワード>' 継承のオーバー ロード メンバーにキーワードが使用する以外の場合は使用しないでください、'<キーワード>' 以外の場合はオーバー ロードするときに '新しいサブ '' ms.date: 07/20/2015 ms.prod: .net ms.technology: @@ -20,7 +20,7 @@ ms.translationtype: MT ms.contentlocale: ja-JP ms.lasthandoff: 11/21/2017 --- -# (& A) #39 です。<キーワード>& #39; 継承のオーバー ロード メンバーにキーワードが使用する以外の場合は使用しないでください、& #39;<キーワード>& #39 以外の場合はオーバー ロードするときに & #39;新しいサブ & #39; +# ' です。<キーワード>' 継承のオーバー ロード メンバーにキーワードが使用する以外の場合は使用しないでください、'<キーワード>' 以外の場合はオーバー ロードするときに '新しいサブ ' コンストラクターが `Overloads` キーワードを使用して宣言されています。 Visual Basic は、コンストラクターの継承またはオーバーロードをサポートしていません。 diff --git a/docs/visual-basic/misc/bc33014.md b/docs/visual-basic/misc/bc33014.md index b63de7783b5..17234407560 100644 --- a/docs/visual-basic/misc/bc33014.md +++ b/docs/visual-basic/misc/bc33014.md @@ -1,5 +1,5 @@ --- -title: '演算子 & #39;<演算子>& #39; 1 つのパラメーターがあります。' +title: 演算子 '<演算子>' 1 つのパラメーターがあります。 ms.date: 07/20/2015 ms.prod: .net ms.technology: @@ -20,7 +20,7 @@ ms.translationtype: MT ms.contentlocale: ja-JP ms.lasthandoff: 11/21/2017 --- -# 演算子 & #39;<演算子>& #39; 1 つのパラメーターがあります。 +# 演算子 '<演算子>' 1 つのパラメーターがあります。 単項演算子がパラメーターなしで定義されているか、2 つ以上のパラメーターを使用して定義されています。 単項演算子には、必ず 1 つのパラメーターを指定する必要があります。 diff --git a/docs/visual-basic/misc/bc36557.md b/docs/visual-basic/misc/bc36557.md index a6489dc03cc..b7eff83222d 100644 --- a/docs/visual-basic/misc/bc36557.md +++ b/docs/visual-basic/misc/bc36557.md @@ -1,5 +1,5 @@ --- -title: '& #39 です。<membername>& #39; メンバー & #39; にない<contextname>& #39; が、現在のコンテキストに存在しません' +title: '' です。<membername>' メンバー ' にない<contextname>' が、現在のコンテキストに存在しません' ms.date: 07/20/2015 ms.prod: .net ms.technology: @@ -20,7 +20,7 @@ ms.translationtype: MT ms.contentlocale: ja-JP ms.lasthandoff: 11/21/2017 --- -# & #39 です。<membername>& #39; メンバー & #39; にない<contextname>& #39; が、現在のコンテキストに存在しません +# ' です。<membername>' メンバー ' にない<contextname>' が、現在のコンテキストに存在しません 匿名型の宣言で、存在しないメンバーの名前がプロパティに割り当てられています。 次の例では、 `.Prop1` と `.Prop2` が匿名型のプロパティです。 `.Prop3` を `.Prop2` に割り当てようとすると、エラーが発生します。 ```vb diff --git a/docs/visual-basic/misc/bc36561.md b/docs/visual-basic/misc/bc36561.md index 9a7071721b8..50a33161f74 100644 --- a/docs/visual-basic/misc/bc36561.md +++ b/docs/visual-basic/misc/bc36561.md @@ -1,5 +1,5 @@ --- -title: '拡張メソッド & #39;<methodname>& #39; 満たされることのない型制約があります' +title: 拡張メソッド '<methodname>' 満たされることのない型制約があります ms.date: 07/20/2015 ms.prod: .net ms.technology: @@ -20,7 +20,7 @@ ms.translationtype: MT ms.contentlocale: ja-JP ms.lasthandoff: 11/21/2017 --- -# 拡張メソッド & #39;<methodname>& #39; 満たされることのない型制約があります +# 拡張メソッド '<methodname>' 満たされることのない型制約があります このメソッドの型パラメーターは、満たされることが妨げられる仕方で相互作用します。 次の拡張メソッドは、例を示します。 ``` diff --git a/includes/backslash-mutex.md b/includes/backslash-mutex.md new file mode 100644 index 00000000000..6e796e96a06 --- /dev/null +++ b/includes/backslash-mutex.md @@ -0,0 +1 @@ +円記号 (\\) は、ミューテックス名の予約文字です。 ターミナル サーバー セッションのミューテックス使用に関する注記に指定されていない限り、ミューテックス名に円記号 (\\) を使用しないでください。 使用した場合、ミューテックスの名前が既存のファイルを表すとしても、 がスローされることがあります。 diff --git a/includes/compiler-options.md b/includes/compiler-options.md index 0f541400743..463cc491981 100644 --- a/includes/compiler-options.md +++ b/includes/compiler-options.md @@ -1,2 +1,2 @@ -すべてのコンパイル オプションは、**-option** および **/option** という 2 つの形で使用できます。 ドキュメントのみが表示オプション形式です。 +すべてのコンパイル オプションは、**-option** および **/option** という 2 つの形で使用できます。 このドキュメントでは、-option のみを示しています。 diff --git a/includes/core-preview-warning.md b/includes/core-preview-warning.md new file mode 100644 index 00000000000..534941e837e --- /dev/null +++ b/includes/core-preview-warning.md @@ -0,0 +1,2 @@ +> [!WARNING] +> このトピックは .NET Core SDK 2.0 Preview 2 を対象としています。 \ No newline at end of file diff --git a/includes/csharp-interactive-note.md b/includes/csharp-interactive-note.md new file mode 100644 index 00000000000..3cd89cd77a7 --- /dev/null +++ b/includes/csharp-interactive-note.md @@ -0,0 +1,3 @@ + +> [!NOTE] +> この記事の C# 例は、[Try.NET](https://try.dot.net) インライン コード ランナーとプレイグラウンドで実行されます。 **[実行]** ボタンを選択すると、対話型ウィンドウで例が実行されます。 コードを実行したら、コードを変更し、**[実行]** をもう一度選択して変更後のコードを実行できます。 変更後のコードが対話型ウィンドウで実行されるか、コンパイルできなかった場合、対話型ウィンドウにすべての C# コンパイラ エラー メッセージが表示されます。 diff --git a/includes/dotnet-restore-note-options.md b/includes/dotnet-restore-note-options.md new file mode 100644 index 00000000000..a3b4e407b96 --- /dev/null +++ b/includes/dotnet-restore-note-options.md @@ -0,0 +1,4 @@ +> [!NOTE] +> .NET Core 2.0 以降、[`dotnet restore`](~/docs/core/tools/dotnet-restore.md) を実行する必要がなくなりました。`dotnet build` や `dotnet run` のような、復元を必要とするあらゆるコマンドによって暗黙的に実行されるためです。 [Visual Studio Team Services の継続的インテグレーション ビルド](/vsts/build-release/apps/aspnet/build-aspnet-core)など、明示的な復元が合理的となる一部のシナリオや、復元の時刻を明示的に制御する必要があるビルド システムでは、引き続き有効なコマンドとなります。 +> +> このコマンドには `dotnet restore` オプションを指定できますが、`--source` のように長い形式で指定する必要があります。 `-s` のような短い形式のオプションはサポートされていません。 \ No newline at end of file diff --git a/includes/immutable-nuget-short-md.md b/includes/immutable-nuget-short-md.md new file mode 100644 index 00000000000..db48f2cee4c --- /dev/null +++ b/includes/immutable-nuget-short-md.md @@ -0,0 +1 @@ +**NuGet パッケージ**: [System.Collections.Immutable](http://go.microsoft.com/fwlink/?LinkId=318047) ([変更できないコレクションの概要とインストール方法](/dotnet/api/system.collections.immutable#Remarks)) diff --git a/includes/interpolated-strings.md b/includes/interpolated-strings.md new file mode 100644 index 00000000000..88968dd8868 --- /dev/null +++ b/includes/interpolated-strings.md @@ -0,0 +1,3 @@ + +> [!IMPORTANT] +> **String.Format** メソッドを呼び出す、あるいは[複合書式指定文字列](~/docs/standard/base-types/composite-formatting.md)を使用する代わりに、お使いの言語でサポートされている場合、*挿入文字列*を使用できます。 挿入文字列は、*挿入式*が含まれている文字列です。 各挿入式は式の値によって解かれ、文字列が割り当てられるとき、結果文字列に含まれます。 詳細については、[文字列補間 (C# リファレンス)](~/docs/csharp/language-reference/tokens/interpolated.md) および[補間文字列 (Visual Basic リファレンス)](~/docs/visual-basic/programming-guide/language-features/strings/interpolated-strings.md) に関するページを参照してください。 diff --git a/includes/migration-guide/retargeting/adonet/dbparameterprecision-dbparameterscale-are-now-public-virtual-members.md b/includes/migration-guide/retargeting/adonet/dbparameterprecision-dbparameterscale-are-now-public-virtual-members.md new file mode 100644 index 00000000000..f9062d6d1ec --- /dev/null +++ b/includes/migration-guide/retargeting/adonet/dbparameterprecision-dbparameterscale-are-now-public-virtual-members.md @@ -0,0 +1,11 @@ +### DbParameter.Precision と DbParameter.Scale は、パブリック仮想メンバーになった + +| | | +|---|---| +|説明| および はパブリック仮想プロパティとして実装されます。 これらは、対応する明示的なインターフェイス実装、 と を置き換えます。| +|提案される解決策|ADO.NET データベース プロバイダーを再構築するとき、これらの違いにより、「override」キーワードが Precision および Scale プロパティに適用される必要があります。 これは、コンポーネントを再構築するときにのみ必要です。既存のバイナリは引き続き機能します。| +|スコープ|マイナー| +|Version|4.5.1| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/asp/aspnet-accessibility-improvements-net-471.md b/includes/migration-guide/retargeting/asp/aspnet-accessibility-improvements-net-471.md new file mode 100644 index 00000000000..b6f3eb8a31b --- /dev/null +++ b/includes/migration-guide/retargeting/asp/aspnet-accessibility-improvements-net-471.md @@ -0,0 +1,10 @@ +### .NET 4.7.1 の ASP.NET アクセシビリティ機能の強化 + +| | | +|---|---| +|説明|.NET Framework 4.7.1 以降、ASP.NET のお客様のサポートを改善する目的で、ASP.NET Web コントロールによる Visual Studio のアクセシビリティ テクノロジの処理方法が向上しています。 この機能強化には次の変更内容が含まれています。
  • [詳細の表示] ウィザードの [フィールドの追加] ダイアログや ListView ウィザードの [ListView の構成] ダイアログなど、コントロールで不足していた UI アクセシビリティ パターンを実装するための変更。
  • データ ページャー フィールド エディターなど、ハイ コントラスト モードでの表示を改善するための変更。
  • DataPager コントロールの [ページャーのフィールドを編集] ウィザードの [フィールド] ダイアログ、[ObjectContext の構成] ダイアログ、[データ ソースの構成] ウィザードの [Configure Data Selction]\(データの選択の構成\) ダイアログなど、キーボードの操作性を改善するための変更。
| +|提案される解決策|以上の変更を選択する方法と選択しない方法Visual Studio デザイナーの場合、.NET Framework 4.7.1 以降で実行しなければ、以上の変更から何の改善も得られません。 Web アプリケーションの場合、次のいずれかの手法をとることで、以上の変更によって機能が強化されます。
  • Visual Studio 2017 15.3 以降をインストールする。このバージョンからは既定で、次の項目にある AppContext スイッチで新しいアクセシビリティ機能に対応しています。
  • 下の例のように、devenv.exe.config ファイルの <runtime> セクションに Switch.UseLegacyAccessibilityFeatures AppContext スイッチを追加し、それを false に設定することで、以前のアクセシビリティ動作を無効にする。
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
...
<!-- AppContextSwitchOverrides value attribute is in the form of 'key1=true/false;key2=true/false'  -->
<AppContextSwitchOverrides value="...;Switch.UseLegacyAccessibilityFeatures=false" />
...
</runtime>
</configuration>
.NET Framework 4.7.1 以降を対象とするアプリケーションで以前のアクセシビリティ動作を残す場合、この AppContext スイッチを明示的に true に設定することで以前のアクセシビリティ機能を選択できます。| +|スコープ|マイナー| +|Version|4.7.1| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/asp/htmltextwriter-does-not-render-br-element-correctly.md b/includes/migration-guide/retargeting/asp/htmltextwriter-does-not-render-br-element-correctly.md new file mode 100644 index 00000000000..dc0baa1cc11 --- /dev/null +++ b/includes/migration-guide/retargeting/asp/htmltextwriter-does-not-render-br-element-correctly.md @@ -0,0 +1,11 @@ +### HtmlTextWriter で `
` 要素が正しく表示されない + +| | | +|---|---| +|説明|.NET Framework 4.6 以降では、 と を <BR /> 要素を指定して呼び出すと、<BR /> を 1 つだけ (2 つではなく) 正しく挿入します。| +|提案される解決策|アプリが余分な <BR /> タグに依存している場合は、 をもう一度呼び出す必要があります。 この動作の変更は、.NET Framework 4.6 以降を対象とするアプリにのみ影響するので、以前の動作を得るためには、以前のバージョンの .NET Framework を対象とするという方法もあります。| +|スコープ|エッジ| +|Version|4.6| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/asp/httpruntimeappdomainapppath-throws-nullreferenceexception.md b/includes/migration-guide/retargeting/asp/httpruntimeappdomainapppath-throws-nullreferenceexception.md new file mode 100644 index 00000000000..45cc491623b --- /dev/null +++ b/includes/migration-guide/retargeting/asp/httpruntimeappdomainapppath-throws-nullreferenceexception.md @@ -0,0 +1,11 @@ +### HttpRuntime.AppDomainAppPath で NullReferenceException がスローされる + +| | | +|---|---| +|説明|ランタイムによってスローされる、.NET Framework 4.6.2、T:System.NullReferenceException取得するときに、 P:System.Web.HttpRuntime.AppDomainAppPath null 文字を含む値です。 .NET Framework 4.6.1 と以前のバージョンでは、ランタイムによってスローされる、T:System.ArgumentNullExceptionです。| +|提案される解決策|次のいずれかでこの変更に対応できます。
  • アプリケーションが .NET Framework 4.6.2 で実行されている場合には T:System.NullReferenceException を処理します。
  • .NET Framework 4.7 にアップグレードします。以前の動作が復元され、T:System.ArgumentNullException がスローされます。
| +|スコープ|エッジ| +|Version|4.6.2| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/asp/machinekeyencode-machinekeydecode-methods-are-now-obsolete.md b/includes/migration-guide/retargeting/asp/machinekeyencode-machinekeydecode-methods-are-now-obsolete.md new file mode 100644 index 00000000000..11590302a85 --- /dev/null +++ b/includes/migration-guide/retargeting/asp/machinekeyencode-machinekeydecode-methods-are-now-obsolete.md @@ -0,0 +1,11 @@ +### MachineKey.Encode メソッドと MachineKey.Decode メソッドが廃止に + +| | | +|---|---| +|説明|これらのメソッドは今後使用しません。 これらのメソッドを呼び出すコードをコンパイルすると、コンパイラ警告が生成されます。| +|提案される解決策|別の方法として、 および を使用することをお勧めします。 または、ビルド警告を抑制するか、古いコンパイラを使用して警告を回避できます。 API は、まだサポートされています。| +|スコープ|マイナー| +|Version|4.5| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/asp/multi-line-aspnet-textbox-spacing-changed-when-using-antixssencoder.md b/includes/migration-guide/retargeting/asp/multi-line-aspnet-textbox-spacing-changed-when-using-antixssencoder.md new file mode 100644 index 00000000000..f7891f00e8b --- /dev/null +++ b/includes/migration-guide/retargeting/asp/multi-line-aspnet-textbox-spacing-changed-when-using-antixssencoder.md @@ -0,0 +1,10 @@ +### AntiXSSEncoder を使用するときの複数行の ASP.Net TextBox の間隔が変更 + +| | | +|---|---| +|説明|.NET Framework 4.0 では、 を使用する場合、ポストバックの複数行テキスト ボックスの行間に余分な行が挿入されました。 .NET Framework 4.5 では、これらの余分な改行は含まれませんが、web アプリが .NET 4.5 を対象としている場合に限ります。| +|提案される解決策|4.0 の Web アプリの対象を .NET 4.5 に変更すると、複数行テキスト ボックスが改善され、余分な改行が挿入されなくなります。 これが望ましくない場合は、.NET Framework 4.0 を対象とすることによって、アプリを .NET Framework 4.5 で実行するときにも以前の動作が可能です。| +|スコープ|マイナー| +|Version|4.5| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/asp/throttle-concurrent-requests-per-session.md b/includes/migration-guide/retargeting/asp/throttle-concurrent-requests-per-session.md new file mode 100644 index 00000000000..44ae1a916da --- /dev/null +++ b/includes/migration-guide/retargeting/asp/throttle-concurrent-requests-per-session.md @@ -0,0 +1,10 @@ +### セッションあたりの同時実行される要求のスロットル + +| | | +|---|---| +|説明|.NET Framework 4.6.2 以前の場合、ASP.NET は同じ Sessionid の要求を順番に実行します。ASP.NET は既定で常にクッキーを経由して Sessionid を発行します。 ページの応答に長い時間がかかる場合、ブラウザーの F5 を押すと、サーバーのパフォーマンスが大幅に低下します。 この修正プログラムでは、キューに置かれた要求を追跡し、特定の制限を超えたときに要求を終了するためのカウンターを追加しました。 既定値は 50 です。 制限に達すると、警告がイベント ログに記録され、HTTP 500 応答は IIS ログに記録される可能性があります。| +|提案される解決策|以前の動作を復元するには、次の設定を web.config ファイルに追加して、新しい動作を無効にできます。
<appSettings>
<add key="aspnet:RequestQueueLimitPerSession" value="2147483647"/>
</appSettings>
| +|スコープ|エッジ| +|Version|4.7| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/asp/webutilityhtmlencode-webutilityhtmldecode-round-trip-bmp-correctly.md b/includes/migration-guide/retargeting/asp/webutilityhtmlencode-webutilityhtmldecode-round-trip-bmp-correctly.md new file mode 100644 index 00000000000..eec4012fe45 --- /dev/null +++ b/includes/migration-guide/retargeting/asp/webutilityhtmlencode-webutilityhtmldecode-round-trip-bmp-correctly.md @@ -0,0 +1,11 @@ +### WebUtility.HtmlEncode と WebUtility.HtmlDecode で BMP が正常に往復する + +| | | +|---|---| +|説明|.NET Framework 4.5 を対象とするアプリケーションの場合、基本多言語面 (BMP: Basic Multilingual Plane) の外部にある文字は、 メソッドに渡されたときに正常に往復します。| +|提案される解決策|この変更は現在のアプリケーションに影響を与えないはずですが、元の動作に戻すには、<httpRuntime> 要素の targetFramework 属性を "4.5" 以外の文字列に設定します。 また、.NET Framework の対象バージョンに関係なくこの動作を制御するために unicodeEncodingConformance 構成要素の unicodeDecodingConformance 属性と <webUtility> 属性を設定することもできます。| +|スコープ|エッジ| +|Version|4.5| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/clickonce/apps-published-with-clickonce-that-use-sha-256-code-signing-certificate-may.md b/includes/migration-guide/retargeting/clickonce/apps-published-with-clickonce-that-use-sha-256-code-signing-certificate-may.md new file mode 100644 index 00000000000..89b2b94b00c --- /dev/null +++ b/includes/migration-guide/retargeting/clickonce/apps-published-with-clickonce-that-use-sha-256-code-signing-certificate-may.md @@ -0,0 +1,10 @@ +### SHA-256 コード署名証明書を使用する ClickOnce で発行されたアプリケーションは、Windows 2003 では失敗することがある + +| | | +|---|---| +|説明|この実行可能ファイルは SHA256 で署名されます。 以前は、コード署名証明書が SHA-1 か SHA-256 に関係なく、SHA 1 で署名されました。 この方法は、次の対象に適用されます。
  • Visual Studio 2012 以降でビルドされたすべてのアプリケーション。
  • .NET Framework 4.5 がインストールされているシステム上で、Visual Studio 2010 以前でビルドされたアプリケーション。
さらに、.NET Framework 4.5 以降が存在する場合、コンパイル対象となった .NET Framework のバージョンに関係なく、ClickOnce マニフェストはSHA-256 証明書の SHA 256 で署名されます。| +|提案される解決策|ClickOnce 実行可能ファイルの署名方法に関するこの変更は、Windows Server 2003 システムにのみ影響を及ぼします。これらのシステムには、KB 938397 をインストールする必要があります。アプリが .NET Framework 4.0 以前のバージョンをターゲットとしている場合でも、SHA-256 を使用したマニフェストの署名方法の変更により、.NET Framework 4.5 以降のバージョンに対するランタイム依存関係が導入されます。| +|スコープ|エッジ| +|Version|4.5| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/clickonce/clickonce-supports-sha-256-on-40-targeted-apps.md b/includes/migration-guide/retargeting/clickonce/clickonce-supports-sha-256-on-40-targeted-apps.md new file mode 100644 index 00000000000..b0e8ec0b402 --- /dev/null +++ b/includes/migration-guide/retargeting/clickonce/clickonce-supports-sha-256-on-40-targeted-apps.md @@ -0,0 +1,10 @@ +### 4.0 を対象とするアプリの ClickOnce が SHA-256 に対応 + +| | | +|---|---| +|説明|以前は、SHA-256 で署名された証明書が与えられた ClickOnce アプリには、アプリの対象が 4.0 の場合でも、.NET 4.5 以降が必要でした。 今回、SHA-256 で署名されている場合でも、4.0 対応の ClickOnce アプリを 4.0 で実行できるようになりました。| +|提案される解決策|この変更により、その依存関係がなくなったので、.NET Framework 4 以前のバージョンを対象とする ClickOnce アプリの署名に SAH-256 証明書が使用できるようになりました。| +|スコープ|マイナー| +|Version|4.6| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/core/aescryptoserviceprovider-decryptor-provides-reusable-transform.md b/includes/migration-guide/retargeting/core/aescryptoserviceprovider-decryptor-provides-reusable-transform.md new file mode 100644 index 00000000000..b45fb8fc2d1 --- /dev/null +++ b/includes/migration-guide/retargeting/core/aescryptoserviceprovider-decryptor-provides-reusable-transform.md @@ -0,0 +1,11 @@ +### AesCryptoServiceProvider の復号で変換が再利用可能に + +| | | +|---|---| +|説明|.NET Framework 4.6.2 以降を対象とするアプリでは、 の復号で変換を再利用できます。 の呼び出しの後、変換は初期化し直され、再利用することができます。 以前のバージョンの .NET Framework を対象とするアプリでは、 の呼び出しの後に、 を呼び出して、復号を再利用しようとすると、 をスローするか、破損しているデータが生成されます。| +|提案される解決策|この動作は想定済みであり、この変更の影響は最小限に抑えられているはずです。この変更の影響は前の動作に依存するアプリケーションは、そのアプリケーションの構成ファイルの <runtime> セクションに次の構成設定を追加して、この動作の使用を無効にすることができます。
<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=true"/>
</runtime>
また、以前のバージョンの .NET Framework を対象とするものの、.NET Framework 4.6.2 以降のバージョンの .NET Framework で実行されているアプリでは、そのアプリケーションの構成ファイルの <runtime> セクションに次の構成設定を追加して、この動作を有効にできます。
<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=false"/>
</runtime>
| +|スコープ|マイナー| +|Version|4.6.2| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/core/calls-claimsidentity-constructors.md b/includes/migration-guide/retargeting/core/calls-claimsidentity-constructors.md new file mode 100644 index 00000000000..e8b4aa9c42b --- /dev/null +++ b/includes/migration-guide/retargeting/core/calls-claimsidentity-constructors.md @@ -0,0 +1,11 @@ +### ClaimsIdentity コンストラクターを呼び出す + +| | | +|---|---| +|説明|.NET Framework 4.6.2 以降、 コンストラクターと パラメーターの組み合わせで プロパティが設定されるしくみに変更があります。 引数が オブジェクトで、その オブジェクトの プロパティが null ではない場合、 メソッドを使用して プロパティがアタッチされます。 Framework 4.6.1 以前のバージョンでは、 プロパティは既存の参照として付けられます。この変更によって、.NET Framework 4.6.2 以降、新しい オブジェクトの プロパティはコンストラクターの 引数の プロパティとは等しくなくなります。 .NET Framework 4.6.1 以前のバージョンでは、等しくなります。| +|提案される解決策|この動作が望ましくない場合、アプリケーション構成ファイルで Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity スイッチを true に設定して以前の動作を復元することができます。 この場合、web.config ファイルの <runtime> セクションに次を追加します。
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity=true" />
</runtime>
</configuration>
| +|スコープ|エッジ| +|Version|4.6.2| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/core/change-path-separator-character-fullname-property-ziparchiveentry-objects.md b/includes/migration-guide/retargeting/core/change-path-separator-character-fullname-property-ziparchiveentry-objects.md new file mode 100644 index 00000000000..2121bf14980 --- /dev/null +++ b/includes/migration-guide/retargeting/core/change-path-separator-character-fullname-property-ziparchiveentry-objects.md @@ -0,0 +1,11 @@ +### ZipArchiveEntry オブジェクトの FullName プロパティのパス区切り文字の変更 + +| | | +|---|---| +|説明|.NET Framework 4.6.1 以降のバージョンを対象とするアプリの場合、 メソッドのオーバーロードによって作成された オブジェクトの プロパティで、パスの区切り文字が円記号 ("") からスラッシュ ("/") に変更されました。 この変更によって、.NET の実装が [.ZIP ファイル形式の仕様](https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT)のセクション 4.4.17.1 に準拠するようになったほか、Windows 以外のシステムで ZIP アーカイブを解凍できるようになりました。以前のバージョンの .NET Framework を対象にするアプリで作成された ZIP ファイルを解凍するとき、Macintosh など、Windows 以外のオペレーティング システムでは、ディレクトリ構造を維持できません。 たとえば、Macintosh で、ディレクトリ パスとファイル名が円記号 ("") 文字で連結された名前を持つ一連のファイルを作成するとします。 その場合、圧縮解除されたファイルのディレクトリ構造は保持されません。| +|提案される解決策|この変更の影響。 .NET Framework の Api によって、Windows オペレーティング システムで圧縮解除した ZIP ファイルこれらの Api が、いずれかにスラッシュをシームレスに処理するために、名前空間が最小限に抑えるにする必要があります ("/") や円記号 ("\") のパス区切り文字として。この変更が望ましくない場合は、選択を解除する、構成設定を追加して、 [\<ランタイム >](~/docs/framework/configure-apps/file-schema/runtime/runtime-element.md)アプリケーション構成ファイルのセクションです。 次の例では、`` セクションと無効に切り替える処理 `Switch.System.IO.Compression.ZipFile.UseBackslash` の両方を確認できます。
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=true" />
</runtime>
また、以前のバージョンの .NET Framework を対象とするものの、.NET Framework 4.6.1 以降のバージョンで実行されているアプリでは、アプリケーション構成ファイルの [\](~/docs/framework/configure-apps/file-schema/runtime/runtime-element.md) セクションに構成設定を追加して、この動作を有効にすることができます。 次では、`` セクションと有効に切り替える処理 `Switch.System.IO.Compression.ZipFile.UseBackslash` の両方を確認できます。
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.Compression.ZipFile.UseBackslash=false" />
</runtime>
| +|スコープ|エッジ| +|Version|4.6.1| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/core/changes-path-normalization.md b/includes/migration-guide/retargeting/core/changes-path-normalization.md new file mode 100644 index 00000000000..84d627611bf --- /dev/null +++ b/includes/migration-guide/retargeting/core/changes-path-normalization.md @@ -0,0 +1,10 @@ +### パスの正規化の変更 + +| | | +|---|---| +|説明|.NET Framework 4.6.2 を対象とするアプリより、ランタイムによってパスを正規化する方法が変わりました。パスの正規化では、パスまたはファイルを識別する文字列を変更し、対象のオペレーティング システムの有効なパスに準拠するようにします。 通常、正規化では次のことを行います。
  • コンポーネントとディレクトリの区切り記号を正規化する。
  • 現在のディレクトリを相対パスに適用する。
  • パスの相対ディレクトリ (.) または親ディレクトリ (..) を評価する。
  • 指定した文字をトリミングする。
.NET Framework 4.6.2 を対象とするアプリより、パス正規化の次の変更が既定で有効になっています。
  • ランタイムはオペレーティング システムの [GetFullPathName](https://msdn.microsoft.com/library/windows/desktop/aa364963(v=vs.85).aspx) 関数に従って、パスを正規化します。
  • 正規化では、ディレクトリ セグメントの末尾 (ディレクトリ名の末尾のスペースなど) がトリミングされなくなりました。
  • \\.\ and, for file I/O APIs in mscorlib.dll, '\?'. も含め、デバイスのパス構文が完全に信頼されます。
  • The runtime does not validate device syntax paths.
  • The use of device syntax to access alternate data streams is supported.
These changes improve performance while allowing methods to access previously inaccessible paths. Apps that target the .NET Framework 4.6.1 and earlier versions but are running under the .NET Framework 4.6.2 or later are unaffected by this change.| +|提案される解決策|.NET Framework 4.6.2 以降を対象とするアプリの場合、アプリケーション構成ファイルの <runtime> セクションに次の行を追加することでこの変更を無効にし、従来の正規化を使用できます。
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=true" />
</runtime>
.NET Framework 4.6.1 以前を対象とするが、.NET Framework 4.6.2 以降で実行されるアプリの場合、アプリケーション構成ファイルの <runtime> セクションに次の行を追加することで、パス正規化の変更を有効にできます。
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false" />
</runtime>
| +|スコープ|マイナー| +|Version|4.6.2| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/core/currentculture-currentuiculture-flow-across-tasks.md b/includes/migration-guide/retargeting/core/currentculture-currentuiculture-flow-across-tasks.md new file mode 100644 index 00000000000..efd99d29cd7 --- /dev/null +++ b/includes/migration-guide/retargeting/core/currentculture-currentuiculture-flow-across-tasks.md @@ -0,0 +1,11 @@ +### タスク全体の CurrentCulture と CurrentUICulture のフロー + +| | | +|---|---| +|説明|.NET Framework 4.6 より、非同期操作全体をフローする、スレッドの に と が格納されます。その結果、 または に対する変更は、後で非同期実行されるタスクで反映されます。 これは、すべての非同期タスクで と がリセットされていた、以前のバージョンの .NET Framework の動作とは異なります。| +|提案される解決策|この変更の影響を受けるアプリでは、非同期タスクの最初の操作として任意の または を明示的に設定することで問題を回避できます。 あるいは、次の互換性スイッチを設定することで、/ をフローしない以前の動作を選択できます。
AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);
この問題は、.NET Framework 4.6.2 の WPF で修正されました。 また、.NET Frameworks 4.6、4.6.1 では [KB 3139549](https://support.microsoft.com/kb/3139549) を通じて修正されました。 .NET 4.6 以降を対象とするアプリケーションでは WPF アプリケーション (/) の正しい動作が自動的に取得されます。これは、ディスパッチャー操作にわたって維持されます。| +|スコープ|マイナー| +|Version|4.6| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/core/etw-event-names-cannot-differ-only-by-start-stop-suffix.md b/includes/migration-guide/retargeting/core/etw-event-names-cannot-differ-only-by-start-stop-suffix.md new file mode 100644 index 00000000000..7cbf4c44e8d --- /dev/null +++ b/includes/migration-guide/retargeting/core/etw-event-names-cannot-differ-only-by-start-stop-suffix.md @@ -0,0 +1,10 @@ +### サフィックスの "Start" または "Stop" のみで ETW イベント名を使い分けることができない + +| | | +|---|---| +|説明|.NET Framework 4.6 と 4.6.1 では、2 つの ETW (Windows イベント トレーシング) イベント名の違いがサフィックスの "Start" または "Stop" のみのとき (たとえば、あるイベントの名前が LogUser で、別のイベントの名前が LogUserStart のとき)、ランタイムによって がスローされます。 この場合、ランタイムはイベント ソースを作成できないため、ログ記録は生成できません。| +|提案される解決策|この例外を回避するには、サフィックスの "Start" または "Stop" でしか違いのないイベント名が存在しないようにします。この要件は .NET Framework 4.6.2 以降で削除されています。サフィックスの "Start" と "Stop" のみが異なるイベント名がランタイムによって区別されます。| +|スコープ|エッジ| +|Version|4.6| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/core/foreach-iterator-variable-now-scoped-within-iteration-so-closure-capturing.md b/includes/migration-guide/retargeting/core/foreach-iterator-variable-now-scoped-within-iteration-so-closure-capturing.md new file mode 100644 index 00000000000..352027c7d02 --- /dev/null +++ b/includes/migration-guide/retargeting/core/foreach-iterator-variable-now-scoped-within-iteration-so-closure-capturing.md @@ -0,0 +1,10 @@ +### foreach 反復子変数は、イテレーション内をスコープとするようになったため、クロージャ キャプチャのセマンティクスが (C#5 では) 異なります。 + +| | | +|---|---| +|説明|C#5 (Visual Studio 2012) 以降では、foreach 反復子変数は、イテレーション内をスコープとします。 このため、変数が foreach のクロージャに含まれないことに依存していたコードは機能しなくなります。 この変更による症状は、デリゲートに渡された反復子変数が、デリゲートが呼び出された時点での値ではなく、デリゲートの作成時点での値として扱われることです。| +|提案される解決策|理想的には、新しいコンパイラの動作を予期するように、コードを更新する必要があります。 古いセマンティクスが必要な場合は、反復子変数を、ループのスコープ外に明示的に配置される別の変数に置き換えることができます。| +|スコープ|Major| +|バージョン|4.5| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/core/iasyncresultcompletedsynchronously-property-must-be-correct-for-resulting.md b/includes/migration-guide/retargeting/core/iasyncresultcompletedsynchronously-property-must-be-correct-for-resulting.md new file mode 100644 index 00000000000..9425284d86d --- /dev/null +++ b/includes/migration-guide/retargeting/core/iasyncresultcompletedsynchronously-property-must-be-correct-for-resulting.md @@ -0,0 +1,11 @@ +### IAsyncResult.CompletedSynchronously プロパティが正しくなければ、結果のタスクは完了しません + +| | | +|---|---| +|説明|TaskFactory.FromAsync を呼び出すとき、 プロパティの実装が正しくなければ、結果のタスクは完了しません。 つまり、実装が同期的に完了した場合にのみ、このプロパティは true を返す必要があります。 以前は、このプロパティは確認されていませんでした。| +|提案される解決策|タスクが同期的に完了したときにのみ、 の実装が プロパティに true を返す場合、中断は発生しません。 ユーザーは、所有する の実装 (ある場合) を見直して、タスクが同期的に完了したかどうかを正しく評価することを確認する必要があります。| +|スコープ|エッジ| +|Version|4.5| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/core/listlttgtforeach-can-throw-exception-when-modifying-list-item.md b/includes/migration-guide/retargeting/core/listlttgtforeach-can-throw-exception-when-modifying-list-item.md new file mode 100644 index 00000000000..fc975cd981f --- /dev/null +++ b/includes/migration-guide/retargeting/core/listlttgtforeach-can-throw-exception-when-modifying-list-item.md @@ -0,0 +1,11 @@ +### List<T>.ForEach は、リスト項目を変更すると、例外をスローすることがあります。 + +| | | +|---|---| +|説明|.NET 4.5 から、 列挙子は、呼び出し元のコレクション内の要素が変更された場合、 例外をスローします。 以前は、この様な場合、例外はスローされませんでしたが、競合状態になることがありました。| +|提案される解決策|理想的には、安全な操作ではないため、要素の列挙中にリストを変更しないようにコードを修正する必要があります。 ただし、以前の動作に戻すには、アプリを .NET 4.0 向けにできます。| +|スコープ|エッジ| +|Version|4.5| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/core/long-path-support.md b/includes/migration-guide/retargeting/core/long-path-support.md new file mode 100644 index 00000000000..3443a846d2d --- /dev/null +++ b/includes/migration-guide/retargeting/core/long-path-support.md @@ -0,0 +1,10 @@ +### 長いパスのサポート + +| | | +|---|---| +|説明|以降とするアプリをターゲットとする .NET Framework 4.6.2、長いパス (最大 32 K の文字) がサポートされている、および 260 文字 (またはMAX_PATH) パスの長さの制限がなくなりました。 .NET Framework 4.6.2 を対象として再コンパイルされたアプリの場合は、コードをスローした以前のパス、 260 文字をスローがパスを超えたため、次の条件下でのみ。
  • パスの長さが (32,767) 文字を超えている。
  • オペレーティング システムが COR_E_PATHTOOLONG またはそれと同等のものを返す。
.NET Framework 4.6.1 以前を対象とするアプリの場合、パスが 260 文字を超えるたびにランタイムで自動的に がスローされます。| +|提案される解決策|.NET Framework 4.6.2 を対象とするアプリケーションの場合、長いパスが望ましくないときは、app.config ファイルの <runtime> セクションに次を追加することで長いパスのサポートを無効にできます。
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=true" />
</runtime>
以前のバージョンの .NET Framework を対象とするが、.NET Framework 4.6.2 以降で実行するアプリの場合、app.config ファイルの <runtime> セクションに次を追加することで長いパスのサポートを選択できます。
<runtime>
<AppContextSwitchOverrides value="Switch.System.IO.BlockLongPaths=false" />
</runtime>
| +|スコープ|マイナー| +|Version|4.6.2| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/core/obsoleteattribute-exports-both-deprecatedattribute-winmd-scenarios.md b/includes/migration-guide/retargeting/core/obsoleteattribute-exports-both-deprecatedattribute-winmd-scenarios.md new file mode 100644 index 00000000000..65c3d397f57 --- /dev/null +++ b/includes/migration-guide/retargeting/core/obsoleteattribute-exports-both-deprecatedattribute-winmd-scenarios.md @@ -0,0 +1,10 @@ +### ObsoleteAttribute は、WinMD のシナリオで、ObsoleteAttribute と DeprecatedAttribute の両方としてエクスポートする + +| | | +|---|---| +|説明|Windows メタデータ ライブラリ (.winmd ファイル) を作成するとき、 属性は および [Windows.Foundation.DeprecatedAttribute](https://docs.microsoft.com/uwp/api/windows.foundation.metadata.deprecatedattribute) の両方としてエクスポートされます。| +|提案される解決策| 属性を使用する既存のソース コードを再コンパイルするとき、C++/CX または JavaScript からそのコードを使用するとき、警告が生成されることがあります。マネージド アセンブリのコードを記述するとき、 と [Windows.Foundation.DeprecatedAttribute](https://docs.microsoft.com/uwp/api/windows.foundation.metadata.deprecatedattribute) の両方を適用することはお勧めしません。ビルドで警告が生成されることがあります。| +|スコープ|エッジ| +|Version|4.5.1| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/core/path-colon-checks-are-stricter.md b/includes/migration-guide/retargeting/core/path-colon-checks-are-stricter.md new file mode 100644 index 00000000000..12f392c7035 --- /dev/null +++ b/includes/migration-guide/retargeting/core/path-colon-checks-are-stricter.md @@ -0,0 +1,11 @@ +### パスのコロン確認が厳密化 + +| | | +|---|---| +|説明|.NET Framework 4.6.2 では、以前はサポートされていなかったパスをサポートするために (長さと形式の両方で) 数多くの変更が加えられました。 適切なドライブ区切り (コロン) 構文の確認がより正確に行われました。その結果、それ以前は許容されていた、ごく少数のパス API の一部の URI パスがブロックされました。| +|提案される解決策|影響を受ける API に URI を渡す場合、まず、文字列を正規のパスに変更します。
  • URL から手動でスキームを削除します (たとえば、URL から file:// を削除します)。
  • クラスに URI を渡し、 を使用します。
あるいは、Switch.System.IO.UseLegacyPathHandling AppContext スイッチを true に設定し、新しいパス正規化を無効にできます。| +|スコープ|エッジ| +|Version|4.6.2| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/core/systemuri-parsing-adheres-rfc-3987.md b/includes/migration-guide/retargeting/core/systemuri-parsing-adheres-rfc-3987.md new file mode 100644 index 00000000000..7a37c239e33 --- /dev/null +++ b/includes/migration-guide/retargeting/core/systemuri-parsing-adheres-rfc-3987.md @@ -0,0 +1,11 @@ +### System.Uri 解析が RFC 3987 に準拠 + +| | | +|---|---| +|説明|.NET 4.5 では、URI 解析がいくつかの点で変更されました。 ただし、これらの変更は .NET 4.5 を対象としたコードのみに影響することに注意してください。 バイナリが .NET 4.0 を対象としている場合、以前の動作が実行されます。 .NET 4.5 での URI 解析の変更は次のとおりです。
  • URI 解析は、RFC 3987 の最新の IRI 規則に従って、正規化と文字チェックを実行します。
  • Unicode 正規化フォーム C は、URI のホスト部分でのみ実行されます。
  • 無効な mailto: URI は、例外の原因になります。
  • パス セグメントの最後の末尾のドットが保存されるようになりました。
  • file:// URI は ? 文字をエスケープしません。
  • Unicode 制御文字の U+0080 から U+009F まではサポートされません。
  • コンマ文字 , または %2c は自動的にエスケープ解除されません。
| +|提案される解決策|古い .NET 4.0 URI 解析セマンティクスが必要な場合 (めったにありません)、.NET 4.0 を対象とすることによって使用できます。 これは、アセンブリで を使用することによって、または、[プロジェクトのプロパティ] ページの Visual Studio のプロジェクト システム UI によって実現できます。| +|スコープ|Major| +|バージョン|4.5| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/core/systemuriiswellformeduristring-method-returns-false-for-relative-uris-with.md b/includes/migration-guide/retargeting/core/systemuriiswellformeduristring-method-returns-false-for-relative-uris-with.md new file mode 100644 index 00000000000..c8865c8e669 --- /dev/null +++ b/includes/migration-guide/retargeting/core/systemuriiswellformeduristring-method-returns-false-for-relative-uris-with.md @@ -0,0 +1,11 @@ +### 最初のセグメントにコロン文字を含む相対 URI に対して System.Uri.IsWellFormedUriString メソッドが false を返す + +| | | +|---|---| +|説明|.NET Framework 4.5 より、 では、最初のセグメントに : を含む相対 URI が形式が正しくないとして処理されます。 これは .NET Framework 4.0 の 動作からの変更であり、RFC3986 に準拠する目的で行われました。| +|提案される解決策|この変更は (他の多くの URI 変更と同様に) .NET Framework 4.5 (以降) を対象とするアプリケーションにのみ影響を与えます。 以前の動作を維持するには、アプリの対象を .NET Framework 4.0 にします。 あるいは、 を呼び出す前に URI を調べて : 文字を探し、以前の動作が望ましければそれを削除し、正しい形式として処理させます。| +|スコープ|マイナー| +|Version|4.5| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/ef/building-an-entity-framework-edmx-with-visual-studio-2013-can-fail-error.md b/includes/migration-guide/retargeting/ef/building-an-entity-framework-edmx-with-visual-studio-2013-can-fail-error.md new file mode 100644 index 00000000000..45afc1099f2 --- /dev/null +++ b/includes/migration-guide/retargeting/ef/building-an-entity-framework-edmx-with-visual-studio-2013-can-fail-error.md @@ -0,0 +1,10 @@ +### Visual Studio 2013 で Entity Framework edmx をビルドすると、EntityDeploySplit または EntityClean タスクを使用している場合、エラー MSB4062 で失敗することがある + +| | | +|---|---| +|説明|MSBuild 12.0 ツール (Visual Studio 2013 に含まれる) は、MSBuild ファイルの位置を変更したため、古い Entity Framework のターゲット ファイルは無効になります。 その結果、EntityDeploySplit および EntityClean タスクは、Microsoft.Data.Entity.Build.Tasks.dll を見つけられないために失敗します。 このエラーは、ツールセット (MSBuild/VS) の変更によるものであり、.NET Framework の変更によるものではないことに注意してください。 開発者ツールをアップグレードしたときにのみ発生し、.NET Framework をアップグレード下だけでは発生しません。| +|提案される解決策|Entity Framework のターゲット ファイルは、.NET Framework 4.6 以降の新しい MSBuild レイアウトで機能するように修正されます。 このバージョンの Framework にアップグレードすることで、この問題は修正されます。 または、[この](http://stackoverflow.com/a/24249247/131944) 回避策を使用して、ターゲット ファイルに直接パッチを当てることができます。| +|スコープ|Major| +|Version|4.5.1| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/ef/entity-framework-version-must-match-net.md b/includes/migration-guide/retargeting/ef/entity-framework-version-must-match-net.md new file mode 100644 index 00000000000..8729241e0f4 --- /dev/null +++ b/includes/migration-guide/retargeting/ef/entity-framework-version-must-match-net.md @@ -0,0 +1,10 @@ +### Entity Framework バージョンは .NET Framework バージョンに一致する必要がある + +| | | +|---|---| +|説明|Entity Framework のバージョンは .NET Framework のバージョンに一致する必要があります。 .NET 4.5 には、Entity Framework 5 をお勧めします。 .NET 4.5 プロジェクトの EF 4.x に に関する既知の問題がいくつかあります。 .NET 4.5 では、別のアセンブリに移動したので、どの注釈を使用するのか判断するという問題があります。| +|提案される解決策|.NET Framework 4.5 の場合、Entity Framework 5 にアップグレードする| +|スコープ|Major| +|バージョン|4.5| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/jit/il-ret-not-allowed-try-region.md b/includes/migration-guide/retargeting/jit/il-ret-not-allowed-try-region.md new file mode 100644 index 00000000000..f6d78b0e711 --- /dev/null +++ b/includes/migration-guide/retargeting/jit/il-ret-not-allowed-try-region.md @@ -0,0 +1,10 @@ +### try 領域で IL ret が許可されない + +| | | +|---|---| +|説明|JIT64 Just-In-Time コンパイラとは異なり、(.NET 4.6 で使用される) RyuJIT では、try 領域で IL ret 命令が許可されません。 ECMA-335 仕様により try 領域から戻ることは許可されておらず、そうした IL を生成する既知のマネージド コンパイラはありません。 ただし、JIT64 コンパイラは、リフレクション出力を使用して生成される場合にはこうした IL を実行します。| +|提案される解決策|try 領域に ret オペコードを含む IL をアプリが生成する場合、そのアプリでは .NET 4.5 を対象にして以前の JIT を使用し、この中断を回避できます。 あるいは、try 領域の後に戻るように生成後の IL を更新できます。| +|スコープ|エッジ| +|Version|4.6| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/jit/new-64-bit-jit-compiler-net-framework-46.md b/includes/migration-guide/retargeting/jit/new-64-bit-jit-compiler-net-framework-46.md new file mode 100644 index 00000000000..eeec4f8bd07 --- /dev/null +++ b/includes/migration-guide/retargeting/jit/new-64-bit-jit-compiler-net-framework-46.md @@ -0,0 +1,10 @@ +### .NET Framework 4.6 の新しい 64 ビット JIT コンパイラ + +| | | +|---|---| +|説明|.NET Framework 4.6 以降では、Just-In-Time コンパイルには新しい 64 ビット JIT コンパイラが使用されます。 場合によっては、予期しない例外がスローされるか、32 ビット コンパイラまたは以前の 64 ビット JIT コンパイラを使用してアプリを実行したときとは動作が異なる可能性があります。 この変更は 32 ビット JIT コンパイラには影響しません。これまで次のような違いの存在が確認されています。
  • 特定の条件下では、最適化が有効なリリース ビルドの がボックス化解除操作でスローされる場合があります。
  • 場合によっては、大きなメソッド本文の実働コードの実行時に がスローされることがあります。
  • 特定の条件下では、メソッドに渡された構造体が、リリース ビルドの値の型ではなく、参照型として扱われます。 この問題の兆候の 1 つは、コレクション内の個々の項目が予期しない順序で表示されることです。
  • 特定の条件下では、最適化が有効な場合、高ビットが設定された 値が正しく比較されません。
  • 特定の条件下では、特に、配列値の初期化中に、 IL 命令でのメモリ初期化により、正しくない値でメモリが初期化される場合があります。 その結果、ハンドルされない例外または正しくない出力が発生する場合があります。
  • 特定のまれな条件下では、コンパイラの最適化が有効な場合に、条件付きのビット テストで正しくない 値が返されたり、例外がスローされたりすることがあります。
  • 特定の条件下では、if ステートメントを使用して、try ブロックの開始前と try ブロックの終了時の条件をテストし、同じ条件を catch または finally ブロックで評価する場合、新しい 64 ビット JIT コンパイラが、コードの最適化の際に catch または finally ブロックから if 条件を削除します。 その結果、catch または finally ブロックの if ステートメント内のコードは無条件で実行されます。
| +|提案される解決策|既知の問題の軽減策 上記の問題が発生する場合は、次のいずれかの方法で解決できます。
  • .NET Framework 4.6.2 にアップグレードします。 .NET Framework 4.6.2 に含まれている新しい 64 ビット コンパイラは、これらの既知の問題のそれぞれに対処します。
  • Windows Update を実行して、Windows のバージョンが最新のものであることを確認します。 .NET Framework 4.6 および 4.6.1 へのサービス更新により、ボックス化解除操作での を除き、これらの問題のそれぞれに対処することができます。
  • 古い 64 ビット JIT コンパイラでコンパイルします。 この方法の詳細については、「その他の問題の軽減策」を参照してください。
その他の問題の軽減策 古い 64 ビット コンパイラと新しい 64 ビット JIT コンパイラでコンパイルされたコードの動作、またはアプリのデバッグ バージョンとリリース バージョン (両方とも新しい 64 ビット JIT コンパイラでコンパイル) の動作に違いが見られる場合は、次のようにして古い 64 ビット JIT コンパイラでアプリをコンパイルできます。
  • アプリケーションごとに、アプリケーションの構成ファイルに [\](~/docs/framework/configure-apps/file-schema/runtime/uselegacyjit-element.md) 要素を追加できます。 次のように新しい 64 ビット JIT コンパイラでのコンパイルを無効にし、代わりに従来の 64 ビット JIT コンパイラを使用します。
<?xml version ="1.0"?>
<configuration>
<runtime>
<useLegacyJit enabled="1" />
</runtime>
</configuration>
  • ユーザーごとに、useLegacyJit という REG_DWORD 値をレジストリの HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework キーに追加できます。 値を 1 にすると、従来の 64 ビット JIT コンパイラが有効になり、値を 0 にすると、従来の 64 ビット JIT コンパイラが無効になり、新しい 64 ビット JIT コンパイラが有効になります。
  • コンピューターごとに、useLegacyJit という名前の REG_DWORD 値をレジストリの HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework キーに追加できます。 値を 1 にすると、従来の 64 ビット JIT コンパイラが有効になり、値を 0 にすると、従来の 64 ビット JIT コンパイラが無効になり、新しい 64 ビット JIT コンパイラが有効になります。
[Microsoft Connect](https://connect.microsoft.com/VisualStudio) でバグを報告し、問題を弊社に知らせることもできます。| +|スコープ|エッジ| +|Version|4.6| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/msbuild/resolveassemblyreference-task-now-warns-dependencies-with-wrong-architecture.md b/includes/migration-guide/retargeting/msbuild/resolveassemblyreference-task-now-warns-dependencies-with-wrong-architecture.md new file mode 100644 index 00000000000..6e0648ae69e --- /dev/null +++ b/includes/migration-guide/retargeting/msbuild/resolveassemblyreference-task-now-warns-dependencies-with-wrong-architecture.md @@ -0,0 +1,10 @@ +### ResolveAssemblyReference タスクは、正しくないアーキテクチャとの依存関係に関する警告を表示するようになりました + +| | | +|---|---| +|説明|タスクは警告 MSB3270 を生成します。これは参照または依存関係がアプリのアーキテクチャと一致しないことを示します。 たとえば、AnyCPU オプションでコンパイルされたアプリに x86 参照が含まれる場合に発生します。 このようなシナリオは、実行時にアプリでエラーが起こった場合に発生することがあります (この場合は、アプリが x64 プロセスとして配置されている場合)。| +|提案される解決策|影響には 2 つの領域があります。
  • 再コンパイルすると、アプリが MSBuild の以前のバージョンでコンパイルされたときには現れなかった警告が生成されます。 ただし、警告はランタイム エラーの可能性のある原因を特定するため、調査と対処が必要です。
  • 警告がエラーとして扱われると、アプリはコンパイルされません。
| +|スコープ|マイナー| +|Version|4.5.1| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/networking/certificate-eku-oid-validation.md b/includes/migration-guide/retargeting/networking/certificate-eku-oid-validation.md new file mode 100644 index 00000000000..fcb2282caf4 --- /dev/null +++ b/includes/migration-guide/retargeting/networking/certificate-eku-oid-validation.md @@ -0,0 +1,11 @@ +### 証明書 EKU OID の検証 + +| | | +|---|---| +|説明|.NET Framework 4.6 以降、 または クラスで EKU (拡張キー使用法) の OID (オブジェクト識別子) が検証されます。 EKU (拡張キー使用法) 拡張は、キーを使用するアプリケーションを示すオブジェクト識別子 (OID) の集まりです。 EKU OID 検証では、リモート証明書に意図している目的にかなった OID が与えられるようにリモート証明書コールバックが使用されます。| +|提案される解決策|この変更が望ましくない場合、アプリの構成ファイルの [`](~/docs/framework/configure-apps/file-schema/runtime/runtime-element.md) の [\](~/docs/framework/configure-apps/file-schema/runtime/appcontextswitchoverrides-element.md) に次のスイッチを追加することで証明書 EKU OID 検証を無効にできます。
<runtime>
<AppContextSwitchOverrides
value="Switch.System.Net.DontCheckCertificateEKUs=true" />
</runtime>
[!IMPORTANT] この設定は下位互換性のためにのみ提供されます。 それ以外の目的での使用はお勧めしません。
| +|スコープ|マイナー| +|Version|4.6| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/networking/default-value-servicepointmanagersecurityprotocol.md b/includes/migration-guide/retargeting/networking/default-value-servicepointmanagersecurityprotocol.md new file mode 100644 index 00000000000..cb3a5ee4a54 --- /dev/null +++ b/includes/migration-guide/retargeting/networking/default-value-servicepointmanagersecurityprotocol.md @@ -0,0 +1,11 @@ +### ServicePointManager.SecurityProtocol の既定値は SecurityProtocolType.System.Default + +| | | +|---|---| +|説明|.NET Framework 4.7 を対象とするアプリから、 プロパティの既定値が になります。 この変更により、SslStream をベースとする NET Framework ネットワーク API (FTP、HTTPS、SMTP など) は、.NET Framework によって定義されるハード コーディングされた値を使用する代わりに、オペレーティング システムから既定のセキュリティ プロトコルを継承できます。 既定値はオペレーティング システムと、システム管理者が実行するカスタム構成によって異なります。 Windows オペレーティング システムの各バージョンの既定の SChannel プロトコルに関する詳細については、「[Protocols in TLS/SSL (Schannel SSP)](https://msdn.microsoft.com/library/windows/desktop/mt808159.aspx)」 (TLS/SSL のプロトコル (Schannel SSP)) を参照してください。以前のバージョンの .NET Framework を対象とするアプリケーションの場合、 プロパティの既定値は、対象となる .NET Framework のバージョンに依存します。 詳細については、「.NET Framework 4.5.2 から 4.6 への移行に関する変更の再ターゲット」の「[ネットワーキング](~/docs/framework/migration-guide/retargeting/4.5.2-4.6.md#networking)」セクションを参照してください。| +|提案される解決策|この変更は、.NET Framework 4.7 以降のバージョンを対象とするアプリケーションに影響を与えます。システムの既定に依存せず、定義されているプロトコルを使用する場合、 プロパティの値を明示的に設定できます。この変更が望ましくない場合、構成設定をアプリケーション構成ファイルの [\](~/docs/framework/configure-apps/file-schema/runtime/runtime-element.md) セクションに追加し、変更を無効にできます。 次の例では、<runtime> セクションと無効に切り替える処理 Switch.System.Net.DontEnableSystemDefaultTlsVersions の両方を確認できます。
<runtime>
<AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=true" />
</runtime>
| +|スコープ|マイナー| +|Version|4.7| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/networking/only-tls-10-11-12-protocols-supported-systemnetservicepointmanager.md b/includes/migration-guide/retargeting/networking/only-tls-10-11-12-protocols-supported-systemnetservicepointmanager.md new file mode 100644 index 00000000000..c39f368778f --- /dev/null +++ b/includes/migration-guide/retargeting/networking/only-tls-10-11-12-protocols-supported-systemnetservicepointmanager.md @@ -0,0 +1,11 @@ +### System.Net.ServicePointManager と System.Net.Security.SslStream で TLS 1.0、1.1、1.2 プロトコルのみサポート + +| | | +|---|---| +|説明|.NET Framework 4.6 から、 クラスと クラスには、Tls1.0、Tls1.1、Tls 1.2 という 3 つのプロトコルのいずれかを使用することのみが許可されます。 SSL3.0 プロトコルと RC4 の暗号化はサポートされていません。| +|提案される解決策|推奨される軽減策はサーバー側のアプリを Tls1.0、Tls1.1、または Tls1.2 にアップグレードすることです。 これが現実的でない場合、またはクライアント アプリが破損している場合は、次の 2 つの方法のいずれかにより、 クラスを使用してこの機能を除外できます。
  1. プログラムで の互換性スイッチを設定する (説明は[こちら](http://blogs.msdn.com/b/dotnet/archive/2015/04/29/net-announcements-at-build-2015.aspx#dotnet46)にあります)
  2. app.config ファイルの <runtime> セクションに次の行を追加する: <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=true"/>
| +|スコープ|マイナー| +|Version|4.6| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/security/rsacng-now-correctly-loads-rsa-keys-non-standard-key-size.md b/includes/migration-guide/retargeting/security/rsacng-now-correctly-loads-rsa-keys-non-standard-key-size.md new file mode 100644 index 00000000000..e52d7864e37 --- /dev/null +++ b/includes/migration-guide/retargeting/security/rsacng-now-correctly-loads-rsa-keys-non-standard-key-size.md @@ -0,0 +1,11 @@ +### RSACng でキー サイズが非標準の RSA キーが正しく読み込まれるようになりました + +| | | +|---|---| +|説明|4.6.2 より前の .NET Framework バージョンでは、RSA 証明書のキー サイズが標準ではない顧客は、拡張メソッドの や でそのキーにアクセスできません。 "The requested key size is not supported (要求されたサイズのキーには対応していません)" というメッセージと共に がスローされます。 .NET Framework 4.6.2 では、この問題が修正されました。 同様に、 と で をスローすることなく非標準サイズのキーが処理されるようになりました。| +|提案される解決策|非標準サイズのキーが使用されるときに がスローされるという以前の動作に依存する例外処理ロジックがある場合、そのロジックを除くことを検討してください。| +|スコープ|エッジ| +|Version|4.6.2| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/security/signedxmlgetpublickey-returns-rsacng-on-net462-or-lightup-without.md b/includes/migration-guide/retargeting/security/signedxmlgetpublickey-returns-rsacng-on-net462-or-lightup-without.md new file mode 100644 index 00000000000..672559967cc --- /dev/null +++ b/includes/migration-guide/retargeting/security/signedxmlgetpublickey-returns-rsacng-on-net462-or-lightup-without.md @@ -0,0 +1,11 @@ +### 変更の対象を変更せず、SignedXml.GetPublicKey が net462 (または Light-Up) で RSACng を返す + +| | | +|---|---| +|説明|.NET Framework 4.6.2 より、 メソッドによって返されるオブジェクトの具象型が CryptoServiceProvider 実装から Cng 実装に変わりました。これは突然の変更ではなく、 certificate.PublicKey.Key の使用から、certificate.GetAnyPublicKey に転送する内部 の使用に実装が変わったためです。| +|提案される解決策|.NET Framework 4.7.1 で実行されるアプリから、アプリの構成ファイルの [runtime](~/docs/framework/configure-apps/file-schema/runtime/runtime-element.md) セクションに次の構成スイッチを追加することで、.NET Framework 4.6.1 以前のバージョンで既定で使用されていた CryptoServiceProvider 実装を使用できます。
<AppContextSwitchOverrides value="Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true" />
| +|スコープ|エッジ| +|Version|4.6.2| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/vb/vbnet-no-longer-supports-partial-namespace-qualification-for-systemwindows.md b/includes/migration-guide/retargeting/vb/vbnet-no-longer-supports-partial-namespace-qualification-for-systemwindows.md new file mode 100644 index 00000000000..e5b81bc4508 --- /dev/null +++ b/includes/migration-guide/retargeting/vb/vbnet-no-longer-supports-partial-namespace-qualification-for-systemwindows.md @@ -0,0 +1,10 @@ +### VB.NET は、System.Windows Api の部分的な名前空間の修飾をサポートしなくなりました + +| | | +|---|---| +|説明|.NET 4.5.2 以降では、VB.NET プロジェクトは、部分的に修飾された名前空間で System.Windows API を指定できません。 たとえば、Windows.Forms.DialogResult の参照は失敗します。 代わりに、コードは、完全修飾名 () を参照するか、特定の名前空間をインポートして、 を参照する必要があります。| +|提案される解決策|System.Windows API を単純な名前で参照するか (および関連する名前空間をインポートする)、完全修飾名で参照するように、コードを更新する必要があります。| +|スコープ|マイナー| +|Version|4.5.2| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/wcf/calling-createdefaultauthorizationcontext-with-null-argument-has-changed.md b/includes/migration-guide/retargeting/wcf/calling-createdefaultauthorizationcontext-with-null-argument-has-changed.md new file mode 100644 index 00000000000..5ee9f61f230 --- /dev/null +++ b/includes/migration-guide/retargeting/wcf/calling-createdefaultauthorizationcontext-with-null-argument-has-changed.md @@ -0,0 +1,11 @@ +### null 引数を指定した CreateDefaultAuthorizationContext の呼び出しが変更されました + +| | | +|---|---| +|説明|null の authorizationPolicies 引数を指定した の呼び出しによって返される の実装が、.NET Framework 4.6 で変更されました。| +|提案される解決策|まれに、カスタム認証を使用する WCF アプリの動作に違いが生じる可能性があります。 このような場合は、2 つの方法のいずれかで、以前の動作を復元できます。
  1. 4.6 よりも前のバージョンの .NET Framework を対象とするようにアプリを再コンパイルする。 IIS でホストされるサービスの場合、<httpRuntime targetFramework="x.x" /> 要素を使用して、以前のバージョンの .NET Framework を対象とする。
  2. app.config ファイルの <appSettings> セクションに以下の行を追加します: <add key="appContext.SetSwitch:Switch.System.IdentityModel.EnableCachedEmptyDefaultAuthorizationContext" value="true" />
| +|スコープ|マイナー| +|Version|4.6| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/wcf/deadlock-may-result-when-using-reentrant-services.md b/includes/migration-guide/retargeting/wcf/deadlock-may-result-when-using-reentrant-services.md new file mode 100644 index 00000000000..d396e1e950d --- /dev/null +++ b/includes/migration-guide/retargeting/wcf/deadlock-may-result-when-using-reentrant-services.md @@ -0,0 +1,11 @@ +### 再入可能なサービスを使用していると、デッドロックが発生する可能性がある + +| | | +|---|---| +|説明|サービスのインスタンスの実行が一度に 1 つのスレッドに制限される再入可能なサービスでは、デッドロックが発生します。 この問題が発生しやすいサービスのコードには、次の が含まれています。
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
| +|提案される解決策|この問題に対処するために、次の操作を行うことができます。
  • サービスの同時実行モードを または <System.ServiceModel.ConcurrencyMode.Multiple?displayProperty=nameWithType> に設定します。 例:
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)]
  • 最新の更新プログラムを .NET framework 4.6.2 にインストールするか、最新バージョンの .NET Framework にアップグレードします。 これにより、 の のフローが無効になります。 この動作は構成可能です。構成ファイルに次のアプリ設定を追加することと同じです。
<appSettings>
<add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>

The value of 'Switch.System.ServiceModel.DisableOperationContextAsyncFlow' should never be set to 'false' for Rentrant services.
| +|スコープ|マイナー| +|Version|4.6.2| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/wcf/improved-accessibility-for-some-net-sdk-tools.md b/includes/migration-guide/retargeting/wcf/improved-accessibility-for-some-net-sdk-tools.md new file mode 100644 index 00000000000..5eb6422702d --- /dev/null +++ b/includes/migration-guide/retargeting/wcf/improved-accessibility-for-some-net-sdk-tools.md @@ -0,0 +1,9 @@ +### 一部の .NET SDK ツールのアクセシビリティが強化されました + +| | | +|---|---| +|説明|.NET Framework SDK 4.7.1 では、svcconfigedit.exe と svctraceviewer.exe のツールが改善され、さまざまなアクセシビリティの問題が修正されました。 その問題のほとんどは、名前の未定義や、特定の UI の自動化パターンが正しく実装されていないといった軽微なものです。 このような問題は、多くのユーザーが認識しないものですが、スクリーン リーダーのような支援技術を使用するお客様はこれらの SDK ツールのアクセシビリティの強化を実感されるでしょう。 実際に、この修正によって、キーボード フォーカスの順序のような以前の動作がいくつか変更されます。これらのツールのアクセシビリティの修正をすべて取得するには、app.config ファイルを次のようにします。
<runtime>
<AppContextSwitchOverrides value="Switch.UseLegacyAccessibilityFeatures=false"/>
</runtime>
| +|スコープ|エッジ| +|Version|4.7.1| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/wcf/operationcontextcurrent-may-return-null-when-called-using-clause.md b/includes/migration-guide/retargeting/wcf/operationcontextcurrent-may-return-null-when-called-using-clause.md new file mode 100644 index 00000000000..38b321baaa1 --- /dev/null +++ b/includes/migration-guide/retargeting/wcf/operationcontextcurrent-may-return-null-when-called-using-clause.md @@ -0,0 +1,11 @@ +### OperationContext.Current が using 句で呼びされたときに null を返す場合がある + +| | | +|---|---| +|説明|次のすべての条件が満たされている場合は、 が null を返し、 が発生する可能性があります。
  • または を返すメソッドで プロパティの値を取得します。
  • using 句で オブジェクトをインスタンス化します。
  • using statement 内で プロパティの値を取得します。 例:
using (new OperationContextScope(OperationContext.Current))
{
OperationContext context = OperationContext.Current;      // OperationContext.Current is null.
// ...
}
| +|提案される解決策|この問題に対処するために、次の操作を行うことができます。
  • 次のようにコードを変更して、新しい null 以外の オブジェクトをインスタンス化します。
OperationContext ocx = OperationContext.Current;
using (new OperationContextScope(OperationContext.Current))
{
OperationContext.Current = new OperationContext(ocx.Channel);
// ...
}
  • 最新の更新プログラムを .NET framework 4.6.2 にインストールするか、最新バージョンの .NET Framework にアップグレードします。 これにより、 で のフローが無効になり、.NET Framework 4.6.1 以前のバージョンで WCF アプリケーションの動作が復元されます。 この動作は構成可能です。構成ファイルに次のアプリ設定を追加することと同じです。
<appSettings>
<add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="true" />
</appSettings>
この変更が望ましくなく、アプリケーションが操作コンテキスト間の実行コンテキスト フローに依存している場合は、次のようにそのフローを有効にできます。
<appSettings>
<add key="Switch.System.ServiceModel.DisableOperationContextAsyncFlow" value="false" />
</appSettings>
| +|スコープ|エッジ| +|Version|4.6.2| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/wcf/serialization-control-characters-with-datacontractjsonserializer-now.md b/includes/migration-guide/retargeting/wcf/serialization-control-characters-with-datacontractjsonserializer-now.md new file mode 100644 index 00000000000..2ab3b618a3d --- /dev/null +++ b/includes/migration-guide/retargeting/wcf/serialization-control-characters-with-datacontractjsonserializer-now.md @@ -0,0 +1,11 @@ +### DataContractJsonSerializer による制御文字のシリアル化が ECMAScript V6 および V8 対応に + +| | | +|---|---| +|説明|.NET framework 4.6.2 以前のバージョンでは、 で、ECMAScript V6 および V8 標準と互換性がある方法で \b、\f、\t などの一部の特殊制御文字がシリアル化されませんでした。 .NET Framework 4.7 以降、これらの制御文字のシリアル化は ECMAScript V6 および V8 と互換性があります。| +|提案される解決策|.NET Framework 4.7 を対象とするアプリの場合、この機能は既定で有効になっています。 この動作が望ましくない場合は、app.config または web.config ファイルの <runtime> セクションに次の行を追加して、この機能を無効にすることができます。
<runtime>
<AppContextSwitchOverrides value="Switch.System.Runtime.Serialization.DoNotUseECMAScriptV6EscapeControlCharacter=false" />
</runtime>
| +|スコープ|エッジ| +|Version|4.7| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/wcf/wcf-binding-with-transportwithmessagecredential-security-mode.md b/includes/migration-guide/retargeting/wcf/wcf-binding-with-transportwithmessagecredential-security-mode.md new file mode 100644 index 00000000000..5f9088be214 --- /dev/null +++ b/includes/migration-guide/retargeting/wcf/wcf-binding-with-transportwithmessagecredential-security-mode.md @@ -0,0 +1,11 @@ +### TransportWithMessageCredential セキュリティ モードを使用する WCF バインド + +| | | +|---|---| +|説明|.NET Framework 4.6.1 より、TransportWithMessageCredential セキュリティ モードを使用する WCF バインドで署名のない非対称のセキュリティ キーの "to" ヘッダーを含むメッセージを取得するように設定できるようになりました。既定では、署名のない "to" ヘッダーは .NET 4.6.1 でも引き続き拒否されます。 これは、アプリケーションが Switch.System.ServiceModel.AllowUnsignedToHeader 構成切り替えを使用するこの新しい動作モードをオプトインした場合にのみ許可されます。これはオプトイン機能であるため、既存のアプリの動作に影響はないはずです。| +|提案される解決策|これはオプトイン機能であるため、既存のアプリの動作に影響はないはずです。 新しい動作を使用するかどうかを制御するには、次の構成設定を使用します。
<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.AllowUnsignedToHeader=true" />
</runtime>
| +|スコープ|透明| +|Version|4.6.1| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/wcf/wcf-message-security-now-able-use-tls11-tls12.md b/includes/migration-guide/retargeting/wcf/wcf-message-security-now-able-use-tls11-tls12.md new file mode 100644 index 00000000000..137441eb47e --- /dev/null +++ b/includes/migration-guide/retargeting/wcf/wcf-message-security-now-able-use-tls11-tls12.md @@ -0,0 +1,10 @@ +### WCF メッセージ セキュリティで TLS1.1 と TLS1.2 が使用可能に + +| | | +|---|---| +|説明|.NET Framework 4.7 以降、顧客はアプリケーション構成設定を介し、SSL3.0 と TLS1.0 に加え、WCF メッセージ セキュリティで TLS1.1 または TLS1.2 を構成できます。| +|提案される解決策|.NET Framework 4.7 では、WCF メッセージ セキュリティの TLS1.1 と TLS1.2 のサポートは既定で無効になっています。 app.config または web.config ファイルの <runtime> セクションに次の行を追加することで有効にできます。
<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false" />
</runtime>
| +|スコープ|エッジ| +|Version|4.7| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/wcf/wcf-transport-security-supports-certificates-stored-using-cng.md b/includes/migration-guide/retargeting/wcf/wcf-transport-security-supports-certificates-stored-using-cng.md new file mode 100644 index 00000000000..0d44f352322 --- /dev/null +++ b/includes/migration-guide/retargeting/wcf/wcf-transport-security-supports-certificates-stored-using-cng.md @@ -0,0 +1,10 @@ +### WCF トランスポート セキュリティで CNG を使用して格納される証明書をサポート + +| | | +|---|---| +|説明|.NET Framework 4.6.2 を対象とするアプリ以降では、WCF トランスポート セキュリティでは、Windows 暗号化ライブラリ (CNG) を使用して格納される証明書がサポートされます。 このサポートは、指数の長さが 32 ビット以下の公開キーを持つ証明書に限定されます。 アプリケーションが対象 .NET Framework 4.6.2、ときにこの機能は既定でオンです。 .NET Framework の以前のバージョンで X509 を使用しようとすると、証明書を CSG のキー記憶域プロバイダーが例外をスローします。| +|提案される解決策|.NET Framework 4.6.1 以前を対象とするものの、.NET Framework 4.6.2 で実行されているアプリの場合、app.config または web.config ファイルの <runtime> セクションに次の行を追加することで、CNG 証明書のサポートを有効にできます。
<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableCngCertificates=false" />
</runtime>
次のコードを使用してプログラムで行うこともできます。
private const string DisableCngCertificates = @"Switch.System.ServiceModel.DisableCngCertificate";
AppContext.SetSwitch(disableCngCertificates, false);

Const DisableCngCertificates As String = "Switch.System.ServiceModel.DisableCngCertificates"
AppContext.SetSwitch(disableCngCertificates, False)
この変更のため、CNG 証明書の失敗で、セキュリティで保護された通信を開始する試行に依存する例外処理コードは、実行されなくなることに注意してください。| +|スコープ|マイナー| +|Version|4.6.2| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/wcf/x509certificateclaimsetfindclaims-considers-all-claimtypes.md b/includes/migration-guide/retargeting/wcf/x509certificateclaimsetfindclaims-considers-all-claimtypes.md new file mode 100644 index 00000000000..f0320214caa --- /dev/null +++ b/includes/migration-guide/retargeting/wcf/x509certificateclaimsetfindclaims-considers-all-claimtypes.md @@ -0,0 +1,11 @@ +### X509CertificateClaimSet.FindClaims は、すべての claimTypes を考慮します + +| | | +|---|---| +|説明|X509 クレーム セットがその SAN フィールド内の複数の DNS エントリを含む証明書から初期化される場合は、.NET Framework 4.6.1 を対象とするアプリで、メソッドをすべての DNS エントリの claimType 引数と一致を試みます。 .NET Framework の以前のバージョンを対象とするアプリに対して、メソッドは claimType 引数と最後の DNS エントリのみを一致させようとしています。| +|提案される解決策|この変更は、.NET Framework 4.6.1 を対象とするアプリケーションのみに影響します。 この変更は、[DisableMultipleDNSEntries](~/docs/framework/migration-guide/mitigation-x509certificateclaimset-findclaims-method.md#mitigation) 互換性スイッチで無効にできます (または、4.6.1 より前を対象としている場合は、有効にできます)。| +|スコープ|マイナー| +|Version|4.6.1| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/wf/accessibility-improvements-windows-workflow-foundation-wf-designer.md b/includes/migration-guide/retargeting/wf/accessibility-improvements-windows-workflow-foundation-wf-designer.md new file mode 100644 index 00000000000..439d3ec7e5c --- /dev/null +++ b/includes/migration-guide/retargeting/wf/accessibility-improvements-windows-workflow-foundation-wf-designer.md @@ -0,0 +1,10 @@ +### Windows Workflow Foundation (WF) ワークフロー デザイナーでのアクセシビリティの向上 + +| | | +|---|---| +|説明|Windows Workflow Foundation (WF) ワークフロー デザイナーは、アクセシビリティ テクノロジによって操作性が向上しています。 次のような改善点があります。
  • 一部のコントロールで、タブ オーダーが左から右、上から下に変更されます:
  • アクティビティの関連付けデータを設定するための関連付けの初期化ウィンドウ
  • 、、、および アクティビティのコンテンツ定義ウィンドウ
  • キーボードで利用できる機能が増えます:
  • アクティビティのプロパティを編集する際、プロパティ グループに初めてフォーカスを設定したときに、プロパティ グループをキーボードで折りたたむことができます。
  • 警告アイコンにキーボードでアクセスできるようになりました。
  • [プロパティ] ウィンドウの [その他のプロパティ] ボタンに、キーボードでアクセスできるようになりました。
  • キーボードを使って、ワークフロー デザイナーの [引数] および [変数] ウィンドウのヘッダー項目にアクセスできるようになりました。
  • 次のような場合に、フォーカスのある項目の可視性が向上しました:
  • ワークフロー デザイナーおよびアクティビティ デザイナーで使われているデータ グリッドへの行の追加。
  • および アクティビティ内のフィールド間の Tab 移動。
  • 変数または引数の既定値の設定
  • スクリーン リーダーが正しく認識できるようになりました:
  • ワークフロー デザイナーで設定されたブレークポイント。
  • 、、 アクティビティ。
  • アクティビティの内容。
  • アクティビティのターゲットの種類。
  • アクティビティの [例外] コンボ ボックスと [Finally] セクション。
  • メッセージング アクティビティの [メッセージの種類] コンボ ボックス、[関連付け初期化子の追加] ウィンドウのスプリッター、[コンテンツ定義] ウィンドウで、および [CorrelatesOn の定義] ウィンドウ (、、、および )。
  • ステート マシンの遷移と遷移先。
  • アクティビティの注釈とコネクタ。
  • アクティビティのコンテキスト (右クリック) メニュー。
  • プロパティ グリッドの、プロパティ値エディター、[検索のクリア] ボタン、[カテゴリ別] および [アルファベット順] の並べ替えボタン、[式エディター] ダイアログ。
  • ワークフロー デザイナーのズーム パーセンテージ。
  • および アクティビティの区切り記号。
  • アクティビティ。
  • ディクショナリ アクティビティの [型の選択] ウィンドウ (Microsoft.Activities.AddToDictionary<TKey,TValue>、Microsoft.Activities.RemoveFromDictionary<TKey,TValue> など)。
  • [.NET 型の参照と選択] ウィンドウ。
  • ワークフロー デザイナーでの階層リンク。
  • ハイ コントラスト テーマを選ぶと、要素間のコントラスト比の向上や、フォーカス要素に使われる選択ボックスの認識性の向上など、ワークフロー デザイナーとそのコントロールの表示について多くの点が向上していることがわかります。
| +|提案される解決策|ワークフロー デザイナーが再ホストされたアプリケーションでは、次のいずれかを行うことでこれらの変更を利用できます。
  • .NET Framework 4.7.1 を対象にしてアプリケーションを再コンパイルします。 これらのアクセシビリティの変更が既定で有効になります。
  • アプリケーションの対象が .NET Framework 4.7 以前であっても、.NET Framework 4.7.1 上で実行している場合は、次の [AppContext スイッチ](~/docs/framework/configure-apps/file-schema/runtime/appcontextswitchoverrides-element.md)を app.config ファイルの <runtime> セクションに追加して 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.UseLegacyAccessibilityFeatures=false" />
</runtime>
</configuration>
.NET Framework 4.7.1 以降を対象とするアプリケーションで以前のアクセシビリティ動作を残す場合、この AppContext スイッチを明示的に true に設定することで以前のアクセシビリティ機能を選択できます。| +|スコープ|マイナー| +|Version|4.7.1| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/wf/new-ambiguous-dispatcherinvoke-overloads-could-result-different-behavior.md b/includes/migration-guide/retargeting/wf/new-ambiguous-dispatcherinvoke-overloads-could-result-different-behavior.md new file mode 100644 index 00000000000..3d9a5e979a8 --- /dev/null +++ b/includes/migration-guide/retargeting/wf/new-ambiguous-dispatcherinvoke-overloads-could-result-different-behavior.md @@ -0,0 +1,11 @@ +### 新しい (あいまいな) Dispatcher.Invoke オーバーロードが、異なる動作になる可能性がある + +| | | +|---|---| +|説明|.NET Framework 4.5 では、 型のパラメーターを含む に新しいオーバーロードが追加されます。 既存のコードを再コンパイルすると、コンパイラは、 パラメーターを持つ Dispatcher.Invoke メソッドの呼び出しを、 パラメーターを持つ Dispatcher.Invoke メソッドの呼び出しとして解決することができます。 パラメーターを持つ Dispatcher.Invoke オーバーロードの呼び出しが パラメーターを持つ Dispatcher.Invoke オーバーロードの呼び出しとして解決された場合、次のような動作の差異が生じることがあります。
  • 例外が発生した場合、 イベントと イベントは発生しません。 代わりに、例外は イベントによって処理されます。
  • などの一部のメンバーの呼び出しは、操作が完了するまでブロックされます。
| +|提案される解決策|あいまいさ (および例外処理またはブロック動作における考えられる相違点) を回避するために、呼び出し元の Dispatcher.Invoke は Invoke 呼び出しの 2 番目のパラメーターとして空の object[] を渡すことで、.NET 4.0 メソッドのオーバーロードに解決されるようにできます。| +|スコープ|マイナー| +|Version|4.5| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/wf/some-workflow-drag-and-drop-apis-are-obsolete.md b/includes/migration-guide/retargeting/wf/some-workflow-drag-and-drop-apis-are-obsolete.md new file mode 100644 index 00000000000..0ceb07647cf --- /dev/null +++ b/includes/migration-guide/retargeting/wf/some-workflow-drag-and-drop-apis-are-obsolete.md @@ -0,0 +1,11 @@ +### 一部の WorkFlow ドラッグ アンド ドロップ API が廃止されました + +| | | +|---|---| +|説明|この WorkFlow ドラッグ アンド ドロップ API は廃止され、アプリが 4.5 向けにリビルドされた場合、コンパイラ警告が発生します。| +|提案される解決策|複数オブジェクトでの操作をサポートする新しい API を代わりに使用する必要があります。 または、ビルド警告を抑制するか、古いコンパイラを使用して警告を回避できます。 API は、まだサポートされています。| +|スコープ|マイナー| +|Version|4.5| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/wf/workflow-30-types-are-obsolete.md b/includes/migration-guide/retargeting/wf/workflow-30-types-are-obsolete.md new file mode 100644 index 00000000000..9df6fc92c31 --- /dev/null +++ b/includes/migration-guide/retargeting/wf/workflow-30-types-are-obsolete.md @@ -0,0 +1,10 @@ +### WorkFlow 3.0 タイプは廃止されました + +| | | +|---|---| +|説明|Windows Workflow Foundation (WWF) 3.0 API (System.Workflow 名前空間からのもの) は廃止されました。| +|提案される解決策|新しい WWF 4.0 API (System.Activities) を代わりに使用する必要があります。 新しい API の使用例は[ここ](~/docs/framework/windows-workflow-foundation/how-to-update-the-definition-of-a-running-workflow-instance.md)にあり、詳しいガイダンスは[ここ](http://blogs.msdn.com/b/workflowteam/archive/2012/02/08/deprecatingwf3.aspx)にあります。 または、WWF 3.0 API はまだサポートされているので、使用でき、ビルド時の警告は、警告を抑制することによって、または以前のコンパイラを使用することによって回避できます。| +|スコープ|Major| +|バージョン|4.5| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/wf/workflow-checksums-changed-from-md5-sha1.md b/includes/migration-guide/retargeting/wf/workflow-checksums-changed-from-md5-sha1.md new file mode 100644 index 00000000000..cf93570a0b0 --- /dev/null +++ b/includes/migration-guide/retargeting/wf/workflow-checksums-changed-from-md5-sha1.md @@ -0,0 +1,10 @@ +### ワークフローのチェックサムが MD5 から SHA1 に変更 + +| | | +|---|---| +|説明|Visual Studio によるデバッグをサポートするために、ワークフロー ランタイムによって、ハッシュ アルゴリズムを使用してワークフロー インスタンスのチェックサムが生成されます。 .NET Framework 4.6.2 以前のバージョンでは、ワークフロー チェックサムのハッシュで MD5 アルゴリズムが使用され、FIPS 対応システムで問題が発生していました。 .NET Framework 4.7 以降、アルゴリズムは SHA1 になります。 コードによってチェックサムが永続化されている場合、互換性がありません。| +|提案される解決策|チェックサム エラーに起因してコードでワークフロー インスタンスを読み込めない場合、AppContext スイッチ "Switch.System.Activities.UseMD5ForWFDebugger" を true に設定してみてください。下のコードをご覧ください。
System.AppContext.SetSwitch("Switch.System.Activities.UseMD5ForWFDebugger", true);
または、次のように構成します。
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Activities.UseMD5ForWFDebugger=true" />
</runtime>
</configuration>
| +|スコープ|マイナー| +|Version|4.7| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/wf/workflowdesignerload-doesnt-remove-symbol-property.md b/includes/migration-guide/retargeting/wf/workflowdesignerload-doesnt-remove-symbol-property.md new file mode 100644 index 00000000000..742b82d3b5d --- /dev/null +++ b/includes/migration-guide/retargeting/wf/workflowdesignerload-doesnt-remove-symbol-property.md @@ -0,0 +1,11 @@ +### WorkflowDesigner.Load ではシンボル プロパティが削除されない + +| | | +|---|---| +|説明|ワークフロー デザイナーで .NET Framework 4.5 を対象とし、再ホストされた 3.5 ワークフローを メソッドで読み込むと、ワークフローの保存中に がスローされます。| +|提案される解決策|このバグは、ワークフロー デザイナーで .NET Framework 4.5 を対象とするときにのみ現れるため、WorkflowDesigner.Context.Services.GetService<DesignerConfigurationService>().TargetFrameworkName を 4.0 の .NET Framework に設定することによって回避できます。あるいは、 の代わりに メソッドを使用してワークフローを読み込むことで問題を回避できます。| +|スコープ|Major| +|バージョン|4.5| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/winforms/accessibility-improvements-windows-forms-controls.md b/includes/migration-guide/retargeting/winforms/accessibility-improvements-windows-forms-controls.md new file mode 100644 index 00000000000..f2f94ff3c2e --- /dev/null +++ b/includes/migration-guide/retargeting/winforms/accessibility-improvements-windows-forms-controls.md @@ -0,0 +1,11 @@ +### Windows フォーム コントロールでのアクセシビリティの向上 + +| | | +|---|---| +|説明|Windows フォームはアクセシビリティ テクノロジによってユーザー サポートの動作が向上します。 次のような点が変更されます。
  • ハイ コントラスト モード中の表示が向上する変更。
  • プロパティ ブラウザーのエクスペリエンスが向上する変更。 プロパティ ブラウザーについては次のような点が向上します。
  • さまざまなドロップダウン選択ウィンドウを利用することでキーボード操作が便利になりました。
  • 不要なタブ ストップが減ります。
  • コントロールの種類の報告機能が改善されました。
  • ナレーターの動作が改善されました。
  • コントロールに不足している UI アクセシビリティ パターンを実装する変更。
| +|提案される解決策|以上の変更を選択する方法と選択しない方法 アプリケーションでこれらの変更を利用するには、.NET Framework 4.7.1 以降で実行する必要があります。 アプリケーションは、次のいずれかの方法でこれらの変更を利用できます。
  • .NET Framework 4.7.1 を対象にして再コンパイルします。 .NET Framework 4.7.1 以降を対象とする Windows フォーム アプリケーションでは、これらのアクセシビリティの変更が既定で有効になります。
  • 下の例のように、app.config ファイルの <runtime> セクションに次の [AppContext スイッチ](~/docs/framework/configure-apps/file-schema/runtime/appcontextswitchoverrides-element.md)を追加し、それを 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.UseLegacyAccessibilityFeatures=false" />
</runtime>
</configuration>
.NET Framework 4.7.1 以降を対象とするアプリケーションで以前のアクセシビリティ動作を残す場合、この AppContext スイッチを明示的に true に設定することで以前のアクセシビリティ機能を選択できます。UI オートメーションの概要については、「[UI オートメーションの概要](~/docs/framework/ui-automation/ui-automation-overview.md)」をご覧ください。UI オートメーション パターンとプロパティに対して追加されたサポート アクセシビリティ クライアントは、一般的なパブリックに記述された呼び出しパターンを使って、新しい WinForms アクセシビリティ機能を利用できます。 これらのパターンは、WinForms に固有ではありません。 たとえば、アクセシビリティ クライアントは、IAccessible インターフェイス (MAAS) の QueryInterface メソッドを呼び出して、IServiceProvider インターフェイスを取得することができます。 このインターフェイスを使用できる場合、クライアントはその QueryService メソッドを使って、IAccessibleEx インターフェイスを要求できます。 詳しくは、「[Using IAccessibleEx from a Client](https://msdn.microsoft.com/library/windows/desktop/dd561924.aspx)」(クライアントからの IAccessibleEx の使用) をご覧ください。 .NET Framework 4.7.1、IServiceProvider で始まると[IAccessibleEx](https://msdn.microsoft.com/library/windows/desktop/dd561898.aspx) (該当する場合) が WinForms ユーザー補助オブジェクトに対して使用します。 .NET Framework 4.7.1 は、次の UI オートメーション パターンやプロパティのサポートを追加します。
  • T:System.Windows.Forms.ToolStripSplitButton および T:System.Windows.Forms.ComboBox コントロールは、[展開/折りたたみパターン](~/docs/framework/ui-automation/implementing-the-ui-automation-expandcollapse-control-pattern.md)をサポートします。
  • T:System.Windows.Forms.ToolStripMenuItem コントロールの [ControlType](~/docs/framework/ui-automation/ui-automation-support-for-the-menubar-control-type.md) プロパティの値は です。
  • T:System.Windows.Forms.ToolStripItem コントロールは、[Name](xref:System.Windows.Automation.AutomationElement.NameProperty) プロパティと[展開/折りたたみパターン](~/docs/framework/ui-automation/implementing-the-ui-automation-expandcollapse-control-pattern.md)をサポートします。
  • T:System.Windows.Forms.ToolStripDropDownItem コントロールは、ドロップダウンが展開されたり折りたたまれたりしたときの StateChange と NameChange を示す をサポートします。
  • T:System.Windows.Forms.ToolStripDropDownButton コントロールの [ControlType](~/docs/framework/ui-automation/ui-automation-support-for-the-menubar-control-type.md) プロパティの値は です。
  • T:System.Windows.Forms.DataGridViewCheckBoxCell コントロールは[トグル パターン](xref:System.Windows.Automation.TogglePattern)をサポートします。
  • T:System.Windows.Forms.NumericUpDown および T:System.Windows.Forms.DomainUpDown コントロールは、[Name](xref:System.Windows.Automation.AutomationElement.NameProperty) をサポートし、[ControlType](~/docs/framework/ui-automation/ui-automation-support-for-the-spinner-control-type.md) は です。
PropertyGrid コントロールの向上 .NET Framework 4.7.1 では、PropertyBrowser コントロールが次のように向上します。
  • ユーザーが T:System.Windows.Forms.PropertyGrid コントロールに誤った値を入力すると表示されるエラー ダイアログの [詳細] ボタンは、[展開/折りたたみパターン](~/docs/framework/ui-automation/implementing-the-ui-automation-expandcollapse-control-pattern.md)、状態と名前の変更通知、および [ControlType](~/docs/framework/ui-automation/ui-automation-support-for-the-menubar-control-type.md) プロパティの値 をサポートします。
  • エラー ダイアログの [詳細] ボタンを展開すると表示されるメッセージ ウィンドウは、キーボードでアクセスできるようになり、エラー メッセージの内容をナレーターで読み上げることができます。
  • T:System.Windows.Forms.PropertyGrid コントロールの行の は、"Row" から "Cell" に変更されました。 セルは UIA の ControlType "DataItem" にマップし、適切なキーボード ショートカットとナレーターの読み上げをサポートすることができます。
  • T:System.Windows.Forms.PropertyGrid コントロールの P:System.Windows.Forms.PropertySort プロパティが F:System.Windows.Forms.PropertySory.Categorized に設定されているときにヘッダー項目を表す T:System.Windows.Forms.PropertyGrid コントロールの行は、[ControlType](~/docs/framework/ui-automation/ui-automation-support-for-the-menubar-control-type.md) プロパティの値が です。
  • T:System.Windows.Forms.PropertyGrid コントロールの P:System.Windows.Forms.PropertySort プロパティが F:System.Windows.Forms.PropertySory.Categorized に設定されているときにヘッダー項目を表す T:System.Windows.Forms.PropertyGrid コントロールの行は、[展開/折りたたみパターン](~/docs/framework/ui-automation/implementing-the-ui-automation-expandcollapse-control-pattern.md)をサポートします。
  • グリッドとその上にある ToolBar の間のキーボード ナビゲーションが向上します。 "Shift + Tab" キーを押すと、ToolBar 全体ではなく、ToolBar の最初のボタンが選択されます。
  • ハイ コントラスト モードで表示された T:System.Windows.Forms.PropertyGrid コントロールでは、P:System.Windows.Forms.PropertySort プロパティの現在の値に対応する ToolBar ボタンの周囲にフォーカス四角形が描画されます。
  • ハイ コントラスト モードで表示され、P:System.Windows.Forms.PropertySort プロパティが F:System.Windows.Forms.PropertySory.Categorized に設定された T:System.Windows.Forms.PropertyGrid コントロールでは、カテゴリ ヘッダーの背景がハイ コントラストの色で表示されます。
  • T:System.Windows.Forms.PropertyGrid コントロールでは、フォーカスが設定された ToolBar 項目と、P:System.Windows.Forms.PropertySort プロパティの現在の値を示す ToolBar 項目の区別が明確になります。 この修正は、ハイ コントラストの変更と、非ハイ コントラストのシナリオに対する変更で構成されます。
  • P:System.Windows.Forms.PropertySort プロパティの現在の値を示す T:System.Windows.Forms.PropertyGrid コントロールの ToolBar 項目は、[トグル パターン](xref:System.Windows.Automation.TogglePattern)をサポートします。
  • 配置ピッカーで選択された配置を区別するナレーターのサポートが向上します。
  • 空の T:System.Windows.Forms.PropertyGrid コントロールがフォームに表示されているとき、以前はフォーカスを設定されませんでしたが、現在はフォーカスを設定されるようになっています。
ハイ コントラスト テーマでの OS で定義された色の使用
  • P:System.Windows.Forms.Control.FlatStyle が (既定のスタイル) に設定された T:System.Windows.Forms.Button および T:System.Windows.Forms.CheckBox コントロールは、ハイ コントラスト テーマが選択されているときは OS で定義された色を使用するようになります。 以前は、テキストと背景の色はコントラストが同じで、見分けるのが困難でした。
  • P:System.Windows.Forms.Control.Enabled が false に設定された T:System.Windows.Forms.Button、T:System.Windows.Forms.CheckBox、T:System.Windows.Forms.RadioButton、T:System.Windows.Forms.Label、T:System.Windows.Forms.LinkLabel、および T:System.Windows.Forms.GroupBox は、以前は影付きの色を使ってハイ コントラスト テーマのテキストをレンダリングしており、背景に対するコントラストが低くなっていました。 現在は、これらのコントロールは OS によって定義された "無効なテキスト" の色を使うようになっています。 この修正は、P:System.Windows.Forms.Control.FlatStyle プロパティが F:System.Windows.Forms.FlatStyle.System 以外の値に設定されたコントロールに適用されます。 後者のコントロールは OS によってレンダリングされます。
  • T:System.Windows.Forms.DataGridView では、現在フォーカスが設定されているセルの内容を囲むように目に見える四角形がレンダリングされます。 以前は、特定のハイ コントラスト テーマではこれは見えませんでした。
  • P:System.Windows.Forms.ToolStripItem.Enabled プロパティが false に設定された T:System.Windows.Forms.ToolStripMenuItem コントロールは、OS によって定義された "無効なテキスト" の色を使うようになります。
  • P:System.Windows.Forms.ToolStripItem.Checked プロパティが true に設定された T:System.Windows.Forms.ToolStripMenuItem コントロールは、コントラストのあるシステム カラーで関連するチェック マークをレンダリングします。 以前は、チェック マークの色に十分なコントラストがなく、ハイ コントラスト テーマでは見えませんでした。
注: Windows 10 では、一部のハイ コントラストのシステム カラーの値が変更されています。 Windows フォームのフレームワークは、Win32 フレームワークに基づいています。 最も快適に利用するためには、最新版の Windows で実行し、テスト アプリケーションに app.manifest ファイルを追加して最新の OS 変更を選択し、次のコードのコメントを解除します。
<!-- Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
キーボード ナビゲーションの向上
  • T:System.Windows.Forms.ComboBox コントロールの P:System.Windows.Forms.ComboBox.DropDownStyle が F:System.Windows.Forms.DropDownStyle.DropDownList に設定されていて、フォームのタブ オーダーで最初のコントロールである場合、キーボードを使って親フォームが開かれると、コントロールにフォーカスの四角形が表示されます。 この変更の前は、キーボード フォーカスはこのコントロールに設定されましたが、フォーカス インジケーターはレンダリングされませんでした。
ナレーター サポートが改善されました
  • T:System.Windows.Forms.MonthCalendar コントロールに、以前は行われなかったナレーターによるコントロールの値の読み上げなど、コントロールにアクセスするための支援技術のサポートが追加されました。
  • T:System.Windows.Forms.CheckedListBox コントロールは、P:System.Windows.Forms.CheckState プロパティが変更されるとナレーターに通知するようになりました。 以前は、ナレーターは通知を受け取らなかったため、ユーザーは P:System.Windows.Forms.CheckState が更新されたことを教えられませんでした。
  • T:System.Windows.Forms.LinkLabel コントロールがコントロール内のテキストをナレーターに通知する方法が変更されました。 以前は、ナレーターはこのテキストを 2 回読み上げ、ユーザーには表示されなくても "&" 記号を実際のテキストとして読んでいました。 重複するテキストおよび不要な "&" 記号が、ナレーターの読み上げから除去されました。
  • T:System.Windows.Forms.DataGridViewCell コントロールの種類が、読み取り専用の状態をナレーターおよびその他の支援技術に正しくレポートするようになりました。
  • ナレーターは、[マルチドキュメント インターフェイス](~/docs/framework/winforms/advanced/multiple-document-interface-mdi-applications.md) アプリケーションの子ウィンドウのシステム メニューを読み上げられるようになりました。
  • ナレーターは、P:System.Windows.Forms.ToolStripItem.Enabled プロパティが false に設定された T:System.Windows.Forms.ToolStripMenuItem コントロールを読み上げられるようになりました。 以前のナレーターは、無効なメニュー項目にフォーカスを設定できず、内容を読み上げることができませんでした。
| +|スコープ|Major| +|Version|4.7.1| +|型|再ターゲット中| +|影響を受ける API|
  • [MonthCalendar.AccessibilityObject](xref:System.Windows.Forms.Control.AccessibilityObject)
| + diff --git a/includes/migration-guide/retargeting/winforms/dataobjectgetdata-now-retrieves-data-utf-8.md b/includes/migration-guide/retargeting/winforms/dataobjectgetdata-now-retrieves-data-utf-8.md new file mode 100644 index 00000000000..27c1b1b606c --- /dev/null +++ b/includes/migration-guide/retargeting/winforms/dataobjectgetdata-now-retrieves-data-utf-8.md @@ -0,0 +1,11 @@ +### DataObject.GetData は、データを UTF-8 として取得するようになりました + +| | | +|---|---| +|説明|.NET Framework 4 を対象とするアプリまたは .NET Framework 4.5.1 以前のバージョンで実行されるアプリでは、DataObject.GetData は HTML 形式のデータを ASCII 文字列として取得します。 その結果、非 ASCII 文字 (ASCII コードが 0x7F よりも大きい文字) は、次の 2 つのランダムな文字で表されます。 .NET Framework 4.5 またはそれ以降と .NET Framework 4.5.2 で実行を対象とするアプリのDataObject.GetData0x7F よりも大きい文字を正しく表している utf-8 として HTML 形式のデータを取得します。| +|提案される解決策|HTML 形式の文字列を使用するエンコーディングの問題に対する回避策 (例: クリップボードから取得した HTML 文字列を に渡して明示的にエンコードすること) を実装し、アプリをバージョン 4 から 4.5 へ再ターゲットしている場合は、その回避策を削除する必要があります。何らかの理由で古い動作を必要とする場合は、アプリのターゲットを .NET Framework 4.0 にしてその動作を得ることができます。| +|スコープ|エッジ| +|Version|4.5.2| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/winforms/encoderparameter-ctor-obsolete.md b/includes/migration-guide/retargeting/winforms/encoderparameter-ctor-obsolete.md new file mode 100644 index 00000000000..cd8ac5d51a8 --- /dev/null +++ b/includes/migration-guide/retargeting/winforms/encoderparameter-ctor-obsolete.md @@ -0,0 +1,11 @@ +### EncoderParameter ctor が廃止に + +| | | +|---|---| +|説明| コンストラクターは廃止され、使用された場合、ビルド警告が発生します。| +|提案される解決策|コンストラクター は引き続き動作しますが、.NET 4.5 のツールでコードを再コンパイルするときに古いビルド警告を回避するには、コンストラクター を代わりに使用する必要があります。| +|スコープ|マイナー| +|Version|4.5| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/winforms/icontobitmap-successfully-converts-icons-with-png-frames-into-bitmap-objects.md b/includes/migration-guide/retargeting/winforms/icontobitmap-successfully-converts-icons-with-png-frames-into-bitmap-objects.md new file mode 100644 index 00000000000..cc39d585e15 --- /dev/null +++ b/includes/migration-guide/retargeting/winforms/icontobitmap-successfully-converts-icons-with-png-frames-into-bitmap-objects.md @@ -0,0 +1,11 @@ +### PNG フレームを含んだアイコンが Icon.ToBitmap によって、Bitmap オブジェクトに正常に変換されます + +| | | +|---|---| +|説明|以降、.NET Framework 4.6 を対象とするアプリで、メソッドがビットマップ オブジェクトに PNG フレームを含んだアイコンを正常に変換します。 .NET Framework 4.5.2 および以前のバージョンを対象とするアプリで、メソッドがスローされます、アイコン オブジェクトに PNG フレームがある場合は例外です。この変更はアプリを .NET Framework 4.6 を対象として再コンパイルして、特別な処理を実装している、アイコン オブジェクトに PNG フレームがある場合にスローされます。 .NET Framework 4.6 で実行している場合は、正常に変換が行われ、 がスローされることはないため、例外ハンドラーは呼び出されません。| +|提案される解決策|この動作に不都合がある場合は、次に示す要素を app.config ファイルの <runtime> セクションに追加することで、以前の動作を維持できます。
<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true" />
app.config ファイルに既に AppContextSwitchOverrides 要素が含まれている場合は、次に示すように新しい値を value 属性にマージする必要があります。
<AppContextSwitchOverrides
value="Switch.System.Drawing.DontSupportPngFramesInIcons=true;<previous key>=<previous value>" />
| +|スコープ|マイナー| +|Version|4.6| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/winforms/incorrect-implementation-memberdescriptorequals.md b/includes/migration-guide/retargeting/winforms/incorrect-implementation-memberdescriptorequals.md new file mode 100644 index 00000000000..642c4a21639 --- /dev/null +++ b/includes/migration-guide/retargeting/winforms/incorrect-implementation-memberdescriptorequals.md @@ -0,0 +1,11 @@ +### MemberDescriptor.Equals の不適切な実装 + +| | | +|---|---| +|説明|"Equals" メソッドの元の実装では、比較対象のオブジェクトからの 2 種類の文字列プロパティを比較していました (カテゴリ名と説明文字列)。 この修正プログラムでは、最初のオブジェクトの "category" を 2 番目のオブジェクトの "category" と比較し、さらに "description" を "description" と比較します。 MemberDescriptorEqualsReturnsFalseIfEquivalent の構成値を true に設定すると、4.6.2 を対象としている場合に、新しい動作を無効にすることができます。この構成を false に設定すると、ターゲット フレームワークのバージョンが 4.6.2 よりも前の場合に、この修正プログラムを有効にするにすることができます。| +|提案される解決策|記述子が等しいときに false を返すことがある MemberDescriptor.Equals にアプリケーションが依存していて、.NET Framework のバージョン 4.6.2 を対象とするときは、いくつかのオプションがあります。
  1. Equals メソッドを実行することに加えて、"category" フィールドと "description" フィールドを手動で比較するようにコードを変更します。
  2. この変更を無効にするには、app.config ファイルに次の値を追加します。
<runtime>
<AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=true" />
</runtime>
アプリケーションが .NET Framework 4.6.1 以前のバージョンを対象にしている場合、この変更を無効にするには、app.config ファイルに次の値を追加することで互換性スイッチを false に設定します。
<runtime>
<AppContextSwitchOverrides value="Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=false" />
</runtime>
| +|スコープ|エッジ| +|Version|4.6.2| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/wpf/calls-systemwindowsinputpencontextdisable-on-touch-enabled-systems-may-throw.md b/includes/migration-guide/retargeting/wpf/calls-systemwindowsinputpencontextdisable-on-touch-enabled-systems-may-throw.md new file mode 100644 index 00000000000..7523a00a1e6 --- /dev/null +++ b/includes/migration-guide/retargeting/wpf/calls-systemwindowsinputpencontextdisable-on-touch-enabled-systems-may-throw.md @@ -0,0 +1,10 @@ +### タッチ対応システムで System.Windows.Input.PenContext.Disable を呼び出すと ArgumentException がスローされることがある + +| | | +|---|---| +|説明|一部の状況では、タッチ対応システムで内部 System.Windows.Intput.PenContext.Disable メソッドを呼び出すと、再入に起因して未処理の T:System.ArgumentException がスローされることがあります。| +|提案される解決策|この問題は、.NET Framework 4.7 では対処済みです。 例外を防ぐには、.NET Framework 4.7 以降のバージョンの .NET Framework にアップグレードします。| +|スコープ|エッジ| +|Version|4.6.1| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/wpf/currentculture-not-preserved-across-wpf-dispatcher-operations.md b/includes/migration-guide/retargeting/wpf/currentculture-not-preserved-across-wpf-dispatcher-operations.md new file mode 100644 index 00000000000..0db7a775d51 --- /dev/null +++ b/includes/migration-guide/retargeting/wpf/currentculture-not-preserved-across-wpf-dispatcher-operations.md @@ -0,0 +1,10 @@ +### CurrentCulture が、複数の WPF ディスパッチャー操作にわたって維持されない + +| | | +|---|---| +|説明|.NET Framework 4.6 以降では、 内で または に加えられた変更は、そのディスパッチャー操作の終了時に失われます。 同様に、ディスパッチャー操作の外部で または に加えられた変更は、その操作の実行時には反映されない場合があります。具体的に言うと、 と の変更は、WPF UI コールバックと WPF アプリケーション内の他のコードの間でフローされない場合があるということです。これは、 の変更によるものであり、この変更により、.NET Framework 4.6 以降を対象とするアプリでは、 および は実行コンテキストに格納されます。 WPF ディスパッチャー操作は、操作を開始するために使用された実行コンテキストを格納して、操作が完了したときに、以前のコンテキストを復元します。 と がそのコンテキストの一部になったため、ディスパッチャー操作内でそれらに加えられた変更は、操作の外部では保持されません。| +|提案される解決策|この変更による影響を受けるアプリは、望ましい または をフィールドに格納し、すべてのディスパッチャー操作の本体 (UI イベントのコールバック ハンドラーを含む) で、正しい と が設定されていることを確認することによって回避できます。 または、この WPF の変更の元となっている ExecutionContext の変更は、.NET Framework 4.6 以降を対象とするアプリのみに影響するため、.NET Framework 4.5.2 を対象とすることによって、この問題を回避できます。また、.NET Framework 4.6 以降を対象とするアプリでは、以下の互換性スイッチを設定することでこの問題を回避することができます。
AppContext.SetSwitch("Switch.System.Globalization.NoAsyncCurrentCulture", true);
この問題は、.NET Framework 4.6.2 の WPF で修正されました。 また、.NET Frameworks 4.6、4.6.1 では [KB 3139549](https://support.microsoft.com/kb/3139549) を通じて修正されました。 .NET 4.6 以降を対象とするアプリケーションでは WPF アプリケーション (/) の正しい動作が自動的に取得されます。これは、ディスパッチャー操作にわたって維持されます。| +|スコープ|マイナー| +|Version|4.6| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/wpf/default-hash-algorithm-for-wpf-packagedigitalsignaturemanager-now-sha256.md b/includes/migration-guide/retargeting/wpf/default-hash-algorithm-for-wpf-packagedigitalsignaturemanager-now-sha256.md new file mode 100644 index 00000000000..63e8252abb0 --- /dev/null +++ b/includes/migration-guide/retargeting/wpf/default-hash-algorithm-for-wpf-packagedigitalsignaturemanager-now-sha256.md @@ -0,0 +1,11 @@ +### WPF PackageDigitalSignatureManager の既定のハッシュ アルゴリズムが SHA256 になりました + +| | | +|---|---| +|説明|System.IO.Packaging.PackageDigitalSignatureManager は、WPF パッケージに関連してデジタル署名の機能を提供します。 .NET Framework 4.7 以前のバージョンでは、パッケージのパーツへの署名に使用される既定のアルゴリズム () は SHA1 でした。 最近明らかになった SHA1 のセキュリティに関する懸念事項により、この既定値は .NET Framework 4.7.1 で開始する SHA256 に変更されています。 この変更は、XPS ドキュメントを含むあらゆるパッケージの署名に影響します。| +|提案される解決策|.NET 4.7.1 より前のフレームワーク バージョンを対象とするときにこの変更を利用する開発者または .NET 4.7.1 以上を対象とするときに以前の機能を必要とする開発者は、次の AppContext フラグを適宜設定することができます。 true の値を設定すると、SHA1 が既定のアルゴリズムとして使用され、false の値を設定すると SHA256 が使用されます。
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.MS.Internal.UseSha1AsDefaultHashAlgorithmForDigitalSignatures=true"/>
</runtime>
</configuration>
| +|スコープ|エッジ| +|Version|4.7.1| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/wpf/tabcontrol-selectionchanged-event-selectedcontent-property.md b/includes/migration-guide/retargeting/wpf/tabcontrol-selectionchanged-event-selectedcontent-property.md new file mode 100644 index 00000000000..afa4ef62edd --- /dev/null +++ b/includes/migration-guide/retargeting/wpf/tabcontrol-selectionchanged-event-selectedcontent-property.md @@ -0,0 +1,11 @@ +### TabControl SelectionChanged イベントおよび SelectedContent プロパティ + +| | | +|---|---| +|説明|.NET Framework 4.7.1、以降のの値を更新、を発生させる前に、プロパティ、イベント、その選択が変更されたときにします。 .NET Framework 4.7 と以前のバージョンでは、イベント後に SelectedContent への更新が発生しました。| +|提案される解決策|.NET Framework 4.7.1 以降を対象とするアプリでこの変更を無効にし、従来の動作を使用することができます。その場合、アプリケーション構成ファイルの <runtime> セクションに次の行を追加します。
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=true" />
</runtime>
.NET Framework 4.7 以前を対象とするものの、.NET Framework 4.7.1 以降で実行されているアプリでは、新しい動作を有効にすることができます。その場合、アプリケーション構成ファイルの <runtime> セクションに次の行を追加します。
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.TabControl.SelectionPropertiesCanLagBehindSelectionChangedEvent=false" />
</runtime>
| +|スコープ|マイナー| +|Version|4.7.1| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/wpf/two-way-data-binding-property-with-non-public-setter-not-supported.md b/includes/migration-guide/retargeting/wpf/two-way-data-binding-property-with-non-public-setter-not-supported.md new file mode 100644 index 00000000000..d957f9eeea3 --- /dev/null +++ b/includes/migration-guide/retargeting/wpf/two-way-data-binding-property-with-non-public-setter-not-supported.md @@ -0,0 +1,11 @@ +### 非パブリック セッターを持つプロパティへの双方向データ バインドはサポートされません + +| | | +|---|---| +|説明|パブリック セッターを持たないプロパティへのデータ バインドを試みることは、サポートされるシナリオではありません。 .NET framework 4.5.1 以降では、このシナリオでは がスローされます。 この新しい例外は、具体的に .NET Framework 4.5.1 を対象とするアプリでのみスローされることに注意してください。 アプリが .NET Framework 4.5 をターゲットとしている場合、この呼び出しは許されます。 アプリが特定のバージョンの .NET Framework をターゲットにしていない場合、バインドは一方向として扱われます。| +|提案される解決策|一方向のバインドを使用するか、プロパティのセッターを公開するように、アプリを更新する必要があります。 または、.NET Framework 4.5 をターゲットにすると、アプリは以前の動作を示すようになります。| +|スコープ|マイナー| +|Version|4.5.1| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/wpf/wpf-grid-allocation-space-star-columns.md b/includes/migration-guide/retargeting/wpf/wpf-grid-allocation-space-star-columns.md new file mode 100644 index 00000000000..9e0dce23648 --- /dev/null +++ b/includes/migration-guide/retargeting/wpf/wpf-grid-allocation-space-star-columns.md @@ -0,0 +1,10 @@ +### WPF Grid での *-column への領域の割り当て + +| | | +|---|---| +|説明|.NET Framework 4.7 以降では、WPF で が *-column に領域を割り当てるために使うアルゴリズムが置き換えられます。 これにより、*-column に割り当てられる実際の幅が、次のようにさまざまな場合で変わります。
  • 1 つまたは複数の *-column に、その列の比例割り当てを無視する最小値または最大値の幅もある場合 (最小値の幅は、明示的な MinWidth 宣言、または列の内容から取得した暗黙的な最小値に由来する可能性があります。 最大値の幅は、明示的な MaxWidth 宣言にのみ由来します)。
  • 1 つまたは複数の *-column で 10^298 を超える非常に大きな *-weight を宣言した場合。
  • *-weight が大幅に異なるため、浮動小数点が不安定になる場合 (オーバーフロー、アンダーフロー、精度の低下)。
  • レイアウトの丸めが有効で、ディスプレイの実効 DPI が十分に高い場合。
最初の 2 つの場合、新しいアルゴリズムで生成される幅は、以前のアルゴリズムで生成される幅と大幅に異なる可能性があります。最後の場合、違いは最大で 1 から 2 ピクセルです。以前のアルゴリズムには次のバグがありましたが、新しいアルゴリズムで修正されました。
  1. 列への割り当ての合計は、グリッドの幅を超える可能性があります。 この問題は、比例配分が最小サイズ未満の列に領域を割り当てると発生します。 このアルゴリズムでは最小サイズが割り当てられるため、他の列に使用できる領域が減ります。 割り当てる *-column がなくなると、割り当ての合計は大きくなりすぎます。
  2. 割り当ての合計が、グリッドの幅未満になる可能性があります。 これは、問題 1 と重なる問題で、比例配分共有が最大サイズを超えている列に割り当て、不足を補う *-column が残っていない場合に発生します。
  3. 2 つの *-column が、その *-weight に比例していない割り当てを受ける可能性があります。 これは問題 1、2 よりも軽度な問題です。*-column A、B、C に (この順序で) 割り当てると、B の比例配分共有はその最小値 (または最大値) に違反します。 前述のように、これによって列 C に使用できる領域が変わり、A よりも比例配分の割り当てが少なく (または多く) なります。
  4. 非常に大きな重みの列 (10^298 を超える場合) は、すべて 10^298 の重みとして処理されます。 そのような列 (およびやや小さな重みの列) の比例配分の差は考慮されません。
  5. 無限の重みを持つ列が正しく処理されません。 [実際には重みを無限大に設定することはできませんが、これは人為的な制限です。 割り当てコードは制限を処理しようとしますが、無効なジョブになります。]
  6. オーバーフロー、アンダーフロー、精度の低下などの浮動小数点精度の問題を回避していますが、いくつかの軽微な問題があります。
  7. 十分に高い DPI でレイアウトの丸めの調整が不適切です。
新しいアルゴリズムでは、次の条件を満たす結果が生成されます。A. *-column に割り当てられる実際の幅が、幅の最小値未満にならない、また幅の最大値を超えないようにします。B. 最小値または最大値の幅が割り当てられていない各 -column に、その -weight に比例した幅を割り当てます。正確には、2 つの列の幅がそれぞれ x、y と宣言され、いずれの列も最小値の幅または最大値の幅が割り当てられていない場合、各列に割り当てられる実際の幅 v と w は同じ比率の v / w == x / y になります。C. "比例配分" の *-column に割り当てられる幅の合計は、制限された列 (固定、自動、および最小値または最大値の幅が割り当てられた *-column) に割り当てられた後に使用できる領域と同じなります。 たとえば、最小値の幅の合計がグリッドに使用できる幅を超える場合は、ゼロになる可能性があります。D. これらすべてのステートメントは "理想的な" レイアウトを基準に解釈されます。 レイアウトの丸めが有効な場合、実際の幅は理想的な幅と最大 1 ピクセル異なる可能性があります。以前のアルゴリズムでは (A) を考慮していましたが、上記の他の条件は考慮されていませんでした。この記事で取り上げた列と幅のすべての情報は、行と高さにも適用されます。| +|提案される解決策|.NET Framework 4.7 以降の .NET Framework をターゲットとするアプリの場合、既定で新しいアルゴリズムが使われますが、.NET Framework 4.6.2 以前をターゲットとするアプリは以前のアルゴリズムが使われます。この既定を無視するには、次の構成設定を使います。
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>
値 "true" を設定すると以前のアルゴリズムが選択され、"false" を設定すると新しいアルゴリズムが選択されます。| +|スコープ|マイナー| +|Version|4.7| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/wpf/wpf-layout-rounding-margins-has-changed.md b/includes/migration-guide/retargeting/wpf/wpf-layout-rounding-margins-has-changed.md new file mode 100644 index 00000000000..fd3895fbf8a --- /dev/null +++ b/includes/migration-guide/retargeting/wpf/wpf-layout-rounding-margins-has-changed.md @@ -0,0 +1,10 @@ +### WPF レイアウトでの余白の丸め方の変更 + +| | | +|---|---| +|説明|余白、境界線、およびそれらの内部の背景の丸め処理の方法が変更されました。 この変更の結果、以下のようになります。
  • 要素の幅または高さが最大で 1 ピクセル拡大または縮小することがあります。
  • オブジェクトの配置が最大で 1 ピクセル移動することがあります。
  • 中央揃えの要素が中央から最大で 1 ピクセル垂直まは水平方向にずれることがあります。
既定では、この新しいレイアウトは .NET Framework の 4.6 を対象とするアプリに対してのみ有効となります。| +|提案される解決策|この変更はの右端または下端高 Dpi での WPF コントロールのクリッピングを除去する傾向があります、ため、.NET Framework の以前のバージョンを対象と、.NET Framework 4.6 上で実行されているアプリこともできますこの新しい動作を次の行を追加することで、<runtime> 、app.config ファイルのセクション: <AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=false" />WPF コントロールへの以前のレイアウトのアルゴリズムを使用してレンダリングの目的は、.NET Framework 4.6 を対象するアプリこれを行うには、次の行を追加することによって、 <runtime> app.config ファイルのセクション<AppContextSwitchOverrides value="Switch.MS.Internal.DoNotApplyLayoutRoundingToMarginsAndBorderThickness=true" />。| +|スコープ|マイナー| +|Version|4.6| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/wpf/wpf-pointer-based-touch-stack.md b/includes/migration-guide/retargeting/wpf/wpf-pointer-based-touch-stack.md new file mode 100644 index 00000000000..6fb003f6444 --- /dev/null +++ b/includes/migration-guide/retargeting/wpf/wpf-pointer-based-touch-stack.md @@ -0,0 +1,10 @@ +### WPF ポインター ベースのタッチ スタック + +| | | +|---|---| +|説明|この変更で、オプションの WM_POINTER ベースの WPF タッチ/スタイラス スタックを有効にする機能が追加されます。 これを明示的に有効にしていない開発者は、WPF タッチ/スタイラス動作の変更を確認できません。オプションの WM_POINTER ベースのタッチ/スタイラス スタックに関する現在の既知の問題を以下に示します。
  • リアルタイム インクがサポートされない。
  • インクと StylusPlugins がまだ機能している間は、UI スレッドで処理されますが、パフォーマンスの低下につながる可能性があります。
  • プロモーションの変更により、タッチ/スタイラス イベントからマウス イベントに動作が変更される。
  • 操作の動作が異なる場合があります。
  • ドラッグ/ドロップでは、タッチ入力の適切なフィードバックが表示されません。
  • これはスタイラス入力には影響しません。
  • ドラッグ/ドロップは、タッチ/スタイラス イベントで開始できなくなりました。
  • そのため、マウス入力が検出されるまで、アプリケーションがハングする可能性があります。
  • 代わりに、開発者はマウス イベントからドラッグ アンド ドロップを開始する必要があります。
| +|提案される解決策|このスタックを有効にする開発者は、アプリケーションの App.config ファイルに次の行を追加/マージできます。
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Input.Stylus.EnablePointerSupport=true"/>
</runtime>
</configuration>
これを削除するか、値を false に設定すると、このオプションのスタックがオフになります。このスタックは Windows 10 Creators Update 以降でのみ使用できることに注意してください。| +|スコープ|エッジ| +|Version|4.7| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/wpf/wpf-textboxtext-can-be-out-of-sync-with-databinding.md b/includes/migration-guide/retargeting/wpf/wpf-textboxtext-can-be-out-of-sync-with-databinding.md new file mode 100644 index 00000000000..94144a9945f --- /dev/null +++ b/includes/migration-guide/retargeting/wpf/wpf-textboxtext-can-be-out-of-sync-with-databinding.md @@ -0,0 +1,11 @@ +### WPF TextBox.Text とデータ バインドを非同期にできる + +| | | +|---|---| +|説明|場合によっては、データ バインディングの書き込み操作中にプロパティが変更された場合、 プロパティにデータ バインディング プロパティ値の以前の値が反映されることがあります。| +|提案される解決策|これによって生じる悪影響はないはずです。 ただし、 プロパティを false に設定して、以前の動作を復元することは可能です。| +|スコープ|エッジ| +|Version|4.5| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/xml/xml-schema-validation-stricter.md b/includes/migration-guide/retargeting/xml/xml-schema-validation-stricter.md new file mode 100644 index 00000000000..4207e8bac1c --- /dev/null +++ b/includes/migration-guide/retargeting/xml/xml-schema-validation-stricter.md @@ -0,0 +1,10 @@ +### XML スキーマ検証がより厳格になりました + +| | | +|---|---| +|説明|.NET Framework 4.5 では、XML スキーマ検証が厳格化されました。 xsd:anyURI を使用して mailto プロトコルなどの URI を検証したときに、URI にスペースが入っていると検証は失敗します。 .NET Framework の以前のバージョンでは、検証は成功していました。 この変更は、.NET Framework 4.5 を対象とするアプリケーションにのみ影響します。| +|提案される解決策|より緩やかな .NET Framework 4.0 の検証が必要な場合、検証アプリケーションはバージョン 4.0 の .NET Framework をターゲットにできます。 もう一度 .NET 4.5 をターゲットにする場合は、無効な URI (およびスペース) が anyURI データ型の属性値として予期されないように、コード レビューを行う必要があります。| +|スコープ|マイナー| +|Version|4.5| +|型|再ターゲット中| + diff --git a/includes/migration-guide/retargeting/xml/xmlwriter-throws-on-invalid-surrogate-pairs.md b/includes/migration-guide/retargeting/xml/xmlwriter-throws-on-invalid-surrogate-pairs.md new file mode 100644 index 00000000000..48eb392504b --- /dev/null +++ b/includes/migration-guide/retargeting/xml/xmlwriter-throws-on-invalid-surrogate-pairs.md @@ -0,0 +1,11 @@ +### XmlWriter が無効なサロゲート ペアに対してスローされる + +| | | +|---|---| +|説明|.NET Framework 4.5.2 またはそれ以前のバージョンをターゲットとするアプリケーションの場合、例外フォールバック処理を使用した無効なサロゲート ペアを作成しても、必ず例外がスローされるとは限りません。 .NET Framework 4.6 をターゲットとするアプリでは、無効なサロゲート ペアを作成しようとすると、 がスローされます。| +|提案される解決策|必要に応じて、.NET Framework 4.5.2 以前をターゲットとすることでこの問題を回避できます。 または、無効なサロゲート ペアを有効な xml に書き込む前に事前処理することもできます。| +|スコープ|エッジ| +|Version|4.6| +|型|再ターゲット中| +|影響を受ける API|
| + diff --git a/includes/migration-guide/retargeting/xml/xsd-schema-validation-now-correctly-detects-violations-unique-constraints-if.md b/includes/migration-guide/retargeting/xml/xsd-schema-validation-now-correctly-detects-violations-unique-constraints-if.md new file mode 100644 index 00000000000..c6685f5089c --- /dev/null +++ b/includes/migration-guide/retargeting/xml/xsd-schema-validation-now-correctly-detects-violations-unique-constraints-if.md @@ -0,0 +1,10 @@ +### XSD スキーマ検証は、複合キーが使用され、1 つのキーが空の場合に、一意制約の違反を正しく検出するようになりました + +| | | +|---|---| +|説明|.NET Framework 4.6 より前のバージョンには、キーの 1 つが空であった場合、XSD 検証で複合キーの一意制約が検出されないというバグがありました。 .NET Framework 4.6 で、この問題は修正されました。 このため、より正しい検証が行われるようになりますが、以前は検証されていた XML の一部が検証されない可能性もあります。| +|提案される解決策|より緩やかな .NET Framework 4.0 の検証が必要な場合、検証アプリケーションはバージョン 4.5 (またはそれ以前) の .NET Framework をターゲットにできます。 ただし、.NET 4.6 に再ターゲットするときには、コード レビューを行って、重複する複合キー (この問題の説明で述べられているように) の検証を予期していないことを確認する必要があります。| +|スコープ|エッジ| +|Version|4.6| +|型|再ターゲット中| + diff --git a/includes/migration-guide/runtime/adonet/adonet-now-attempts-automatically-reconnect-broken-sql-connections.md b/includes/migration-guide/runtime/adonet/adonet-now-attempts-automatically-reconnect-broken-sql-connections.md new file mode 100644 index 00000000000..f9ecef0b346 --- /dev/null +++ b/includes/migration-guide/runtime/adonet/adonet-now-attempts-automatically-reconnect-broken-sql-connections.md @@ -0,0 +1,11 @@ +### ADO.NET では、切断された SQL 接続の再接続が自動的に試行されるようになりました + +| | | +|---|---| +|説明|.NET Framework 4.5.1 以降、.NET Framework では、切断された SQL 接続の再接続が自動的に試行されます。 通常、これはアプリの安定性を高めますが、再接続時に行動できるよう、接続が失われたことをアプリに認識させる必要があるという極端な状況があります。| +|提案される解決策|互換性の問題からこの機能が望ましくない場合、接続文字列 (または ) の プロパティを 0 に設定することで無効にできます。| +|スコープ|エッジ| +|Version|4.5.1| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/asp/aspnet-mvc-now-escapes-spaces-strings-passed-via-route-parameters.md b/includes/migration-guide/runtime/asp/aspnet-mvc-now-escapes-spaces-strings-passed-via-route-parameters.md new file mode 100644 index 00000000000..3fc36726006 --- /dev/null +++ b/includes/migration-guide/runtime/asp/aspnet-mvc-now-escapes-spaces-strings-passed-via-route-parameters.md @@ -0,0 +1,11 @@ +### ASP.NET MVC は、ルート パラメーターで渡された文字列内のスペースをエスケープするようになりました + +| | | +|---|---| +|説明|RFC 2396 に準拠するために、ルートからアクション パラメーターを設定するときに、ルートのパスに含まれるスペースがエスケープされるようになりました。 そのため、/controller/action/some data は以前はルート /controller/action/{data} し、some data をデータ パラメーターとして与えましたが、代わりに some%20data を与えるようになります。| +|提案される解決策|ルートからの文字列パラメーターをエスケープ解除するように、コードを更新する必要があります。 元の URI が必要な場合は、.OriginalString API でアクセスできます。| +|スコープ|マイナー| +|Version|4.5.2| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/asp/gridviews-with-allowcustompaging-set-true-may-fire-pageindexchanging-event.md b/includes/migration-guide/runtime/asp/gridviews-with-allowcustompaging-set-true-may-fire-pageindexchanging-event.md new file mode 100644 index 00000000000..6d2a8161026 --- /dev/null +++ b/includes/migration-guide/runtime/asp/gridviews-with-allowcustompaging-set-true-may-fire-pageindexchanging-event.md @@ -0,0 +1,11 @@ +### AllowCustomPaging が true に設定された GridView では、ビューの最終ページから他に移動するときに、PageIndexChanging イベントが発生する場合がある + +| | | +|---|---| +|説明|.NET Framework 4.5 でのバグのため、 が有効になっている に対して が発生しないことがあります。| +|提案される解決策|この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。 回避策として、アプリでは、これらの条件 ( が最終ページで、最後の が と異なる) を満たす Page_Load で明示的に BindGrid を行うことができます。 または、(カスタム ページングではなく) ページングを許可するようにアプリを変更することもできます。このシナリオでは問題は発生していません。| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/asp/httprequestcontentencoding-property-prohibits-utf7.md b/includes/migration-guide/runtime/asp/httprequestcontentencoding-property-prohibits-utf7.md new file mode 100644 index 00000000000..ae5c134ed08 --- /dev/null +++ b/includes/migration-guide/runtime/asp/httprequestcontentencoding-property-prohibits-utf7.md @@ -0,0 +1,11 @@ +### HttpRequest.ContentEncoding プロパティで UTF7 が禁止される + +| | | +|---|---| +|説明|.NET Framework 4.5 以降では、 の本文では UTF-7 エンコードが禁止されます。 UTF-7 データの受信を必要とするアプリケーションのデータが、正しくデコードされない場合があります。| +|提案される解決策|理想的には、 で UTF-7 エンコードを使用しないようにアプリケーションを更新する必要があります。 または、[](https://msdn.microsoft.com/library/hh975440(v=vs.110).aspx) 要素の aspnet:AllowUtf7RequestContentEncoding 属性を使用して、レガシ動作に戻すことができます。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/asp/httputilityjavascriptstringencode-escapes-ampersand.md b/includes/migration-guide/runtime/asp/httputilityjavascriptstringencode-escapes-ampersand.md new file mode 100644 index 00000000000..722a76d5fe8 --- /dev/null +++ b/includes/migration-guide/runtime/asp/httputilityjavascriptstringencode-escapes-ampersand.md @@ -0,0 +1,11 @@ +### HttpUtility.JavaScriptStringEncode でアンパサンドがエスケープされる + +| | | +|---|---| +|説明|.NET Framework 4.5 以降では、 でアンパサンド (&) 文字がエスケープされます。| +|提案される解決策|アプリがこのメソッドの以前の動作に依存している場合、構成ファイルの [ASP.NET appSettings 要素](https://msdn.microsoft.com/library/hh975440.aspx) に aspnet:JavaScriptDoNotEncodeAmpersand 設定を追加できます。| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/asp/ipad-should-not-be-used-custom-capabilities-file-because-it-now-browser.md b/includes/migration-guide/runtime/asp/ipad-should-not-be-used-custom-capabilities-file-because-it-now-browser.md new file mode 100644 index 00000000000..89b6e6d572f --- /dev/null +++ b/includes/migration-guide/runtime/asp/ipad-should-not-be-used-custom-capabilities-file-because-it-now-browser.md @@ -0,0 +1,10 @@ +### iPad はブラウザー機能になったため、カスタム機能ファイルでは使用できない + +| | | +|---|---| +|説明|.NET 4.5 以降では、iPad は既定の ASP.NET ブラウザー機能ファイルの識別子であるため、カスタム機能ファイルでは使用できません。| +|提案される解決策|iPad 固有の機能が必要な場合は、ユーザー エージェントのマッチングで新しい "IPad" ID を生成するのではなく、定義済みのゲートウェイ refID "IPad" で機能を設定して、iPad の動作を変更する必要があります。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/asp/no-longer-able-set-enableviewstatemac-false.md b/includes/migration-guide/runtime/asp/no-longer-able-set-enableviewstatemac-false.md new file mode 100644 index 00000000000..9bc27d6aef4 --- /dev/null +++ b/includes/migration-guide/runtime/asp/no-longer-able-set-enableviewstatemac-false.md @@ -0,0 +1,10 @@ +### EnableViewStateMac を false に設定できなくなった + +| | | +|---|---| +|説明|ASP.NET では、開発者は <pages enableViewStateMac="false"/> または <@Page EnableViewStateMac="false" %> を指定できなくなりました。 ビュー ステートのメッセージ認証コード (MAC) は、ビュー ステートが埋め込まれたすべての要求に強制されています。 EnableViewStateMac プロパティを明示的に false に設定するアプリのみが影響を受けます。| +|提案される解決策|EnableViewStateMac は true であると想定する必要があり、結果としての MAC エラーを解決する必要があります ([このガイダンス](https://support.microsoft.com/kb/2915218)で説明されているように、MAC エラーの原因の詳細によって複数の解決策があります)。| +|スコープ|Major| +|Version|4.5.2| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/asp/pageloadcomplete-event-no-longer-causes.md b/includes/migration-guide/runtime/asp/pageloadcomplete-event-no-longer-causes.md new file mode 100644 index 00000000000..7ba0925d7bc --- /dev/null +++ b/includes/migration-guide/runtime/asp/pageloadcomplete-event-no-longer-causes.md @@ -0,0 +1,10 @@ +### Page.LoadComplete イベントによって、System.Web.UI.WebControls.EntityDataSource コントロールがデータ バインディングを呼び出さなくなりました + +| | | +|---|---| +|説明| イベントが原因で、 のコントロールがパラメーターの作成/更新/削除に変更を加えるためにデータ バインディングを呼び出すことがなくなりました。 この変更により、データベースへの不要なアクセスが排除され、コントロールの値がリセットされるのを防ぐことができるほか、 や などのように他のデータ コントロールと一貫性の取れた動作が生成されます。 この変更により、アプリケーションが イベントのデータ バインディングの呼び出しに依存するような珍しい状況において、異なる動作が生成されるようになりました。| +|提案される解決策|データバインドの必要がある場合は、ポストバックの前半であるイベントでデータバインドを手動で呼び出します。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/asp/profiling-aspnet-mvc4-apps-can-lead-fatal-execution-engine-error.md b/includes/migration-guide/runtime/asp/profiling-aspnet-mvc4-apps-can-lead-fatal-execution-engine-error.md new file mode 100644 index 00000000000..52152c25e5a --- /dev/null +++ b/includes/migration-guide/runtime/asp/profiling-aspnet-mvc4-apps-can-lead-fatal-execution-engine-error.md @@ -0,0 +1,10 @@ +### ASP.Net MVC4 アプリのプロファイリングにより、致命的な実行エンジン エラーが発生する可能性がある + +| | | +|---|---| +|説明|NGEN/プロファイル アセンブリを使用するプロファイラーにより、起動時にプロファイルされた ASP.NET MVC4 アプリケーションがクラッシュし、"致命的な実行エンジン例外" が示される場合があります。| +|提案される解決策|この問題は、.NET Framework 4.5.2 で修正されます。 プロファイラーは、イベント マスクで COR_PRF_DISABLE_ALL_NGEN_IMAGES を指定することで、この問題を回避することもできます。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/asp/sharing-session-state-with-aspnet-stateserver-requires-all-servers-web-farm.md b/includes/migration-guide/runtime/asp/sharing-session-state-with-aspnet-stateserver-requires-all-servers-web-farm.md new file mode 100644 index 00000000000..48ddda6e9c0 --- /dev/null +++ b/includes/migration-guide/runtime/asp/sharing-session-state-with-aspnet-stateserver-requires-all-servers-web-farm.md @@ -0,0 +1,11 @@ +### Asp.Net StateServer とセッション状態を共有するには、Web ファーム内のすべてのサーバーが同じ .NET Framework バージョンを使用する必要があります + +| | | +|---|---| +|説明| セッション状態を有効にする場合、状態を正しく共有するには、指定の Web ファーム内のすべてのサーバーが同じバージョンの .NET Framework を使用する必要があります。| +|提案される解決策|同時に状態を共有する Web サーバー上で必ず .NET Framework バージョンのアップグレードを行います。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/asp/webutilityhtmldecode-no-longer-decodes-invalid-input-sequences.md b/includes/migration-guide/runtime/asp/webutilityhtmldecode-no-longer-decodes-invalid-input-sequences.md new file mode 100644 index 00000000000..80b8b15c8c7 --- /dev/null +++ b/includes/migration-guide/runtime/asp/webutilityhtmldecode-no-longer-decodes-invalid-input-sequences.md @@ -0,0 +1,11 @@ +### WebUtility.HtmlDecode が無効な入力シーケンスをデコードしなくなった + +| | | +|---|---| +|説明|既定では、デコード メソッドによって無効な入力シーケンスが無効な UTF-16 文字列にデコードされることがなくなりました。 代わりに、元の入力が返されます。| +|提案される解決策|デコーダーの出力の変更は、UTF-16 データではなくバイナリ データを文字列に格納した場合にのみ影響があります。 明示的にこの動作を制御するには、[appSettings](~/docs/framework/configure-apps/file-schema/appsettings/index.md) 要素の aspnet:AllowRelaxedUnicodeDecoding 属性を true に設定して従来の動作を有効にするか、false に設定して現在の動作を有効にします。| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/core/appdomainsetupdynamicbase-no-longer-randomized-by.md b/includes/migration-guide/runtime/core/appdomainsetupdynamicbase-no-longer-randomized-by.md new file mode 100644 index 00000000000..c2cf7667acc --- /dev/null +++ b/includes/migration-guide/runtime/core/appdomainsetupdynamicbase-no-longer-randomized-by.md @@ -0,0 +1,11 @@ +### AppDomainSetup.DynamicBase が UseRandomizedStringHashAlgorithm でランダム化されなくなった + +| | | +|---|---| +|説明|.NET Framework 4.6 より前では、UseRandomizedStringHashAlgorithm がアプリの構成ファイルで有効になっている場合、 の値がアプリケーション ドメイン間、またはプロセス間でランダム化されます。 .NET Framework 4.6 以降では、 は実行されているアプリの異なるインスタンス間、および異なるアプリ ドメイン間で安定した結果を返します。 それでも動的ベースはアプリによって異なります。この変更では、同じアプリの異なるインスタンスのランダムな名前付け要素のみが削除されます。| +|提案される解決策|UseRandomizedStringHashAlgorithm を有効にすると、 がランダム化されなくなることに注意してください。 ランダム ベースが必要な場合は、この API を使用するのではなく、アプリのコードで生成する必要があります。| +|スコープ|エッジ| +|Version|4.6| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/core/assemblies-compiled-with-regexcompiletoassembly-breaks-between-40-45.md b/includes/migration-guide/runtime/core/assemblies-compiled-with-regexcompiletoassembly-breaks-between-40-45.md new file mode 100644 index 00000000000..1d7e8911c5f --- /dev/null +++ b/includes/migration-guide/runtime/core/assemblies-compiled-with-regexcompiletoassembly-breaks-between-40-45.md @@ -0,0 +1,11 @@ +### Regex.CompileToAssembly でコンパイルされたアセンブリは 4.0 と 4.5 の間で区別されます + +| | | +|---|---| +|説明|コンパイル済みの正規表現のアセンブリが .NET Framework 4.5 でビルドされ、.NET Framework 4 を対象としている場合、.NET Framework 4 がインストールされているシステム上でそのアセンブリの正規表現の 1 つを使用しようとすると、例外をスローします。| +|提案される解決策|この問題を回避するには、次のいずれかの方法を実行します。
  • .NET Framework 4 を使用して正規表現を含むアセンブリをビルドします。
  • 解釈される正規表現を使用します。
| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/core/blockingcollectionlttgttrytakefromany-does-not-throw-anymore.md b/includes/migration-guide/runtime/core/blockingcollectionlttgttrytakefromany-does-not-throw-anymore.md new file mode 100644 index 00000000000..a5f6cf493f1 --- /dev/null +++ b/includes/migration-guide/runtime/core/blockingcollectionlttgttrytakefromany-does-not-throw-anymore.md @@ -0,0 +1,11 @@ +### BlockingCollection<T>.TryTakeFromAny がスローしなくなった + +| | | +|---|---| +|説明|入力コレクションの 1 つに完了のマークが付けられた場合、 -1 を返さず、例外をスローしなくなりました。 この変更の結果、コレクションの 1 つが空であったり完了していても、他のコレクションに取得できる項目がある場合にコレクションで作業をすることができるようになりました。| +|提案される解決策|-1 を返す TryTakeFromAny またはスローする TakeFromAny が制御フロー目的で使用されていた場合、ブロッキング コレクションが完了する場合、そのようなコードは、その条件を検出するように .Any(b => b.IsCompleted) を使用するように変更される必要があります。| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/core/calling-attributegetcustomattributes-on-an-indexer-property-no-longer-throws.md b/includes/migration-guide/runtime/core/calling-attributegetcustomattributes-on-an-indexer-property-no-longer-throws.md new file mode 100644 index 00000000000..b070320707d --- /dev/null +++ b/includes/migration-guide/runtime/core/calling-attributegetcustomattributes-on-an-indexer-property-no-longer-throws.md @@ -0,0 +1,11 @@ +### インデクサー プロパティに対して Attribute.GetCustomAttributes を呼び出しても、インデックスの型によって、あいまいさを解決できる場合、AmbiguousMatchException はスローされなくなった + +| | | +|---|---| +|説明|.NET Framework 4.6 より以前には、インデックスの型のみが別のプロパティと異なるインデクサ― プロパティに対して GetCustomAttribute(s) を呼び出すと、 になりました。 .NET Framework 4.6 からは、プロパティの属性が正しく返されます。| +|提案される解決策|GetCustomAttribute(s) が、より頻繁に機能するようになったことに注意してください。 アプリが に依存していた場合は、代わりにリフレクションを使用して、複数のインデクサーを明示的に検索する必要があります。| +|スコープ|エッジ| +|Version|4.6| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/core/compiler-support-for-type-forwarding-when-multi-targeting-mscorlib.md b/includes/migration-guide/runtime/core/compiler-support-for-type-forwarding-when-multi-targeting-mscorlib.md new file mode 100644 index 00000000000..e051e4f3070 --- /dev/null +++ b/includes/migration-guide/runtime/core/compiler-support-for-type-forwarding-when-multi-targeting-mscorlib.md @@ -0,0 +1,9 @@ +### mscorlib の複数バージョン対応時の型転送のコンパイラ サポート + +| | | +|---|---| +|説明|新しい CodeDOM の機能を使用すると、mscorlib.dll の .NET Framework 4.5 バージョンではなく、mscorlib.dll の対象バージョンに対してコンパイルできるようになります。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/core/concurrentqueuelttgttrypeek-can-return-an-erroneous-null-via-its-out.md b/includes/migration-guide/runtime/core/concurrentqueuelttgttrypeek-can-return-an-erroneous-null-via-its-out.md new file mode 100644 index 00000000000..0792578517d --- /dev/null +++ b/includes/migration-guide/runtime/core/concurrentqueuelttgttrypeek-can-return-an-erroneous-null-via-its-out.md @@ -0,0 +1,11 @@ +### ConcurrentQueue<T>.TryPeek は、出力パラメーターを介して誤った null を返すことがあります + +| | | +|---|---| +|説明|一部のマルチ スレッド シナリオでは、 は true を返すことができますが、出力パラメーターに (正しいピーク値の代わりに) null 値を入れることがあります。| +|提案される解決策|この問題は、.NET Framework 4.5.1 で修正されます。 この Framework にアップグレードすると、問題が解決されます。| +|スコープ|Major| +|バージョン|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/core/corprfgcroothandles-are-not-being-enumerated-by-profilers.md b/includes/migration-guide/runtime/core/corprfgcroothandles-are-not-being-enumerated-by-profilers.md new file mode 100644 index 00000000000..c814f7e67fe --- /dev/null +++ b/includes/migration-guide/runtime/core/corprfgcroothandles-are-not-being-enumerated-by-profilers.md @@ -0,0 +1,10 @@ +### COR_PRF_GC_ROOT_HANDLE がプロファイラーで列挙されていない + +| | | +|---|---| +|説明|.NET Framework v4.5.1 では、プロファイル API RootReferences2() が正しく COR_PRF_GC_ROOT_HANDLE を返しません (代わりに、COR_PRF_GC_ROOT_OTHER として返される)。 この問題は、.NET Framework 4.6 以降で修正されています。| +|提案される解決策|この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。| +|スコープ|マイナー| +|Version|4.5.1| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/core/deserialization-objects-across-appdomains-can-fail.md b/includes/migration-guide/runtime/core/deserialization-objects-across-appdomains-can-fail.md new file mode 100644 index 00000000000..f5853fbb38a --- /dev/null +++ b/includes/migration-guide/runtime/core/deserialization-objects-across-appdomains-can-fail.md @@ -0,0 +1,10 @@ +### アプリ ドメイン全体でのオブジェクトの逆シリアル化に失敗する可能性がある + +| | | +|---|---| +|説明|場合によっては、アプリが異なるアプリケーション ベースを持つ複数のアプリ ドメインを使用すると、アプリ ドメイン間で論理呼び出しコンテキストのオブジェクトを逆シリアル化しようとして、例外がスローされます。| +|提案される解決策|「[軽減策: アプリ ドメイン全体でのオブジェクトの逆シリアル化](~/docs/framework/migration-guide/mitigation-deserialization-of-objects-across-app-domains.md)」を参照してください。| +|スコープ|エッジ| +|Version|4.5.1| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/core/etw-eventlisteners-do-not-capture-events-from-providers-with-explicit.md b/includes/migration-guide/runtime/core/etw-eventlisteners-do-not-capture-events-from-providers-with-explicit.md new file mode 100644 index 00000000000..196e302b8cc --- /dev/null +++ b/includes/migration-guide/runtime/core/etw-eventlisteners-do-not-capture-events-from-providers-with-explicit.md @@ -0,0 +1,11 @@ +### ETW EventListeners は、明示的なキーワードを持つプロバイダーからのイベント (TPL プロバイダーなど) をキャプチャしません + +| | | +|---|---| +|説明|空白のキーワード マスクを持つ ETW EventListeners は、明示的なキーワードを持つプロバイダーからのイベントを正しくキャプチャしません。 .NET Framework 4.5 では、TPL プロバイダーは、明示的なキーワードを提供するようになり、この問題が発生しました。 .NET Framework 4.6 では、EventListeners が更新され、この問題は修正されました。| +|提案される解決策|この問題を回避するには、 の呼び出しを、使用する "任意のキーワード" マスクを明示的に指定する EnableEvents オーバーロード (EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff))) の呼び出しに置換します。または、この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/core/eventlistener-truncates-strings-with-embedded-nulls.md b/includes/migration-guide/runtime/core/eventlistener-truncates-strings-with-embedded-nulls.md new file mode 100644 index 00000000000..e7cf7fd617a --- /dev/null +++ b/includes/migration-guide/runtime/core/eventlistener-truncates-strings-with-embedded-nulls.md @@ -0,0 +1,11 @@ +### EventListener は、null が埋め込まれた文字列を切り捨てる + +| | | +|---|---| +|説明| は、埋め込まれた null のある文字列を切り捨てます。 null 文字は クラスでサポートされません。 変更は、プロセスの データを読み取るために を使用し、区切り記号として null 文字を使用するアプリにのみ影響します。| +|提案される解決策|可能な場合は、埋め込まれた null 文字を使用しないように データを更新する必要があります。| +|スコープ|エッジ| +|Version|4.5.1| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/core/eventsourcewriteevent-impls-must-pass-writeevent-same-parameters-that-it.md b/includes/migration-guide/runtime/core/eventsourcewriteevent-impls-must-pass-writeevent-same-parameters-that-it.md new file mode 100644 index 00000000000..730edd72424 --- /dev/null +++ b/includes/migration-guide/runtime/core/eventsourcewriteevent-impls-must-pass-writeevent-same-parameters-that-it.md @@ -0,0 +1,10 @@ +### EventSource.WriteEvent impls は、受け取ったのと同じパラメーター (と ID) を WriteEvent に渡す必要がある + +| | | +|---|---| +|説明|ランタイムは次の内容を指定するコントラクトを強制するようになりました: ETW イベント メソッドを定義する から派生するクラスは、ETW イベント メソッドが渡された同じ引数が続くイベント ID の基底クラス EventSource.WriteEvent メソッドを呼び出す必要があります。| +|提案される解決策| 例外は、 がこのコントラクトに違反するイベント ソースのプロセスの データを読み取るときに、スローされます。| +|スコープ|マイナー| +|Version|4.5.1| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/core/exceptions-during-unobserved-processing-systemthreadingtaskstask-no-longer.md b/includes/migration-guide/runtime/core/exceptions-during-unobserved-processing-systemthreadingtaskstask-no-longer.md new file mode 100644 index 00000000000..8b39e886f94 --- /dev/null +++ b/includes/migration-guide/runtime/core/exceptions-during-unobserved-processing-systemthreadingtaskstask-no-longer.md @@ -0,0 +1,11 @@ +### System.Threading.Tasks.Task で監視されていない処理中の例外が、ファイナライザー スレッドに伝播されなくなった + +| | | +|---|---| +|説明| クラスは非同期操作を表すため、非同期処理中に発生する重大ではない例外がすべてキャッチされます。 .NET Framework 4.5 では、例外が監視されていず、コードがタスクを待機していない場合、例外はファイナライザー スレッドに伝播されなくなり、ガベージ コレクション時にプロセスをクラッシュします。 この変更により、Task クラスを使用して、監視されていない非同期処理を実行するアプリケーションの信頼性が向上します。| +|提案される解決策|アプリが、監視されていない非同期例外のファイナライザー スレッドへの伝播に依存している場合、 イベントの適切なハンドラーを提供することによって、または[ランタイム構成要素](~/docs/framework/configure-apps/file-schema/runtime/throwunobservedtaskexceptions-element.md)を設定することによって、以前の動作を復元できます。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/core/listsort-algorithm-changed.md b/includes/migration-guide/runtime/core/listsort-algorithm-changed.md new file mode 100644 index 00000000000..2a1d8134fa1 --- /dev/null +++ b/includes/migration-guide/runtime/core/listsort-algorithm-changed.md @@ -0,0 +1,11 @@ +### List.Sort アルゴリズムが変更された + +| | | +|---|---| +|説明|.NET Framework 4.5 以降では、 の並べ替えアルゴリズムが (クイック並べ替えではなく、内省的な並べ替えになるように) 変更されました。 の並べ替えは安定しますが、この変更により、さまざまなシナリオが不安定な方法で並べ替えられる可能性があります。 これは単に、同等の項目が API の後続の呼び出しで異なる順序で並べ替えられる可能性があることを意味します。| +|提案される解決策|以前の並べ替えアルゴリズムも不安定であるため (ただし、方法は若干異なる)、特定の順序で常に並べ替える同等の項目に依存するコードがあってはなりません。 それに依存していて、以前の動作で問題がないコードのインスタンスが存在する場合は、適切な順序で項目を決定論的に並べ替える比較子を使用するようにそのコードを更新する必要があります。| +|スコープ|透明| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/core/marshalsizeof-marshalptrtostructure-overloads-break-dynamic-code.md b/includes/migration-guide/runtime/core/marshalsizeof-marshalptrtostructure-overloads-break-dynamic-code.md new file mode 100644 index 00000000000..c348669c73c --- /dev/null +++ b/includes/migration-guide/runtime/core/marshalsizeof-marshalptrtostructure-overloads-break-dynamic-code.md @@ -0,0 +1,10 @@ +### Marshal.SizeOf および Marshal.PtrToStructure オーバー ロードがダイナミック コードを中断する + +| | | +|---|---| +|説明|.NET Framework 4.5.1 以降では、メソッド 、、、、、または への動的なバインドを (たとえば、Windows PowerShell、IronPython、または C# のダイナミック キーワードを使用して) 行うと、これらのメソッドの新しいオーバーロードが追加され、スクリプト エンジンにとってあいまいなことがあるため、MethodInvocationExceptions になります。| +|提案される解決策|使用するオーバーロードを明確に示すように、スクリプトを更新します。 これは、一般に、メソッドの型パラメーターを として明示的にキャストすることによって行われます。 この問題の回避方法の詳細と例については、[このリンク](https://support.microsoft.com/kb/2909958/) を参照してください。| +|スコープ|マイナー| +|Version|4.5.1| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/core/missing-target-framework-moniker-results-40-behavior.md b/includes/migration-guide/runtime/core/missing-target-framework-moniker-results-40-behavior.md new file mode 100644 index 00000000000..00dfd65895f --- /dev/null +++ b/includes/migration-guide/runtime/core/missing-target-framework-moniker-results-40-behavior.md @@ -0,0 +1,10 @@ +### ターゲット フレームワーク モニカーがないと、4.0 の動作になる + +| | | +|---|---| +|説明|アセンブリ レベルで が適用されていないアプリケーションは、自動的に .NET Framework 4.0 のセマンティクス (quirks) を使用して実行します。 高い品質を確保するには、すべてのバイナリを、ビルドされた .NET Framework のバージョンを示す で明示的に属性指定することをお勧めします。 プロジェクト ファイルでターゲット フレームワーク モニカーを使用すると、MSBuid は を自動的に適用します。| +|提案される解決策| は、属性をアセンブリに直接追加するか、[プロジェクト ファイルで、または Visual Studio のプロジェクト プロパティ GUI](http://blogs.msdn.com/b/visualstudio/archive/2010/05/19/visual-studio- managed-multi-targeting-part-1-concepts-target-framework-moniker-target-framework.aspx) でターゲット フレームワークを指定することによって指定する必要があります。| +|スコープ|Major| +|バージョン|4.5| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/core/persian-calendar-now-uses-hijri-solar-algorithm.md b/includes/migration-guide/runtime/core/persian-calendar-now-uses-hijri-solar-algorithm.md new file mode 100644 index 00000000000..0ce82c8063d --- /dev/null +++ b/includes/migration-guide/runtime/core/persian-calendar-now-uses-hijri-solar-algorithm.md @@ -0,0 +1,11 @@ +### ペルシャ暦でイスラム暦の太陽アルゴリズムが使用されるようになった + +| | | +|---|---| +|説明|.NET Framework 4.6 以降では、 クラスでイスラム暦の太陽アルゴリズムが使用されます。 と他のカレンダーの間で日付を変換すると、.NET Framework 4.6 以降では、1800 年より前か 2023 年 (グレゴリオ暦) よりも後の日付について、わずかに異なる結果になることがあります。また、 は March 22, 0622 instead of March 21, 0622 になります。| +|提案される解決策|.NET 4.6 で PersianCalendar を使用するときには、一部の早い日付または遅い日付に若干の差が生じる場合があることに注意してください。 また、異なるバージョンの .NET Framework で実行する可能性のあるプロセス間で日付をシリアル化するときには、PersianCalendar の日付文字列として格納しないでください (これらの値が異なる場合があるため)。| +|スコープ|マイナー| +|Version|4.6| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/core/reflection-objects-can-no-longer-be-passed-from-managed-code-out-of-process.md b/includes/migration-guide/runtime/core/reflection-objects-can-no-longer-be-passed-from-managed-code-out-of-process.md new file mode 100644 index 00000000000..9328013dba6 --- /dev/null +++ b/includes/migration-guide/runtime/core/reflection-objects-can-no-longer-be-passed-from-managed-code-out-of-process.md @@ -0,0 +1,10 @@ +### リフレクション オブジェクトが、マネージド コードからアウト プロセス DCOM クライアントに渡されなくなった + +| | | +|---|---| +|説明|リフレクション オブジェクトはマネージ コードからアウト プロセス DCOM クライアントに渡されなくなりました。 影響を受ける型は次のとおりです。
  • (およびその派生型、、、、 など)
  • 。
オブジェクトの IMarshal の呼び出しは E_NOINTERFACE を返します。| +|提案される解決策|非リフレクション オブジェクトで動作するように、マーシャリング コードを更新します。| +|スコープ|マイナー| +|Version|4.6| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/core/some-net-apis-cause-first-chance-handled-entrypointnotfoundexceptions.md b/includes/migration-guide/runtime/core/some-net-apis-cause-first-chance-handled-entrypointnotfoundexceptions.md new file mode 100644 index 00000000000..d8a56445687 --- /dev/null +++ b/includes/migration-guide/runtime/core/some-net-apis-cause-first-chance-handled-entrypointnotfoundexceptions.md @@ -0,0 +1,11 @@ +### 一部の .NET API がファースト チャンス (処理済み) EntryPointNotFoundExceptions の原因になります + +| | | +|---|---| +|説明|.NET Framework 4.5 では、少数の .NET メソッドが、ファースト チャンス をスローするようになりました。 これらの例外は .NET Framework 内で処理されますが、ファースト チャンス例外を予期していないテスト自動化を中断することがありました。 これらと同じ API は、HighVersionLie が有効なとき、一部の ApiVerifier シナリオを中断させます。| +|提案される解決策|このバグは、.NET Framework 4.5.1 にアップグレードすることによって回避できます。 または、ファースト チャンス で中断しないように、テスト自動化を更新できます。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/core/systemthreadingtaskstask-no-longer-throw-objectdisposedexception-after.md b/includes/migration-guide/runtime/core/systemthreadingtaskstask-no-longer-throw-objectdisposedexception-after.md new file mode 100644 index 00000000000..31dd618e58c --- /dev/null +++ b/includes/migration-guide/runtime/core/systemthreadingtaskstask-no-longer-throw-objectdisposedexception-after.md @@ -0,0 +1,10 @@ +### System.Threading.Tasks.Task は、オブジェクトが破棄された後、ObjectDisposedException をスローしなくなりました + +| | | +|---|---| +|説明|を除き、 メソッドでオブジェクトが破棄された後も の例外がスローされることがなくなりました。この変更により、キャッシュされたタスクを使用できるようになりました。 たとえば、メソッドで新しいタスクを割り当てる代わりに、既に完了した操作を表す、キャッシュされたタスクを返すことができます。 これは、タスクの任意のコンシューマーによって破棄されてしまうと、使用不可能になってしまう以前の .NET Framework のバージョンでは不可能でした。| +|提案される解決策|オブジェクトが破棄されたとき、Task メソッドが をスローしなくなったことに注意してください。 アプリが、タスクが破棄されたことを確認するために、この例外に依存していた場合は、 を使用してタスクのステータスを明示的に確認するように、アプリを更新する必要があります。| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/core/systemuri-escaping-now-supports-rfc-3986.md b/includes/migration-guide/runtime/core/systemuri-escaping-now-supports-rfc-3986.md new file mode 100644 index 00000000000..e5425d54c04 --- /dev/null +++ b/includes/migration-guide/runtime/core/systemuri-escaping-now-supports-rfc-3986.md @@ -0,0 +1,11 @@ +### System.Uri エスケープで RFC 3986 がサポート対象に + +| | | +|---|---| +|説明|URI エスケープは、.NET 4.5 で、[RFC 3986](http://tools.ietf.org/html/rfc3986)をサポートするように変更されました。 具体的な変更内容:
  • は、予約されている文字を RFC 3986 に基づいてエスケープします。
  • は、予約されている文字をエスケープしません。
  • は、無効なエスケープ シーケンスが発生した場合に例外をスローしません。
  • 予約されていないエスケープ文字はエスケープ解除されます。
| +|提案される解決策|
  • 無効なエスケープ シーケンスの場合、 のスローに依存しないように、アプリケーションを更新します。 このようなシーケンスは、直接削除する必要があります。
  • 同様に、エスケープおよびエスケープ解除された URI とデータ文字列は、.NET 4.0 と .NET 4.5 で異なる場合があるため、.NET のバージョン間で直接比較しないでください。 代わりに、1 つの .NET バージョンで解析と正規化を行ってから比較してください。
| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/core/targetframeworkname-for-default-app-domain-no-longer-defaults-null-if-not.md b/includes/migration-guide/runtime/core/targetframeworkname-for-default-app-domain-no-longer-defaults-null-if-not.md new file mode 100644 index 00000000000..76bed8f9823 --- /dev/null +++ b/includes/migration-guide/runtime/core/targetframeworkname-for-default-app-domain-no-longer-defaults-null-if-not.md @@ -0,0 +1,11 @@ +### 既定のアプリケーション ドメインの TargetFrameworkName は、設定されなかった場合、既定で null に設定されなくなった + +| | | +|---|---| +|説明| は、以前は、明示的に設定されない限り、既定のアプリケーション ドメインでは null でした。 4.6 以降では、既定のアプリケーション ドメインの プロパティは、TargetFrameworkAttribute (ある場合) から派生された既定値を持ちます。 既定以外のアプリケーション ドメインは、明示的にオーバーライドされない限り、既定のアプリケーション ドメイン (4.6 では既定で null に設定されない) から を継承し続けます。| +|提案される解決策| が既定で null に設定されることに依然しないように、コードを更新する必要があります。 このプロパティが引き続き null として評価される必要がある場合、明示的にその値に設定できます。| +|スコープ|エッジ| +|Version|4.6| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/core/winrt-stream-adapters-no-long-call-flushasync-automatically-on-close.md b/includes/migration-guide/runtime/core/winrt-stream-adapters-no-long-call-flushasync-automatically-on-close.md new file mode 100644 index 00000000000..a1c96150823 --- /dev/null +++ b/includes/migration-guide/runtime/core/winrt-stream-adapters-no-long-call-flushasync-automatically-on-close.md @@ -0,0 +1,10 @@ +### 終了時に WinRT ストリーム アダプターで FlushAsync が自動的に呼び出されなくなりました + +| | | +|---|---| +|説明|Windows ストア アプリの Windows ランタイム ストリーム アダプターで、Dispose メソッドから FlushAsync メソッドが呼び出されなくなりました。| +|提案される解決策|この変更は透過的である必要があります。 開発者は次のようなコードを記述して以前の動作を復元できます。
using (var stream = GetWindowsRuntimeStream() as Stream)
{
// do something
await stream.FlushAsync();
}
| +|スコープ|透明| +|Version|4.5.1| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/core/x509certificate2tostringbool-does-not-throw-now-when-net-cannot-handle.md b/includes/migration-guide/runtime/core/x509certificate2tostringbool-does-not-throw-now-when-net-cannot-handle.md new file mode 100644 index 00000000000..6b6c7f4b7bc --- /dev/null +++ b/includes/migration-guide/runtime/core/x509certificate2tostringbool-does-not-throw-now-when-net-cannot-handle.md @@ -0,0 +1,11 @@ +### .NET で証明書を処理できないときに、X509Certificate2.ToString(bool) がスローしなくなった + +| | | +|---|---| +|説明|以前は、このメソッドは、verbose パラメーターとして true が渡され、.NET Framework ではサポートされない証明書がインストールされていた場合、スローしました。 現在は、メソッドは成功し、証明書のアクセス不能部分を省いた有効な文字列を返します。| +|提案される解決策| に依存しているコードは、以前は API がスローしていたような場合には、返される文字列から一部の証明書データ (公開鍵、秘密鍵、拡張子など) が除外されることを予期するように更新する必要があります。| +|スコープ|エッジ| +|Version|4.6| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/data/attempting-tcpip-connection-sql-server-database-that-resolves-localhost.md b/includes/migration-guide/runtime/data/attempting-tcpip-connection-sql-server-database-that-resolves-localhost.md new file mode 100644 index 00000000000..5681153e879 --- /dev/null +++ b/includes/migration-guide/runtime/data/attempting-tcpip-connection-sql-server-database-that-resolves-localhost.md @@ -0,0 +1,10 @@ +### `localhost` に解決される SQL Server データベースへの TCP/IP 接続の試みが失敗します + +| | | +|---|---| +|説明|.NET Framework 4.6 および 4.6.1 で、localhost に解決される SQL Server データベースへの TCP/IP 接続の試みが次のエラーで失敗していました: "SQL Server への接続を確立しているときにネットワーク関連またはインスタンス固有のエラーが発生しました。 サーバーが見つからないかアクセスできません。 インスタンス名が正しいこと、および SQL Server がリモート接続を許可するように構成されていることを確認してください。 (プロバイダー: SQL ネットワーク インターフェイス、エラー: 26 - 指定されたサーバーまたはインスタンスの位置を特定しているときにエラーが発生しました)"。| +|提案される解決策|この問題は修正済みであり、.NET Framework 4.6.2 では以前の動作に戻っています。 localhost に解決される SQL Server データベースに接続するには、.NET Framework 4.6.2 にアップグレードします。| +|スコープ|マイナー| +|Version|4.6| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/data/connection-pool-blocking-period-for-azure-sql-databases-removed.md b/includes/migration-guide/runtime/data/connection-pool-blocking-period-for-azure-sql-databases-removed.md new file mode 100644 index 00000000000..30b3658a109 --- /dev/null +++ b/includes/migration-guide/runtime/data/connection-pool-blocking-period-for-azure-sql-databases-removed.md @@ -0,0 +1,11 @@ +### Azure SQL データベースの接続プールのブロック期間が削除される + +| | | +|---|---| +|説明|.NET Framework 4.6.2 以降では、既知の Azure SQL データベースへの接続確立要求の場合 (*.database.windows.net、*.database.chinacloudapi.cn、*.database.usgovcloudapi.net、*.database.cloudapi.de)、接続プールのブロック期間が削除され、接続確立のエラーはキャッシュされません。 接続オープン要求の再試行は、一時的な接続エラーのほぼすぐ後に発生します。 この変更により、Azure SQL データベースへの接続確立がすぐに再試行するされるため、クラウド対応アプリケーションのパフォーマンスが向上します。 他のすべての接続試行中に接続プールのブロック期間は適用するのには続行されます。 .NET Framework 4.6.1 以前のバージョンで、アプリでは、データベースに接続するときに一時的な接続エラーが発生したときに、接続試行を再試行できません早すぎると、接続プールが、エラーをキャッシュし、1 を 5 秒間に再スローされます。1 分です。 詳しくは、「[SQL Server の接続プール (ADO.NET)](~/docs/framework/data/adonet/sql-server-connection-pooling.md)」をご覧ください。 この動作は、Azure SQL データベースへの接続時に問題となります。多くの場合、一時的なエラーが発生し、通常数秒内に回復します。 接続プールのブロック機能を使うと、データベースが使用可能で、アプリが数秒以内にレンダリングする必要がある場合でも、アプリは長期間データベースに接続できません。| +|提案される解決策|この動作が望ましくない場合は、.NET Framework 4.6.2 で導入された プロパティを設定することで、接続プールのブロック期間を構成できます。 プロパティ値が 列挙型のメンバーである場合、次の 3 つの値のいずれかを使用できます。
プロパティを に設定して、以前の動作を復元することができます。| +|スコープ|マイナー| +|Version|4.6.2| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/data/sqlbulkcopy-uses-destination-column-encoding-for-strings.md b/includes/migration-guide/runtime/data/sqlbulkcopy-uses-destination-column-encoding-for-strings.md new file mode 100644 index 00000000000..333ab2ecc24 --- /dev/null +++ b/includes/migration-guide/runtime/data/sqlbulkcopy-uses-destination-column-encoding-for-strings.md @@ -0,0 +1,11 @@ +### SqlBulkCopy で文字列に挿入先の列エンコードが使用される + +| | | +|---|---| +|説明|データを列に挿入する場合、 は VARCHAR と CHAR の型の既定エンコードではなく、挿入先の列のエンコードを使用します。 この変更により、挿入先の列が既定のエンコードを使用しない場合に、既定のエンコードを使用することによって発生するデータ破損の可能性がなくなります。 まれに、エンコードに変更を加えることによって、挿入先の列に収まりきらない大きいデータが生成された場合に、既存のアプリケーションで SqlException の例外がスローされることがあります。| +|提案される解決策| では、エンコードが異なるため、データは破損しなくなると予想します。 挿入先の列のサイズ制限に近づいている文字列がコピーされている場合、データの事前エンコード (コピーして挿入先の行にデータが収まることを確認するため) や のキャッチが必要になることがあります。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/data/sqlconnection-can-no-longer-connect-sql-server-1997-databases-using-via.md b/includes/migration-guide/runtime/data/sqlconnection-can-no-longer-connect-sql-server-1997-databases-using-via.md new file mode 100644 index 00000000000..7f9de02e72a --- /dev/null +++ b/includes/migration-guide/runtime/data/sqlconnection-can-no-longer-connect-sql-server-1997-databases-using-via.md @@ -0,0 +1,11 @@ +### SqlConnection は VIA アダプターを使用して SQL Server 1997 またはデータベースに接続できなくなりました + +| | | +|---|---| +|説明|[仮想インターフェイス アダプター (VIA) プロトコル](https://technet.microsoft.com/library/ms191229%28v=sql.105%29.aspx)を使用した SQL Server データベースへの接続はサポートされなくなりました。 SQL Server データベースへの接続に使用されるプロトコルは、接続文字列で表示されます。 VIA 接続には via:<servername> が含まれます。 このアプリが VIA 以外のプロトコル (tcp: や np: など) を介して SQL に接続される場合、破壊的変更は検出されません。また、SQL Server 7 (1997) への接続がサポートされなくなります。| +|提案される解決策|VIA プロトコルは推奨されていないので、SQL データベースに接続するには別のプロトコルを使用する必要があります。 最も一般的に使用されるプロトコルは TCP/IP です。 TCP/IP プロトコルを有効にするための手順については、[こちら](https://msdn.microsoft.com/library/bb909712.aspx)を参照してください。 データベースへのアクセスがイントラネット内からに限定されていて、ネットワーク速度が遅い場合は、共有パイプ プロトコルがより優れたパフォーマンスを提供する可能性があります。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/data/sqlconnectionopen-fails-on-windows-7-with-non-ifs-winsock-bsp-lsp-present.md b/includes/migration-guide/runtime/data/sqlconnectionopen-fails-on-windows-7-with-non-ifs-winsock-bsp-lsp-present.md new file mode 100644 index 00000000000..e68c3bab8f7 --- /dev/null +++ b/includes/migration-guide/runtime/data/sqlconnectionopen-fails-on-windows-7-with-non-ifs-winsock-bsp-lsp-present.md @@ -0,0 +1,11 @@ +### IFS 以外の Winsock BSP または LSP が存在する Windows 7 で SqlConnection.Open が失敗する + +| | | +|---|---| +|説明| および は、コンピューター上に IFS 以外の Winsock BSP または LSP が存在する Windows 7 コンピューターで実行している場合、.NET Framework 4.5 では失敗します。IFS 以外の BSP または LSP がインストールされているかどうかを確認するには、netsh WinSock Show Catalog コマンドを使用して、返される Winsock Catalog Provider Entry 項目をすべて調べてください。 Service Flags 値の 0x20000 ビットがセットされている場合、プロバイダーは IFS ハンドルを使用していて、正しく機能します。 0x20000 ビットがクリアされている (セットされていない) 場合は、IFS 以外の BSP または LSP です。| +|提案される解決策|このバグは .NET framework 4.5.2 で修正されたため、.NET Framework をアップグレードすることによって回避できます。 または、インストールされている IFS 以外の Winsock LSP を削除することによって回避できます。| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/data/sqlvariant-data-uses-collation-rather-than-database.md b/includes/migration-guide/runtime/data/sqlvariant-data-uses-collation-rather-than-database.md new file mode 100644 index 00000000000..3ec9204ec8b --- /dev/null +++ b/includes/migration-guide/runtime/data/sqlvariant-data-uses-collation-rather-than-database.md @@ -0,0 +1,10 @@ +### sql_variant データはデータベースの照合順序ではなく、sql_variant の照合順序を使用する + +| | | +|---|---| +|説明|sql_variant データはデータベースの照合順序ではなく sql_variant の照合順序を使用します。| +|提案される解決策|この変更により、データベースの照合順序が sql_variant の照合順序と異なる場合にデータ破損が生じる可能性に対応できます。 破損したデータに依存するアプリケーションでは、エラーが発生する場合があります。| +|スコープ|透明| +|Version|4.5| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/debugger/null-coalescer-values-are-not-visible-debugger-until-one-step-later.md b/includes/migration-guide/runtime/debugger/null-coalescer-values-are-not-visible-debugger-until-one-step-later.md new file mode 100644 index 00000000000..b662cd66575 --- /dev/null +++ b/includes/migration-guide/runtime/debugger/null-coalescer-values-are-not-visible-debugger-until-one-step-later.md @@ -0,0 +1,10 @@ +### デバッガーですぐに null コアレッサー値が表示されない + +| | | +|---|---| +|説明|.NET Framework 4.5 のバグにより、64 ビット版の Framework で実行中に代入演算が実行された直後に、デバッガーで null 合体演算で設定された値が表示されません。| +|提案される解決策|デバッガーでの操作に時間がかかると、ローカル/フィールドの値が正しく更新されなくなります。 この問題は .NET Framework 4.6 で修正されました。このバージョンの .NET Framework にアップグレードすれば、問題は解決します。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/ef/change-behavior-data-definition-language-ddl-apis.md b/includes/migration-guide/runtime/ef/change-behavior-data-definition-language-ddl-apis.md new file mode 100644 index 00000000000..5a5e2bb357d --- /dev/null +++ b/includes/migration-guide/runtime/ef/change-behavior-data-definition-language-ddl-apis.md @@ -0,0 +1,10 @@ +### データ定義言語 (DDL: Data Definition Language) API の動作の変更 + +| | | +|---|---| +|説明|AttachDBFilename が指定されたときの DDL API の動作が、次のように変更されました。
  • 接続文字列で初期カタログ値を指定する必要がなくなりました。 以前は、AttachDBFilename と初期カタログの両方が必要でした。
  • AttachDBFilename と初期カタログの両方が指定され、指定された MDF ファイルが存在した場合、ObjectContext.DatabaseExists メソッドは true を返します。 以前は、false を返していました。
  • AttachDBFilename と初期カタログの両方が指定され、指定された MDF ファイルが存在した場合、ObjectContext.DeleteDatabase メソッドを呼び出すと、ファイルは削除されます。
  • 接続文字列が存在しない MDF と存在しない初期カタログで AttachDBFilename の値を指定したときに ObjectContext.DeleteDatabase が呼び出された場合、メソッドは InvalidOperationException 例外をスローします。 以前は、SqlException 例外をスローしていました。
| +|提案される解決策|これらの変更により、DDL API を使用するアプリケーションおよびツールの構築が簡単になりました。 これらの変更は、次のシナリオでアプリケーションの互換性に影響を及ぼす可能性があります。
  • ユーザーは、ObjectContext.DatabaseExists が true を返した場合に ObjectContext.DeleteDatabase を呼び出す代わりに、DROP DATABASE コマンドを直接実行するコードを作成します。 データベースがアタッチされておらず、MDF ファイルが存在する場合、これによって既存のコードが破損します。
  • ユーザーは、初期カタログと MDF ファイルが存在しないとき、ObjectContext.DeleteDatabase メソッドが InvalidOperationException 例外ではなく、SqlException 例外をスローすることを前提としたコードを作成します。
| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/ef/different-exception-handling-for-objectcontextcreatedatabase.md b/includes/migration-guide/runtime/ef/different-exception-handling-for-objectcontextcreatedatabase.md new file mode 100644 index 00000000000..96b693e82e1 --- /dev/null +++ b/includes/migration-guide/runtime/ef/different-exception-handling-for-objectcontextcreatedatabase.md @@ -0,0 +1,11 @@ +### ObjectContext.CreateDatabase メソッドと DbProviderServices.CreateDatabase メソッドで異なる例外処理 + +| | | +|---|---| +|説明|.NET 4.5 から、データベースの作成が失敗した場合、CreateDatabase メソッドは、空のデータベースの削除を試みます。 その操作が成功した場合、元の は伝播されます (.NET 4.0 で常にスローされていた の代わりに)。| +|提案される解決策| または の実行中に をキャッチするときには、SQLExceptions もキャッチする必要があります。| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/ef/ef-no-longer-throws-for-queryviews-with-specific-characteristics.md b/includes/migration-guide/runtime/ef/ef-no-longer-throws-for-queryviews-with-specific-characteristics.md new file mode 100644 index 00000000000..f76bae18214 --- /dev/null +++ b/includes/migration-guide/runtime/ef/ef-no-longer-throws-for-queryviews-with-specific-characteristics.md @@ -0,0 +1,10 @@ +### EF で特定の特性を持つ QueryViews がスローされなくなった + +| | | +|---|---| +|説明|クエリの一部として関連エンティティを含めようとする 0..1 ナビゲーション プロパティを使用して QueryViews に関係するクエリをアプリが実行する場合、Entity Framework で 例外がスローされなくなりました。 たとえば、.Include(e => e.RelatedNavProp) を呼び出す場合です。| +|提案される解決策|この変更は、.Include を呼び出すクエリの実行時に 1 - 0..1 の関係にある QueryViews を使用するコードにのみ影響します。 これにより信頼性が向上し、ほとんどすべてのアプリに対して透過的になります。 ただし、予期しない動作が発生する場合、次のエントリをアプリの構成ファイルの <appSettings> セクションに追加することにより、この変更を無効にできます。
<add key="EntityFramework_SimplifyUserSpecifiedViews" value="false" />
| +|スコープ|エッジ| +|Version|4.5.2| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/ef/entityframework-60-loads-very-slowly-apps-launched-from-visual-studio.md b/includes/migration-guide/runtime/ef/entityframework-60-loads-very-slowly-apps-launched-from-visual-studio.md new file mode 100644 index 00000000000..9301c766df1 --- /dev/null +++ b/includes/migration-guide/runtime/ef/entityframework-60-loads-very-slowly-apps-launched-from-visual-studio.md @@ -0,0 +1,10 @@ +### EntityFramework 6.0 は、Visual Studio から起動されたアプリを読み込むとき、非常に遅くなる + +| | | +|---|---| +|説明|Entity Framework 6.0 を使用するアプリを Visual Studio 2013 から起動すると、非常に遅くなることがあります。| +|提案される解決策|この問題は、EntityFramework 6.0.2 で修正されます。 パフォーマンス問題を回避するには、EntityFramework を更新してください。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/ef/log-file-name-created-by-objectcontextcreatedatabase-method-has-changed.md b/includes/migration-guide/runtime/ef/log-file-name-created-by-objectcontextcreatedatabase-method-has-changed.md new file mode 100644 index 00000000000..c02c9175127 --- /dev/null +++ b/includes/migration-guide/runtime/ef/log-file-name-created-by-objectcontextcreatedatabase-method-has-changed.md @@ -0,0 +1,11 @@ +### ObjectContext.CreateDatabase メソッドによって作成されたログ ファイル名が、SQL Server の仕様に一致するように変更された + +| | | +|---|---| +|説明| メソッドが、直接、または SqlClient プロバイダーと共に Code First と接続文字列の AttachDBFilename 値を使用して呼び出されると、filename.ldf (filename は AttachDBFilename 値によって指定されたファイルの名前) ではなく、filename_log.ldf という名前のログ ファイルを作成します。 この変更により、SQL Server の仕様に従ってログ ファイル名が提供されるため、デバッグ機能が向上します。| +|提案される解決策|ログ ファイル名がアプリケーションにとって重要な場合、標準の _log.ldf ファイル名形式を予期するように、アプリケーションを更新する必要があります。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/ef/objectcontexttranslate-objectcontextexecutestorequery-now-support-enum-type.md b/includes/migration-guide/runtime/ef/objectcontexttranslate-objectcontextexecutestorequery-now-support-enum-type.md new file mode 100644 index 00000000000..2375c47e351 --- /dev/null +++ b/includes/migration-guide/runtime/ef/objectcontexttranslate-objectcontextexecutestorequery-now-support-enum-type.md @@ -0,0 +1,11 @@ +### ObjectContext.Translate と ObjectContext.ExecuteStoreQuery で列挙型がサポートされるようになった + +| | | +|---|---| +|説明|.NET 4.0 では、ObjectContext.Translate および ObjectContext.ExecuteStoreQuery メソッドのジェネリック パラメーター T は、列挙型にできませんでした。 このシナリオがサポートされるようになりました。| +|提案される解決策|.NET 4.0 では、列挙型に対して Translate または ExecuteStoreQuery が呼び出された場合、「0」が返されました。 この動作が望ましい場合は、呼び出しを定数 0 (または同等の列挙型) に置き換えてください。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/ef/opt-in-break-revert-from-different-45-sql-generation-simpler-40.md b/includes/migration-guide/runtime/ef/opt-in-break-revert-from-different-45-sql-generation-simpler-40.md new file mode 100644 index 00000000000..bb990573243 --- /dev/null +++ b/includes/migration-guide/runtime/ef/opt-in-break-revert-from-different-45-sql-generation-simpler-40.md @@ -0,0 +1,10 @@ +### 異なる 4.5 SQL 生成からより単純な 4.0 SQL 生成に戻す + +| | | +|---|---| +|説明|最初に OrderBy を使用せずに JOIN ステートメントを生成し、制限操作への呼び出しを含むクエリで、より単純な SQL が生成されるようになりました。 .NET Framework 4.5 へのアップグレード後、これらのクエリは以前のバージョンよりも複雑な SQL を生成しました。| +|提案される解決策|既定では、この機能は無効です。 Entity Framework がパフォーマンスを低下させる追加の JOIN ステートメントを生成する場合は、アプリケーション構成 (app.config) ファイルの <appSettings> セクションへ次のエントリを追加してこの機能を有効にできます。
<add key="EntityFramework_SimplifyLimitOperations" value="true" />
| +|スコープ|透明| +|Version|4.5.2| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/globalization/unicode-standard-version-80-categories-now-supported.md b/includes/migration-guide/runtime/globalization/unicode-standard-version-80-categories-now-supported.md new file mode 100644 index 00000000000..0f06bb6633f --- /dev/null +++ b/includes/migration-guide/runtime/globalization/unicode-standard-version-80-categories-now-supported.md @@ -0,0 +1,11 @@ +### Unicode 標準バージョン 8.0 のカテゴリのサポート開始 + +| | | +|---|---| +|説明|.NET Framework 4.6.2 で、フレームワークの Unicode データが Unicode 標準バージョン 6.3 からバージョン 8.0 にアップグレードされました。 .NET Framework 4.6.2 で Unicode 文字カテゴリを要求すると、いくつかの結果が以前の .NET Framework バージョンの結果と一致しない可能性があります。 この変更は、主にチェロキーの音節、新タイ ロ文字の母音記号および声調記号に影響します。| +|提案される解決策|コードを確認し、ハードコーディングされた Unicode 文字カテゴリに依存するロジックを削除/変更します。| +|スコープ|マイナー| +|Version|4.6.2| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/jit/incorrect-code-generation-when-passing-comparing-uint16-values.md b/includes/migration-guide/runtime/jit/incorrect-code-generation-when-passing-comparing-uint16-values.md new file mode 100644 index 00000000000..74530f5003b --- /dev/null +++ b/includes/migration-guide/runtime/jit/incorrect-code-generation-when-passing-comparing-uint16-values.md @@ -0,0 +1,10 @@ +### UInt16 値を渡して比較する場合にコード生成が正しく行われません + +| | | +|---|---| +|説明|.NET Framework 4.7 で変更が導入されたため、.NET Framework 4.7 で実行されているアプリケーションの JIT コンパイラによって生成されたコードが 2 つの T:System.UInt16 値を正しく比較しない場合があります。 詳細については、GitHub.com の「[Issue #11508: Silent bad codegen when passing and comparing ushort args](https://github.com/dotnet/coreclr/issues/11508)」 (問題 #11508: ushort の引数を渡して比較する場合のサイレントかつ不適切な codegen ) を参照してください。| +|提案される解決策|.NET Framework 4.7 で 16 ビットの符号なし値を比較したときに問題が検出された場合は、.NET Framework 4.7.1 にアップグレードしてください。| +|スコープ|エッジ| +|Version|4.7| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/linq/enumerableemptylttresultgt-always-returns-cached-instance.md b/includes/migration-guide/runtime/linq/enumerableemptylttresultgt-always-returns-cached-instance.md new file mode 100644 index 00000000000..1238d4e6005 --- /dev/null +++ b/includes/migration-guide/runtime/linq/enumerableemptylttresultgt-always-returns-cached-instance.md @@ -0,0 +1,11 @@ +### Enumerable.Empty<TResult> は、常にキャッシュされたインスタンスを返します + +| | | +|---|---| +|説明|.NET 4.5 以降では、 は、常にキャッシュされた内部インスタンス を返します。以前は、 は、API が呼び出された時点で空の をキャッシュしました。つまり、 が迅速かつ同時に呼び出されるような条件では、API の別の呼び出しに対して、型の別のインスタンスが返される可能性がありました。| +|提案される解決策|以前の動作は非確定的なため、コードがそれに依存している可能性は低いです。 ただし、ありそうにないことですが、空の列挙が比較され、ときには等しくないことが予期されている場合には、 を使用する代わりに、明示的に空の配列を作成する (new T[0]) 必要があります。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/mef/mef-catalogs-implement-ienumerable-therefore-can-no-longer-be-used-create.md b/includes/migration-guide/runtime/mef/mef-catalogs-implement-ienumerable-therefore-can-no-longer-be-used-create.md new file mode 100644 index 00000000000..b0ea75abd02 --- /dev/null +++ b/includes/migration-guide/runtime/mef/mef-catalogs-implement-ienumerable-therefore-can-no-longer-be-used-create.md @@ -0,0 +1,10 @@ +### MEF カタログは IEnumerable を実装するため、シリアライザーの作成には使用できなくなった + +| | | +|---|---| +|説明|.NET Framework 4.5 以降では、MEF カタログは IEnumerable を実装するため、シリアライザー ( オブジェクト) の作成には使用できなくなりました。 MEF カタログをシリアル化しようとすると、例外がスローされます。| +|提案される解決策|シリアライザーの作成に MEF を使用できなくなりました。| +|スコープ|Major| +|バージョン|4.5| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/networking/contentdisposition-datetimes-returns-slightly-different-string.md b/includes/migration-guide/runtime/networking/contentdisposition-datetimes-returns-slightly-different-string.md new file mode 100644 index 00000000000..23874068b69 --- /dev/null +++ b/includes/migration-guide/runtime/networking/contentdisposition-datetimes-returns-slightly-different-string.md @@ -0,0 +1,11 @@ +### ContentDisposition DateTimes で少し異なる文字列が返される + +| | | +|---|---| +|説明| の文字列表現が更新され、4.6 以降では、常に の時間コンポーネントが 2 桁で表されます。 これは、[RFC822](http://www.ietf.org/rfc/rfc0822.txt) と [RFC2822](http://www.ietf.org/rfc/rfc2822.txt) に準拠しています。 これにより、4.6 では、配置の時間要素の 1 つが午前 10 時より前のシナリオでは、 は少し異なる文字列を返します。 ContentDispositions は文字列への変換によってシリアル化される場合があるため、 操作、シリアル化、または GetHashCode 呼び出しを見直す必要があることに注意してください。| +|提案される解決策|異なるバージョンの .NET Framework からの ContentDispotisions の文字列表現が互いに正しく対応することを期待しないでください。 可能な場合は、比較を行う前に、文字列を ContentDispositions に戻してください。| +|スコープ|マイナー| +|Version|4.6| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/networking/deserialization-mailmessage-objects-serialized-under-net-framework-45-may.md b/includes/migration-guide/runtime/networking/deserialization-mailmessage-objects-serialized-under-net-framework-45-may.md new file mode 100644 index 00000000000..1cd5b99f8e2 --- /dev/null +++ b/includes/migration-guide/runtime/networking/deserialization-mailmessage-objects-serialized-under-net-framework-45-may.md @@ -0,0 +1,11 @@ +### .NET Framework 4.5 でシリアル化された MailMessage オブジェクトの逆シリアル化が失敗する可能性がある + +| | | +|---|---| +|説明|.NET Framework 4.5 以降では、 オブジェクトに非 ASCII 文字を含めることができます。 .NET Framework 4 では、ASCII 文字しかサポートされていません。 非 ASCII 文字が含まれ、.NET Framework 4.5 以降でシリアル化された オブジェクトは、.NET Framework 4 で逆シリアル化することはできません。| +|提案される解決策| オブジェクトの逆シリアル化時に、コードで例外処理が提供されることを確認します。| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/networking/systemnetpeertopeercollaboration-unavailable-on-windows-8.md b/includes/migration-guide/runtime/networking/systemnetpeertopeercollaboration-unavailable-on-windows-8.md new file mode 100644 index 00000000000..abf425ed2b1 --- /dev/null +++ b/includes/migration-guide/runtime/networking/systemnetpeertopeercollaboration-unavailable-on-windows-8.md @@ -0,0 +1,11 @@ +### Windows 8 で System.Net.PeerToPeer.Collaboration が使用できない + +| | | +|---|---| +|説明|System.Net.PeerToPeer.Collaboration 名前空間は、Windows 8 以上では使用できません。| +|提案される解決策|Windows 8 以上をサポートするアプリは、この名前空間またはそのメンバーに依存しないように更新する必要があります。| +|スコープ|Major| +|バージョン|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/security/rsacng-dsacng-are-once-again-usable-partial-trust-scenarios.md b/includes/migration-guide/runtime/security/rsacng-dsacng-are-once-again-usable-partial-trust-scenarios.md new file mode 100644 index 00000000000..69517888e19 --- /dev/null +++ b/includes/migration-guide/runtime/security/rsacng-dsacng-are-once-again-usable-partial-trust-scenarios.md @@ -0,0 +1,11 @@ +### 部分信頼のシナリオで RSACng と DSACng が再び使用可能に + +| | | +|---|---| +|説明|CngLightup ( などの複数の上位レベル暗号化 API で使われます) および は、完全信頼に依存する場合があります。 たとえば、 アクセス許可をアサートしない P/Invoke や、 に に対するアクセス許可要求があるコード パスなどです。 .NET Framework 4.6.2 以降では、CngLightup は可能な場合に常に に切り替えるために使われました。 その結果、 を正常に使っていた部分信頼アプリが、失敗して 例外をスローするようになりました。この変更では、CngLightup を使っているすべての関数が必要なアクセス許可を持つように、必要なアサートが追加されます。| +|提案される解決策|.NET Framework 4.6.2 でのこの変更により部分信頼アプリに悪影響があった場合は、.NET Framework 4.7.1 にアップグレードしてください。| +|スコープ|エッジ| +|Version|4.6.2| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/security/rsacngverifyhash-now-returns-false-for-any-verification-failure.md b/includes/migration-guide/runtime/security/rsacngverifyhash-now-returns-false-for-any-verification-failure.md new file mode 100644 index 00000000000..c4ad08627c3 --- /dev/null +++ b/includes/migration-guide/runtime/security/rsacngverifyhash-now-returns-false-for-any-verification-failure.md @@ -0,0 +1,11 @@ +### RSACng.VerifyHash で検証が失敗した場合に False が返されるようになった + +| | | +|---|---| +|説明|.NET Framework 4.6.2 以降では、署名自体の形式が正しくない場合、このメソッドでは False が返されます。 今すぐ false を返しますの検証に失敗しました。 .NET Framework 4.6 および 4.6.1 では、メソッドによってスローされる、署名自体が正しくフォーマットされている場合。| +|提案される解決策|検証が失敗し、メソッドで False が返される場合は、代わりにその実行が の処理に依存するコードが実行される必要があります。| +|スコープ|マイナー| +|Version|4.6.2| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/security/signedxml-encryptedxml-breaking-changes.md b/includes/migration-guide/runtime/security/signedxml-encryptedxml-breaking-changes.md new file mode 100644 index 00000000000..a702a3d9f9f --- /dev/null +++ b/includes/migration-guide/runtime/security/signedxml-encryptedxml-breaking-changes.md @@ -0,0 +1,11 @@ +### SignedXml と EncryptedXml の互換性に影響する変更点 + +| | | +|---|---| +|説明|.NET Framework 4.6.2 では、 および のセキュリティ修正プログラムにより、実行時の動作が変わります。 たとえば、オブジェクトに適用された
  • ドキュメントに id 属性が同じ値の複数の要素があり、署名でそれらの要素の 1 つが署名のルートとして指定されている場合、ドキュメントは無効と見なされるようになります。
  • 参照で非正規 XPath 変換アルゴリズムを使っているドキュメントは、無効と見なされるようになります。
  • 参照で非正規 XSLT 変換アルゴリズムを使っているドキュメントは、無効と見なされるようになります。
  • 外部リソースのデタッチされた署名を利用しているプログラムは、利用できなくなります。
| +|提案される解決策|ドキュメントの受信者が処理できない可能性があるため、開発者は と の使用、および の派生型を確認することが必要な場合があります。| +|スコープ|マイナー| +|Version|4.6.2| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/serialization/binaryformatter-can-fail-find-type-from-loadfrom-context.md b/includes/migration-guide/runtime/serialization/binaryformatter-can-fail-find-type-from-loadfrom-context.md new file mode 100644 index 00000000000..20ed472a37c --- /dev/null +++ b/includes/migration-guide/runtime/serialization/binaryformatter-can-fail-find-type-from-loadfrom-context.md @@ -0,0 +1,11 @@ +### BinaryFormatter による LoadFrom コンテキストからの型の検索が失敗する場合がある + +| | | +|---|---| +|説明|.NET Framework 4.5 の時点で、 の複数の変更により、LoadFrom コンテキストに読み込まれた型の を使った逆シリアル化に違いが発生する場合があります。 これらの変更は が型を読み込む新しい方法によるものであり、後で がその型に逆シリアル化しようとするときに異なる動作が発生します。 既定のシリアル化バインダーは LoadFrom コンテキストを自動的に検索しませんが、状況によっては XmlSerializer の以前の動作に基づいて機能する可能性があります。 変更のため、異なるコンテキストで読み込まれたアセンブリから型が読み込まれるときに、 がスローされる可能性があります。| +|提案される解決策|この例外が発生する場合は、 の Binder プロパティを、正しい型を検索するカスタム バインダーに設定することができます。
var formatter = new BinaryFormatter { Binder = new TypeFinderBinder() }
そして、カスタム バインダーで次のようにします。
public class TypeFinderBinder : SerializationBinder
{
private static readonly string s_assemblyName = Assembly.GetExecutingAssembly().FullName;

public override Type BindToType(string assemblyName, string typeName)
{
return Type.GetType(String.Format(CultureInfo.InvariantCulture, "{0}, {1}", typeName, s_assemblyName));
}
}
| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/serialization/exception-message-has-changed-for-failed-datacontract-serialization-case-an.md b/includes/migration-guide/runtime/serialization/exception-message-has-changed-for-failed-datacontract-serialization-case-an.md new file mode 100644 index 00000000000..ed0b4d5c0c6 --- /dev/null +++ b/includes/migration-guide/runtime/serialization/exception-message-has-changed-for-failed-datacontract-serialization-case-an.md @@ -0,0 +1,11 @@ +### 不明な型の場合に失敗した DataContract シリアル化の例外メッセージが変更された + +| | | +|---|---| +|説明|.NET Framework 4.6 以降では、"既知の型" がないために または のシリアル化または逆シリアル化が失敗した場合に提供される例外メッセージが明確化されました。| +|提案される解決策|アプリは、特定の例外メッセージに依存しないようにする必要があります。 アプリがこのメッセージに依存している場合は、新しいメッセージを使うように更新するか、(可能であれば) 例外の種類のみに依存するように変更してください。| +|スコープ|エッジ| +|Version|4.6| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/serialization/soapformatter-cannot-deserialize-hashtable-similar-ordered-collection.md b/includes/migration-guide/runtime/serialization/soapformatter-cannot-deserialize-hashtable-similar-ordered-collection.md new file mode 100644 index 00000000000..94be3bf56f7 --- /dev/null +++ b/includes/migration-guide/runtime/serialization/soapformatter-cannot-deserialize-hashtable-similar-ordered-collection.md @@ -0,0 +1,11 @@ +### SoapFormatter は、ハッシュテーブルなどの順序付けられたコレクション オブジェクトを逆シリアル化できない + +| | | +|---|---| +|説明| は、特定のバージョンの .NET Framework でシリアル化されたオブジェクトが別のバージョンで正常に逆シリアル化されることを保証しません。 具体的には、( のような) 順序付けられたコレクションの中には、4.0 と 4.5 の間でメンバーが追加されたものがあり、このような種類のオブジェクトが .NET 4.5 でシリアル化された場合、.NET 4.0 では逆シリアル化できません。 シリアル化データのシリアル化と逆シリアル化の両方が同じバージョンの .NET Framework で行われた場合、問題は発生しないことに注意してください。| +|提案される解決策| のシリアル化は、.NET Framework の変更に対応できる のシリアル化または に置き換える必要があります。| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/serialization/xmlserializer-fails-while-serializing-type-that-hides-an-accessible-member.md b/includes/migration-guide/runtime/serialization/xmlserializer-fails-while-serializing-type-that-hides-an-accessible-member.md new file mode 100644 index 00000000000..13b802cb16f --- /dev/null +++ b/includes/migration-guide/runtime/serialization/xmlserializer-fails-while-serializing-type-that-hides-an-accessible-member.md @@ -0,0 +1,11 @@ +### アクセス可能なメンバーを非表示にする型をアクセス不可のメンバーでシリアル化すると、XmlSerializer が失敗する + +| | | +|---|---| +|説明|基本型で (パブリックなど) 以前はアクセス可能だった同じ名前のフィールドまたはプロパティを ("新しい" キーワードを使用して) 非表示にするアクセス不可のフィールドまたはプロパティが型に含まれている場合、派生型をシリアル化すると、 が失敗する可能性があります。| +|提案される解決策|この問題は、新しい非表示メンバーを にアクセスできるようにする (パブリックにするなど) ことで解決できます。または、次の構成設定で 4.0 の動作に戻します。これにより、問題が解決されます。
<system.xml.serialization>
<xmlSerializer useLegacySerializerGeneration="true" />
</system.xml.serialization>
| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/setup/net-framework-46-does-not-use-45xx-version-when-registering-itself-registry.md b/includes/migration-guide/runtime/setup/net-framework-46-does-not-use-45xx-version-when-registering-itself-registry.md new file mode 100644 index 00000000000..221d52e4b9c --- /dev/null +++ b/includes/migration-guide/runtime/setup/net-framework-46-does-not-use-45xx-version-when-registering-itself-registry.md @@ -0,0 +1,10 @@ +### .NET Framework 4.6 は、自分自身をレジストリに登録するときに 4.5.x.x バージョンを使用しない + +| | | +|---|---| +|説明|予想されるように、.NET Framework 4.6 に対してレジストリ (HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full) に設定されるバージョン キーは、"4.5" ではなく "4.6" で始まります。 これらのレジストリ キーに依存してコンピューターにインストールされている .NET Framework のバージョンを特定するアプリは、4.6 が可能な新しいバージョンであり、前の 4.5.x リリースと互換性があることを認識するように、更新する必要があります。| +|提案される解決策|4.5 のレジストリ キーを検索することによって .NET Framework 4.5 のインストールを調べるアプリを、4.6 も受け付けるように更新します。| +|スコープ|エッジ| +|Version|4.6| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/setup/product-versioning-changes-net-framework-46-later-versions.md b/includes/migration-guide/runtime/setup/product-versioning-changes-net-framework-46-later-versions.md new file mode 100644 index 00000000000..8dc3ab31f90 --- /dev/null +++ b/includes/migration-guide/runtime/setup/product-versioning-changes-net-framework-46-later-versions.md @@ -0,0 +1,10 @@ +### .NET Framework 4.6 以降のバージョンでの製品のバージョン管理に関する変更点 + +| | | +|---|---| +|説明|製品のバージョン管理が、.NET Framework の以前のリリース (特に .NET Framework 4、4.5、4.5.1、および 4.5.2) から変更されました。変更の詳細は次のとおりです。
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full キーの Version エントリの値が、.NET Framework 4.6 とそのポイント リリースの場合は 4.6.xxxxx に、.NET Framework 4.7 と 4.7.1 の場合は 4.7.xxxxx に、それぞれ変更されました。 .NET Framework 4.5、4.5.1、および 4.5.2 では、4.5.xxxxx という形式でした。
  • .NET Framework ファイルにおけるファイルおよび製品のバージョン管理は、以前のバージョン管理方式である 4.0.30319.x から、.NET Framework 4.6 とそのポイント リリースの場合は 4.6.X.0 に、.NET Framework 4.7 と 4.7.1 の場合は 4.7.X.0 に、それぞれ変更されました。 ファイルを右クリックしてファイルの [プロパティ] を表示すると、これらの新しい値を確認できます。
  • マネージド アセンブリの 属性と 属性の Version 値は、.NET Framework 4.6 とそのポイント リリースの場合は 4.6.X.0 という形式に、.NET Framework 4.7 と 4.7.1 の場合は 4.7.X.0 という形式になります。
  • .NET Framework 4.6、4.6.1、4.6.2、4.7、4.7.1 では、 プロパティは固定のバージョン文字列 4.0.30319.42000 を返します。 .NET Framework 4、4.5、4.5.1、および 4.5.2 では、4.0.30319.xxxxx という形式のバージョン文字列が返されます (例: "4.0.30319.18010")。 アプリケーションのコードで Environment.Version プロパティに新しい依存関係を設定することは推奨されていないことに注意してください。
詳しくは、「[方法: インストールされている .NET Framework バージョンを確認する](~/docs/framework/migration-guide/how-to-determine-which-versions-are-installed.md)」をご覧ください。| +|提案される解決策|一般に、.NET Framework のランタイムのバージョンやインストール ディレクトリを検出する際、アプリケーションは推奨される技法に従う必要があります。
  • .NET Framework のランタイムのバージョンを検出するには、「[方法 : インストールされている .NET Framework バージョンを確認する](~/docs/framework/migration-guide/how-to-determine-which-versions-are-installed.md)」を参照してください。
  • .NET Framework のインストール パスを確認するには、HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full キーの InstallPath エントリの値を使用します。
[!IMPORTANT] サブキー名は、.NET Framework Setup ではなく NET Framework Setup です。
  • .NET Framework の共通言語ランタイムへのディレクトリ パスを確認するには、 メソッドを呼び出します。
  • CLR のバージョンを取得するには、 メソッドを呼び出します。 .NET Framework 4 とそのポイント リリース (.NET Framework 4.5、4.5.1、4.5.2、および .NET Framework 4.6、4.6.1、4.6.2、4.7、4.7.1) の場合、このメソッドは文字列 v4.0.30319 を返します。
| +|スコープ|マイナー| +|Version|4.6| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/tools/contractinvariant-contractrequirestexception-do-not-consider.md b/includes/migration-guide/runtime/tools/contractinvariant-contractrequirestexception-do-not-consider.md new file mode 100644 index 00000000000..e6e5a01379d --- /dev/null +++ b/includes/migration-guide/runtime/tools/contractinvariant-contractrequirestexception-do-not-consider.md @@ -0,0 +1,11 @@ +### Contract.Invariant または Contract.Requires が String.IsNullOrEmpty の純粋性を考慮しない + +| | | +|---|---| +|説明|.NET Framework 4.6.1 が対象のアプリでは、 の不変コントラクトまたは の実行前の状態のコントラクトが メソッドを呼び出した場合、リライターはコンパイラの警告 CC1036: "Detected call to method 'System.String.IsNullOrWhiteSpace(System.String)' without [Pure] in method." を生成します。これはコンパイラ エラーではなく、コンパイラ警告です。| +|提案される解決策|この動作については [GitHubの問題 #339](https://github.com/Microsoft/CodeContracts/issues/339) で報告されています。 この警告が表示されないようにするには、コード コントラクト ツールのソース コードの更新バージョンを [GitHub](https://github.com/Microsoft/CodeContracts/blob/master/README.md) からダウンロードしてコンパイルします。 ページ下部から情報をダウンロードできます。| +|スコープ|マイナー| +|Version|4.6.1| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wcf/error-codes-for-maxrequestlength-maxreceivedmessagesize-are-different.md b/includes/migration-guide/runtime/wcf/error-codes-for-maxrequestlength-maxreceivedmessagesize-are-different.md new file mode 100644 index 00000000000..da858bf386a --- /dev/null +++ b/includes/migration-guide/runtime/wcf/error-codes-for-maxrequestlength-maxreceivedmessagesize-are-different.md @@ -0,0 +1,10 @@ +### maxRequestLength または maxReceivedMessageSize のエラー コードが異なる + +| | | +|---|---| +|説明|Internet Information Services (IIS) または ASP.NET 開発サーバーでホストされており、maxRequestLength (ASP.NET の場合) または maxReceivedMessageSize (WCF の場合) を超える WCF Web サービスのメッセージに異なるエラー コードがあります。HTTP 状態コードは 400 (正しくない要求) から 413 (要求したエンティティが大きすぎます) に変更され、maxRequestLength または maxReceivedMessageSize 設定を超えるメッセージでは 例外がスローされます。 これには、転送モードが Streamed である場合も含まれます。| +|提案される解決策|この変更により、メッセージ長が ASP.NET または WCF で許可されている制限を超えたときのデバッグが簡単になります。HTTP 400 状態コードに基づいて処理を実行するコードはすべて変更する必要があります。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/wcf/minfreememorypercentagetoactiveservice-now-respected.md b/includes/migration-guide/runtime/wcf/minfreememorypercentagetoactiveservice-now-respected.md new file mode 100644 index 00000000000..2b733f547f5 --- /dev/null +++ b/includes/migration-guide/runtime/wcf/minfreememorypercentagetoactiveservice-now-respected.md @@ -0,0 +1,10 @@ +### MinFreeMemoryPercentageToActiveService が順守されるようになった + +| | | +|---|---| +|説明|この設定は、WCF サービスをアクティブにするためにサーバー上で使用できなければならない最小メモリを設定します。 例外が発生しないようにデザインされています。 .NET Framework 4.5 では、この設定には効果はありません。 .NET Framework 4.5.1 では、この設定が守られます。| +|提案される解決策|Web サーバーで使用できる空きメモリが構成設定によって定義されたパーセンテージよりも小さい場合、例外が発生します。 制約されたメモリ環境で正常に開始し、実行された WCF サービスが今度は失敗することがあります。| +|スコープ|マイナー| +|Version|4.5.1| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/wcf/remove-ssl3-from-wcf-transportdefaults.md b/includes/migration-guide/runtime/wcf/remove-ssl3-from-wcf-transportdefaults.md new file mode 100644 index 00000000000..ecd778f0a18 --- /dev/null +++ b/includes/migration-guide/runtime/wcf/remove-ssl3-from-wcf-transportdefaults.md @@ -0,0 +1,11 @@ +### WCF TransportDefaults からの Ssl3 の削除 + +| | | +|---|---| +|説明|トランスポート セキュリティで NetTcp を使用し、証明書の資格情報の種類を使用する場合、SSL 3 プロトコルは、安全な接続のネゴシエーションに使用される既定のプロトコルではなくなりました。 TLS 1.0 は常に NetTcp のプロトコル一覧に含まれているため、ほとんどの場合、既存のアプリには影響はないと考えられます。 既存のすべてのクライアントは TLS 1.0 以降を使用して接続をネゴシエートできるようになりました。| +|提案される解決策|Ssl3 が必要な場合は、以下の構成メカニズムのいずれかを使用して、ネゴシエートされたプロトコルの一覧に Ssl3 を追加します。
  • [<](~/docs/framework/configure-apps/file-schema/wcf/transport-of-nettcpbinding.md)
  • [<customBinding> の <sslStreamSecurity> セクション]~/docs/framework/configure-apps/file-schema/wcf/sslstreamsecurity.md)
| +|スコープ|エッジ| +|Version|4.6.2| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wcf/replace-method-odata-urls-disabled-by-default.md b/includes/migration-guide/runtime/wcf/replace-method-odata-urls-disabled-by-default.md new file mode 100644 index 00000000000..a8985dec65c --- /dev/null +++ b/includes/migration-guide/runtime/wcf/replace-method-odata-urls-disabled-by-default.md @@ -0,0 +1,11 @@ +### OData URL の Replace メソッドが既定で無効になる + +| | | +|---|---| +|説明|.NET Framework 4.5 以降では、OData URL の Replace メソッドは既定では無効です。 OData Replace が無効のとき (既定)、replace 関数を含むユーザー要求 (一般的ではない) は失敗します。| +|提案される解決策|Replace メソッドが必要な場合 (一般的ではない)、構成設定 () によって再び有効にできます。 ただし、有効になった replace メソッドはセキュリティの脆弱性を開くことがあり、慎重にレビューしてから使用する必要があります。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wcf/systemservicemodelwebwebservicehost-object-no-longer-adds-default-endpoint.md b/includes/migration-guide/runtime/wcf/systemservicemodelwebwebservicehost-object-no-longer-adds-default-endpoint.md new file mode 100644 index 00000000000..ff0a9897054 --- /dev/null +++ b/includes/migration-guide/runtime/wcf/systemservicemodelwebwebservicehost-object-no-longer-adds-default-endpoint.md @@ -0,0 +1,11 @@ +### System.ServiceModel.Web.WebServiceHost オブジェクトは、既定のエンドポイントを追加しなくなりました + +| | | +|---|---| +|説明| オブジェクトでは、アプリケーション コードによって明示的なエンドポイントが追加された場合に、既定のエンドポイントが追加されなくなりました。| +|提案される解決策|ユーザーが既定のエンドポイントに接続できることを期待していて、他の明示的なエンドポイントが に追加されている場合は、既定のエンドポイントも明示的に追加する必要があります ( を使用して)。| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wcf/wcf-addressheadercollection-now-throws-an-argumentexception-if-addressheader.md b/includes/migration-guide/runtime/wcf/wcf-addressheadercollection-now-throws-an-argumentexception-if-addressheader.md new file mode 100644 index 00000000000..2516dda20a2 --- /dev/null +++ b/includes/migration-guide/runtime/wcf/wcf-addressheadercollection-now-throws-an-argumentexception-if-addressheader.md @@ -0,0 +1,11 @@ +### addressHeader 要素が null の場合、WCF AddressHeaderCollection で ArgumentException がスローされるようになった + +| | | +|---|---| +|説明|.NET Framework 4.7.1 以降では、要素のいずれかが null の場合、 コンストラクターで がスローされます。 .NET Framework 4.7 以前のバージョンでは、例外はスローされません。| +|提案される解決策|.NET Framework 4.7.1 以降のバージョンでこの変更に関する互換性の問題が発生した場合は、次の行を app.config ファイルの <runtime> セクションに追加することで、無効にできます。
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableAddressHeaderCollectionValidation=true" />
</runtime>
</configuration>
| +|スコープ|マイナー| +|Version|4.7.1| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wcf/wcf-msmqsecurehashalgorithm-default-value-now-sha256.md b/includes/migration-guide/runtime/wcf/wcf-msmqsecurehashalgorithm-default-value-now-sha256.md new file mode 100644 index 00000000000..c036bbff38c --- /dev/null +++ b/includes/migration-guide/runtime/wcf/wcf-msmqsecurehashalgorithm-default-value-now-sha256.md @@ -0,0 +1,10 @@ +### WCF MsmqSecureHashAlgorithm の既定値が SHA256 になった + +| | | +|---|---| +|説明|.NET Framework 4.7.1 以降では、Msmq メッセージの WCF での既定のメッセージ署名アルゴリズムは SHA256 です。 .NET Framework 4.7 以前のバージョンでは、既定のメッセージ署名アルゴリズムは SHA1 です。| +|提案される解決策|.NET Framework 4.7.1 以降でこの変更に関する互換性の問題が発生した場合は、次の行を app.config ファイルの <runtime> セクションに追加することで、変更を無効にできます。
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.UseSha1InMsmqEncryptionAlgorithm=true" />
</runtime>
</configuration>
| +|スコープ|マイナー| +|Version|4.7.1| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/wcf/wcf-pipeconnectiongethashalgorithm-now-uses-sha256.md b/includes/migration-guide/runtime/wcf/wcf-pipeconnectiongethashalgorithm-now-uses-sha256.md new file mode 100644 index 00000000000..97ecf229ae4 --- /dev/null +++ b/includes/migration-guide/runtime/wcf/wcf-pipeconnectiongethashalgorithm-now-uses-sha256.md @@ -0,0 +1,10 @@ +### WCF PipeConnection.GetHashAlgorithm が SHA256 を使用するようになった + +| | | +|---|---| +|説明|.NET Framework 4.7.1 以降の Windows Communication Foundation は、SHA256 ハッシュを使用して名前付きパイプ用のランダムな名前を生成します。 .NET Framework 4.7 以前のバージョンでは、SHA1 ハッシュを使っていました。| +|提案される解決策|.NET Framework 4.7.1 以降でこの変更に関する互換性の問題が発生した場合は、次の行を app.config ファイルの <runtime> セクションに追加することで、変更を無効にできます。
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.ServiceModel.UseSha1InPipeConnectionGetHashAlgorithm=true" />
</runtime>
</configuration>
| +|スコープ|マイナー| +|Version|4.7.1| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/wcf/wcf-services-that-use-nettcp-with-ssl-security-md5-certificate.md b/includes/migration-guide/runtime/wcf/wcf-services-that-use-nettcp-with-ssl-security-md5-certificate.md new file mode 100644 index 00000000000..7157353ea41 --- /dev/null +++ b/includes/migration-guide/runtime/wcf/wcf-services-that-use-nettcp-with-ssl-security-md5-certificate.md @@ -0,0 +1,10 @@ +### SSL セキュリティと MD5 証明書認証で NETTCP を使用する WCF サービス + +| | | +|---|---| +|説明|.NET Framework 4.6 では、WCF SSL の既定のプロトコル一覧に TLS 1.1 および TLS 1.2 が追加されます。 クライアントとサーバーの両方のコンピューターに .NET Framework 4.6 以降がインストールされている場合は、TLS 1.2 がネゴシエーションに使用されます。TLS 1.2 では MD5 証明書認証がサポートされません。 このため、顧客が MD5 証明書を使用する場合、WCF クライアントでは WCF サービスへ接続できません。| +|提案される解決策|次のいずれかの操作を実行することで、この問題を回避して、WCF クライアントを WCF サーバーに接続できるようになります。
  • MD5 アルゴリズムを使用しないように証明書を更新します。 この解決策をお勧めします。
  • バインドがソース コードで動的に構成されていない場合は、TLS 1.1 または以前のバージョンのプロトコルを使用するようにアプリケーションの構成ファイルを更新します。 これにより、引き続き MD5 ハッシュ アルゴリズムによる証明書を使用することができます。
[!WARNING] MD5 ハッシュ アルゴリズムによる証明書は安全でないと見なされるため、この回避策はお勧めできません。
次の構成ファイルでこれを行います。
<configuration>
<system.serviceModel>
<bindings>
<netTcpBinding>
<binding>
<security mode= "None/Transport/Message/TransportWithMessageCredential" >
<transport clientCredentialType="None/Windows/Certificate"
protectionLevel="None/Sign/EncryptAndSign"
sslProtocols="Ssl3/Tls1/Tls11">
</transport>
</security>
</binding>
</netTcpBinding>
</bindings>
</system.ServiceModel>
</configuration>
  • バインドがソース コードで動的に構成されている場合は、ソース コード内で TLS 1.1 () または以前のバージョンのプロトコルを使用するように プロパティを更新します。
[!WARNING] MD5 ハッシュ アルゴリズムによる証明書は安全でないと見なされるため、この回避策はお勧めできません。
| +|スコープ|マイナー| +|Version|4.6| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/web/managed-browser-hosting-controls-from-net-framework-11-20-are-blocked.md b/includes/migration-guide/runtime/web/managed-browser-hosting-controls-from-net-framework-11-20-are-blocked.md new file mode 100644 index 00000000000..e59617758b3 --- /dev/null +++ b/includes/migration-guide/runtime/web/managed-browser-hosting-controls-from-net-framework-11-20-are-blocked.md @@ -0,0 +1,10 @@ +### .NET Framework 1.1 および 2.0 からのマネージド ブラウザーでのコントロールのホストがブロックされる + +| | | +|---|---| +|説明|これらのコントロールのホストは、Internet Explorer でブロックされます。| +|提案される解決策|Internet Explorer では、マネージ ブラウザーを使用してコントロールをホストするアプリケーションは起動できません。 以前の動作を復元するには、レジストリ サブキー HKLM/SOFTWARE/MICROSOFT/.NETFramework の EnableIEHosting 値を、x86 システム用および x64 システム上の 32 ビット プロセス用に 1 に設定し、レジストリ サブキー HKLM/SOFTWARE/Wow6432Node/Microsoft/.NETFramework の EnableIEHosting 値を x64 システム上の 64 ビット プロセス用に 1 に設定します。| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/wf/systemactivities-now-aptca.md b/includes/migration-guide/runtime/wf/systemactivities-now-aptca.md new file mode 100644 index 00000000000..8f793ecea3b --- /dev/null +++ b/includes/migration-guide/runtime/wf/systemactivities-now-aptca.md @@ -0,0 +1,10 @@ +### System.Activities が APTCA に + +| | | +|---|---| +|説明|アセンブリは 属性でマークされています。| +|提案される解決策|派生クラスに のマークを付けることはできません。 以前は、派生型に マークを付ける必要がありました。 ただし、この変更によって生じる実質的な影響はないはずです。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/wf/wf-serializes-expressionsliterallttgt-datetimes-differently-now-breaks.md b/includes/migration-guide/runtime/wf/wf-serializes-expressionsliterallttgt-datetimes-differently-now-breaks.md new file mode 100644 index 00000000000..a26690dacbd --- /dev/null +++ b/includes/migration-guide/runtime/wf/wf-serializes-expressionsliterallttgt-datetimes-differently-now-breaks.md @@ -0,0 +1,10 @@ +### WF による Expressions.Literal<T> DateTimes のシリアル化の方法が変わった (カスタム XAML パーサーが機能しなくなる) + +| | | +|---|---| +|説明|関連する オブジェクトは、Second コンポーネントと コンポーネントが非ゼロで ( 値の場合)、 プロパティが Unspecified ではない オブジェクトまたは オブジェクトを文字列ではなくプロパティ要素構文に変換します。 この変更により、 値と 値を往復させることができるようになります。 入力 XAML が属性構文であると想定するカスタム XAML パーサーは正しく機能しません。| +|提案される解決策|この変更により、 値と 値を往復させることができるようになります。 入力 XAML が属性構文であると想定するカスタム XAML パーサーは正しく機能しません。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/wf/workflow-now-throws-original-exception-instead-nullreferenceexception-some.md b/includes/migration-guide/runtime/wf/workflow-now-throws-original-exception-instead-nullreferenceexception-some.md new file mode 100644 index 00000000000..23ac9fb774b --- /dev/null +++ b/includes/migration-guide/runtime/wf/workflow-now-throws-original-exception-instead-nullreferenceexception-some.md @@ -0,0 +1,11 @@ +### 場合によって、ワークフローで NullReferenceException ではなく、元の例外がスローされるようになった + +| | | +|---|---| +|説明|.NET Framework 4.6.2 ワークフロー アクティビティの Execute メソッドを使用して例外をスローした場合、以前のバージョンで、null値をプロパティ、System.Activities ワークフロー ランタイムは、スロー、 、マスク、元の例外。 .NET Framework 4.7 以前マスクは、例外がスローされます。| +|提案される解決策|コードが の処理に依存する場合は、カスタム アクティビティからスローされる可能性のある例外をキャッチするように変更します。| +|スコープ|マイナー| +|Version|4.7| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wf/workflow-sql-persistence-adds-primary-key-clusters-disallows-null-values.md b/includes/migration-guide/runtime/wf/workflow-sql-persistence-adds-primary-key-clusters-disallows-null-values.md new file mode 100644 index 00000000000..ac040966522 --- /dev/null +++ b/includes/migration-guide/runtime/wf/workflow-sql-persistence-adds-primary-key-clusters-disallows-null-values.md @@ -0,0 +1,10 @@ +### Workflow SQL の永続化で主キー クラスターが追加され、一部の列の null 値が許可されない + +| | | +|---|---| +|説明|.NET Framework 4.7 以降では、SqlWorkflowInstanceStoreSchema.sql スクリプトで SQL Workflow Instance Store (SWIS) に作成されたテーブルにはクラスター化された主キーが使用されます。 そのため、ID では null 値はサポートされません。 SWIS の操作には、この変更による影響はありません。 SQL Server トランザクション レプリケーションをサポートするように更新されました。| +|提案される解決策|この変更では、SQL ファイルの SqlWorkflowInstanceStoreSchemaUpgrade.sql を既存のインストールに適用する必要があります。 新しいデータベースのインストールは自動的に変更されます。| +|スコープ|エッジ| +|Version|4.7| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/winforms/previewlostkeyboardfocus-called-repeatedly-if-its-handler-shows-windows.md b/includes/migration-guide/runtime/winforms/previewlostkeyboardfocus-called-repeatedly-if-its-handler-shows-windows.md new file mode 100644 index 00000000000..60e50fcc6ed --- /dev/null +++ b/includes/migration-guide/runtime/winforms/previewlostkeyboardfocus-called-repeatedly-if-its-handler-shows-windows.md @@ -0,0 +1,11 @@ +### PreviewLostKeyboardFocus は、そのハンドラーが Windows フォーム メッセージ ボックスを表示する場合、繰り返し呼び出される + +| | | +|---|---| +|説明|.NET Framework 4.5 以降では、 ハンドラーから System.Windows.Forms.MessageBox.Show を呼び出すと、メッセージ ボックスが閉じられたとき、ハンドラーが再実行して、メッセージ ボックスの無限ループになる可能性があります。| +|提案される解決策|この問題を回避するには、2 つの方法があります。
  1. System.Windows.Forms.MessageBox.Show の代わりに System.Windows.MessageBox.Show を呼び出すことによって回避できます。
  2. イベント ハンドラーから ( イベント ハンドラーではなく) メッセージ ボックスを表示することによって回避できます。
| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/winforms/winforms-checkforoverflowunderflow-property-now-true-for-systemdrawing.md b/includes/migration-guide/runtime/winforms/winforms-checkforoverflowunderflow-property-now-true-for-systemdrawing.md new file mode 100644 index 00000000000..06d091a7898 --- /dev/null +++ b/includes/migration-guide/runtime/winforms/winforms-checkforoverflowunderflow-property-now-true-for-systemdrawing.md @@ -0,0 +1,10 @@ +### WinForm の CheckForOverflowUnderflow プロパティが System.Drawing に対して true に設定されるようになった + +| | | +|---|---| +|説明|System.Drawing.dll アセンブリの CheckForOverflowUnderflow プロパティが true に設定されます。| +|提案される解決策|これまではオーバーフローが発生すると、その結果は自動的に切り捨てられました。 現在では、 例外がスローされます。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/wpf/accessing-wpf-datagrids-selected-items-from-handler-unloadingrow-event-can.md b/includes/migration-guide/runtime/wpf/accessing-wpf-datagrids-selected-items-from-handler-unloadingrow-event-can.md new file mode 100644 index 00000000000..4b47527083a --- /dev/null +++ b/includes/migration-guide/runtime/wpf/accessing-wpf-datagrids-selected-items-from-handler-unloadingrow-event-can.md @@ -0,0 +1,11 @@ +### DataGrid の UnloadingRow イベントのハンドラーから WPF DataGrid の選択された項目にアクセスすると、NullReferenceException が発生する可能性がある + +| | | +|---|---| +|説明|.NET Framework 4.5 のバグが原因で、行の削除に関連する イベントのイベント ハンドラーにより、 の または プロパティにアクセスする場合に がスローされる可能性があります。| +|提案される解決策|この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wpf/calling-datagridcommitedit-from-celleditending-handler-drops-focus.md b/includes/migration-guide/runtime/wpf/calling-datagridcommitedit-from-celleditending-handler-drops-focus.md new file mode 100644 index 00000000000..44dd68931a7 --- /dev/null +++ b/includes/migration-guide/runtime/wpf/calling-datagridcommitedit-from-celleditending-handler-drops-focus.md @@ -0,0 +1,11 @@ +### CellEditEnding ハンドラーから DataGrid.CommitEdit を呼び出すと、フォーカスが削除される + +| | | +|---|---| +|説明| の イベント ハンドラーのいずれかから を呼び出すと、 からフォーカスが失われます。| +|提案される解決策|このバグは .NET framework 4.5.2 で修正されたため、.NET Framework をアップグレードすることによって回避できます。 または、 を呼び出した後で を明示的に再選択することによって回避できます。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wpf/calling-itemsrefresh-on-wpf-listbox-listview-datagrid-with-items-selected.md b/includes/migration-guide/runtime/wpf/calling-itemsrefresh-on-wpf-listbox-listview-datagrid-with-items-selected.md new file mode 100644 index 00000000000..c13c5f24137 --- /dev/null +++ b/includes/migration-guide/runtime/wpf/calling-itemsrefresh-on-wpf-listbox-listview-datagrid-with-items-selected.md @@ -0,0 +1,11 @@ +### 項目が選択されている WPF ListBox、ListView、または DataGrid に対して Items.Refresh を呼び出すと、重複した項目が要素に表示されることがある + +| | | +|---|---| +|説明|.NET Framework 4.5 では、 で項目が選択されているときにコードから ListBox.Items.Refresh を呼び出すと、選択された項目がリストに複製されることがあります。 同様の問題が と で発生します。 これは、.NET Framework 4.6 で修正されます。| +|提案される解決策|この問題は、 が呼び出される前に、プログラムで項目を選択解除して、呼び出しの完了後に再び選択することによって回避できます。 または、この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wpf/changing-isenabled-property-parent-textblock-control-affects-any-child.md b/includes/migration-guide/runtime/wpf/changing-isenabled-property-parent-textblock-control-affects-any-child.md new file mode 100644 index 00000000000..962a951881d --- /dev/null +++ b/includes/migration-guide/runtime/wpf/changing-isenabled-property-parent-textblock-control-affects-any-child.md @@ -0,0 +1,11 @@ +### TextBlock コントロールの親の IsEnabled プロパティの変更がすべての子コントロールに影響する + +| | | +|---|---| +|説明|.NET Framework 4.6.2、変更以降のの親のプロパティ、コントロール (ハイパーリンクやボタンなど) などの子コントロールに影響を与える、コントロール。 .NET Framework 4.6.1 以前のバージョンで、内部コントロール、の状態を常に反映されませんでした、のプロパティ、親。| +|提案される解決策|なし。 この変更は、 コントロール内部のコントロールに期待される動作に準拠しています。| +|スコープ|マイナー| +|Version|4.6.2| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wpf/coerceisselectionboxhighlighted.md b/includes/migration-guide/runtime/wpf/coerceisselectionboxhighlighted.md new file mode 100644 index 00000000000..3ede33fe053 --- /dev/null +++ b/includes/migration-guide/runtime/wpf/coerceisselectionboxhighlighted.md @@ -0,0 +1,11 @@ +### CoerceIsSelectionBoxHighlighted + +| | | +|---|---| +|説明| とそのデータ ソースに関連するアクションの特定のシーケンスで が発生する可能性があります。| +|提案される解決策|可能であれば、.NET 4.6.2 にアップグレードしてください。| +|スコープ|マイナー| +|Version|4.6| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wpf/crash-selector-when-removing-an-item-from-custom-incc-collection.md b/includes/migration-guide/runtime/wpf/crash-selector-when-removing-an-item-from-custom-incc-collection.md new file mode 100644 index 00000000000..e5e61e5ebfe --- /dev/null +++ b/includes/migration-guide/runtime/wpf/crash-selector-when-removing-an-item-from-custom-incc-collection.md @@ -0,0 +1,10 @@ +### カスタム INCC コレクションから項目を削除すると、セレクターでクラッシュが発生する + +| | | +|---|---| +|説明|T:System.InvalidOperationException は、次のシナリオで発生する可能性があります。
  • T:System.Windows.Controls.Primitives.Selector の ItemsSource が、T:System.Collections.Specialized.INotifyCollectionChanged のカスタム実装を含むコレクションである。
  • 選択した項目をコレクションから削除する。
  • T:System.Collections.Specialized.NotifyCollectionChangedEventArgs の P:System.Collections.Specialized.NotifyCollectionChangedEventArgs.OldStartingIndex が -1 (不明な位置を示す) である。
例外のコールスタックは、System.Windows.Threading.Dispatcher.VerifyAccess()、System.Windows.DependencyObject.GetValue(DependencyProperty dp)、System.Windows.Controls.Primitives.Selector.GetIsSelected(DependencyObject element) で始まります。アプリケーションに複数のディスパッチャー スレッドがある場合、この例外は .Net 4.5 で発生する可能性があります。 .Net 4.7 では、1 つのディスパッチャー スレッドのアプリケーションでも例外が発生する場合があります。 この問題は .Net 4.7.1 で修正されます。| +|提案される解決策|.NET 4.7.1 にアップグレードします。| +|スコープ|マイナー| +|Version|4.7| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/wpf/datagridcellspanelbringindexintoview-throws-argumentoutofrangeexception.md b/includes/migration-guide/runtime/wpf/datagridcellspanelbringindexintoview-throws-argumentoutofrangeexception.md new file mode 100644 index 00000000000..4a79f6dc0aa --- /dev/null +++ b/includes/migration-guide/runtime/wpf/datagridcellspanelbringindexintoview-throws-argumentoutofrangeexception.md @@ -0,0 +1,11 @@ +### DataGridCellsPanel.BringIndexIntoView で ArgumentOutOfRangeException がスローされる + +| | | +|---|---| +|説明|列の仮想化は有効になっているが、列の幅がまだ決定されていない場合、 は非同期で動作します。 非同期動作が発生する前に列が削除されると、 が発生する場合があります。| +|提案される解決策|以下のいずれかを実行してください。
  1. .NET 4.7 にアップグレードする。
  2. .NET 4.6.2 の最新のサービス パッチをインストールする。
  3. に対する非同期応答が完了するまでは列を削除しないようにする。
| +|スコープ|エッジ| +|Version|4.6.2| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wpf/flowdocument-may-show-an-extra-line-text.md b/includes/migration-guide/runtime/wpf/flowdocument-may-show-an-extra-line-text.md new file mode 100644 index 00000000000..4a5bebc8e2a --- /dev/null +++ b/includes/migration-guide/runtime/wpf/flowdocument-may-show-an-extra-line-text.md @@ -0,0 +1,11 @@ +### FlowDocument でテキストの余分な行が表示される場合がある + +| | | +|---|---| +|説明|.NET Framework 4.0 での実行時の表示と比べて、.NET Framework 4.5 での実行時に 要素でテキストの余分な行が表示されることがあります。 変更によってテキストが正しく表示されなくなったり、読みにくくなったりするようなことはありませんが、以前は のビューから除外されていたテキストが表示される可能性があります。| +|提案される解決策|場合によっては、表示要素の PageHeight プロパティを 1 ずつ減らすことで、表示行の以前の数を復元できます。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wpf/glyphruncomputeinkboundingbox-formattedtextextent-return-different-values.md b/includes/migration-guide/runtime/wpf/glyphruncomputeinkboundingbox-formattedtextextent-return-different-values.md new file mode 100644 index 00000000000..60f145cf1c9 --- /dev/null +++ b/includes/migration-guide/runtime/wpf/glyphruncomputeinkboundingbox-formattedtextextent-return-different-values.md @@ -0,0 +1,11 @@ +### GlyphRun.ComputeInkBoundingBox() と FormattedText.Extent が、.NET 4.5 以降では、異なる値を返す + +| | | +|---|---| +|説明|.NET Framework 4.5 では、 と が改善され、場合によっては含まれるグリフに対してボックスが小さすぎるという .NET Framework 4.0 での問題に対応しました。 この結果、.NET Framework 4.5 以降では、いくつかの境界ボックスが大きくなり、UI のレイアウトにわずかな違いが生じます。| +|提案される解決策|いくつかのグリフの境界ボックスのサイズが大きくなったことに注意してください。 このような変更は、通常、プレゼンテーションおよびヒット ボックス テストを向上させますが、以前の (.NET 4.5 より前の) 動作が望ましい場合は、次のエントリをアプリの構成ファイルに追加することによって実現できます。
<appsettings>
<add key="IncludeAllInkInBoundingBox" value="false">
</appsettings>
| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wpf/horizontal-scrolling-virtualization.md b/includes/migration-guide/runtime/wpf/horizontal-scrolling-virtualization.md new file mode 100644 index 00000000000..97e40b96e60 --- /dev/null +++ b/includes/migration-guide/runtime/wpf/horizontal-scrolling-virtualization.md @@ -0,0 +1,11 @@ +### 水平方向スクロールと仮想化 + +| | | +|---|---| +|説明|この変更は、メインのスクロール方向と直交する方向で独自に仮想化を行う に適用されます (代表的な例は、EnableColumnVirtualization="True" である です)。 特定の水平方向スクロール操作の結果が変更され、比較可能な垂直操作の結果により類似した、より直感的な結果が生成されるようになりました。このような操作としては "ここにスクロール" や "右端" などがあり、水平スクロール バーを右クリックすると表示されるメニューから名前を使用することができます。 これらの両方の計算、候補オフセットと呼び出しです。新しいオフセットの概念にスクロール後"ここ"または"エッジを右"の値を除外仮想化されたコンテンツが新しく変更されたために変更可能性があるです。 .Net 4.6.2 では、前に、スクロール操作だけを使用して候補のオフセットができない場合でも"ここ"または、"エッジを右"かを確認します。 その結果、スクロールつまみの "バウンス" などの効果が得られます。次に例を示します。 たとえば、 で ExtentWidth=1000 および Width=200 であるものとします。 "右端" へのスクロールでは、1000 - 200 = 800 という候補オフセットを使用します。 そのオフセットへのスクロール時に、新しい列が非仮想化されます。これらの列が非常に広いため、 を 2000 に変更したとします。 スクロールは HorizontalOffset=800 で終了し、つまみはスクロールバーの中央付近 (正確には 800/2000 = 40%) に "戻り" ます。このような状況が発生した場合、変更は新しい候補オフセットを再計算し、再試行することになっています。 (垂直方向スクロールの動作は既にこのようになっています)。この変更により、エンド ユーザーにはより予測可能で直感的なエクスペリエンスが提供されるようになりますが、水平方向スクロール後の の正確な値に依存するアプリに影響する可能性もあります。これは、エンド ユーザーによる呼び出しであるか、 の明示的な呼び出しであるかは関係ありません。| +|提案される解決策| の予測値を使用するアプリを、非仮想化により が変更される可能性のある水平方向スクロール後の実際の値 (および の値) を取得するように変更する必要があります。| +|スコープ|マイナー| +|Version|4.6.2| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wpf/intermittently-unable-scroll-bottom-item-itemscontrols-like-listbox-datagrid.md b/includes/migration-guide/runtime/wpf/intermittently-unable-scroll-bottom-item-itemscontrols-like-listbox-datagrid.md new file mode 100644 index 00000000000..2be882f8e1e --- /dev/null +++ b/includes/migration-guide/runtime/wpf/intermittently-unable-scroll-bottom-item-itemscontrols-like-listbox-datagrid.md @@ -0,0 +1,10 @@ +### カスタム DataTemplate を使用しているとき、断続的に、ItemsControl (ListBox や DataGrid など) 内の最後の項目までスクロールできない + +| | | +|---|---| +|説明|場合によっては、.NET Framework 4.5 のバグにより、カスタム DataTemplate を使用していると、ItemsControl (、、 など) の最後の項目までスクロールできません。 (上へスクロールした後で) もう一度スクロールを試みると、今度はスクロールできます。| +|提案される解決策|この問題は .NET Framework 4.5.2 で修正されたため、このバージョン (またはそれ以降のバージョン) の .NET Framework にアップグレードすることによって対処できます。 または、ユーザーは、スクロール バーをこれらのコレクションの最後の項目までドラッグできますが、2 回試みなければならないことがあります。| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/wpf/item-scrolling-flat-list-with-items-different-pixel-height.md b/includes/migration-guide/runtime/wpf/item-scrolling-flat-list-with-items-different-pixel-height.md new file mode 100644 index 00000000000..52a06bbf9fb --- /dev/null +++ b/includes/migration-guide/runtime/wpf/item-scrolling-flat-list-with-items-different-pixel-height.md @@ -0,0 +1,11 @@ +### ピクセルの高さが異なる項目を含むフラット リストでの項目スクロール + +| | | +|---|---| +|説明| に仮想化 (IsVirtualizing=true) と項目スクロール (ScrollUnit=Item) を使うコレクションが表示される場合、およびコントロールがスクロールされ、近隣項目と異なる高さ (ピクセル単位) の項目が表示される場合、 ではコレクション内のすべての項目に対してイテレーションが行われます。 このイテレーション中に UI は応答しません。コレクションのサイズが大きい場合、ハングとして認識される場合があります。他の状況では、以前の .Net のリリースであっても、イテレーションは発生します。 たとえば、これは、ピクセル スクロール (ScrollUnit=Pixel) が高さの異なる項目 (ピクセル単位) を検出した場合、および階層データの項目スクロール ( や、グループ化が有効になっている など) が近隣項目と異なる数の子項目を持つ項目を検出した場合に発生します。項目スクロールと高さが異なる (ピクセル単位) 場合の対処方として、階層データのレイアウトのバグを修正できるようイテレーションが .Net 4.6.1 で導入されました。 データがフラットである場合 (階層がない場合) は必要ないため、そのような状況では .Net 4.6.2 はイテレーションを行いません。| +|提案される解決策|.Net 4.6.1 でイテレーションが発生し、以前のリリースでは発生しない場合、つまり が異なる高さの (ピクセル単位) の項目を含むフラットなリストを項目スクロールしている場合、実行できる対応策は以下の 2 つです。
  1. .Net 4.6.2 をインストールします。
  2. .Net 4.6.1 に修正プログラム HR 1605 をインストールします。
| +|スコープ|マイナー| +|Version|4.6.1| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wpf/itemsclear-does-not-remove-duplicates-from-selecteditems.md b/includes/migration-guide/runtime/wpf/itemsclear-does-not-remove-duplicates-from-selecteditems.md new file mode 100644 index 00000000000..4dc045204ef --- /dev/null +++ b/includes/migration-guide/runtime/wpf/itemsclear-does-not-remove-duplicates-from-selecteditems.md @@ -0,0 +1,11 @@ +### Items.Clear で SelectedItems から重複部分が削除されない + +| | | +|---|---| +|説明|セレクター (複数選択が有効になっている) の コレクションに重複部分があるとします。その場合、同じ項目が複数回表示されます。 データ ソースからこれらの項目を削除すると (たとえば、Items.Clear を呼び出すことにより)、 からそれらの項目を削除できなくなります。最初のインスタンスのみが削除されます。 さらに、 (SelectedItems.Clear() など) を引き続き使用すると、 などの問題が発生する可能性があります。これは、 に、データ ソース内にはもう存在しない項目が含まれているためです。| +|提案される解決策|可能であれば、.NET 4.6.2 にアップグレードします。| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wpf/listboxitem-isselected-binding-issue-with-observablecollectionlttgtmove.md b/includes/migration-guide/runtime/wpf/listboxitem-isselected-binding-issue-with-observablecollectionlttgtmove.md new file mode 100644 index 00000000000..8a32b3d5734 --- /dev/null +++ b/includes/migration-guide/runtime/wpf/listboxitem-isselected-binding-issue-with-observablecollectionlttgtmove.md @@ -0,0 +1,11 @@ +### ObservableCollection<T>.Move に対する ListBoxItem IsSelected のバインディングの問題 + +| | | +|---|---| +|説明|項目が選択された にバインドされるコレクションで または を呼び出すと、 項目の今後の選択または選択解除で不規則な動作が発生する可能性があります。| +|提案される解決策| ではなく と を呼び出すことで、この問題は解決されます。 または、この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wpf/new-enum-values-wpfs-pagerangeselection.md b/includes/migration-guide/runtime/wpf/new-enum-values-wpfs-pagerangeselection.md new file mode 100644 index 00000000000..eee89605880 --- /dev/null +++ b/includes/migration-guide/runtime/wpf/new-enum-values-wpfs-pagerangeselection.md @@ -0,0 +1,11 @@ +### WPF の PageRangeSelection の新しい列挙値 + +| | | +|---|---| +|説明|新しい 2 つのメンバー ( および ) が 列挙型に追加されました。| +|提案される解決策|ほとんどの場合、これらの変更はユーザー コードに影響しません。 ただし、 型に対する または 呼び出しに特定の数の要素が存在することに依存するコードは、修正する必要があります。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wpf/objectdisposedexception-thrown-by-wpf-spellchecker.md b/includes/migration-guide/runtime/wpf/objectdisposedexception-thrown-by-wpf-spellchecker.md new file mode 100644 index 00000000000..bfe7fe8b80d --- /dev/null +++ b/includes/migration-guide/runtime/wpf/objectdisposedexception-thrown-by-wpf-spellchecker.md @@ -0,0 +1,10 @@ +### ObjectDisposedException が WPF スペルチェックでスローされる + +| | | +|---|---| +|説明|スペルチェックで がスローされ、WPF アプリケーションがシャットダウン時にクラッシュする場合があります。 これは .NET 4.7 WPF で修正されます。例外は正しく処理されるため、アプリケーションが悪影響を受けることはなくなります。 ただし、デバッグ時に実行中のアプリケーションで初回例外が見られる場合があるので注意してください。| +|提案される解決策|.NET 4.7 にアップグレードします。| +|スコープ|エッジ| +|Version|4.6.1| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/wpf/resizing-grid-can-hang.md b/includes/migration-guide/runtime/wpf/resizing-grid-can-hang.md new file mode 100644 index 00000000000..729644acd93 --- /dev/null +++ b/includes/migration-guide/runtime/wpf/resizing-grid-can-hang.md @@ -0,0 +1,10 @@ +### グリッドのサイズを変更すると、ハングする可能性がある + +| | | +|---|---| +|説明|次の状況では、T:System.Windows.Controls.Grid のレイアウト中に無限ループが発生する可能性があります。
  • 行の定義に、MinHeight と MaxHeight の両方を宣言する、2 つの * 行が含まれている。
  • * 行のコンテンツが対応する MaxHeight を超えていない。
  • 最初の MinHeight (その他の固定または自動の行を含む) がグリッドの利用可能な高さを超えている。
  • アプリの対象を .Net 4.7 とする、または Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=false を設定して、4.7 割り当てアルゴリズムを利用することを選択する。
3 つ以上の行または列の場合は似ています、ループも発生します。 .Net 4.7.1 で問題が解決します。| +|提案される解決策|.NET 4.7.1 にアップグレードします。 4.7 割り当てアルゴリズムが必要でない場合は、次の構成設定を使用することもできます。
<runtime>
<AppContextSwitchOverrides value="Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true" />
</runtime>
| +|スコープ|エッジ| +|Version|4.7| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/wpf/ribbongroup-background-set-transparent-localized-builds.md b/includes/migration-guide/runtime/wpf/ribbongroup-background-set-transparent-localized-builds.md new file mode 100644 index 00000000000..fa07b08cf0b --- /dev/null +++ b/includes/migration-guide/runtime/wpf/ribbongroup-background-set-transparent-localized-builds.md @@ -0,0 +1,10 @@ +### ローカライズされたビルドで RibbonGroup の背景が透明に設定される + +| | | +|---|---| +|説明|ローカライズされたビルドの の背景が常に透明のブラシで塗りつぶされており、UI の操作性が低下していました。 これは、.NET 4.7 WPF 修正プログラムで修正されます。 のローカライズされたリソースが更新され、正しいブラシが確実に選択されるようになります。| +|提案される解決策|.NET 4.7 にアップグレードします。| +|スコープ|エッジ| +|Version|4.6.2| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/wpf/right-clicking-on-wpf-datagrid-row-header-changes-selection.md b/includes/migration-guide/runtime/wpf/right-clicking-on-wpf-datagrid-row-header-changes-selection.md new file mode 100644 index 00000000000..419525d987d --- /dev/null +++ b/includes/migration-guide/runtime/wpf/right-clicking-on-wpf-datagrid-row-header-changes-selection.md @@ -0,0 +1,11 @@ +### WPF DataGrid 行ヘッダーを右クリックすると、DataGrid の選択が変更される + +| | | +|---|---| +|説明|複数行が選択されている状態で、選択した 行ヘッダーを右クリックすると、その行のみで の選択が変更されます。| +|提案される解決策|この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wpf/scrolling-wpf-treeview-grouped-listbox-virtualizingstackpanel-can-cause-hang.md b/includes/migration-guide/runtime/wpf/scrolling-wpf-treeview-grouped-listbox-virtualizingstackpanel-can-cause-hang.md new file mode 100644 index 00000000000..c5fd54942c5 --- /dev/null +++ b/includes/migration-guide/runtime/wpf/scrolling-wpf-treeview-grouped-listbox-virtualizingstackpanel-can-cause-hang.md @@ -0,0 +1,11 @@ +### VirtualizingStackPanel 内の WPF TreeView またはグループ化された ListBox をスクロールすると、ハングすることがある + +| | | +|---|---| +|説明|.NET Framework v4.5 では、仮想化されたスタック パネル内の WPF をスクロールすると、ビューポートに余白があった場合 (たとえば、 内の項目間や、ItemsPresenter 要素上)、ハングすることがあります。 さらに、場合によっては、ビュー内にサイズの異なる項目があると、余白がない場合でも、不安定になることがあります。| +|提案される解決策|このバグは、.NET Framework 4.5.1 にアップグレードすることによって回避できます。 または、含まれているすべての項目が同じサイズである場合は、仮想化されたスタック パネル内のビュー コレクション ( など) から余白を削除できます。| +|スコープ|Major| +|バージョン|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wpf/wpf-datatemplate-elements-are-now-visible-uia.md b/includes/migration-guide/runtime/wpf/wpf-datatemplate-elements-are-now-visible-uia.md new file mode 100644 index 00000000000..9d1905e665a --- /dev/null +++ b/includes/migration-guide/runtime/wpf/wpf-datatemplate-elements-are-now-visible-uia.md @@ -0,0 +1,11 @@ +### WPF DataTemplate 要素が UIA に表示されるようになった + +| | | +|---|---| +|説明|以前は、 要素は UI オートメーションには表示されませんでした。 4.5 から、UI オートメーションは、これらの要素を検出します。 これは、多くの場合に便利ですが、 要素を含まない UIA ツリーに依存するテストは中断することがあります。| +|提案される解決策|このアプリの UI オートメーション テストを更新して、以前は非表示の 要素を含んでいる UIA ツリーに対応できるようにしなければならないことがあります。 たとえば、いくつかの要素が互いに隣り合っていることを予期しているテストでは、以前は非表示であった UIA 要素が間にあることを予期する必要があります。 または、UIA 要素の特定のカウントまたはインデックスに依存するテストは、新しい値で更新しなければならないことがあります。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wpf/wpf-dispatchersynchronizationcontextcreatecopy-now-returns-new-copy-instead.md b/includes/migration-guide/runtime/wpf/wpf-dispatchersynchronizationcontextcreatecopy-now-returns-new-copy-instead.md new file mode 100644 index 00000000000..0627b32bc9b --- /dev/null +++ b/includes/migration-guide/runtime/wpf/wpf-dispatchersynchronizationcontextcreatecopy-now-returns-new-copy-instead.md @@ -0,0 +1,11 @@ +### WPF DispatcherSynchronizationContext.CreateCopy は、現在のインスタンスの代わりに新しいコピーを返すようになった + +| | | +|---|---| +|説明|.NET Framework 4 では、 は、主にパフォーマンスの最適化として、現在のインスタンスへの参照を返しました。 .NET Framework 4.5 では、これが新しいインスタンスになり、参照が等しければ、実行中のスレッドが正しい同期コンテキストにあると結論付けることが初めて可能になりました。 これらの参照の ID をチェックするコードが影響を受ける可能性は低いですが、この変更により、 を呼び出すコードは、.NET Framework 4.5 以降への移行の一部としてテストする必要があります。| +|提案される解決策| が新しい オブジェクトを返すようになったことに注意してください。 以前は、このように生成された参照の等価性を使用するコードは、実際には、正しいコンテキストにあるかどうかを確認していませんでしたが、.NET 4.5 以降でのビルド時には確認を行います。 問題になる可能性は低いですが、影響を受けるコードのパスをよく調べて、何か問題が生じないかどうか確認する必要があります。| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wpf/wpf-printing-stack-update.md b/includes/migration-guide/runtime/wpf/wpf-printing-stack-update.md new file mode 100644 index 00000000000..0c376108bca --- /dev/null +++ b/includes/migration-guide/runtime/wpf/wpf-printing-stack-update.md @@ -0,0 +1,10 @@ +### WPF での印刷スタックの更新 + +| | | +|---|---| +|説明| を使う WPF の印刷 API は、非推奨になった XPS 印刷 API ではなく Windows ドキュメント印刷パッケージ API を呼び出すようになりました。 この変更はサービス性を考慮して行われたもので、ユーザーも開発者も、動作または API の使用の変化を目にすることはありません。 Windows 10 Creators Update で実行すると、新しい印刷スタックは既定で有効になります。 以前のバージョンの Windows では、以前の印刷スタックが引き続き同じように動作します。| +|提案される解決策|Windows 10 Creators Update で以前のスタックを使用するには、HKEY_CURRENT_USER\Software\Microsoft\.NETFramework\Windows Presentation Foundation\Printing レジストリ キーの UseXpsOMPrinting REG_DWORD 値を 1 に設定します。| +|スコープ|エッジ| +|Version|4.7| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/wpf/wpf-spawns-wisptisexe-process-which-can-freeze-mouse.md b/includes/migration-guide/runtime/wpf/wpf-spawns-wisptisexe-process-which-can-freeze-mouse.md new file mode 100644 index 00000000000..ebabdc4fd1c --- /dev/null +++ b/includes/migration-guide/runtime/wpf/wpf-spawns-wisptisexe-process-which-can-freeze-mouse.md @@ -0,0 +1,10 @@ +### WPF が wisptis.exe プロセスを生成し、マウスがフリーズする可能性がある + +| | | +|---|---| +|説明|この問題は 4.5.2 から発生するようになり、wisptis.exe が生成され、マウス入力がフリーズする可能性があります。| +|提案される解決策|この問題はサービス リリースの .NET Framework 4.5.2 (修正プログラム ロールアップ 3026376) で、あるいは .NET Framework 4.6 にアップグレードすることで解決できます。| +|スコープ|Major| +|Version|4.5.2| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/wpf/wpf-spell-checking-fails-unexpected-ways.md b/includes/migration-guide/runtime/wpf/wpf-spell-checking-fails-unexpected-ways.md new file mode 100644 index 00000000000..02105e9fd62 --- /dev/null +++ b/includes/migration-guide/runtime/wpf/wpf-spell-checking-fails-unexpected-ways.md @@ -0,0 +1,10 @@ +### WPF スペル チェックが予期しない方法で失敗する + +| | | +|---|---| +|説明|これには、次の WPF スペル チェックのいくつかの問題が含まれます。
  • WPF スペル チェックで がスローされる場合がある。
  • "別のユーザーとして実行" を使用してアプリケーションが起動された場合、WPF スペル チェックが で失敗する。
  • WPF スペル チェックで、ドイツ語の "Hausnummer" などの複合語のスペル ミスが正しく識別されない。
| +|提案される解決策|問題 1 - これは .NET Framework 4.6.2 で修正されました。問題 2 - "別のユーザーとして実行" を使用してアプリケーションが起動された場合、WPF スペル チェックがサポートされなくなりました。 .NET Framework 4.6.2 以降では、このように起動されたアプリケーションが予期せずクラッシュしなくなります。代わりに、スペル チェックが自動的に無効になります。 問題 3 - これは .NET Framework 4.6.2 で修正されました。| +|スコープ|エッジ| +|Version|4.6.1| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/wpf/wpf-spell-checking-text-enabled-controls-will-not-work-windows-10-for.md b/includes/migration-guide/runtime/wpf/wpf-spell-checking-text-enabled-controls-will-not-work-windows-10-for.md new file mode 100644 index 00000000000..20ea16189a0 --- /dev/null +++ b/includes/migration-guide/runtime/wpf/wpf-spell-checking-text-enabled-controls-will-not-work-windows-10-for.md @@ -0,0 +1,10 @@ +### OS の入力言語リストにない言語の場合、Windows 10 でテキスト対応コントロールの WPF スペル チェックが動作しなくなる + +| | | +|---|---| +|説明|プラットフォームのスペル チェック機能は入力言語リストに存在する言語でしか使用できないため、 Windows 10 での実行時には、WPF テキスト対応コントロール向けのスペル チェック機能が動作しないことがあります。Windows 10 では、使用可能なキーボードのリストに言語を追加すると、対応するオンデマンド機能 (FOD) パッケージが自動的にダウンロードおよびインストールされ、スペル チェック機能が提供されます。 入力言語リストに言語を追加することで、スペル チェック機能がサポートされます。| +|提案される解決策|Windows 10 でスペルチェックを動作させるには、スペルチェック対象の言語またはテキストを入力言語として追加する必要があることに注意してください。| +|スコープ|エッジ| +|Version|4.6| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/wpf/wpf-textbox-defaults-undo-limit-100.md b/includes/migration-guide/runtime/wpf/wpf-textbox-defaults-undo-limit-100.md new file mode 100644 index 00000000000..9fc3a86e41a --- /dev/null +++ b/includes/migration-guide/runtime/wpf/wpf-textbox-defaults-undo-limit-100.md @@ -0,0 +1,11 @@ +### WPF TextBox は既定で元に戻す上限が 100 に設定される + +| | | +|---|---| +|説明|.NET 4.5 では、WPF テキスト ボックスの既定の元に戻す上限は 100 です (.NET 4.0 では無制限でした)。| +|提案される解決策|元に戻す上限が 100 では低すぎる場合、 を使用して上限を明示的に設定できます。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wpf/wpf-textbox-selected-text-appears-different-color-when-box-inactive.md b/includes/migration-guide/runtime/wpf/wpf-textbox-selected-text-appears-different-color-when-box-inactive.md new file mode 100644 index 00000000000..ab2458a0548 --- /dev/null +++ b/includes/migration-guide/runtime/wpf/wpf-textbox-selected-text-appears-different-color-when-box-inactive.md @@ -0,0 +1,11 @@ +### WPF TextBox で選択されているテキストが、テキスト ボックスがアクティブでないときに異なる色で表示される + +| | | +|---|---| +|説明|.NET 4.5 では、WPF テキスト ボックス コントロールがアクティブでないとき (フォーカスがないとき)、ボックス内で選択されているテキストは、コントロールがアクティブなときとは別の色で表示されます。| +|提案される解決策| プロパティを false に設定することで、以前 (.NET 4.0) の動作が復元される可能性があります。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/wpf/wpf-treeviewitem-must-be-used-within-treeview.md b/includes/migration-guide/runtime/wpf/wpf-treeviewitem-must-be-used-within-treeview.md new file mode 100644 index 00000000000..3778752fe47 --- /dev/null +++ b/includes/migration-guide/runtime/wpf/wpf-treeviewitem-must-be-used-within-treeview.md @@ -0,0 +1,10 @@ +### WPF TreeViewItem は TreeView 内で使用する必要がある + +| | | +|---|---| +|説明| の外部での 要素の使用を制限する変更が 4.5 で導入されました。 これは、次のような条件で発生します。
  • のビジュアルの親がパネルではありません。 ( に対して生成された は、親としてパネルを持ちます)
  • は、リスト コントロール (ListBox、DataGrid、ListView など) の "項目ホスト" として機能する の子孫です。 仮想化を有効にする必要はありません。
  • は、項目のスクロールです (ScrollUnit="Item")。
  • 誰かが要素 v をスクロールして表示させるために VirtualizingStackPanel.MakeVisible(v) を呼び出します。 これは、明示的に行うか、さまざまな方法で暗黙的に行うことができます。おそらく、最も一般的な方法は、v をクリックして、キーボードのフォーカスを与えることです。
  • v から までのビジュアル親チェーンが を通過します。
言い換えると、これは、 が の外部で使用されるときに見られ、ユーザーは の子孫をクリックして表示させます。 にフォーカスを取得できる子孫がない場合、この問題は見られません。 これが該当する状況の例は、 が DataTemplate のルートであるときです。 この問題に遭遇したときには、WPF フレームワーク内で InvalidCastException が発生しています。| +|提案される解決策|このための修正プログラムが使用可能になります。| +|スコープ|マイナー| +|Version|4.5| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/wpf/wpf-windows-are-rendered-without-clipping-when-extending-outside-single.md b/includes/migration-guide/runtime/wpf/wpf-windows-are-rendered-without-clipping-when-extending-outside-single.md new file mode 100644 index 00000000000..3c36c4ce809 --- /dev/null +++ b/includes/migration-guide/runtime/wpf/wpf-windows-are-rendered-without-clipping-when-extending-outside-single.md @@ -0,0 +1,10 @@ +### 1 つのモニターの外部に拡張すると、クリッピングなしで WPF ウィンドウがレンダリングされる + +| | | +|---|---| +|説明|Windows 8 以上で実行している .NET Framework 4.6 では、マルチ モニターのシナリオで 1 つのディスプレイの外部にウィンドウを拡張すると、ウィンドウ全体がクリッピングなしでレンダリングされます。 これは、1 つのディスプレイを超える WPF ウィンドウをクリッピングする、以前のバージョンの .NET Framework とは異なります。| +|提案される解決策|この動作 (クリッピングするかどうか) は、アプリケーションの構成ファイルの <appSettings> で <EnableMultiMonitorDisplayClipping> 要素を使用するか、アプリの起動時に EnableMultiMonitorDisplayClipping プロパティを設定することで明示的に設定できます。| +|スコープ|マイナー| +|Version|4.6| +|型|ランタイム| + diff --git a/includes/migration-guide/runtime/xml/xmlschemaexception-now-sets-line-positions-properly.md b/includes/migration-guide/runtime/xml/xmlschemaexception-now-sets-line-positions-properly.md new file mode 100644 index 00000000000..b8bf0b6300e --- /dev/null +++ b/includes/migration-guide/runtime/xml/xmlschemaexception-now-sets-line-positions-properly.md @@ -0,0 +1,11 @@ +### XmlSchemaException で行位置が正しく設定されるようになった + +| | | +|---|---| +|説明| 値が Load メソッドに渡されたときに検証エラーが発生すると、 プロパティと プロパティに行情報が含まれるようになりました。| +|提案される解決策|XML の読み込み中に SetLineInfo が使用されるとき、 と は正しく設定されるようになったので、これらのプロパティが設定されないことを想定している例外処理コードは、更新する必要があります。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/xml/xmltextreader-dtd-entity-expansion-limited-10000000-characters.md b/includes/migration-guide/runtime/xml/xmltextreader-dtd-entity-expansion-limited-10000000-characters.md new file mode 100644 index 00000000000..5e44b184a0a --- /dev/null +++ b/includes/migration-guide/runtime/xml/xmltextreader-dtd-entity-expansion-limited-10000000-characters.md @@ -0,0 +1,11 @@ +### XmlTextReader DTD エンティティの拡張が、10,000, 000 文字に制限される + +| | | +|---|---| +|説明|DTD エンティティの拡張は 10,000,000 文字までに制限されるようになりました。 DTD エンティティの展開を使用しない XML ファイルの読み込みや、制限された DTD エンティティの展開を使用した XML ファイルの読み込みは、影響を受けません。 DTD エンティティの展開が 10,000,000 文字を超えるファイルは読み込みに失敗し、例外をスローします。| +|提案される解決策|DTD エンティティの拡張の制限が 10,000, 000 では低すぎる場合には、 プロパティで値をオーバーライドできます。 適切な 値を持つ を、 を受け取る XmlReader.Create に渡すことができます ( など)| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/xml/xslt-forward-compat-now-works.md b/includes/migration-guide/runtime/xml/xslt-forward-compat-now-works.md new file mode 100644 index 00000000000..534a443ed6a --- /dev/null +++ b/includes/migration-guide/runtime/xml/xslt-forward-compat-now-works.md @@ -0,0 +1,11 @@ +### XSLT 上位互換が機能するようになった + +| | | +|---|---| +|説明|.NET Framework 4 では、XSLT 1.0 の上位互換性に、次の問題がありました。
  • バージョンが 2.0 に設定されているときに、パーサーが認識できない XSLT 1.0 コンストラクトに遭遇すると、スタイル シートの読み込みが失敗していました。
  • スタイル シートのバージョンが 1.1 に設定されている場合、xsl:sort コンストラクトでデータを並べ替えることができませんでした。
.NET Framework 4.5 では、これらの問題は修正され、XSLT 1.0 の上位互換モードが正常に機能するようになりました。| +|提案される解決策|ほとんどのアプリには影響しませんが、xsl:sort が優先される場合は異なる方法でデータが並べ替えられます。 xsl:sort が 1.1 スタイル シートで使用されている場合は、アプリが並べ替えられていないデータの順序に依存していないことを確認してください。 アプリが 4.0 の並べ替え動作に依存している場合は、スタイル シートから xsl:sort を削除してください。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/migration-guide/runtime/xml/xslt-style-sheet-exception-message-changed.md b/includes/migration-guide/runtime/xml/xslt-style-sheet-exception-message-changed.md new file mode 100644 index 00000000000..06ac0b08868 --- /dev/null +++ b/includes/migration-guide/runtime/xml/xslt-style-sheet-exception-message-changed.md @@ -0,0 +1,11 @@ +### XSLT スタイル シートの例外メッセージが変更された + +| | | +|---|---| +|説明|.NET Framework 4.5 では、XSLT ファイルが複雑すぎるときのエラー メッセージのテキストが "スタイル シートが複雑すぎます" になります。以前のバージョンのエラー メッセージは "XSLT コンパイル エラー" でした。エラー メッセージのテキストに依存するアプリケーション コードは機能しなくなります。 ただし、例外の種類は同じなので、この変更による実質的な影響はありません。| +|提案される解決策|このエラー条件からの例外メッセージに依存しているアプリケーション コードを、新しいメッセージを予期するように更新するか、(さらに望ましくは) 変更されていない例外の種類 () のみに依存するようにコードを更新します。| +|スコープ|エッジ| +|Version|4.5| +|型|ランタイム| +|影響を受ける API|
| + diff --git a/includes/note-compatibility-md.md b/includes/note-compatibility-md.md new file mode 100644 index 00000000000..d860e24d4a3 --- /dev/null +++ b/includes/note-compatibility-md.md @@ -0,0 +1,2 @@ +> [!NOTE] +> 名前空間の関数とオブジェクトは、Visual Basic 6.0 から Visual Basic 2008 へのアップグレード ツールで使用するために用意されています。 ほとんどの場合、これらの関数とオブジェクトは、.NET Framework の他の名前空間にある機能と重複しています。 これらが必要になるのは、Visual Basic 6.0 のコード モデルが .NET Framework の実装と大きく異なる場合だけです。 \ No newline at end of file diff --git a/includes/note-unnecessary-dispose.md b/includes/note-unnecessary-dispose.md new file mode 100644 index 00000000000..4855fdb8707 --- /dev/null +++ b/includes/note-unnecessary-dispose.md @@ -0,0 +1,2 @@ +> [!NOTE] +> この型は インターフェイスを実装しますが、実際に破棄するリソースはありません。 つまり、 を直接呼び出したり、`using` (C# の場合) または `Using` (Visual Basic の場合) といった言語構築を行ってリソースを破棄する必要はありません。 diff --git a/includes/provider-string-format.md b/includes/provider-string-format.md new file mode 100644 index 00000000000..0650ca1c4ac --- /dev/null +++ b/includes/provider-string-format.md @@ -0,0 +1,4 @@ + +ただし、**String.Format** メソッドの呼び出し時に、呼び出す特定のオーバーロードに焦点を当てる必要はありません。 代わりに、カルチャに依存した書式設定またはカスタム書式設定および 1 つ以上の書式項目を含む[複合書式指定文字列](~/docs/standard/base-types/composite-formatting.md)を提供するオブジェクトを使用して、メソッドを呼び出すことができます。 各書式項目を数値インデックスに割り当てます。最初のインデックスは 0 から始まります。 最初の文字列だけでなく、メソッド呼び出しには、インデックス値と同じ数の追加引数が必要です。 たとえば、書式項目のインデックスが 0 と 1 の文字列には 2 個の引数が必要です。インデックスが 0 から 5 の場合は、6 個の引数が必要です。 その後、言語コンパイラは、**String.Format** メソッドの特定のオーバーロードに対するメソッド呼び出しを解決します。 + +**String.Format** メソッドの使用に関する詳細なドキュメントについては、[String.Format メソッドの概要](#Starting)と[呼び出すメソッド](#FTaskList)に関するトピックを参照してください。 diff --git a/includes/roslyn-installation.md b/includes/roslyn-installation.md new file mode 100644 index 00000000000..3717a18a738 --- /dev/null +++ b/includes/roslyn-installation.md @@ -0,0 +1,29 @@ +## インストール手順 + +**Visual Studio インストーラー**で **.NET Compiler Platform SDK** を見つけるには、以下の 2 つの異なる方法があります。 + +### ワークロード ビューを使用してインストールする + +.NET Compiler Platform SDK は、Visual Studio 拡張機能の開発ワークロードの一部として自動的に選択されません。 省略可能なコンポーネントとして選択する必要があります。 + +1. **Visual Studio インストーラー**を実行します。 +1. **[変更]** を選択します。 +1. **Visual Studio 拡張機能の開発**ワークロードを確認します。 +1. 概要ツリーの **[Visual Studio 拡張機能の開発]** ノードを開きます。 +1. **[.NET Compiler Platform SDK]** のチェック ボックスをオンにします。 省略可能なコンポーネントの最後に表示されます。 + +また、必要に応じて、**DGML エディター**のビジュアライザーでグラフを表示します。 + +1. 概要ツリーの **[個別のコンポーネント]** ノードを開きます。 +1. **[DGML エディター]** のチェック ボックスをオンにします。 + +### [個別のコンポーネント] タブを使用してインストールする + +1. **Visual Studio インストーラー**を実行します。 +1. **[変更]** を選択します。 +1. **[個別のコンポーネント]** タブを選択します。 +1. **[.NET Compiler Platform SDK]** のチェック ボックスをオンにします。 **[Compilers, build tools ,and runtimes]\(コンパイラ、ビルド ツール、およびランタイム\)** セクションの最後に表示されます。 + +また、必要に応じて、**DGML エディター**のビジュアライザーでグラフを表示します。 + +1. **[DGML エディター]** チェック ボックスをオンにします。 **[コード ツール]** セクションに表示されます。 diff --git a/includes/simple-string-format.md b/includes/simple-string-format.md new file mode 100644 index 00000000000..2d5884b9684 --- /dev/null +++ b/includes/simple-string-format.md @@ -0,0 +1,4 @@ + +ただし、**String.Format** メソッドの呼び出し時に、呼び出す特定のオーバーロードに焦点を当てる必要はありません。 代わりに、1 つ以上の書式項目を含む、[複合書式指定文字列](~/docs/standard/base-types/composite-formatting.md)を指定してメソッドを呼び出すことができます。 各書式項目を数値インデックスに割り当てます。最初のインデックスは 0 から始まります。 最初の文字列だけでなく、メソッド呼び出しには、インデックス値と同じ数の追加引数が必要です。 たとえば、書式項目のインデックスが 0 と 1 の文字列には 2 個の引数が必要です。インデックスが 0 から 5 の場合は、6 個の引数が必要です。 その後、言語コンパイラは、**String.Format** メソッドの特定のオーバーロードに対するメソッド呼び出しを解決します。 + +**String.Format** メソッドの使用に関する詳細なドキュメントについては、[String.Format メソッドの概要](#Starting)と[呼び出すメソッド](#FTaskList)に関するトピックを参照してください。 diff --git a/includes/sqo-diff-overload-example-elementtype-md.md b/includes/sqo-diff-overload-example-elementtype-md.md new file mode 100644 index 00000000000..8910a12df8c --- /dev/null +++ b/includes/sqo-diff-overload-example-elementtype-md.md @@ -0,0 +1,2 @@ +> [!NOTE] +> このコード例で使用するオーバーロードされたメソッドのオーバーロードは、このトピックで説明する特定のオーバーロードとは異なります。 コード例をこのトピックに適用するには、ソース シーケンスの要素を適切な数値型の要素に置き換えます。 \ No newline at end of file diff --git a/includes/sqo-diff-overload-example-func-md.md b/includes/sqo-diff-overload-example-func-md.md new file mode 100644 index 00000000000..6dfdd8f8fc2 --- /dev/null +++ b/includes/sqo-diff-overload-example-func-md.md @@ -0,0 +1,2 @@ +> [!NOTE] +> このコード例で使用するオーバーロードされたメソッドのオーバーロードは、このトピックで説明する特定のオーバーロードとは異なります。 コード例をこのトピックに適用するには、`selector` 関数の本体を変更します。 \ No newline at end of file diff --git a/includes/sslprotocols-none-md.md b/includes/sslprotocols-none-md.md new file mode 100644 index 00000000000..6d03a3fe070 --- /dev/null +++ b/includes/sslprotocols-none-md.md @@ -0,0 +1 @@ +.NET Framework 4.7 より、この方法では を使用して認証を行うため、オペレーティング システムが使用する最適なプロトコルを選択し、セキュリティで保護されていないプロトコルをブロックできるようになります。 .NET Framework 4.6 (および最新のセキュリティ パッチがインストールされている .NET Framework 4.5) で許可されている TLS /SSL プロトコルのバージョンは 1.2、1.1 および 1.0 です (ただし、Windows のレジストリを編集して強力な暗号化を無効にしていない場合に限ります)。 diff --git a/includes/stringbuilder-perf-note.md b/includes/stringbuilder-perf-note.md new file mode 100644 index 00000000000..71ab7383233 --- /dev/null +++ b/includes/stringbuilder-perf-note.md @@ -0,0 +1,25 @@ + プロパティで文字ベースのインデックス付けを使用すると、次の条件下では非常に遅くなることがあります。 + +- インスタンスが大きい (たとえば、数万文字が含まれている)。 +- が "チャンク化" している。 つまり、 などのメソッドの反復的な呼び出しにより、オブジェクトの プロパティが自動的に展開され、メモリの新しいチャンクがそれに割り当てられています。 + +文字にアクセスするたびに、チャンクのリンク リスト全体が走査されて、インデックスを付ける適切なバッファーが検索されるため、パフォーマンスが著しく低下します。 + +> [!NOTE] +> 大きな "チャンク化" した オブジェクトの場合でも、1 つまたは少数の文字へのインデックス ベースのアクセスに プロパティを使うと、パフォーマンスへの影響はごくわずかです。通常、これは **0(n)** 操作です。 オブジェクト内の文字を反復処理するときは、パフォーマンスに大きな影響が発生します。これは、**O(n^2)** 操作でます。 + + オブジェクトで文字ベースのインデックス付けを使うときにパフォーマンスの問題が発生する場合は、次のいずれかの回避策を使うことができます。 + +- メソッドを呼び出して インスタンスを に変換した後、文字列内の文字にアクセスします。 + +- 既存の オブジェクトの内容を、事前にサイズを設定した新しい オブジェクトにコピーします。 新しい オブジェクトはチャンク化していないため、パフォーマンスが向上します。 例: + + ```csharp + // sbOriginal is the existing StringBuilder object + var sbNew = new StringBuilder(sbOriginal.ToString(), sbOriginal.Length); + ``` + ```vb + ' sbOriginal is the existing StringBuilder object + Dim sbNew = New StringBuilder(sbOriginal.ToString(), sbOriginal.Length) + ``` +- コンストラクターを呼び出して、 オブジェクトの初期容量を、予想される最大サイズにほぼ等しい値に設定します。 このようにすると、 が最大容量に達することがほとんどない場合であっても、メモリ ブロック全体が割り当てられることに注意してください。 diff --git a/includes/tla2sharptla-uiautomation-md.md b/includes/tla2sharptla-uiautomation-md.md index 2bd371952d0..d8c9672a7cb 100644 --- a/includes/tla2sharptla-uiautomation-md.md +++ b/includes/tla2sharptla-uiautomation-md.md @@ -1 +1 @@ -UI 自動化 \ No newline at end of file +UI オートメーション \ No newline at end of file diff --git a/includes/version-keys-note.md b/includes/version-keys-note.md new file mode 100644 index 00000000000..e841511eb08 --- /dev/null +++ b/includes/version-keys-note.md @@ -0,0 +1,3 @@ + +> [!IMPORTANT] +> 次の表では、.NET Framework のリリース バージョンのみのキーの一覧を示します。 プレビュー バージョンまたはプレリリース バージョンのキーは示されていません。 diff --git a/includes/wif-saml2-ref-md.md b/includes/wif-saml2-ref-md.md new file mode 100644 index 00000000000..4e01afd0c1a --- /dev/null +++ b/includes/wif-saml2-ref-md.md @@ -0,0 +1 @@ +このクラスが表す要素について詳しくは、[OASIS Security Assertion Markup Language (SAML) V2.0 のアサーションとプロトコルの仕様](http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf)をご覧ください。 diff --git a/includes/wif-wsfed-ref-md.md b/includes/wif-wsfed-ref-md.md new file mode 100644 index 00000000000..ed266e42cfa --- /dev/null +++ b/includes/wif-wsfed-ref-md.md @@ -0,0 +1 @@ +このクラスが表すメッセージについて詳しくは、次の仕様のセクション 13 をご覧ください。[Web Services Federation Language (WS-Federation) Version 1.2 ](http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html) (http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html)。 diff --git a/includes/wif-wstrust-ref-md.md b/includes/wif-wstrust-ref-md.md new file mode 100644 index 00000000000..0e8893220f7 --- /dev/null +++ b/includes/wif-wstrust-ref-md.md @@ -0,0 +1 @@ +このクラスが表す要素について詳しくは、それぞれのシナリオに応じて、[WS-Trust February 2005](http://schemas.xmlsoap.org/ws/2005/02/trust/)、[WS-Trust 1.3](http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html)、または [WS-Trust 1.4](http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/os/ws-trust-1.4-spec-os.html) の各 WS-Trust 仕様をご覧ください。