From 1e75991ba5a9e2f19090331375c7f7b8e1e204a7 Mon Sep 17 00:00:00 2001
From: olprod <olprod@microsoft.com>
Date: Tue, 13 Nov 2018 11:24:08 +0000
Subject: [PATCH] commit translated contents

---
 docs/core/tools/dotnet-publish.md             |  8 +-
 docs/core/tools/dotnet-test.md                | 22 ++++--
 docs/core/tutorials/using-on-mac-vs.md        |  6 +-
 .../compiler-messages/cs0178.md               |  6 +-
 docs/csharp/language-reference/keywords/as.md | 11 +--
 .../language-reference/keywords/byte.md       |  9 ++-
 .../language-reference/keywords/char.md       | 10 +--
 .../language-reference/keywords/internal.md   |  9 ++-
 .../language-reference/keywords/long.md       |  9 ++-
 .../language-reference/keywords/nameof.md     | 13 +--
 .../language-reference/keywords/protected.md  | 10 +--
 .../language-reference/keywords/public.md     | 12 +--
 .../language-reference/keywords/sbyte.md      | 11 +--
 .../language-reference/keywords/short.md      |  8 +-
 .../language-reference/keywords/typeof.md     | 13 +--
 .../language-reference/keywords/uint.md       | 11 +--
 .../language-reference/keywords/ulong.md      | 11 +--
 .../language-reference/keywords/ushort.md     | 11 +--
 .../operators/addition-assignment-operator.md | 26 +++---
 .../operators/addition-operator.md            | 12 +--
 .../operators/and-assignment-operator.md      | 73 +++++++++--------
 .../operators/and-operator.md                 | 79 +++++++++++++------
 .../operators/conditional-and-operator.md     | 63 +++++++--------
 .../operators/conditional-operator.md         | 69 ++++++++++------
 .../operators/conditional-or-operator.md      | 60 +++++++-------
 .../operators/null-coalescing-operator.md     | 14 ++--
 .../partial-classes-and-methods.md            | 11 +--
 .../private-constructors.md                   | 13 +--
 .../classes-and-structs/properties.md         | 11 +--
 .../classes-and-structs/using-constructors.md | 11 +--
 .../concepts/linq/linq-to-xml-overview.md     | 64 ++++++++++-----
 .../creating-and-throwing-exceptions.md       | 13 +--
 .../exceptions/exception-handling.md          | 11 +--
 .../generics/generic-interfaces.md            | 10 +--
 .../general-structure-of-a-csharp-program.md  | 13 +--
 .../fixed-size-buffers.md                     |  6 +-
 ...rwarding-in-the-common-language-runtime.md |  6 +-
 .../how-to-debug-clr-activation-issues.md     |  6 +-
 .../deployment/net-framework-applications.md  |  6 +-
 .../migration-guide/retargeting/4.7-4.7.1.md  |  6 +-
 .../connection-grouping.md                    |  6 +-
 .../creating-internet-requests.md             |  6 +-
 .../deriving-from-webrequest.md               |  6 +-
 .../listening-with-sockets.md                 |  6 +-
 .../insert-xml-data-using-xpathnavigator.md   |  4 +-
 docs/standard/framework-libraries.md          | 28 +++----
 docs/standard/io/file-path-formats.md         | 10 +--
 ...synchronous-message-based-communication.md |  6 +-
 ...service-based-composite-ui-shape-layout.md |  6 +-
 ...lti-container-microservice-applications.md |  6 +-
 .../common-web-application-architectures.md   | 12 +--
 ...aged-and-unmanaged-threading-in-windows.md |  6 +-
 ...terscale-are-now-public-virtual-members.md |  2 +-
 ...inapppath-throws-nullreferenceexception.md |  2 +-
 ...acing-changed-when-using-antixssencoder.md |  2 +-
 ...hrottle-concurrent-requests-per-session.md |  2 +-
 ...lityhtmldecode-round-trip-bmp-correctly.md |  2 +-
 ...se-sha-256-code-signing-certificate-may.md |  2 +-
 ...r-decryptor-provides-reusable-transform.md |  2 +-
 .../core/calls-claimsidentity-constructors.md |  2 +-
 ...ture-currentuiculture-flow-across-tasks.md |  2 +-
 ...ream-uses-native-apis-for-decompression.md |  2 +-
 ...d-within-iteration-so-closure-capturing.md |  2 +-
 ...-property-must-be-correct-for-resulting.md |  2 +-
 ...hrow-exception-when-modifying-list-item.md |  2 +-
 .../retargeting/core/long-path-support.md     |  2 +-
 .../core/path-colon-checks-are-stricter.md    |  2 +-
 ...serialport-background-thread-exceptions.md |  2 +-
 ...table-pdbs-now-include-source-file-line.md |  2 +-
 .../systemuri-parsing-adheres-rfc-3987.md     |  2 +-
 ...od-returns-false-for-relative-uris-with.md |  2 +-
 ...entity-framework-version-must-match-net.md |  2 +-
 .../jit/il-ret-not-allowed-try-region.md      |  2 +-
 ...lue-servicepointmanagersecurityprotocol.md |  2 +-
 ...dauxrecord-flag-underlying-schannel-api.md |  2 +-
 ...ly-loads-rsa-keys-non-standard-key-size.md |  2 +-
 ...rns-rsacng-on-net462-or-lightup-without.md |  2 +-
 ...ay-result-when-using-reentrant-services.md |  2 +-
 ...ay-return-null-when-called-using-clause.md |  2 +-
 ...ssage-security-now-able-use-tls11-tls12.md |  2 +-
 ...kflowinstancemanagementtransactedcancel.md |  2 +-
 ...erloads-could-result-different-behavior.md |  2 +-
 .../wf/workflow-30-types-are-obsolete.md      |  2 +-
 ...ignerload-doesnt-remove-symbol-property.md |  2 +-
 ...ents-windows-forms-controls-for-net-472.md |  2 +-
 ...r-throws-for-re-entrant-implementations.md |  2 +-
 ...t-implementation-memberdescriptorequals.md |  2 +-
 ...ckagedigitalsignaturemanager-now-sha256.md |  2 +-
 .../wpf/wpf-pointer-based-touch-stack.md      |  2 +-
 ...ext-can-be-out-of-sync-with-databinding.md |  2 +-
 .../xml/xml-schema-validation-stricter.md     |  2 +-
 ...etects-violations-unique-constraints-if.md |  2 +-
 ...contentencoding-property-prohibits-utf7.md |  2 +-
 ...avascriptstringencode-escapes-ampersand.md |  2 +-
 ...w-unicode-uris-that-resemble-unc-shares.md |  2 +-
 ...etupdynamicbase-no-longer-randomized-by.md |  2 +-
 ...gttrytakefromany-does-not-throw-anymore.md |  2 +-
 ...orwarding-when-multi-targeting-mscorlib.md |  2 +-
 ...ure-events-from-providers-with-explicit.md |  2 +-
 ...passed-from-managed-code-out-of-process.md |  2 +-
 ...ger-throw-objectdisposedexception-after.md |  2 +-
 ...p-domain-no-longer-defaults-null-if-not.md |  2 +-
 ...-7-with-non-ifs-winsock-bsp-lsp-present.md |  2 +-
 ...avior-data-definition-language-ddl-apis.md |  2 +-
 ...ueryviews-with-specific-characteristics.md |  2 +-
 ...on-when-passing-comparing-uint16-values.md |  2 +-
 ...-therefore-can-no-longer-be-used-create.md |  2 +-
 ...s-serialized-under-net-framework-45-may.md |  2 +-
 ...te-validation-for-nettcp-authentication.md |  2 +-
 ...ersion-when-registering-itself-registry.md |  2 +-
 ...-object-no-longer-adds-default-endpoint.md |  2 +-
 ...s-an-argumentexception-if-addressheader.md |  2 +-
 ...ettcp-with-ssl-security-md5-certificate.md |  2 +-
 ...ableregex-app-setting-on-by-default-net.md |  2 +-
 ...ls-from-net-framework-11-20-are-blocked.md |  2 +-
 ...ion-instead-nullreferenceexception-some.md |  2 +-
 ...mary-key-clusters-disallows-null-values.md |  2 +-
 ...ing-an-item-from-custom-incc-collection.md |  2 +-
 ...lowdocument-may-show-an-extra-line-text.md |  2 +-
 .../horizontal-scrolling-virtualization.md    |  2 +-
 ...tem-itemscontrols-like-listbox-datagrid.md |  2 +-
 ...ot-remove-duplicates-from-selecteditems.md |  2 +-
 ...ssue-with-observablecollectionlttgtmove.md |  2 +-
 .../runtime/wpf/resizing-grid-can-hang.md     |  2 +-
 ...x-virtualizingstackpanel-can-cause-hang.md |  2 +-
 .../runtime/wpf/wpf-printing-stack-update.md  |  2 +-
 ...sptisexe-process-which-can-freeze-mouse.md |  2 +-
 ...pf-spell-checking-fails-unexpected-ways.md |  2 +-
 ...d-controls-will-not-work-windows-10-for.md |  2 +-
 ...-clipping-when-extending-outside-single.md |  2 +-
 ...t-style-sheet-exception-message-changed.md |  2 +-
 includes/topic-appliesto-net-core-all.md      |  2 +-
 132 files changed, 573 insertions(+), 462 deletions(-)

diff --git a/docs/core/tools/dotnet-publish.md b/docs/core/tools/dotnet-publish.md
index 494362df9f7..496dac08f16 100644
--- a/docs/core/tools/dotnet-publish.md
+++ b/docs/core/tools/dotnet-publish.md
@@ -4,11 +4,11 @@ description: dotnet publish コマンドは、.NET Core プロジェクトをデ
 author: mairaw
 ms.author: mairaw
 ms.date: 05/29/2018
-ms.openlocfilehash: a60777d613573076f41fba3e5ed610b236884063
-ms.sourcegitcommit: 2eceb05f1a5bb261291a1f6a91c5153727ac1c19
+ms.openlocfilehash: 17bacc92eea90072b95b2d42a87cb57e9fa0be67
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/04/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "43511425"
 ---
 # <a name="dotnet-publish"></a>dotnet publish
@@ -58,7 +58,7 @@ dotnet publish [-h|--help]
 
 `PROJECT`
 
-発行するプロジェクト。 指定しない場合は、既定で現在のディレクトリに設定されます。
+発行するプロジェクト。 これは、[C#](csproj.md)、F#、または Visual Basic のプロジェクト ファイルのパスおよびファイル名か、C#、F#、または Visual Basic のプロジェクト ファイルを含むディレクトリへのパスです。 指定しない場合は、既定で現在のディレクトリに設定されます。
 
 ## <a name="options"></a>オプション
 
diff --git a/docs/core/tools/dotnet-test.md b/docs/core/tools/dotnet-test.md
index 07344c0ade6..ddc7b1a5893 100644
--- a/docs/core/tools/dotnet-test.md
+++ b/docs/core/tools/dotnet-test.md
@@ -4,11 +4,11 @@ description: dotnet test コマンドは、指定されたプロジェクトで
 author: mairaw
 ms.author: mairaw
 ms.date: 05/29/2018
-ms.openlocfilehash: e80ba874ec8d0fbc49858719dc3b9b6e02254c78
-ms.sourcegitcommit: ad99773e5e45068ce03b99518008397e1299e0d1
+ms.openlocfilehash: 73b1d832b855798dd053187bbb24e8fb989fedf1
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/23/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "46696457"
 ---
 # <a name="dotnet-test"></a>dotnet test
@@ -25,7 +25,9 @@ ms.locfileid: "46696457"
 
 ```console
 dotnet test [<PROJECT>] [-a|--test-adapter-path] [--blame] [-c|--configuration] [--collect] [-d|--diag] [-f|--framework] [--filter]
-    [-l|--logger] [--no-build] [--no-restore] [-o|--output] [-r|--results-directory] [-s|--settings] [-t|--list-tests] [-v|--verbosity]
+    [-l|--logger] [--no-build] [--no-restore] [-o|--output] [-r|--results-directory] [-s|--settings] [-t|--list-tests] 
+    [-v|--verbosity] [-- <RunSettings arguments>]
+
 dotnet test [-h|--help]
 ```
 
@@ -34,6 +36,7 @@ dotnet test [-h|--help]
 ```console
 dotnet test [<PROJECT>] [-a|--test-adapter-path] [-c|--configuration] [--collect] [-d|--diag] [-f|--framework] [--filter]
     [-l|--logger] [--no-build] [--no-restore] [-o|--output] [-r|--results-directory] [-s|--settings] [-t|--list-tests] [-v|--verbosity]
+
 dotnet test [-h|--help]
 ```
 
@@ -41,6 +44,7 @@ dotnet test [-h|--help]
 
 ```console
 dotnet test [<PROJECT>] [-a|--test-adapter-path] [-c|--configuration] [-d|--diag] [-f|--framework] [--filter] [-l|--logger] [--no-build] [-o|--output] [-s|--settings] [-t|--list-tests]  [-v|--verbosity]
+
 dotnet test [-h|--help]
 ```
 
@@ -128,6 +132,14 @@ dotnet test [-h|--help]
 
 コマンドの詳細レベルを設定します。 指定できる値は、`q[uiet]`、`m[inimal]`、`n[ormal]`、`d[etailed]`、および `diag[nostic]` です。
 
+`RunSettings arguments`
+
+テストの RunSettings 構成として渡される引数です。 引数は、"-- " に続く `[name]=[value]` のペアとして指定されます (-- の後ろのスペースに注意してください)。 複数の `[name]=[value]` のペアを区切るにはスペースを使用します。
+
+例 : `dotnet test -- MSTest.DeploymentEnabled=false MSTest.MapInconclusiveToFailed=True`
+
+RunSettings について詳しくは、[vstest.console.exe: RunSettings 引数渡し](https://github.com/Microsoft/vstest-docs/blob/master/docs/RunSettingsArguments.md)に関するページをご覧ください。
+
 # <a name="net-core-20tabnetcore20"></a>[.NET Core 2.0](#tab/netcore20)
 
 `-a|--test-adapter-path <PATH_TO_ADAPTER>`
@@ -285,7 +297,7 @@ dotnet test [-h|--help]
 
 | 演算子            | 関数 |
 | ------------------- | -------- |
-| <code>&#124;</code> | OR       |
+| <code>&#124;</code> | OR       |
 | `&`                 | AND      |
 
 条件演算子を使用する場合は、式をかっこで囲みます (例: `(Name~TestMethod1) | (Name~TestMethod2)`)。
diff --git a/docs/core/tutorials/using-on-mac-vs.md b/docs/core/tutorials/using-on-mac-vs.md
index c9e3e9eacd8..ee7fe40af35 100644
--- a/docs/core/tutorials/using-on-mac-vs.md
+++ b/docs/core/tutorials/using-on-mac-vs.md
@@ -5,11 +5,11 @@ author: guardrex
 ms.author: mairaw
 ms.date: 06/12/2017
 ms.openlocfilehash: f751e7532e9627de3d3733476f7214654089e468
-ms.sourcegitcommit: 9bd8f213b50f0e1a73e03bd1e840c917fbd6d20a
+ms.sourcegitcommit: 5fd80619c760fa8c25d33a6f5661247cb65da465
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/27/2018
-ms.locfileid: "50170732"
+ms.lasthandoff: 11/01/2018
+ms.locfileid: "50744115"
 ---
 # <a name="getting-started-with-net-core-on-macos-using-visual-studio-for-mac"></a>Visual Studio for Mac を使用した macOS での .NET Core の概要
 
diff --git a/docs/csharp/language-reference/compiler-messages/cs0178.md b/docs/csharp/language-reference/compiler-messages/cs0178.md
index fbf30723c65..3e6d9ca58e3 100644
--- a/docs/csharp/language-reference/compiler-messages/cs0178.md
+++ b/docs/csharp/language-reference/compiler-messages/cs0178.md
@@ -7,11 +7,11 @@ helpviewer_keywords:
 - CS0178
 ms.assetid: 73e48648-6c0c-4987-92ca-fb2015a38910
 ms.openlocfilehash: a1939db032bee593884c04dd981d6c77493867f1
-ms.sourcegitcommit: 9bd8f213b50f0e1a73e03bd1e840c917fbd6d20a
+ms.sourcegitcommit: 5fd80619c760fa8c25d33a6f5661247cb65da465
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/25/2018
-ms.locfileid: "50044659"
+ms.lasthandoff: 11/01/2018
+ms.locfileid: "50744393"
 ---
 # <a name="compiler-error-cs0178"></a>コンパイラ エラー CS0178
 無効な次元指定子です: ',' または ']' を指定してください  
diff --git a/docs/csharp/language-reference/keywords/as.md b/docs/csharp/language-reference/keywords/as.md
index 7b2dcd07ba6..ecc7427ef8d 100644
--- a/docs/csharp/language-reference/keywords/as.md
+++ b/docs/csharp/language-reference/keywords/as.md
@@ -8,11 +8,11 @@ helpviewer_keywords:
 - type conversion [C#], as keyword
 - as keyword [C#]
 ms.assetid: a9be126b-cbf4-4990-a70d-d0e1983cad0e
-ms.openlocfilehash: ce3163f7d957df96a5c0304adc0b3083d8e20104
-ms.sourcegitcommit: 15d99019aea4a5c3c91ddc9ba23692284a7f61f3
+ms.openlocfilehash: d6c9d44ff22881e6e5e7a542e1df41bbf77b23d8
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/12/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "49122725"
 ---
 # <a name="as-c-reference"></a>as (C# リファレンス)
@@ -42,8 +42,9 @@ expression is type ? (type)expression : (type)null
 [!code-csharp[csrefKeywordsOperator#2](~/samples/snippets/csharp/VS_Snippets_VBCSharp/csrefKeywordsOperator/CS/csrefKeywordsOperators.cs#2)]
   
 ## <a name="c-language-specification"></a>C# 言語仕様  
- [!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]  
-  
+
+詳細については、「[C# 言語仕様](../language-specification/index.md)」の [as 演算子](~/_csharplang/spec/expressions.md#the-as-operator)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
+ 
 ## <a name="see-also"></a>参照  
 - [C# リファレンス](../../../csharp/language-reference/index.md)  
 - [C# プログラミング ガイド](../../../csharp/programming-guide/index.md)  
diff --git a/docs/csharp/language-reference/keywords/byte.md b/docs/csharp/language-reference/keywords/byte.md
index 06875ea4f11..4cc38785918 100644
--- a/docs/csharp/language-reference/keywords/byte.md
+++ b/docs/csharp/language-reference/keywords/byte.md
@@ -7,11 +7,11 @@ f1_keywords:
 helpviewer_keywords:
 - byte keyword [C#]
 ms.assetid: 111f1db9-ca32-4f0e-b497-4783517eda47
-ms.openlocfilehash: ee70b7c804423a35e2db3fe20ac4b66d8d1b98e2
-ms.sourcegitcommit: 2eceb05f1a5bb261291a1f6a91c5153727ac1c19
+ms.openlocfilehash: d952f56df62aa3a53e3889baa65c491e1a0fc81e
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/04/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "43505096"
 ---
 # <a name="byte-c-reference"></a>byte (C# リファレンス)
@@ -102,7 +102,8 @@ SampleMethod((byte)5);
  暗黙的な数値変換規則について詳しくは、「[暗黙的な数値変換の一覧表](../../../csharp/language-reference/keywords/implicit-numeric-conversions-table.md)」をご覧ください。  
   
 ## <a name="c-language-specification"></a>C# 言語仕様  
- [!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]  
+
+詳細については、「[C# 言語仕様](../language-specification/index.md)」の[整数型](~/_csharplang/spec/types.md#integral-types)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
   
 ## <a name="see-also"></a>参照  
 
diff --git a/docs/csharp/language-reference/keywords/char.md b/docs/csharp/language-reference/keywords/char.md
index 2670e033a5a..9569d5da29d 100644
--- a/docs/csharp/language-reference/keywords/char.md
+++ b/docs/csharp/language-reference/keywords/char.md
@@ -7,11 +7,11 @@ f1_keywords:
 helpviewer_keywords:
 - char data type [C#]
 ms.assetid: b51cf4fb-124c-4067-af48-afbac122b228
-ms.openlocfilehash: 95ecfaaf1397f7a4598faba6528b38170062145a
-ms.sourcegitcommit: 3c1c3ba79895335ff3737934e39372555ca7d6d0
+ms.openlocfilehash: 4d4e4719eabf7dbe31a59cc2e1e3d3d9019f080d
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/06/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "43742027"
 ---
 # <a name="char-c-reference"></a>char (C# リファレンス)
@@ -36,9 +36,9 @@ ms.locfileid: "43742027"
 
 <xref:System.Char?displayProperty=nameWithType> 型では、`char` 値を操作するための静的メソッドがいくつか提供されています。
 
-## <a name="c-language-specification"></a>C# 言語仕様
+## <a name="c-language-specification"></a>C# 言語仕様  
 
-[!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]
+詳細については、「[C# 言語仕様](../language-specification/index.md)」の[整数型](~/_csharplang/spec/types.md#integral-types)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
 
 ## <a name="see-also"></a>関連項目
 
diff --git a/docs/csharp/language-reference/keywords/internal.md b/docs/csharp/language-reference/keywords/internal.md
index b702474ce24..80cffeb4f47 100644
--- a/docs/csharp/language-reference/keywords/internal.md
+++ b/docs/csharp/language-reference/keywords/internal.md
@@ -7,11 +7,11 @@ f1_keywords:
 helpviewer_keywords:
 - internal keyword [C#]
 ms.assetid: 6ee0785c-d7c8-49b8-bb72-0a4dfbcb6461
-ms.openlocfilehash: 54ec003683953b53dedf8885a41350daf5338f83
-ms.sourcegitcommit: 2eceb05f1a5bb261291a1f6a91c5153727ac1c19
+ms.openlocfilehash: 28e74671894297e9fe81e681ba793d0806c9f28a
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/04/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "43523362"
 ---
 # <a name="internal-c-reference"></a>internal (C# リファレンス)
@@ -87,7 +87,8 @@ public class TestAccess
 ```  
   
 ## <a name="c-language-specification"></a>C# 言語仕様  
- [!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]  
+
+詳細については、「[C# 言語仕様](../language-specification/index.md)」の[宣言されたアクセシビリティ](~/_csharplang/spec/basic-concepts.md#declared-accessibility)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
   
 ## <a name="see-also"></a>参照
 
diff --git a/docs/csharp/language-reference/keywords/long.md b/docs/csharp/language-reference/keywords/long.md
index 33d91d16da6..0bd14495685 100644
--- a/docs/csharp/language-reference/keywords/long.md
+++ b/docs/csharp/language-reference/keywords/long.md
@@ -7,11 +7,11 @@ f1_keywords:
 helpviewer_keywords:
 - long keyword [C#]
 ms.assetid: f9b24319-1f39-48be-a42b-d528ee28a7fd
-ms.openlocfilehash: 52755e0914ead3ab61930dd8bfb9ecdd8ced0a14
-ms.sourcegitcommit: 2eceb05f1a5bb261291a1f6a91c5153727ac1c19
+ms.openlocfilehash: 1cc800b9e1d91884e4d048d29cc51cdc2b01b76c
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/04/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "43507148"
 ---
 # <a name="long-c-reference"></a>long (C# リファレンス)
@@ -100,7 +100,8 @@ long y = (long)3.0;   // OK: explicit conversion
 ```  
   
 ## <a name="c-language-specification"></a>C# 言語仕様  
- [!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]  
+
+詳細については、「[C# 言語仕様](../language-specification/index.md)」の[整数型](~/_csharplang/spec/types.md#integral-types)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
   
 ## <a name="see-also"></a>参照
 
diff --git a/docs/csharp/language-reference/keywords/nameof.md b/docs/csharp/language-reference/keywords/nameof.md
index eb04fe0248a..bdfad9ba0e7 100644
--- a/docs/csharp/language-reference/keywords/nameof.md
+++ b/docs/csharp/language-reference/keywords/nameof.md
@@ -5,12 +5,12 @@ f1_keywords:
 - nameof_CSharpKeyword
 - nameof
 ms.assetid: 33601bf3-cc2c-4496-846d-f9679bccf2a7
-ms.openlocfilehash: 726abfd903f37826a247e6e98c0d11f230447550
-ms.sourcegitcommit: ea00c05e0995dae928d48ead99ddab6296097b4c
+ms.openlocfilehash: 01c87f8d63264aa342b04b8d3fcfc7e6f38db44b
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/02/2018
-ms.locfileid: "48035254"
+ms.lasthandoff: 11/07/2018
+ms.locfileid: "50744357"
 ---
 # <a name="nameof-c-reference"></a>nameof (C# リファレンス)
 
@@ -131,8 +131,9 @@ class C {
  "`Method1 (str, str)`" などの署名情報を取得する方法はありません。  そうする 1 つの方法は、`Expression e = () => A.B.Method1("s1", "s2")` という式を使用し、結果として得られる式ツリーから MemberInfo を取得することです。  
   
 ## <a name="language-specifications"></a>言語仕様  
- [!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]  
-  
+
+詳細については、「[C# 言語仕様](../language-specification/index.md)」の [nameof 演算子](~/_csharplang/spec/expressions.md#nameof-expressions)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
+ 
 ## <a name="see-also"></a>参照
 
 - [C# リファレンス](../../../csharp/language-reference/index.md)  
diff --git a/docs/csharp/language-reference/keywords/protected.md b/docs/csharp/language-reference/keywords/protected.md
index 0ceaa760b00..f258731f48a 100644
--- a/docs/csharp/language-reference/keywords/protected.md
+++ b/docs/csharp/language-reference/keywords/protected.md
@@ -7,11 +7,11 @@ f1_keywords:
 helpviewer_keywords:
 - protected keyword [C#]
 ms.assetid: 05ce3794-6675-4025-bddb-eaaa0ec22892
-ms.openlocfilehash: cc3c8f81edb68fb26be560c8635e30dfd6e7b372
-ms.sourcegitcommit: c93fd5139f9efcf6db514e3474301738a6d1d649
+ms.openlocfilehash: 6e3f72226d10910152f7a2139a5a1be35e681ec7
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/28/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "50183179"
 ---
 # <a name="protected-c-reference"></a>protected (C# リファレンス)
@@ -46,9 +46,9 @@ protected メンバーは、そのクラス内部と、派生クラスのイン
 
 `'Point.x' is inaccessible due to its protection level.`
 
-## <a name="c-language-specification"></a>C# 言語仕様
+## <a name="c-language-specification"></a>C# 言語仕様  
 
-[!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]
+詳細については、「[C# 言語仕様](../language-specification/index.md)」の[宣言されたアクセシビリティ](~/_csharplang/spec/basic-concepts.md#declared-accessibility)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
 
 ## <a name="see-also"></a>関連項目
 
diff --git a/docs/csharp/language-reference/keywords/public.md b/docs/csharp/language-reference/keywords/public.md
index c7f114518d0..5cdc8d9b834 100644
--- a/docs/csharp/language-reference/keywords/public.md
+++ b/docs/csharp/language-reference/keywords/public.md
@@ -7,11 +7,11 @@ f1_keywords:
 helpviewer_keywords:
 - public keyword [C#]
 ms.assetid: 0ae45d16-a551-4b74-9845-57208de1328e
-ms.openlocfilehash: 84a3bc49b6eea047d518edc01dab7f2301854b6a
-ms.sourcegitcommit: 2eceb05f1a5bb261291a1f6a91c5153727ac1c19
+ms.openlocfilehash: b2e09bdb16d6128d69a3eb33cf2cffd4cba60376
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/04/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "43518187"
 ---
 # <a name="public-c-reference"></a>public (C# リファレンス)
@@ -37,14 +37,14 @@ class SampleClass
 
 'PointTest.y' はアクセスできない保護レベルになっています。
 
-## <a name="c-language-specification"></a>C# 言語仕様
+## <a name="c-language-specification"></a>C# 言語仕様  
 
-[!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]
+詳細については、「[C# 言語仕様](../language-specification/index.md)」の[宣言されたアクセシビリティ](~/_csharplang/spec/basic-concepts.md#declared-accessibility)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
 
 ## <a name="see-also"></a>関連項目
 
 - [C# リファレンス](../index.md)
-- [C# プログラミング ガイド](../../programming-guide/index.md)
+- [C# プログラミングガイド](../../programming-guide/index.md)
 - [アクセス修飾子](../../programming-guide/classes-and-structs/access-modifiers.md)
 - [C# のキーワード](index.md)
 - [アクセス修飾子](access-modifiers.md)
diff --git a/docs/csharp/language-reference/keywords/sbyte.md b/docs/csharp/language-reference/keywords/sbyte.md
index b6d38d23a35..d7fc9aac755 100644
--- a/docs/csharp/language-reference/keywords/sbyte.md
+++ b/docs/csharp/language-reference/keywords/sbyte.md
@@ -7,12 +7,12 @@ f1_keywords:
 helpviewer_keywords:
 - sbyte keyword [C#]
 ms.assetid: 1a9c7b48-73d1-4d33-b485-c4faf0a816bc
-ms.openlocfilehash: 1dca23c4a4216f1edc79b7701a002a28652aed26
-ms.sourcegitcommit: fb78d8abbdb87144a3872cf154930157090dd933
+ms.openlocfilehash: c64aae58317c54499b3d16c5643e4a473544c6a6
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/27/2018
-ms.locfileid: "47207142"
+ms.lasthandoff: 11/07/2018
+ms.locfileid: "50744510"
 ---
 # <a name="sbyte-c-reference"></a>sbyte (C# リファレンス)
 
@@ -102,7 +102,8 @@ sbyte y = (sbyte)3.0;  // OK: explicit conversion
  暗黙的な数値変換規則の詳細については、「[暗黙的な数値変換の一覧表](../../../csharp/language-reference/keywords/implicit-numeric-conversions-table.md)」を参照してください。  
   
 ## <a name="c-language-specification"></a>C# 言語仕様  
- [!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]  
+
+詳細については、「[C# 言語仕様](../language-specification/index.md)」の[整数型](~/_csharplang/spec/types.md#integral-types)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
   
 ## <a name="see-also"></a>参照
 
diff --git a/docs/csharp/language-reference/keywords/short.md b/docs/csharp/language-reference/keywords/short.md
index 9822597840b..ace0a3ac331 100644
--- a/docs/csharp/language-reference/keywords/short.md
+++ b/docs/csharp/language-reference/keywords/short.md
@@ -7,11 +7,11 @@ f1_keywords:
 helpviewer_keywords:
 - short keyword [C#]
 ms.assetid: 04c10688-e51a-4a87-bfec-83f7fb42ff11
-ms.openlocfilehash: 0d90f31da49b94eee490e95f0cdf1d582bb0b059
-ms.sourcegitcommit: c93fd5139f9efcf6db514e3474301738a6d1d649
+ms.openlocfilehash: d3b374c01c78a63e8341023b65dc3e57542ec1fd
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/27/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "50184154"
 ---
 # <a name="short-c-reference"></a>short (C# リファレンス)
@@ -100,7 +100,7 @@ short y = (short)3.0;   // OK: explicit conversion
 
 ## <a name="c-language-specification"></a>C# 言語仕様
 
-[!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]
+詳細については、「[C# 言語仕様](../language-specification/index.md)」の[整数型](~/_csharplang/spec/types.md#integral-types)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
 
 ## <a name="see-also"></a>関連項目
 
diff --git a/docs/csharp/language-reference/keywords/typeof.md b/docs/csharp/language-reference/keywords/typeof.md
index 8cc071ef59e..0dbd58679cd 100644
--- a/docs/csharp/language-reference/keywords/typeof.md
+++ b/docs/csharp/language-reference/keywords/typeof.md
@@ -7,12 +7,12 @@ f1_keywords:
 helpviewer_keywords:
 - typeof keyword [C#]
 ms.assetid: 0c08d880-515e-46bb-8cd2-48b8dd62c08d
-ms.openlocfilehash: 2493e78fd0782eebee17afd979e1c429339d0a3f
-ms.sourcegitcommit: 2eceb05f1a5bb261291a1f6a91c5153727ac1c19
+ms.openlocfilehash: aff7462f0df938a8e96cca33155489bee4891da0
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/04/2018
-ms.locfileid: "43529209"
+ms.lasthandoff: 11/07/2018
+ms.locfileid: "50744445"
 ---
 # <a name="typeof-c-reference"></a>typeof (C# リファレンス)
 型の `System.Type` オブジェクトを取得するために使用されます。 `typeof` 式は次の形式になります。  
@@ -44,8 +44,9 @@ System.Type type = i.GetType();
  [!code-csharp[csrefKeywordsOperator#13](../../../csharp/language-reference/keywords/codesnippet/CSharp/typeof_2.cs)]  
   
 ## <a name="c-language-specification"></a>C# 言語仕様  
- [!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]  
-  
+
+詳細については、「[C# 言語仕様](../language-specification/index.md)」の [typeof 演算子](~/_csharplang/spec/expressions.md#the-typeof-operator)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
+ 
 ## <a name="see-also"></a>参照
 
 - <xref:System.Type?displayProperty=nameWithType>  
diff --git a/docs/csharp/language-reference/keywords/uint.md b/docs/csharp/language-reference/keywords/uint.md
index 455d2709c31..a8f3b7a0f39 100644
--- a/docs/csharp/language-reference/keywords/uint.md
+++ b/docs/csharp/language-reference/keywords/uint.md
@@ -7,12 +7,12 @@ f1_keywords:
 helpviewer_keywords:
 - uint keyword [C#]
 ms.assetid: e93e42c6-ec72-4b0b-89df-2fd8d36f7a7b
-ms.openlocfilehash: e75abf8ac356eaed6c54dd0309316fb6755bf635
-ms.sourcegitcommit: 3c1c3ba79895335ff3737934e39372555ca7d6d0
+ms.openlocfilehash: c8610d13a97e672773fdf80d013a159a58e7cfbf
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/06/2018
-ms.locfileid: "43858305"
+ms.lasthandoff: 11/07/2018
+ms.locfileid: "50744331"
 ---
 # <a name="uint-c-reference"></a>uint (C# リファレンス)
 
@@ -85,7 +85,8 @@ uint y = (uint)3.0;
  暗黙的な数値変換規則の詳細については、「[暗黙的な数値変換の一覧表](../../../csharp/language-reference/keywords/implicit-numeric-conversions-table.md)」を参照してください。  
   
 ## <a name="c-language-specification"></a>C# 言語仕様  
- [!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]  
+
+詳細については、「[C# 言語仕様](../language-specification/index.md)」の[整数型](~/_csharplang/spec/types.md#integral-types)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
   
 ## <a name="see-also"></a>参照
 
diff --git a/docs/csharp/language-reference/keywords/ulong.md b/docs/csharp/language-reference/keywords/ulong.md
index 4144ad994b4..5818f7256bc 100644
--- a/docs/csharp/language-reference/keywords/ulong.md
+++ b/docs/csharp/language-reference/keywords/ulong.md
@@ -7,12 +7,12 @@ f1_keywords:
 helpviewer_keywords:
 - ulong keyword [C#]
 ms.assetid: f2ece624-837a-40cf-92c5-343e7f33397c
-ms.openlocfilehash: a68ebe1d382bf39e945d333a728fad66934fd286
-ms.sourcegitcommit: 2eceb05f1a5bb261291a1f6a91c5153727ac1c19
+ms.openlocfilehash: 9a1e7457812bac64b8ef27141a174dc01ca466c3
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/04/2018
-ms.locfileid: "43505178"
+ms.lasthandoff: 11/07/2018
+ms.locfileid: "50980847"
 ---
 # <a name="ulong-c-reference"></a>ulong (C# リファレンス)
 
@@ -93,7 +93,8 @@ ulong y = (ulong)3.0;
  暗黙的な数値変換規則について詳しくは、「[暗黙的な数値変換の一覧表](../../../csharp/language-reference/keywords/implicit-numeric-conversions-table.md)」をご覧ください。  
   
 ## <a name="c-language-specification"></a>C# 言語仕様  
- [!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]  
+
+詳細については、「[C# 言語仕様](../language-specification/index.md)」の[整数型](~/_csharplang/spec/types.md#integral-types)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
   
 ## <a name="see-also"></a>参照
 
diff --git a/docs/csharp/language-reference/keywords/ushort.md b/docs/csharp/language-reference/keywords/ushort.md
index 6c8d13d68ef..1bddf09f2e9 100644
--- a/docs/csharp/language-reference/keywords/ushort.md
+++ b/docs/csharp/language-reference/keywords/ushort.md
@@ -7,12 +7,12 @@ f1_keywords:
 helpviewer_keywords:
 - ushort keyword [C#]
 ms.assetid: 1a7dbaae-b7a0-4111-872a-c88a6d3981ac
-ms.openlocfilehash: 2f038378e1af85520cea13d914da69dfcb054ac0
-ms.sourcegitcommit: 3c1c3ba79895335ff3737934e39372555ca7d6d0
+ms.openlocfilehash: fa7f80f8f0fd6efa92242949ef16963213d0a28e
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/06/2018
-ms.locfileid: "43857299"
+ms.lasthandoff: 11/07/2018
+ms.locfileid: "50744484"
 ---
 # <a name="ushort-c-reference"></a>ushort (C# リファレンス)
 
@@ -101,7 +101,8 @@ ushort y = (ushort)3.0;
  暗黙的な数値変換規則の詳細については、「[暗黙的な数値変換の一覧表](../../../csharp/language-reference/keywords/implicit-numeric-conversions-table.md)」を参照してください。  
   
 ## <a name="c-language-specification"></a>C# 言語仕様  
- [!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]  
+
+詳細については、「[C# 言語仕様](../language-specification/index.md)」の[整数型](~/_csharplang/spec/types.md#integral-types)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
   
 ## <a name="see-also"></a>参照
 
diff --git a/docs/csharp/language-reference/operators/addition-assignment-operator.md b/docs/csharp/language-reference/operators/addition-assignment-operator.md
index 2a6dfb703a2..a7cee917344 100644
--- a/docs/csharp/language-reference/operators/addition-assignment-operator.md
+++ b/docs/csharp/language-reference/operators/addition-assignment-operator.md
@@ -1,6 +1,6 @@
 ---
 title: += 演算子 (C# リファレンス)
-ms.date: 10/22/2018
+ms.date: 10/29/2018
 f1_keywords:
 - +=_CSharpKeyword
 helpviewer_keywords:
@@ -8,40 +8,46 @@ helpviewer_keywords:
 - addition assignment operator (+=) [C#]
 - event subscription [C#]
 ms.assetid: 9cdf97e6-331d-492b-85e1-3ec3171484e9
-ms.openlocfilehash: ee335e3e2e7d352d4e26b802bad2b08a05c666ab
-ms.sourcegitcommit: c93fd5139f9efcf6db514e3474301738a6d1d649
+ms.openlocfilehash: ac9330e283cb58ae4e0ee7b644aa2c22bdf64c46
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/27/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "50192032"
 ---
 # <a name="-operator-c-reference"></a>+= 演算子 (C# リファレンス)
 
 加算代入演算子です。
 
-次のような `+=` 演算子を使用する式があるとします  
+次のような `+=` 演算子を使用する式があるとします
 
 ```csharp
 x += y
-```  
+```
 
-上記の式は、次の式と同じです。  
+上記の式は、次の式と同じです。
 
 ```csharp
 x = x + y
-```  
+```
 
 ただし、`x` が評価されるのは 1 回だけです。
   
 数値型の場合、[加算演算子](addition-operator.md) `+` によってそのオペランドの合計が計算されます。 一方または両方のオペランドが[文字列型](../keywords/string.md)である場合、そのオペランドの文字列表現を連結します。 デリゲート型の場合、`+` 演算子によって、そのオペランドの組み合わせである新しいデリゲート インスタンスが返されます。
 
-ユーザー定義型により[加算演算子](addition-operator.md) `+` が[オーバーロード](../keywords/operator.md)される場合、加算代入演算子 `+=` が暗黙的にオーバーロードされます。
-
 [イベント](../keywords/event.md)をサブスクライブするとき、`+=` 演算子を使用してイベント ハンドラー メソッドを指定することもできます。 詳細については、「[方法: イベント サブスクリプションとサブスクリプションの解除](../../programming-guide/events/how-to-subscribe-to-and-unsubscribe-from-events.md)」を参照してください。
 
 `+=` 演算子の使用例を次に示します。
 
 [!code-csharp-interactive[+= examples](~/samples/snippets/csharp/language-reference/operators/AdditionExamples.cs#AddAndAssign)]
+
+## <a name="operator-overloadability"></a>演算子のオーバーロード可/不可
+
+ユーザー定義型により[加算演算子](addition-operator.md) `+` が[オーバーロード](../keywords/operator.md)される場合、加算代入演算子 `+=` が暗黙的にオーバーロードされます。 ユーザー定義型は、加算代入演算子を明示的にオーバー ロードできません。
+
+## <a name="c-language-specification"></a>C# 言語仕様
+
+詳細については、「[C# 言語仕様](../language-specification/index.md)」の[複合代入](~/_csharplang/spec/expressions.md#compound-assignment)と[イベント代入](~/_csharplang/spec/expressions.md#event-assignment)に関するセクションを参照してください。
   
 ## <a name="see-also"></a>関連項目
 
diff --git a/docs/csharp/language-reference/operators/addition-operator.md b/docs/csharp/language-reference/operators/addition-operator.md
index bb6df16fc30..fa84285615b 100644
--- a/docs/csharp/language-reference/operators/addition-operator.md
+++ b/docs/csharp/language-reference/operators/addition-operator.md
@@ -8,19 +8,17 @@ helpviewer_keywords:
 - concatenation operator [C#]
 - addition operator [C#]
 ms.assetid: 93e56486-bb42-43c1-bd43-60af11e64e67
-ms.openlocfilehash: ae2774d96bc50afa271fffdea445e640e68c3647
-ms.sourcegitcommit: c93fd5139f9efcf6db514e3474301738a6d1d649
+ms.openlocfilehash: 27ea47d698b20f112880750ec0bc931f1917f142
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/27/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "50192305"
 ---
 # <a name="-operator-c-reference"></a>+ 演算子 (C# リファレンス)
 
 `+` 演算子は 2 つの形式でサポートされます。単項プラス演算子と二項加算演算子です。
 
-単項演算子と二項 `+` 演算子は、ユーザー定義型で[オーバーロード](../keywords/operator.md)できます。 二項 `+` 演算子をオーバーロードすると、[加算代入演算子](addition-assignment-operator.md) `+=` も暗黙的にオーバーロードされます。
-
 ## <a name="unary-plus-operator"></a>単項プラス演算子
 
 単項 `+` 演算子によって、そのオペランドの値が返されます。 すべての数値型でサポートされます。
@@ -49,6 +47,10 @@ C# 6 以降、[文字列補間](../tokens/interpolated.md)という文字列を
 
 デリゲート型の詳細については、[デリゲート](../../programming-guide/delegates/index.md)に関するページを参照してください。
 
+## <a name="operator-overloadability"></a>演算子のオーバーロード可/不可
+
+単項演算子と二項 `+` 演算子は、ユーザー定義型で[オーバーロード](../keywords/operator.md)できます。 二項 `+` 演算子をオーバーロードすると、[加算代入演算子](addition-assignment-operator.md) `+=` も暗黙的にオーバーロードされます。
+
 ## <a name="c-language-specification"></a>C# 言語仕様
 
 詳細については、[C# 言語仕様](../language-specification/index.md)の[単項プラス演算子](~/_csharplang/spec/expressions.md#unary-plus-operator)と[加算演算子](~/_csharplang/spec/expressions.md#addition-operator)に関するセクションを参照してください。
diff --git a/docs/csharp/language-reference/operators/and-assignment-operator.md b/docs/csharp/language-reference/operators/and-assignment-operator.md
index 9eba29a2b66..b536aec65e6 100644
--- a/docs/csharp/language-reference/operators/and-assignment-operator.md
+++ b/docs/csharp/language-reference/operators/and-assignment-operator.md
@@ -1,44 +1,53 @@
 ---
 title: '&amp;= 演算子 (C# リファレンス)'
-ms.date: 07/20/2015
+ms.date: 10/29/2018
 f1_keywords:
 - '&=_CSharpKeyword'
 helpviewer_keywords:
 - AND assignment operator (&=) [C#]
 - '&= operator [C#]'
 ms.assetid: e8d58f3f-72dd-4b5a-b995-452fcce7e6bb
-ms.openlocfilehash: f3a6fe20ca89a90b5a64118d73fb39e9a364d1e9
-ms.sourcegitcommit: 2eceb05f1a5bb261291a1f6a91c5153727ac1c19
+ms.openlocfilehash: 8ce27c999cf21a9059ba23ee3c86b8fa024c7341
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/04/2018
-ms.locfileid: "43506402"
+ms.lasthandoff: 11/07/2018
+ms.locfileid: "50980610"
 ---
 # <a name="amp-operator-c-reference"></a>&amp;= 演算子 (C# リファレンス)
-AND 代入演算子です。  
-  
-## <a name="remarks"></a>コメント  
- 次のような `&=` 代入演算子を使用する式があるとします  
-  
-```csharp  
-x &= y  
-```  
-  
- 上記の式は、次の式と同じです。  
-  
-```csharp  
-x = x & y  
-```  
-  
- ただし、`x` が評価されるのは 1 回だけです。 [& 演算子](../../../csharp/language-reference/operators/and-operator.md)では、整数のオペランドではビットごとの論理 AND 演算、`bool` オペランドでは論理 AND 演算が実行されます。  
-  
- `&=` 演算子は直接オーバーロードできませんが、[& 演算子](../../../csharp/language-reference/operators/and-operator.md)はユーザー定義型でオーバーロードできます (「[operator](../../../csharp/language-reference/keywords/operator.md)」を参照)。  
-  
-## <a name="example"></a>例  
- [!code-csharp[csRefOperators#34](../../../csharp/language-reference/operators/codesnippet/CSharp/and-assignment-operator_1.cs)]  
-  
-## <a name="see-also"></a>参照
-
-- [C# リファレンス](../../../csharp/language-reference/index.md)  
-- [C# プログラミング ガイド](../../../csharp/programming-guide/index.md)  
-- [C# 演算子](../../../csharp/language-reference/operators/index.md)
+
+AND 代入演算子です。
+
+次のような `&=` 演算子を使用する式があるとします
+
+```csharp
+x &= y
+```
+
+上記の式は、次の式と同じです。
+
+```csharp
+x = x & y
+```
+
+ただし、`x` が評価されるのは 1 回だけです。
+
+整数オペランドの場合、[`&` 演算子](and-operator.md)はそのオペランドのビット演算論理 AND を計算しますが、[bool](../keywords/bool.md) オペランドの場合は、そのオペランドの論理 AND を計算します。
+
+`&=` 演算子の使用例を次に示します。
+
+[!code-csharp-interactive[AND assignment example](~/samples/snippets/csharp/language-reference/operators/AndOperatorExamples.cs#AndAssignmentExample)]
+
+## <a name="operator-overloadability"></a>演算子のオーバーロード可/不可
+
+ユーザー定義型により、[`&` 演算子](and-operator.md)が[オーバーロード](../keywords/operator.md)される場合、AND 代入演算子 `&=` が暗黙的にオーバーロードされます。 ユーザー定義型は、AND 代入演算子を明示的にオーバー ロードできません。
+
+## <a name="c-language-specification"></a>C# 言語仕様
+
+詳細については、「[C# 言語仕様](../language-specification/index.md)」の[複合代入](~/_csharplang/spec/expressions.md#compound-assignment)に関するセクションを参照してください。
+
+## <a name="see-also"></a>関連項目
+
+- [C# リファレンス](../index.md)
+- [C# プログラミングガイド](../../programming-guide/index.md)
+- [C# 演算子](index.md)
diff --git a/docs/csharp/language-reference/operators/and-operator.md b/docs/csharp/language-reference/operators/and-operator.md
index e9c45286eb3..54c5651400b 100644
--- a/docs/csharp/language-reference/operators/and-operator.md
+++ b/docs/csharp/language-reference/operators/and-operator.md
@@ -1,6 +1,6 @@
 ---
 title: '&amp; 演算子 (C# リファレンス)'
-ms.date: 04/04/2018
+ms.date: 10/29/2018
 f1_keywords:
 - '&_CSharpKeyword'
 helpviewer_keywords:
@@ -9,32 +9,61 @@ helpviewer_keywords:
 - '& operator [C#]'
 - AND operator (&) [C#]
 ms.assetid: afa346d5-90ec-4b1f-a2c8-3881f018741d
-ms.openlocfilehash: b257c7d41618464e26ab3b54bcfb1f1e2c2e420e
-ms.sourcegitcommit: 2eceb05f1a5bb261291a1f6a91c5153727ac1c19
+ms.openlocfilehash: a8f76ded0ef9f8e8099838a903d90f1695324991
+ms.sourcegitcommit: b5cd9d5d3b75a5537fc9ad8a3f085f0bb1845ee0
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/04/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "43510979"
 ---
 # <a name="amp-operator-c-reference"></a>&amp; 演算子 (C# リファレンス)
-`&` 演算子には、単項演算子としての働きと 2 項演算子としての働きとがあります。  
-  
-## <a name="remarks"></a>コメント  
- 単項 `&` 演算子では、オペランドのアドレスが返されます ([unsafe](../../../csharp/language-reference/keywords/unsafe.md) コンテキストが必要)。  
-  
- 整数型と `bool` には、2 項 `&` 演算子が事前定義されています。 整数型の場合、& はオペランドのビットごとの論理 AND を計算します。 `bool` オペランドの場合、& は、そのオペランドの論理 AND を計算します。つまり、結果は、両方のオペランドが `true` の場合にのみ `true` になります。  
-  
- バイナリ `&` 演算子では、[条件 AND 演算子](../../../csharp/language-reference/operators/conditional-and-operator.md) `&&` とは対照的に、最初の演算子の値に関係なく、両方の演算子が評価されます。 例:  
-  
- [!code-csharp[csRefOperators#37](../../../csharp/language-reference/operators/codesnippet/CSharp/and-operator_1.cs)]  
-  
- ユーザー定義型は二項 `&` 演算子をオーバーロードできます (「[演算子](../../../csharp/language-reference/keywords/operator.md)」を参照)。 整数型に対する演算は、通常、列挙型で使用できます。 二項演算子をオーバーロードすると、対応する代入演算子がある場合、これも暗黙的にオーバーロードされます。  
-  
-## <a name="example"></a>例  
- [!code-csharp[csRefOperators#38](../../../csharp/language-reference/operators/codesnippet/CSharp/and-operator_2.cs)]  
-  
-## <a name="see-also"></a>参照
-
-- [C# リファレンス](../../../csharp/language-reference/index.md)  
-- [C# プログラミング ガイド](../../../csharp/programming-guide/index.md)  
-- [C# 演算子](../../../csharp/language-reference/operators/index.md)
+
+`&` 演算子は 2 つの形式でサポートされます。単項 address-of 演算子と二項論理演算子です。
+
+## <a name="unary-address-of-operator"></a>単項 address-of 演算子
+
+単項 `&` 演算子によって、そのオペランドのアドレスが返されます。 詳細については、「[方法: 変数のアドレスを取得する](../../programming-guide/unsafe-code-pointers/how-to-obtain-the-address-of-a-variable.md)」を参照してください。
+
+address-of 演算子 `&` には [unsafe](../keywords/unsafe.md) コンテキストが必要です。
+
+## <a name="integer-logical-bitwise-and-operator"></a>整数論理ビット演算 AND 演算子
+
+整数型の場合、`&` 演算子がそのオペランドの論理ビット演算 AND を計算します。
+
+[!code-csharp-interactive[integer logical bitwise AND](~/samples/snippets/csharp/language-reference/operators/AndOperatorExamples.cs#IntegerOperands)]
+
+> [!NOTE]
+> 上記の例では、[C# 7.0 で導入され](../../whats-new/csharp-7.md#numeric-literal-syntax-improvements)、[C# 7.2 で強化された](../../whats-new/csharp-7-2.md#leading-underscores-in-numeric-literals)バイナリ リテラルを使用しています。
+
+整数型に対する演算は一般的に列挙型でも許可されているため、`&` 演算子は [enum](../keywords/enum.md) オペランドもサポートします。
+
+## <a name="boolean-logical-and-operator"></a>ブール論理 AND 演算子
+
+[bool](../keywords/bool.md) オペランドの場合、`&` 演算子がそのオペランドの論理 AND を計算します。 `x` と `y` の両方が `true` であれば、`x & y` の結果は `true` です。 それ以外の場合、結果は `false` です。
+
+`&` 演算子は最初のオペランドが `false` と評価されても両方のオペランドを評価するため、結果は 2 番目のオペランドの値に関係なく、必ず `false` になります。 次の例は、その動作を示します。
+
+[!code-csharp-interactive[bool logical AND](~/samples/snippets/csharp/language-reference/operators/AndOperatorExamples.cs#BooleanOperands)]
+
+[条件 AND 演算子](conditional-and-operator.md)`&&`もそのオペランドの論理 AND を計算しますが、2 番目のオペランドが評価されるのは、最初のオペランドが `true` と評価された場合にのみです。
+
+Null 許容型ブールのオペランドの場合、`&` 演算子の動作は、SQL の 3 値論理と一致します。 詳細については、「[Null 許容型の使用](../../programming-guide/nullable-types/using-nullable-types.md)」の記事の「[bool? 型](../../programming-guide/nullable-types/using-nullable-types.md#the-bool-type)」のセクションを参照してください。
+
+## <a name="operator-overloadability"></a>演算子のオーバーロード可/不可
+
+ユーザー定義型は二項 `&` 演算子を[オーバーロード](../keywords/operator.md)できます。 二項 `&` 演算子をオーバーロードすると、[AND 代入演算子](and-assignment-operator.md) `&=` も暗黙的にオーバーロードされます。
+
+## <a name="c-language-specification"></a>C# 言語仕様
+
+詳細については、「[C# 言語仕様](../language-specification/index.md)」の [address-of 演算子](~/_csharplang/spec/unsafe-code.md#the-address-of-operator)と[論理演算子](~/_csharplang/spec/expressions.md#logical-operators)に関するセクションを参照してください。
+
+## <a name="see-also"></a>関連項目
+
+- [C# リファレンス](../index.md)
+- [C# プログラミングガイド](../../programming-guide/index.md)
+- [C# 演算子](index.md)
+- [ポインター型](../../programming-guide/unsafe-code-pointers/pointer-types.md)
+- [| 演算子](or-operator.md)
+- [^ 演算子](xor-operator.md)
+- [~ 演算子](bitwise-complement-operator.md)
+- [&& 演算子](conditional-and-operator.md)
diff --git a/docs/csharp/language-reference/operators/conditional-and-operator.md b/docs/csharp/language-reference/operators/conditional-and-operator.md
index 4d8e595cfff..92192cfb00e 100644
--- a/docs/csharp/language-reference/operators/conditional-and-operator.md
+++ b/docs/csharp/language-reference/operators/conditional-and-operator.md
@@ -1,49 +1,40 @@
 ---
 title: '&amp;&amp; 演算子 (C# リファレンス)'
-ms.date: 07/20/2015
+ms.date: 11/06/2018
 f1_keywords:
 - '&&_CSharpKeyword'
 helpviewer_keywords:
 - '&& operator [C#]'
 - logical AND operator [C#]
 ms.assetid: 2e4f0a1c-92a3-40f8-8e3b-17b607f20c31
-ms.openlocfilehash: 459b791fde3e4d3940dbd3d916f940e81f365da6
-ms.sourcegitcommit: 2eceb05f1a5bb261291a1f6a91c5153727ac1c19
+ms.openlocfilehash: d0e6d9a5aedc7dc87393e3dea070bf442b3268dc
+ms.sourcegitcommit: b5cd9d5d3b75a5537fc9ad8a3f085f0bb1845ee0
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/04/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "43529236"
 ---
 # <a name="ampamp-operator-c-reference"></a>&amp;&amp; 演算子 (C# リファレンス)
-条件 AND 演算子 (`&&`) では `bool` オペランドの論理 AND が実行されますが、2 番目のオペランドは必要な場合にのみ評価されます。  
-  
-## <a name="remarks"></a>コメント  
- 次の演算は、  
-  
-```csharp  
-x && y  
-```  
-  
- 次の演算に対応しています。  
-  
-```csharp  
-x & y  
-```  
-  
- ただし `x` が `false` の場合は、AND 演算の結果は `y` の値に関係なく `false` となるため、`y` は評価されません。 これは、"ショートサーキット" 評価と呼ばれます。  
-  
- 条件 AND 演算子はオーバーロードできませんが、通常の論理演算子、[true](../../../csharp/language-reference/keywords/true.md) 演算子、[false](../../../csharp/language-reference/keywords/false.md) 演算子のオーバーロードは、条件論理演算子の制約付きのオーバーロードとも見なされます。  
-  
-## <a name="example"></a>例  
- 次の例では、2 番目の `if` ステートメントの条件式で最初のオペランドのみが評価されます。これは、このオペランドが `false` を返すからです。  
-  
- [!code-csharp[csRefOperators#48](../../../csharp/language-reference/operators/codesnippet/CSharp/conditional-and-operator_1.cs)]  
-  
-## <a name="c-language-specification"></a>C# 言語仕様  
- [!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]  
-  
-## <a name="see-also"></a>参照
-
-- [C# リファレンス](../../../csharp/language-reference/index.md)  
-- [C# プログラミング ガイド](../../../csharp/programming-guide/index.md)  
-- [C# 演算子](../../../csharp/language-reference/operators/index.md)
+
+条件論理 AND 演算子 `&&` は、"短絡" 論理 AND 演算子とも呼ばれ、その [bool](../keywords/bool.md) オペランドの論理 AND を計算します。 `x` と `y` の両方が `true` と評価されれば、`x && y` の結果は `true` です。 それ以外の場合、結果は `false` です。 最初のオペランドが `false` と評価されると、2 番目のオペランドは評価されず、演算の結果は `false` になります。 次の例は、その動作を示します。
+
+[!code-csharp-interactive[conditional logical AND](~/samples/snippets/csharp/language-reference/operators/ConditionalLogicalOperatorsExamples.cs#And)]
+
+[論理 AND 演算子](and-operator.md) `&` もその `bool` オペランドの論理 AND を計算しますが、常に両方のオペランドを評価します。
+
+## <a name="operator-overloadability"></a>演算子のオーバーロード可/不可
+
+ユーザー定義型は条件論理 AND 演算子をオーバーロードできません。 ただし、ユーザー定義型が[論理 AND](and-operator.md)、[true](../keywords/true-operator.md)、および [false](../keywords/false-operator.md) 演算子を特定の方法でオーバーロードする場合、`&&` 演算はその型のオペランドに対して評価を行うことができます。 詳細については、「[C# 言語仕様](../language-specification/index.md)」の[ユーザー定義型条件論理演算子](~/_csharplang/spec/expressions.md#user-defined-conditional-logical-operators)に関するセクションを参照してください。
+
+## <a name="c-language-specification"></a>C# 言語仕様
+
+詳細については、「[C# 言語仕様](../language-specification/index.md)」の[条件論理演算子](~/_csharplang/spec/expressions.md#conditional-logical-operators)に関するセクションを参照してください。
+
+## <a name="see-also"></a>関連項目
+
+- [C# リファレンス](../index.md)
+- [C# プログラミングガイド](../../programming-guide/index.md)
+- [C# 演算子](index.md)
+- [|| 演算子](conditional-or-operator.md)
+- [! 演算子](logical-negation-operator.md)
+- [& 演算子](and-operator.md)
diff --git a/docs/csharp/language-reference/operators/conditional-operator.md b/docs/csharp/language-reference/operators/conditional-operator.md
index 5bced80a085..4e14287c451 100644
--- a/docs/csharp/language-reference/operators/conditional-operator.md
+++ b/docs/csharp/language-reference/operators/conditional-operator.md
@@ -9,27 +9,43 @@ helpviewer_keywords:
 - '?: operator [C#]'
 - conditional operator (?:) [C#]
 ms.assetid: e83a17f1-7500-48ba-8bee-2fbc4c847af4
-ms.openlocfilehash: 150149453a67d8e5319461266865cb25be180347
-ms.sourcegitcommit: 2eceb05f1a5bb261291a1f6a91c5153727ac1c19
+ms.openlocfilehash: 3e45ff6eaaefa5829c3ed9415abe1a12b7a1d069
+ms.sourcegitcommit: 4bca8f7e172fd019ef437a4803bf5895c6bc4781
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/04/2018
-ms.locfileid: "43506433"
+ms.lasthandoff: 11/03/2018
+ms.locfileid: "50980623"
 ---
 # <a name="-operator-c-reference"></a>?: 演算子 (C# リファレンス)
+
 一般に三項条件演算子として知られる、条件演算子 (`?:`) では、ブール式の値に応じて 2 つの値のいずれかが返されます。 条件演算子の構文は次のとおりです。  
-  
-```  
+
+```csharp
 condition ? first_expression : second_expression;  
-```  
-  
-## <a name="remarks"></a>コメント  
- `condition` は、`true` または `false` に評価される必要があります。 `condition` が `true` の場合、`first_expression` が評価され、これが結果となります。 `condition` が `false` の場合、`second_expression` が評価され、これが結果となります。 2 つの式のどちらか一方だけが評価されます。  
-  
- `first_expression` の型と `second_expression` の型とは、同じ型であるか、または一方の型から他方の型への暗黙の型変換が存在している必要があります。  
-  
- `if-else` の構築が必要となる場面で条件演算子を使用すると、計算をより簡潔に表現できます。 たとえば、次のコードは、まず `if` ステートメントを使用し、次に条件演算子を使用して、整数を正または負に分類します。  
-  
+```
+
+C# 7.2 より、`first_expression` と `second_expression` を [`ref` 式](https://github.com/dotnet/csharplang/blob/master/proposals/csharp-7.2/conditional-ref.md)にすることができます。
+
+```csharp
+ref condition ? ref first_expression : ref second_expression;  
+```
+
+結果は `ref` または `ref readonly` 変数に、または何の修飾子もない変数に割り当てることができます。
+
+## <a name="remarks"></a>コメント
+
+`condition` は、`true` または `false` に評価される必要があります。 `condition` が `true` の場合、`first_expression` が評価され、これが結果となります。 `condition` が `false` の場合、`second_expression` が評価され、これが結果となります。 2 つの式のどちらか一方だけが評価されます。 これは、結果が `ref` となる式では次が有効になるため、特に重要です。
+
+```csharp
+ref (storage != null) ? ref storage[3] : ref defaultValue;
+```
+
+`storage` が null である場合、`storage`の参照は評価されません。
+
+結果が値である場合、`first_expression` の型と `second_expression` の型とは、同じ型であるか、または一方の型から他方の型への暗黙の型変換が存在している必要があります。 結果が `ref` である場合は、`first_expression` と `second_expression` の型が同じである必要があります。
+
+`if-else` の構築が必要となる場面で条件演算子を使用すると、計算をより簡潔に表現できます。 たとえば、次のコードは、まず `if` ステートメントを使用し、次に条件演算子を使用して、整数を正または負に分類します。
+
 ```csharp
 int input = Convert.ToInt32(Console.ReadLine());  
 string classify;  
@@ -42,19 +58,26 @@ else
   
 // ?: conditional operator.  
 classify = (input > 0) ? "positive" : "negative";  
-```  
-  
- 条件演算子の結合規則は右から左になります。 `a ? b : c ? d : e` という式は、`a ? b : (c ? d : e)` ではなく、`(a ? b : c) ? d : e` と評価されます。  
-  
- 条件演算子は、オーバーロードできません。  
+```
+
+条件演算子の結合規則は右から左になります。 `a ? b : c ? d : e` という式は、`a ? b : (c ? d : e)` ではなく、`(a ? b : c) ? d : e` と評価されます。  
   
-## <a name="example"></a>例  
- [!code-csharp[csRefOperators#41](../../../csharp/language-reference/operators/codesnippet/CSharp/conditional-operator_1.cs)]  
+条件演算子は、オーバーロードできません。
   
+## <a name="example"></a>例
+
+次の例は、結果が値になる、条件演算子を示します。
+
+[!code-csharp[csRefOperators?:](~/samples/snippets/csharp/language-reference/operators/ConditionalExamples.cs#ConditionalValue)]
+
+もう 1 つの例は、結果が ref になる条件演算子を示します。
+
+[!code-csharp[csRefOperatorsRef?:](~/samples/snippets/csharp/language-reference/operators/ConditionalExamples.cs#ConditionalRef)]
+
 ## <a name="see-also"></a>参照
 
 - [C# リファレンス](../../../csharp/language-reference/index.md)  
-- [C# プログラミング ガイド](../../../csharp/programming-guide/index.md)  
+- [C# プログラミングガイド](../../../csharp/programming-guide/index.md)  
 - [C# 演算子](../../../csharp/language-reference/operators/index.md)  
 - [if-else](../../../csharp/language-reference/keywords/if-else.md)  
 - [?. 演算子と ?[] 演算子](../../../csharp/language-reference/operators/null-conditional-operators.md)  
diff --git a/docs/csharp/language-reference/operators/conditional-or-operator.md b/docs/csharp/language-reference/operators/conditional-or-operator.md
index 67a27b3504f..3c72b9be8a1 100644
--- a/docs/csharp/language-reference/operators/conditional-or-operator.md
+++ b/docs/csharp/language-reference/operators/conditional-or-operator.md
@@ -1,6 +1,6 @@
 ---
 title: '|| 演算子 (C# リファレンス)'
-ms.date: 07/20/2015
+ms.date: 11/06/2018
 f1_keywords:
 - '||_CSharpKeyword'
 helpviewer_keywords:
@@ -8,40 +8,34 @@ helpviewer_keywords:
 - conditional-OR operator (||) [C#]
 - '|| operator [C#]'
 ms.assetid: 7d442d8e-400d-421f-b4d2-034bf82bcbdc
-ms.openlocfilehash: 58e5fd72a3748e7af0894093fc461c4efb543608
-ms.sourcegitcommit: 412bbc2e43c3b6ca25b358cdf394be97336f0c24
+ms.openlocfilehash: a391078372e4ec0a3882bed4515733adedffb547
+ms.sourcegitcommit: b5cd9d5d3b75a5537fc9ad8a3f085f0bb1845ee0
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 08/25/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "42925541"
 ---
 # <a name="-operator-c-reference"></a>|| 演算子 (C# リファレンス)
-条件付き OR 演算子 (`||`) では、`bool` オペランドの論理 OR が実行されます。 最初のオペランドが `true` と評価されると、2 番目のオペランドは評価されません。 最初のオペランドが `false` と評価されると、2 番目の演算子は、OR 式を、全体として、`true` または `false` に評価するかどうかを判断します。  
-  
-## <a name="remarks"></a>コメント  
- 次の演算は、  
-  
-```csharp  
-x || y  
-```  
-  
- 次の演算に対応しています。  
-  
-```csharp  
-x | y  
-```  
-  
- ただし `x` が `true` の場合、OR 演算は `y` の値に関係なく `true` となるため、`y` は評価されません。 この概念は、"ショートサーキット" 評価と呼ばれます。  
-  
- 条件付き OR 演算子はオーバーロードできませんが、通常の論理演算子、[true](../../../csharp/language-reference/keywords/true.md) 演算子、[false](../../../csharp/language-reference/keywords/false.md) 演算子のオーバーロードは、一定の制約内で、条件付き論理演算子のオーバーロードとも見なされます。  
-  
-## <a name="example"></a>例  
- 次の例では、`||` が使用されている式は、最初のオペランドだけを評価します。 `|` が使用されている式は、両方のオペランドを評価します。 2 番目の例では、両方のオペランドが評価されると、実行時例外が発生します。  
-  
- [!code-csharp[csRefOperators#52](../../../csharp/language-reference/operators/codesnippet/CSharp/conditional-or-operator_1.cs)]  
-  
-## <a name="see-also"></a>参照
-
-- [C# リファレンス](../../../csharp/language-reference/index.md)  
-- [C# プログラミング ガイド](../../../csharp/programming-guide/index.md)  
-- [C# 演算子](../../../csharp/language-reference/operators/index.md)
+
+条件論理 OR 演算子 `||` は、"短絡" 論理 OR 演算子とも呼ばれ、その [bool](../keywords/bool.md) オペランドの論理 OR を計算します。 `x` または `y` のどちらかが `true` と評価された場合、`x || y` の結果は `true` になります。 それ以外の場合、結果は `false` です。 最初のオペランドが `true` と評価されると、2 番目のオペランドは評価されず、演算の結果は `true` になります。 次の例は、その動作を示します。
+
+[!code-csharp-interactive[conditional logical OR](~/samples/snippets/csharp/language-reference/operators/ConditionalLogicalOperatorsExamples.cs#Or)]
+
+[論理 OR 演算子](or-operator.md) `|` もその `bool` オペランドの論理 OR を計算しますが、常に両方のオペランドを評価します。
+
+## <a name="operator-overloadability"></a>演算子のオーバーロード可/不可
+
+ユーザー定義型は条件論理 OR 演算子をオーバーロードできません。 ただし、ユーザー定義型が[論理 OR](or-operator.md)、[true](../keywords/true-operator.md)、および [false](../keywords/false-operator.md) 演算子を特定の方法でオーバーロードする場合、`||` 演算はその型のオペランドに対して評価を行うことができます。 詳細については、「[C# 言語仕様](../language-specification/index.md)」の[ユーザー定義型条件論理演算子](~/_csharplang/spec/expressions.md#user-defined-conditional-logical-operators)に関するセクションを参照してください。
+
+## <a name="c-language-specification"></a>C# 言語仕様
+
+詳細については、「[C# 言語仕様](../language-specification/index.md)」の[条件論理演算子](~/_csharplang/spec/expressions.md#conditional-logical-operators)に関するセクションを参照してください。
+
+## <a name="see-also"></a>関連項目
+
+- [C# リファレンス](../index.md)
+- [C# プログラミングガイド](../../programming-guide/index.md)
+- [C# 演算子](index.md)
+- [&& 演算子](conditional-and-operator.md)
+- [! 演算子](logical-negation-operator.md)
+- [| 演算子](or-operator.md)
diff --git a/docs/csharp/language-reference/operators/null-coalescing-operator.md b/docs/csharp/language-reference/operators/null-coalescing-operator.md
index 05b0eb59dd0..7a8b5366191 100644
--- a/docs/csharp/language-reference/operators/null-coalescing-operator.md
+++ b/docs/csharp/language-reference/operators/null-coalescing-operator.md
@@ -8,12 +8,12 @@ helpviewer_keywords:
 - ?? operator [C#]
 - conditional-AND operator (&&) [C#]
 ms.assetid: 088b1f0d-c1af-4fe1-b4b8-196fd5ea9132
-ms.openlocfilehash: 03d81d4216dabce2ea75b9fdcf6ef0971cc32490
-ms.sourcegitcommit: 2eceb05f1a5bb261291a1f6a91c5153727ac1c19
+ms.openlocfilehash: fbcfda07cc55628aeed82eb7561516f7012bc4fe
+ms.sourcegitcommit: b5cd9d5d3b75a5537fc9ad8a3f085f0bb1845ee0
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/04/2018
-ms.locfileid: "43530107"
+ms.lasthandoff: 11/07/2018
+ms.locfileid: "50980675"
 ---
 # <a name="-operator-c-reference"></a>?? 演算子 (C# リファレンス)
 `??` 演算子は、null 合体演算子と呼ばれます。  左側のオペランドが null 値でない場合には左側のオペランドを返し、null 値である場合には右側のオペランドを返します。  
@@ -28,10 +28,14 @@ ms.locfileid: "43530107"
 ## <a name="example"></a>例  
  [!code-csharp[csRefOperators#53](../../../csharp/language-reference/operators/codesnippet/CSharp/null-conditional-operator_1.cs)]  
   
+## <a name="c-language-specification"></a>C# 言語仕様  
+
+詳細については、「[C# 言語仕様](../language-specification/index.md)」の [null 合体演算子](~/_csharplang/spec/expressions.md#the-null-coalescing-operator)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
+  
 ## <a name="see-also"></a>参照
 
 - [C# リファレンス](../../../csharp/language-reference/index.md)  
-- [C# プログラミング ガイド](../../../csharp/programming-guide/index.md)  
+- [C# プログラミングガイド](../../../csharp/programming-guide/index.md)  
 - [C# 演算子](../../../csharp/language-reference/operators/index.md)  
 - [Null 許容型](../../../csharp/programming-guide/nullable-types/index.md)  
 - ['Lifted' の正確な意味](https://blogs.msdn.microsoft.com/ericlippert/2007/06/27/what-exactly-does-lifted-mean/)
diff --git a/docs/csharp/programming-guide/classes-and-structs/partial-classes-and-methods.md b/docs/csharp/programming-guide/classes-and-structs/partial-classes-and-methods.md
index 024ab91a3f8..206584b802a 100644
--- a/docs/csharp/programming-guide/classes-and-structs/partial-classes-and-methods.md
+++ b/docs/csharp/programming-guide/classes-and-structs/partial-classes-and-methods.md
@@ -6,11 +6,11 @@ helpviewer_keywords:
 - partial classes [C#]
 - C# language, partial classes and methods
 ms.assetid: 804cecb7-62db-4f97-a99f-60975bd59fa1
-ms.openlocfilehash: 21350c28f5fcce812f47742bebe07f5bcdf842f1
-ms.sourcegitcommit: 2eceb05f1a5bb261291a1f6a91c5153727ac1c19
+ms.openlocfilehash: 2975b9e79824560c711e96382a9ccc03bdc72810
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/04/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "43521170"
 ---
 # <a name="partial-classes-and-methods-c-programming-guide"></a>部分クラスと部分メソッド (C# プログラミング ガイド)
@@ -158,11 +158,12 @@ partial void onNameChanged()
 -   [delegate](../../../csharp/language-reference/keywords/delegate.md) は、定義および実装されている部分メソッドには使用できますが、定義されているのみの部分メソッドには使用できません。  
   
 ## <a name="c-language-specification"></a>C# 言語仕様  
- [!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]  
+
+詳細については、「[C# 言語仕様](../../language-reference/language-specification/index.md)」の[部分型](~/_csharplang/spec/classes.md#partial-types)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
   
 ## <a name="see-also"></a>参照
 
-- [C# プログラミング ガイド](../../../csharp/programming-guide/index.md)  
+- [C# プログラミングガイド](../../../csharp/programming-guide/index.md)  
 - [クラス](../../../csharp/programming-guide/classes-and-structs/classes.md)  
 - [構造体](../../../csharp/programming-guide/classes-and-structs/structs.md)  
 - [インターフェイス](../../../csharp/programming-guide/interfaces/index.md)  
diff --git a/docs/csharp/programming-guide/classes-and-structs/private-constructors.md b/docs/csharp/programming-guide/classes-and-structs/private-constructors.md
index 3ef2cf2e669..d3a19266b2d 100644
--- a/docs/csharp/programming-guide/classes-and-structs/private-constructors.md
+++ b/docs/csharp/programming-guide/classes-and-structs/private-constructors.md
@@ -5,12 +5,12 @@ helpviewer_keywords:
 - C# language, private constructors
 - private constructors [C#]
 ms.assetid: 29eeaa7d-8d81-453c-94b9-0e2800172621
-ms.openlocfilehash: 1338a6efbe03522093899009178b6f31e558d8dd
-ms.sourcegitcommit: 6eac9a01ff5d70c6d18460324c016a3612c5e268
+ms.openlocfilehash: 5b387447046e4755287fc9f6a8813a19752799c2
+ms.sourcegitcommit: b5cd9d5d3b75a5537fc9ad8a3f085f0bb1845ee0
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/16/2018
-ms.locfileid: "45646997"
+ms.lasthandoff: 11/07/2018
+ms.locfileid: "50980717"
 ---
 # <a name="private-constructors-c-programming-guide"></a>プライベート コンストラクター (C# プログラミング ガイド)
 プライベート コンストラクターは、特別なインスタンス コンストラクターです。 通常は、静的メンバーだけを含むクラスで使用されます。 クラスに 1 つ以上のプライベート コンストラクターがあり、パブリック コンストラクターがない場合、他のクラス (入れ子になったクラスを除く) は、このクラスのインスタンスを作成できません。 例:  
@@ -31,11 +31,12 @@ ms.locfileid: "45646997"
  [!code-csharp[csProgGuideObjects#13](../../../csharp/programming-guide/classes-and-structs/codesnippet/CSharp/private-constructors_3.cs)]  
   
 ## <a name="c-language-specification"></a>C# 言語仕様  
- [!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]  
+
+詳細については、「[C# 言語仕様](../../language-reference/language-specification/index.md)」の[プライベート コンストラクター](~/_csharplang/spec/classes.md#private-constructors)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
   
 ## <a name="see-also"></a>参照
 
-- [C# プログラミング ガイド](../../../csharp/programming-guide/index.md)  
+- [C# プログラミングガイド](../../../csharp/programming-guide/index.md)  
 - [クラスと構造体](../../../csharp/programming-guide/classes-and-structs/index.md)  
 - [コンストラクター](../../../csharp/programming-guide/classes-and-structs/constructors.md)  
 - [ファイナライザー](../../../csharp/programming-guide/classes-and-structs/destructors.md)  
diff --git a/docs/csharp/programming-guide/classes-and-structs/properties.md b/docs/csharp/programming-guide/classes-and-structs/properties.md
index 1cdebfdc753..eff34ff5ecb 100644
--- a/docs/csharp/programming-guide/classes-and-structs/properties.md
+++ b/docs/csharp/programming-guide/classes-and-structs/properties.md
@@ -7,11 +7,11 @@ helpviewer_keywords:
 - properties [C#]
 - C# language, properties
 ms.assetid: e295a8a2-b357-4ee7-a12e-385a44146fa8
-ms.openlocfilehash: 74020696a9d2370de2976671a9f1ed944aba8fb9
-ms.sourcegitcommit: 3c1c3ba79895335ff3737934e39372555ca7d6d0
+ms.openlocfilehash: b2ce46d4493731719ba42fb0f1175c6210d61e07
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/06/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "43857681"
 ---
 # <a name="properties-c-programming-guide"></a>プロパティ (C# プログラミング ガイド)
@@ -70,11 +70,12 @@ ms.locfileid: "43857681"
 -   [自動実装プロパティ](../../../csharp/programming-guide/classes-and-structs/auto-implemented-properties.md)  
   
 ## <a name="c-language-specification"></a>C# 言語仕様  
- [!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]  
+
+詳細については、「[C# 言語の仕様](../../language-reference/language-specification/index.md)」の[プロパティ](~/_csharplang/spec/classes.md#properties)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
   
 ## <a name="see-also"></a>参照
 
-- [C# プログラミング ガイド](../../../csharp/programming-guide/index.md)  
+- [C# プログラミングガイド](../../../csharp/programming-guide/index.md)  
 - [プロパティの使用](../../../csharp/programming-guide/classes-and-structs/using-properties.md)  
 - [インデクサー](../../../csharp/programming-guide/indexers/index.md)  
 - [get キーワード](../../../csharp/language-reference/keywords/get.md)    
diff --git a/docs/csharp/programming-guide/classes-and-structs/using-constructors.md b/docs/csharp/programming-guide/classes-and-structs/using-constructors.md
index 45d19e435aa..e9ba64f68b2 100644
--- a/docs/csharp/programming-guide/classes-and-structs/using-constructors.md
+++ b/docs/csharp/programming-guide/classes-and-structs/using-constructors.md
@@ -4,11 +4,11 @@ ms.date: 07/20/2015
 helpviewer_keywords:
 - constructors [C#], about constructors
 ms.assetid: 464253b2-fd5d-469a-836d-df0fdf2a43f7
-ms.openlocfilehash: b19676b2549bbb54af7fb1d72ff0e98352c61383
-ms.sourcegitcommit: 2eceb05f1a5bb261291a1f6a91c5153727ac1c19
+ms.openlocfilehash: d10b0de0a3811e615297b31d2d9c8934c9338078
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/04/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "43529021"
 ---
 # <a name="using-constructors-c-programming-guide"></a>コンストラクターの使用 (C# プログラミング ガイド)
@@ -88,11 +88,12 @@ Console.WriteLine("{0}, {1}", a, b);
  コンストラクターは、[static](../../../csharp/language-reference/keywords/static.md) キーワードを使用して静的として宣言できます。 静的コンストラクターは、静的フィールドがアクセスされる直前に自動的に呼び出され、通常は静的なクラス メンバーを初期化するために使用されます。 詳細については、「[静的コンストラクター](../../../csharp/programming-guide/classes-and-structs/static-constructors.md)」を参照してください。  
   
 ## <a name="c-language-specification"></a>C# 言語仕様  
- [!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]  
+
+詳細については、「[C# 言語仕様](../../language-reference/language-specification/index.md)」の[インスタンス コンストラクター](~/_csharplang/spec/classes.md#instance-constructors)と[静的コンストラクター](~/_csharplang/spec/classes.md#static-constructors)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
   
 ## <a name="see-also"></a>参照
 
-- [C# プログラミング ガイド](../../../csharp/programming-guide/index.md)  
+- [C# プログラミングガイド](../../../csharp/programming-guide/index.md)  
 - [クラスと構造体](../../../csharp/programming-guide/classes-and-structs/index.md)  
 - [コンストラクター](../../../csharp/programming-guide/classes-and-structs/constructors.md)  
 - [ファイナライザー](../../../csharp/programming-guide/classes-and-structs/destructors.md)
diff --git a/docs/csharp/programming-guide/concepts/linq/linq-to-xml-overview.md b/docs/csharp/programming-guide/concepts/linq/linq-to-xml-overview.md
index 5474c4bc560..3ec8e183807 100644
--- a/docs/csharp/programming-guide/concepts/linq/linq-to-xml-overview.md
+++ b/docs/csharp/programming-guide/concepts/linq/linq-to-xml-overview.md
@@ -1,12 +1,12 @@
 ---
 title: LINQ to XML の概要 (C#)
-ms.date: 07/20/2015
+ms.date: 10/30/2018
 ms.assetid: 716b94d3-0091-4de1-8e05-41bc069fa9dd
-ms.openlocfilehash: 5b557c95993d7f1e907a8eb6ef1e5ec23a2988ab
-ms.sourcegitcommit: 3c1c3ba79895335ff3737934e39372555ca7d6d0
+ms.openlocfilehash: 5e005343226b47fb843b817747ca03c49c28dbfc
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/06/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "43856622"
 ---
 # <a name="linq-to-xml-overview-c"></a>LINQ to XML の概要 (C#)
@@ -30,26 +30,50 @@ XML は、多くのコンテキストでデータを書式設定する方法と
   
  たとえば、「[サンプル XML ファイル: 一般的な購買発注書 (LINQ to XML)](sample-xml-file-typical-purchase-order-linq-to-xml-1.md)」で説明されているように、典型的な XML の購買発注書を使用することもできます。 [!INCLUDE[sqltecxlinq](~/includes/sqltecxlinq-md.md)] を使用することで、次のクエリを実行して購買発注書のすべての品目要素の部品番号属性を取得できます。  
   
-```csharp  
-IEnumerable<string> partNos =  
-from item in purchaseOrder.Descendants("Item")  
-select (string) item.Attribute("PartNumber");  
-```  
-  
- もう 1 つの例として、金額が $100 を超える品目を部品番号順に並べた一覧が必要であるとします。 この情報を取得するには、次のクエリを実行します。  
+```csharp
+// Load the XML file from our project directory containing the purchase orders
+var filename = "PurchaseOrder.xml";
+var currentDirectory = Directory.GetCurrentDirectory();
+var purchaseOrderFilepath = Path.Combine(currentDirectory, filename);
+
+XElement purchaseOrder = XElement.Load($"{purchaseOrderFilepath}");
+
+IEnumerable<string> partNos =  from item in purchaseOrder.Descendants("Item")  
+                               select (string) item.Attribute("PartNumber");  
+``` 
+これは、メソッドの構文の形式で書き直すことができます。
+
+```csharp
+IEnumerable<string> partNos = purchaseOrder.Descendants("Item").Select(x => (string) x.Attribute("PartNumber"));
+```
+
+もう 1 つの例として、金額が $100 を超える品目を部品番号順に並べた一覧が必要であるとします。 この情報を取得するには、次のクエリを実行します。  
   
-```csharp  
-IEnumerable<XElement> partNos =  
-from item in purchaseOrder.Descendants("Item")  
-where (int) item.Element("Quantity") *  
-    (decimal) item.Element("USPrice") > 100  
-orderby (string)item.Element("PartNumber")  
-select item;  
+```csharp 
+// Load the XML file from our project directory containing the purchase orders
+var filename = "PurchaseOrder.xml";
+var currentDirectory = Directory.GetCurrentDirectory();
+var purchaseOrderFilepath = Path.Combine(currentDirectory, filename);
+
+XElement purchaseOrder = XElement.Load($"{purchaseOrderFilepath}");
+
+IEnumerable<XElement> pricesByPartNos =  from item in purchaseOrder.Descendants("Item")  
+                                 where (int) item.Element("Quantity") * (decimal) item.Element("USPrice") > 100  
+                                 orderby (string)item.Element("PartNumber")  
+                                 select item;  
 ```  
-  
+
+これも、メソッドの構文の形式で書き直すことができます。
+
+```csharp
+IEnumerable<XElement> pricesByPartNos = purchaseOrder.Descendants("Item")
+                                        .Where(item => (int)item.Element("Quantity") * (decimal)item.Element("USPrice") > 100)
+                                        .OrderBy(order => order.Element("PartNumber"));
+```
+
  これらの [!INCLUDE[vbteclinq](~/includes/vbteclinq-md.md)] 機能に加え、[!INCLUDE[sqltecxlinq](~/includes/sqltecxlinq-md.md)] では XML プログラミング インターフェイスが機能強化されています。 [!INCLUDE[sqltecxlinq](~/includes/sqltecxlinq-md.md)] を使用すると、次のことを実行できます。  
   
--   ファイルまたはストリームからの XML の読み込み  
+-   [ファイル](how-to-load-xml-from-a-file.md)または[ストリーム](how-to-stream-xml-fragments-from-an-xmlreader.md)からの XML の読み込み  
   
 -   ファイルまたはストリームへの XML のシリアル化  
   
diff --git a/docs/csharp/programming-guide/exceptions/creating-and-throwing-exceptions.md b/docs/csharp/programming-guide/exceptions/creating-and-throwing-exceptions.md
index 0539a5532b6..43c6b2fe846 100644
--- a/docs/csharp/programming-guide/exceptions/creating-and-throwing-exceptions.md
+++ b/docs/csharp/programming-guide/exceptions/creating-and-throwing-exceptions.md
@@ -7,11 +7,11 @@ helpviewer_keywords:
 - exceptions [C#], creating
 - exceptions [C#], throwing
 ms.assetid: 6bbba495-a115-4c6d-90cc-1f4d7b5f39e2
-ms.openlocfilehash: 2e792a230ccead5d9a73f9b78a83d57738c31085
-ms.sourcegitcommit: 4b6490b2529707627ad77c3a43fbe64120397175
+ms.openlocfilehash: 43d566fed4e2963489da0b7a11c78a54740b7ab1
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/10/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "44260072"
 ---
 # <a name="creating-and-throwing-exceptions-c-programming-guide"></a>例外の作成とスロー (C# プログラミング ガイド)
@@ -62,11 +62,12 @@ ms.locfileid: "44260072"
  例外クラスへの新しいプロパティの追加は、プロパティによって提供されるデータが例外の解決に役立つ場合にのみ行う必要があります。 派生例外クラスに新しいプロパティを追加する場合は、`ToString()` をオーバーライドして追加情報を返す必要があります。  
   
 ## <a name="c-language-specification"></a>C# 言語仕様  
- [!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]  
+
+詳細については、「[C# 言語仕様](../../language-reference/language-specification/index.md)」の[例外](~/_csharplang/spec/exceptions.md)と [throw ステートメント](~/_csharplang/spec/statements.md#the-throw-statement)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
   
 ## <a name="see-also"></a>参照
 
-- [C# プログラミング ガイド](../../../csharp/programming-guide/index.md)  
+- [C# プログラミングガイド](../../../csharp/programming-guide/index.md)  
 - [例外と例外処理](../../../csharp/programming-guide/exceptions/index.md)  
-- [例外階層](https://msdn.microsoft.com/library/f7d68675-be06-40fb-a555-05f0c5a6f66b)  
+- [例外階層](../../../standard/exceptions/index.md)  
 - [例外処理](../../../csharp/programming-guide/exceptions/exception-handling.md)
diff --git a/docs/csharp/programming-guide/exceptions/exception-handling.md b/docs/csharp/programming-guide/exceptions/exception-handling.md
index b20a2921d05..724a0cc6fb1 100644
--- a/docs/csharp/programming-guide/exceptions/exception-handling.md
+++ b/docs/csharp/programming-guide/exceptions/exception-handling.md
@@ -5,11 +5,11 @@ helpviewer_keywords:
 - exception handling [C#], about exception handling
 - exceptions [C#], handling
 ms.assetid: b4e4ecf2-b907-4e58-891f-2563762258e9
-ms.openlocfilehash: f6cc48843518a5d8791b6eda3e82a9f140039ceb
-ms.sourcegitcommit: 2eceb05f1a5bb261291a1f6a91c5153727ac1c19
+ms.openlocfilehash: 99a61dc4125d2fe86d70d5051741a1f1f33e58d4
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/04/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "43514043"
 ---
 # <a name="exception-handling-c-programming-guide"></a>例外処理 (C# プログラミング ガイド)
@@ -52,12 +52,13 @@ ms.locfileid: "43514043"
  [!code-csharp[csProgGuideExceptions#11](../../../csharp/programming-guide/exceptions/codesnippet/CSharp/exception-handling_6.cs)]  
   
 ## <a name="c-language-specification"></a>C# 言語仕様  
- [!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]  
+
+詳細については、「[C# 言語仕様](../../language-reference/language-specification/index.md)」の[例外](~/_csharplang/spec/exceptions.md)と [try ステートメント](~/_csharplang/spec/statements.md#the-try-statement)に関するセクションを参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
   
 ## <a name="see-also"></a>参照
 
 - [C# リファレンス](../../../csharp/language-reference/index.md)  
-- [C# プログラミング ガイド](../../../csharp/programming-guide/index.md)  
+- [C# プログラミングガイド](../../../csharp/programming-guide/index.md)  
 - [例外と例外処理](../../../csharp/programming-guide/exceptions/index.md)  
 - [try-catch](../../../csharp/language-reference/keywords/try-catch.md)  
 - [try-finally](../../../csharp/language-reference/keywords/try-finally.md)  
diff --git a/docs/csharp/programming-guide/generics/generic-interfaces.md b/docs/csharp/programming-guide/generics/generic-interfaces.md
index 176a97f55d6..b8745a9baf9 100644
--- a/docs/csharp/programming-guide/generics/generic-interfaces.md
+++ b/docs/csharp/programming-guide/generics/generic-interfaces.md
@@ -5,12 +5,12 @@ helpviewer_keywords:
 - C# language, generic interfaces
 - generics [C#], interfaces
 ms.assetid: a8fa49a1-6e78-4a09-87e5-84a0b9f5ffbe
-ms.openlocfilehash: a5763413662d32d66e955fb0edfc6b438968720b
-ms.sourcegitcommit: 3c1c3ba79895335ff3737934e39372555ca7d6d0
+ms.openlocfilehash: 4c7449568ff250c8de521e7afb71178536f52657
+ms.sourcegitcommit: 4bca8f7e172fd019ef437a4803bf5895c6bc4781
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/06/2018
-ms.locfileid: "43857746"
+ms.lasthandoff: 11/03/2018
+ms.locfileid: "50980776"
 ---
 # <a name="generic-interfaces-c-programming-guide"></a>ジェネリック インターフェイス (C# プログラミング ガイド)
 ジェネリック コレクション クラスのインターフェイスか、コレクション内の項目を表すジェネリック クラスのインターフェイスを定義すると、多くの場合、便利です。 ジェネリック クラスの優先設定の意図は、値型に対するボックス化とボックス化解除を回避する目的で、<xref:System.IComparable> ではなく <xref:System.IComparable%601> など、ジェネリック インターフェイスを利用することにあります。 .NET Framework クラス ライブラリにより、<xref:System.Collections.Generic> 名前空間のコレクション クラスと共に利用するためのジェネリック インターフェイスがいくつか定義されます。  
@@ -45,7 +45,7 @@ ms.locfileid: "43857746"
   
 ## <a name="see-also"></a>参照
 
-- [C# プログラミング ガイド](../../../csharp/programming-guide/index.md)  
+- [C# プログラミングガイド](../../../csharp/programming-guide/index.md)  
 - [ジェネリックの概要](../../../csharp/programming-guide/generics/introduction-to-generics.md)  
 - [interface](../../../csharp/language-reference/keywords/interface.md)  
 - [ジェネリック](~/docs/standard/generics/index.md)
diff --git a/docs/csharp/programming-guide/inside-a-program/general-structure-of-a-csharp-program.md b/docs/csharp/programming-guide/inside-a-program/general-structure-of-a-csharp-program.md
index 03295cd5700..27162e6727f 100644
--- a/docs/csharp/programming-guide/inside-a-program/general-structure-of-a-csharp-program.md
+++ b/docs/csharp/programming-guide/inside-a-program/general-structure-of-a-csharp-program.md
@@ -4,11 +4,11 @@ ms.date: 07/20/2015
 helpviewer_keywords:
 - C# language, program structure
 ms.assetid: 5ae964a5-0ef0-40fe-88fb-6d1793371d0d
-ms.openlocfilehash: d3920fff26eccdd509c72143ff8553fb0c501bbc
-ms.sourcegitcommit: 5bbfe34a9a14e4ccb22367e57b57585c208cf757
+ms.openlocfilehash: 3e2718d932506f261ea32e7289a3191bca7c22e8
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/17/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "45698157"
 ---
 # <a name="general-structure-of-a-c-program-c-programming-guide"></a>C# プログラムの一般構造 (C# プログラミング ガイド)
@@ -30,11 +30,12 @@ C# プログラムは、1 つ以上のファイルで構成できます。 各
 -   [デリゲート](../../../csharp/programming-guide/delegates/index.md)  
   
 ## <a name="c-language-specification"></a>C# 言語仕様  
- [!INCLUDE[CSharplangspec](~/includes/csharplangspec-md.md)]  
+
+詳細については、「[C# 言語の仕様](../../language-reference/language-specification/index.md)」の「[基本概念](~/_csharplang/spec/basic-concepts.md)」を参照してください。 言語仕様は、C# の構文と使用法に関する信頼性のある情報源です。
   
 ## <a name="see-also"></a>参照
 
-- [C# プログラミング ガイド](../../../csharp/programming-guide/index.md)  
+- [C# プログラミングガイド](../../../csharp/programming-guide/index.md)  
 - [インサイド C# プログラム](../../../csharp/programming-guide/inside-a-program/index.md)  
 - [C# リファレンス](../../../csharp/language-reference/index.md)  
-- [\<paveover>C# サンプル アプリケーション](https://msdn.microsoft.com/library/9a9d7aaa-51d3-4224-b564-95409b0f3e15)
+- [C# サンプル アプリケーション](https://msdn.microsoft.com/library/9a9d7aaa-51d3-4224-b564-95409b0f3e15)
diff --git a/docs/csharp/programming-guide/unsafe-code-pointers/fixed-size-buffers.md b/docs/csharp/programming-guide/unsafe-code-pointers/fixed-size-buffers.md
index 95e59091c17..49c72a92379 100644
--- a/docs/csharp/programming-guide/unsafe-code-pointers/fixed-size-buffers.md
+++ b/docs/csharp/programming-guide/unsafe-code-pointers/fixed-size-buffers.md
@@ -6,11 +6,11 @@ helpviewer_keywords:
 - unsafe buffers [C#]
 - unsafe code [C#], fixed size buffers
 ms.openlocfilehash: 134a219acd02caa2b16c5a6e8716c3245579ecca
-ms.sourcegitcommit: c93fd5139f9efcf6db514e3474301738a6d1d649
+ms.sourcegitcommit: 5fd80619c760fa8c25d33a6f5661247cb65da465
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/28/2018
-ms.locfileid: "50049556"
+ms.lasthandoff: 11/01/2018
+ms.locfileid: "50744003"
 ---
 # <a name="fixed-size-buffers-c-programming-guide"></a>固定サイズ バッファー (C# プログラミング ガイド)
 
diff --git a/docs/framework/app-domains/type-forwarding-in-the-common-language-runtime.md b/docs/framework/app-domains/type-forwarding-in-the-common-language-runtime.md
index 6e0b939890e..a13f15e7c56 100644
--- a/docs/framework/app-domains/type-forwarding-in-the-common-language-runtime.md
+++ b/docs/framework/app-domains/type-forwarding-in-the-common-language-runtime.md
@@ -11,11 +11,11 @@ ms.assetid: 51f8ffa3-c253-4201-a3d3-c4fad85ae097
 author: rpetrusha
 ms.author: ronpet
 ms.openlocfilehash: 7ad6c87dcec55a332bced00370fe6ea888508793
-ms.sourcegitcommit: 9bd8f213b50f0e1a73e03bd1e840c917fbd6d20a
+ms.sourcegitcommit: 5fd80619c760fa8c25d33a6f5661247cb65da465
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/26/2018
-ms.locfileid: "50134921"
+ms.lasthandoff: 11/01/2018
+ms.locfileid: "50744366"
 ---
 # <a name="type-forwarding-in-the-common-language-runtime"></a>共通言語ランタイムでの型の転送
 型の転送を使用すると、別のアセンブリに型を移動する際に、元のアセンブリを使用するアプリケーションを再コンパイルする必要がありません。  
diff --git a/docs/framework/deployment/how-to-debug-clr-activation-issues.md b/docs/framework/deployment/how-to-debug-clr-activation-issues.md
index 2ff46f89c70..882c47989b8 100644
--- a/docs/framework/deployment/how-to-debug-clr-activation-issues.md
+++ b/docs/framework/deployment/how-to-debug-clr-activation-issues.md
@@ -7,11 +7,11 @@ ms.assetid: 4fe17546-d56e-4344-a930-6d8e4a545914
 author: mairaw
 ms.author: mairaw
 ms.openlocfilehash: 89724e9a322f2f28dbe5d18ae697acbdd0a32d8e
-ms.sourcegitcommit: 9bd8f213b50f0e1a73e03bd1e840c917fbd6d20a
+ms.sourcegitcommit: 5fd80619c760fa8c25d33a6f5661247cb65da465
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/25/2018
-ms.locfileid: "50041623"
+ms.lasthandoff: 11/01/2018
+ms.locfileid: "50744471"
 ---
 # <a name="how-to-debug-clr-activation-issues"></a>方法: CLR のアクティブ化に関する問題をデバッグする
 正しいバージョンの共通言語ランタイム (CLR) でアプリケーションを実行して問題が発生した場合、CLR アクティベーション ログを表示し、デバッグできます。 アプリケーションで予想とは異なる CLR バージョンが読み込まれるときでも、CLR がまったく読み込まれないときでも、アクティベーション問題の根本原因を突き止めるときにこのログが大変役立ちます。 [.NET Framework 初期化エラー: ユーザー エクスペリエンスの管理](../../../docs/framework/deployment/initialization-errors-managing-the-user-experience.md)では、アプリケーションに対して CLR が見つからない場合について説明されています。  
diff --git a/docs/framework/deployment/net-framework-applications.md b/docs/framework/deployment/net-framework-applications.md
index 4d0c0437792..f8bf5a4b9ea 100644
--- a/docs/framework/deployment/net-framework-applications.md
+++ b/docs/framework/deployment/net-framework-applications.md
@@ -8,11 +8,11 @@ ms.assetid: 139d4cb1-5972-40f4-bdd8-1ce68e4dfb80
 author: mairaw
 ms.author: mairaw
 ms.openlocfilehash: 9536b53531d3ee7575a51b8702b34b57338b4f8b
-ms.sourcegitcommit: 9bd8f213b50f0e1a73e03bd1e840c917fbd6d20a
+ms.sourcegitcommit: 0fbd677fcdc5bf46c4d827f492eaaa970edc07b6
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/25/2018
-ms.locfileid: "50040908"
+ms.lasthandoff: 10/30/2018
+ms.locfileid: "50235753"
 ---
 # <a name="deploying-net-framework-applications"></a>.NET Framework アプリケーションの配置
 .NET Framework ドキュメントの本セクションでは、アセンブリの読み込み、アセンブリ参照の解決、およびネイティブ イメージの生成を使用したアプリケーションのパフォーマンス向上のためのガイドラインなど、.NET Framework アプリケーションを配置するための重要な情報を提供します。  
diff --git a/docs/framework/migration-guide/retargeting/4.7-4.7.1.md b/docs/framework/migration-guide/retargeting/4.7-4.7.1.md
index 0b5553e38cd..0967f238860 100644
--- a/docs/framework/migration-guide/retargeting/4.7-4.7.1.md
+++ b/docs/framework/migration-guide/retargeting/4.7-4.7.1.md
@@ -5,11 +5,11 @@ ms.assetid: c04c68f4-9e47-48cc-9b45-b2d4798f3b1c
 author: chlowell
 ms.author: ronpet
 ms.openlocfilehash: bcea3c19e1b45c34758fc806daa9b44161725871
-ms.sourcegitcommit: c93fd5139f9efcf6db514e3474301738a6d1d649
+ms.sourcegitcommit: 5fd80619c760fa8c25d33a6f5661247cb65da465
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/27/2018
-ms.locfileid: "50180272"
+ms.lasthandoff: 11/01/2018
+ms.locfileid: "50744378"
 ---
 # <a name="retargeting-changes-for-migration-from-net-framework-47-to-471"></a>.NET Framework 4.7 から 4.7.1 への移行に関する変更の再ターゲット
 
diff --git a/docs/framework/network-programming/connection-grouping.md b/docs/framework/network-programming/connection-grouping.md
index a3d9947c462..c4add3476d6 100644
--- a/docs/framework/network-programming/connection-grouping.md
+++ b/docs/framework/network-programming/connection-grouping.md
@@ -9,11 +9,11 @@ helpviewer_keywords:
 - connection pooling
 ms.assetid: 2ec502e8-4ba0-4c22-9410-f28eaf4eee63
 ms.openlocfilehash: 9dc2e656bdaa49bf1a94904ed7806b740eed2252
-ms.sourcegitcommit: c93fd5139f9efcf6db514e3474301738a6d1d649
+ms.sourcegitcommit: 5fd80619c760fa8c25d33a6f5661247cb65da465
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/27/2018
-ms.locfileid: "50180735"
+ms.lasthandoff: 11/01/2018
+ms.locfileid: "50743977"
 ---
 # <a name="connection-grouping"></a>接続のグループ化
 接続のグループ化では、1 つのアプリケーション内の特定の要求を定義済みの接続プールに関連付けます。 これは、ユーザーの代わりにバック エンド サーバーに接続し、デリゲートをサポートする認証プロトコル (Kerberos など) を使用する中間層アプリケーションや、以下の例のように、独自の資格情報を指定する中間層アプリケーションで必要になる場合があります。 たとえば、Joe というユーザーが、自分の給与情報を表示する内部 Web サイトにアクセスするとします。 Joe の認証後、中間層アプリケーション サーバーは、Joe の資格情報を使用してバック エンド サーバーに接続し、Joe の給与情報を取得します。 次に、Susan がサイトにアクセスし、自分の給与情報を要求します。 中間層アプリケーションが Joe の資格情報を使用して既に接続しているため、バック エンド サーバーは Joe の情報で応答します。 ただし、アプリケーションがバック エンド サーバーに送信される各要求をユーザー名から形成される接続グループに割り当てると、各ユーザーは個別の接続プールに属すことになり、誤って他のユーザーと認証情報を共有することがなくなります。  
diff --git a/docs/framework/network-programming/creating-internet-requests.md b/docs/framework/network-programming/creating-internet-requests.md
index 7e66c5e5f28..ed97c09388a 100644
--- a/docs/framework/network-programming/creating-internet-requests.md
+++ b/docs/framework/network-programming/creating-internet-requests.md
@@ -11,11 +11,11 @@ helpviewer_keywords:
 - data requests, creating requests
 ms.assetid: faab683e-3f1e-4eee-b5e9-59f7245033d5
 ms.openlocfilehash: ff346c5b4241f7ac037088adbe068bab2232d12f
-ms.sourcegitcommit: c93fd5139f9efcf6db514e3474301738a6d1d649
+ms.sourcegitcommit: 5fd80619c760fa8c25d33a6f5661247cb65da465
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/27/2018
-ms.locfileid: "50190685"
+ms.lasthandoff: 11/01/2018
+ms.locfileid: "50744198"
 ---
 # <a name="creating-internet-requests"></a>インターネット要求の作成
 アプリケーションは、<xref:System.Net.WebRequest.Create%2A?displayProperty=nameWithType> メソッドを使用して <xref:System.Net.WebRequest> のインスタンスを作成します。 これは、渡された URI スキームに基づいて **WebRequest** から派生するクラスを作成する静的メソッドです。  
diff --git a/docs/framework/network-programming/deriving-from-webrequest.md b/docs/framework/network-programming/deriving-from-webrequest.md
index 94b827f54b6..eda028c160a 100644
--- a/docs/framework/network-programming/deriving-from-webrequest.md
+++ b/docs/framework/network-programming/deriving-from-webrequest.md
@@ -11,11 +11,11 @@ helpviewer_keywords:
 - protocols, pluggable
 ms.assetid: 9810c177-973e-43d7-823c-14960bd625ea
 ms.openlocfilehash: 859593c6c53d9f6dc89047efae1c682a6a9873a7
-ms.sourcegitcommit: c93fd5139f9efcf6db514e3474301738a6d1d649
+ms.sourcegitcommit: 5fd80619c760fa8c25d33a6f5661247cb65da465
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/27/2018
-ms.locfileid: "50181265"
+ms.lasthandoff: 11/01/2018
+ms.locfileid: "50744406"
 ---
 # <a name="deriving-from-webrequest"></a>WebRequest からの派生
 <xref:System.Net.WebRequest> クラスは、.NET Framework プラグ可能なプロトコル モデルに適合するプロトコル固有の要求ハンドラーを作成するための基本メソッドとプロパティを提供する抽象基底クラスです。 **WebRequest** クラスを使用するアプリケーションは、使用されるプロトコルを指定することなく、サポートされている任意のプロトコルを使用してデータを要求できます。  
diff --git a/docs/framework/network-programming/listening-with-sockets.md b/docs/framework/network-programming/listening-with-sockets.md
index 11adae14e76..d9d082f7672 100644
--- a/docs/framework/network-programming/listening-with-sockets.md
+++ b/docs/framework/network-programming/listening-with-sockets.md
@@ -16,11 +16,11 @@ helpviewer_keywords:
 - Internet, sockets
 ms.assetid: 40e426cc-13db-4371-95eb-f7388bd23ebf
 ms.openlocfilehash: 2b19b6d29d0117d4822f370dcc9abc840a18ad3d
-ms.sourcegitcommit: 9bd8f213b50f0e1a73e03bd1e840c917fbd6d20a
+ms.sourcegitcommit: 296183dbe35077b5c5e5e74d5fbe7f399bc507ee
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/27/2018
-ms.locfileid: "50045046"
+ms.lasthandoff: 11/05/2018
+ms.locfileid: "50982751"
 ---
 # <a name="listening-with-sockets"></a>リッスン (ソケットで)
 リスナーまたはサーバー ソケットは、ネットワーク上のポートを開き、クライアントがそのポートに接続するまで待機します。 他のネットワーク アドレス ファミリとプロトコルもありますが、この例では、TCP/IP ネットワーク用のリモート サービスを作成する方法を説明します。  
diff --git a/docs/standard/data/xml/insert-xml-data-using-xpathnavigator.md b/docs/standard/data/xml/insert-xml-data-using-xpathnavigator.md
index 9483e00b5b3..df41abba1df 100644
--- a/docs/standard/data/xml/insert-xml-data-using-xpathnavigator.md
+++ b/docs/standard/data/xml/insert-xml-data-using-xpathnavigator.md
@@ -10,10 +10,10 @@ ms.assetid: 2ed8c28b-b88d-4be7-9c87-92df01f0821f
 author: mairaw
 ms.author: mairaw
 ms.openlocfilehash: 8b9eedfab68dc6aeacf9ed51ffc7205b73c062ca
-ms.sourcegitcommit: 5bbfe34a9a14e4ccb22367e57b57585c208cf757
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/17/2018
+ms.lasthandoff: 11/07/2018
 ms.locfileid: "45698342"
 ---
 # <a name="insert-xml-data-using-xpathnavigator"></a>XPathNavigator による XML データの挿入
diff --git a/docs/standard/framework-libraries.md b/docs/standard/framework-libraries.md
index 640927c5391..feba076ae6a 100644
--- a/docs/standard/framework-libraries.md
+++ b/docs/standard/framework-libraries.md
@@ -1,17 +1,17 @@
 ---
-title: フレームワーク ライブラリ
-description: 多くの一般的な型、アプリ固有の型、アルゴリズム、ユーティリティの機能の実装を提供しているライブラリについて説明します。
-author: richlander
-ms.author: ronpet
-ms.date: 06/20/2016
-ms.technology: dotnet-standard
-ms.assetid: 7b77b6c1-8367-4602-bff3-91e4c05ac643
-ms.openlocfilehash: dd8baa481e51aa44c4c884b4b165bdf319ac1c4d
-ms.sourcegitcommit: 3d5d33f384eeba41b2dff79d096f47ccc8d8f03d
-ms.translationtype: HT
-ms.contentlocale: ja-JP
-ms.lasthandoff: 05/04/2018
-ms.locfileid: "33576283"
+title: フレームワーク ライブラリ
+description: 多くの一般的な型、アプリ固有の型、アルゴリズム、ユーティリティの機能の実装を提供しているライブラリについて説明します。
+author: richlander
+ms.author: ronpet
+ms.date: 06/20/2016
+ms.technology: dotnet-standard
+ms.assetid: 7b77b6c1-8367-4602-bff3-91e4c05ac643
+ms.openlocfilehash: 1b5099c73264f3175aa05094f4460c1c97774533
+ms.sourcegitcommit: 5fd80619c760fa8c25d33a6f5661247cb65da465
+ms.translationtype: HT
+ms.contentlocale: ja-JP
+ms.lasthandoff: 11/01/2018
+ms.locfileid: "50743964"
 ---
 # <a name="framework-libraries"></a>フレームワーク ライブラリ
 
@@ -59,4 +59,4 @@ BCL は最も基本的な型およびユーティリティの機能を提供し
 
 .NET で使用できる多くのアプリ モデルが、複数の企業から提供されています。
 
-*   [ASP.NET](http://asp.net): Web サイトとサービスを構築するための Web フレームワークを提供します。 Windows、Linux、macOS でサポートされます (ASP.NET のバージョンによって異なります)。
+*   [ASP.NET](https://www.asp.net): Web サイトとサービスを構築するための Web フレームワークを提供します。 Windows、Linux、macOS でサポートされます (ASP.NET のバージョンによって異なります)。
diff --git a/docs/standard/io/file-path-formats.md b/docs/standard/io/file-path-formats.md
index 308748ffb7f..97baf3699c3 100644
--- a/docs/standard/io/file-path-formats.md
+++ b/docs/standard/io/file-path-formats.md
@@ -9,12 +9,12 @@ helpviewer_keywords:
 - path formats, Windows
 author: rpetrusha
 ms.author: ronpet
-ms.openlocfilehash: 5821d15e71492bd54fa6b5d891f2ff38a2902a06
-ms.sourcegitcommit: fb78d8abbdb87144a3872cf154930157090dd933
+ms.openlocfilehash: 05146467f321a3c83f3637e2eecc4c7c42dc4ba0
+ms.sourcegitcommit: 3b1cb8467bd73dee854b604e306c0e7e3882d91a
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 09/28/2018
-ms.locfileid: "47424390"
+ms.lasthandoff: 11/06/2018
+ms.locfileid: "51214195"
 ---
 # <a name="file-path-formats-on-windows-systems"></a>Windows システムのファイル パス形式
 
@@ -202,7 +202,7 @@ Windows API に渡されるパスはほとんどすべて正規化されます
 Windows を使っていないユーザーや開発者がとまどうことには、Windows ファイル システムではパス名とディレクトリ名で大文字と小文字が区別されないという特徴があります。 つまり、ディレクトリ名とファイル名は、それが作成されたときの大文字/小文字の使い分けを反映します。 たとえば、次のメソッドを呼び出すと、
 
 ```csharp
-Directory.Create(TeStDiReCtOrY);
+Directory.Create("TeStDiReCtOrY");
 ```
 TeStDiReCtOrY という名前のディレクトリが作成されます。 ディレクトリやファイルの名前を変更し、大文字を小文字に変えるか、小文字を大文字に変えると、その名前変更時の大文字/小文字の使い方がディレクトリ名またはファイル名に反映されます。 たとえば、次のコードでは test.txt というファイルの名前が Test.txt に変更されます。
 
diff --git a/docs/standard/microservices-architecture/architect-microservice-container-applications/asynchronous-message-based-communication.md b/docs/standard/microservices-architecture/architect-microservice-container-applications/asynchronous-message-based-communication.md
index b29f31e1679..3c64aef4f37 100644
--- a/docs/standard/microservices-architecture/architect-microservice-container-applications/asynchronous-message-based-communication.md
+++ b/docs/standard/microservices-architecture/architect-microservice-container-applications/asynchronous-message-based-communication.md
@@ -5,11 +5,11 @@ author: CESARDELATORRE
 ms.author: wiwagn
 ms.date: 05/26/2017
 ms.openlocfilehash: 865966a70f18c9023e4c733d82ea90aba9478753
-ms.sourcegitcommit: 9bd8f213b50f0e1a73e03bd1e840c917fbd6d20a
+ms.sourcegitcommit: db8b83057d052c1f9f249d128b08d4423af0f7c2
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/27/2018
-ms.locfileid: "50135376"
+ms.lasthandoff: 11/01/2018
+ms.locfileid: "50757440"
 ---
 # <a name="asynchronous-message-based-communication"></a>メッセージベースの非同期通信
 
diff --git a/docs/standard/microservices-architecture/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout.md b/docs/standard/microservices-architecture/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout.md
index 639e553c262..e010b498633 100644
--- a/docs/standard/microservices-architecture/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout.md
+++ b/docs/standard/microservices-architecture/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout.md
@@ -5,11 +5,11 @@ author: CESARDELATORRE
 ms.author: wiwagn
 ms.date: 05/26/2017
 ms.openlocfilehash: 3c5f4c5a1dd1c1065be63ad916af078050c069c1
-ms.sourcegitcommit: 9bd8f213b50f0e1a73e03bd1e840c917fbd6d20a
+ms.sourcegitcommit: 5fd80619c760fa8c25d33a6f5661247cb65da465
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/25/2018
-ms.locfileid: "50033650"
+ms.lasthandoff: 11/01/2018
+ms.locfileid: "50744497"
 ---
 # <a name="creating-composite-ui-based-on-microservices-including-visual-ui-shape-and-layout-generated-by-multiple-microservices"></a>複数のマイクロサービスによって生成されるビジュアル UI シェイプ、レイアウトなど、マイクロサービスを基にしている複合 UI を作成する
 
diff --git a/docs/standard/microservices-architecture/architect-microservice-container-applications/scalable-available-multi-container-microservice-applications.md b/docs/standard/microservices-architecture/architect-microservice-container-applications/scalable-available-multi-container-microservice-applications.md
index dda54e1e642..d36e975179a 100644
--- a/docs/standard/microservices-architecture/architect-microservice-container-applications/scalable-available-multi-container-microservice-applications.md
+++ b/docs/standard/microservices-architecture/architect-microservice-container-applications/scalable-available-multi-container-microservice-applications.md
@@ -5,11 +5,11 @@ author: CESARDELATORRE
 ms.author: wiwagn
 ms.date: 10/18/2017
 ms.openlocfilehash: 25175e2a4409d53be412ae72be5af1c07c3ec68d
-ms.sourcegitcommit: c93fd5139f9efcf6db514e3474301738a6d1d649
+ms.sourcegitcommit: 296183dbe35077b5c5e5e74d5fbe7f399bc507ee
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/28/2018
-ms.locfileid: "50199664"
+ms.lasthandoff: 11/05/2018
+ms.locfileid: "50982777"
 ---
 # <a name="orchestrating-microservices-and-multi-container-applications-for-high-scalability-and-availability"></a>高いスケーラビリティと可用性のためにマイクロサービスと複数のコンテナー アプリケーションを調整する
 
diff --git a/docs/standard/modern-web-apps-azure-architecture/common-web-application-architectures.md b/docs/standard/modern-web-apps-azure-architecture/common-web-application-architectures.md
index 1ee11978e4e..cce36e65fa9 100644
--- a/docs/standard/modern-web-apps-azure-architecture/common-web-application-architectures.md
+++ b/docs/standard/modern-web-apps-azure-architecture/common-web-application-architectures.md
@@ -4,12 +4,12 @@ description: ASP.NET Core および Azure での最新の Web アプリケーシ
 author: ardalis
 ms.author: wiwagn
 ms.date: 06/28/2018
-ms.openlocfilehash: ff483c9b555fdf394d11626536c28e7e07516d05
-ms.sourcegitcommit: 4c158beee818c408d45a9609bfc06f209a523e22
+ms.openlocfilehash: ae141b3d60a9968ee3fe59474e32a174bdb77e3b
+ms.sourcegitcommit: db8b83057d052c1f9f249d128b08d4423af0f7c2
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 07/03/2018
-ms.locfileid: "37404633"
+ms.lasthandoff: 11/01/2018
+ms.locfileid: "50757453"
 ---
 # <a name="common-web-application-architectures"></a>一般的な Web アプリケーション アーキテクチャ
 
@@ -97,7 +97,7 @@ Azure 内で Web アプリケーションをスケーリングする最も簡単
 
 ## <a name="clean-architecture"></a>クリーン アーキテクチャ
 
-依存関係逆転の原則ならびにドメイン駆動設計 (DDD) の原則に従うアプリケーションは、同様のアーキテクチャに到達する傾向があります。 このアーキテクチャには長年にわたってさまざまな名称が付けられてきました。 最初の名前の 1 つがヘキサゴナル アーキテクチャ (Hexagonal Architecture) でした。その後に使用された名前がポート アンド アダプター (Ports-and-Adapters) でした。 最近では、このアーキテクチャは[オニオン アーキテクチャ](http://jeffreypalermo.com/blog/the-onion-architecture-part-1/)または[クリーン アーキテクチャ](https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html)として引用されています。 後者のクリーン アーキテクチャは、この電子書籍でアーキテクチャの名前として使用されています。
+依存関係逆転の原則ならびにドメイン駆動設計 (DDD) の原則に従うアプリケーションは、同様のアーキテクチャに到達する傾向があります。 このアーキテクチャには長年にわたってさまざまな名称が付けられてきました。 最初の名前の 1 つがヘキサゴナル アーキテクチャ (Hexagonal Architecture) でした。その後に使用された名前がポート アンド アダプター (Ports-and-Adapters) でした。 最近では、このアーキテクチャは[オニオン アーキテクチャ](https://jeffreypalermo.com/blog/the-onion-architecture-part-1/)または[クリーン アーキテクチャ](https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html)として引用されています。 後者のクリーン アーキテクチャは、この電子書籍でアーキテクチャの名前として使用されています。
 
 > [!NOTE]
 > クリーン アーキテクチャという用語は、DDD 原則を使用して構築されたアプリケーションにも、DDD 原則を使用して構築されていないアプリケーションにも適用できます。 前者の場合、この組み合わせを "クリーン DDD アーキテクチャ" と呼ぶことがあります。
@@ -307,7 +307,7 @@ Visual Studio を使用して、ご利用のアプリケーションに Docker 
 > - **クリーン アーキテクチャ**  
 >   <https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html>
 > - **オニオン アーキテクチャ**  
->   <http://jeffreypalermo.com/blog/the-onion-architecture-part-1/>
+>   <https://jeffreypalermo.com/blog/the-onion-architecture-part-1/>
 > - **リポジトリ パターン**  
 >   <https://deviq.com/repository-pattern/>
 > - **クリーン アーキテクチャ ソリューションのサンプル**  
diff --git a/docs/standard/threading/managed-and-unmanaged-threading-in-windows.md b/docs/standard/threading/managed-and-unmanaged-threading-in-windows.md
index 3fdeffa82d8..083a52a5659 100644
--- a/docs/standard/threading/managed-and-unmanaged-threading-in-windows.md
+++ b/docs/standard/threading/managed-and-unmanaged-threading-in-windows.md
@@ -12,11 +12,11 @@ ms.assetid: 4fb6452f-c071-420d-9e71-da16dee7a1eb
 author: rpetrusha
 ms.author: ronpet
 ms.openlocfilehash: 34bd959890717a16df80d3870099757dd7400943
-ms.sourcegitcommit: c93fd5139f9efcf6db514e3474301738a6d1d649
+ms.sourcegitcommit: db8b83057d052c1f9f249d128b08d4423af0f7c2
 ms.translationtype: HT
 ms.contentlocale: ja-JP
-ms.lasthandoff: 10/28/2018
-ms.locfileid: "50199735"
+ms.lasthandoff: 11/01/2018
+ms.locfileid: "50757362"
 ---
 # <a name="managed-and-unmanaged-threading-in-windows"></a>Windows でのマネージド スレッド処理とアンマネージド スレッド処理
 
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
index f9062d6d1ec..4e5eb0569be 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|<xref:System.Data.Common.DbParameter.Precision> および <xref:System.Data.Common.DbParameter.Scale> はパブリック仮想プロパティとして実装されます。 これらは、対応する明示的なインターフェイス実装、<xref:System.Data.Common.DbParameter.System%23Data%23IDbDataParameter%23Precision> と <xref:System.Data.Common.DbParameter.System%23Data%23IDbDataParameter%23Scale> を置き換えます。|
+|詳細|<xref:System.Data.Common.DbParameter.Precision> および <xref:System.Data.Common.DbParameter.Scale> はパブリック仮想プロパティとして実装されます。 これらは、対応する明示的なインターフェイス実装、<xref:System.Data.Common.DbParameter.System%23Data%23IDbDataParameter%23Precision> と <xref:System.Data.Common.DbParameter.System%23Data%23IDbDataParameter%23Scale> を置き換えます。|
 |提案される解決策|ADO.NET データベース プロバイダーを再構築するとき、これらの違いにより、「override」キーワードが Precision および Scale プロパティに適用される必要があります。 これは、コンポーネントを再構築するときにのみ必要です。既存のバイナリは引き続き機能します。|
 |スコープ|マイナー|
 |Version|4.5.1|
diff --git a/includes/migration-guide/retargeting/asp/httpruntimeappdomainapppath-throws-nullreferenceexception.md b/includes/migration-guide/retargeting/asp/httpruntimeappdomainapppath-throws-nullreferenceexception.md
index 45cc491623b..869c08ad3e7 100644
--- a/includes/migration-guide/retargeting/asp/httpruntimeappdomainapppath-throws-nullreferenceexception.md
+++ b/includes/migration-guide/retargeting/asp/httpruntimeappdomainapppath-throws-nullreferenceexception.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|ランタイムによってスローされる、.NET Framework 4.6.2、<code>T:System.NullReferenceException</code>取得するときに、 <code>P:System.Web.HttpRuntime.AppDomainAppPath</code> null 文字を含む値です。 .NET Framework 4.6.1 と以前のバージョンでは、ランタイムによってスローされる、<code>T:System.ArgumentNullException</code>です。|
+|詳細|ランタイムによってスローされる、.NET Framework 4.6.2、<code>T:System.NullReferenceException</code>取得するときに、 <code>P:System.Web.HttpRuntime.AppDomainAppPath</code> null 文字を含む値です。 .NET Framework 4.6.1 と以前のバージョンでは、ランタイムによってスローされる、<code>T:System.ArgumentNullException</code>です。|
 |提案される解決策|次のいずれかでこの変更に対応できます。<ul><li>アプリケーションが .NET Framework 4.6.2 で実行されている場合には <code>T:System.NullReferenceException</code> を処理します。</li><li>.NET Framework 4.7 にアップグレードします。以前の動作が復元され、<code>T:System.ArgumentNullException</code> がスローされます。</li></ul>|
 |スコープ|エッジ|
 |Version|4.6.2|
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
index e8ecb408a59..e0196bba65c 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.0 では、<xref:System.Web.Security.AntiXss.AntiXssEncoder?displayProperty=name> を使用する場合、ポストバックの複数行テキスト ボックスの行間に余分な行が挿入されました。 .NET Framework 4.5 では、これらの余分な改行は含まれませんが、web アプリが .NET Framework 4.5 を対象としている場合に限ります。|
+|詳細|.NET Framework 4.0 では、<xref:System.Web.Security.AntiXss.AntiXssEncoder?displayProperty=name> を使用する場合、ポストバックの複数行テキスト ボックスの行間に余分な行が挿入されました。 .NET Framework 4.5 では、これらの余分な改行は含まれませんが、web アプリが .NET Framework 4.5 を対象としている場合に限ります。|
 |提案される解決策|4.0 の Web アプリの対象を .NET Framework 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
index 847d77962ce..d867da46685 100644
--- a/includes/migration-guide/retargeting/asp/throttle-concurrent-requests-per-session.md
+++ b/includes/migration-guide/retargeting/asp/throttle-concurrent-requests-per-session.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.6.2 以前の場合、ASP.NET は同じ Sessionid の要求を順番に実行します。ASP.NET は既定で常にクッキーを経由して Sessionid を発行します。 ページの応答に長い時間がかかる場合、ブラウザーの F5 を押すと、サーバーのパフォーマンスが大幅に低下します。 この修正プログラムでは、キューに置かれた要求を追跡し、特定の制限を超えたときに要求を終了するためのカウンターを追加しました。 既定値は 50 です。 制限に達すると、警告がイベント ログに記録され、HTTP 500 応答は IIS ログに記録される可能性があります。|
+|詳細|.NET Framework 4.6.2 以前の場合、ASP.NET は同じ Sessionid の要求を順番に実行します。ASP.NET は既定で常にクッキーを経由して Sessionid を発行します。 ページの応答に長い時間がかかる場合、ブラウザーの F5 を押すと、サーバーのパフォーマンスが大幅に低下します。 この修正プログラムでは、キューに置かれた要求を追跡し、特定の制限を超えたときに要求を終了するためのカウンターを追加しました。 既定値は 50 です。 制限に達すると、警告がイベント ログに記録され、HTTP 500 応答は IIS ログに記録される可能性があります。|
 |提案される解決策|以前の動作を復元するには、次の設定を web.config ファイルに追加して、新しい動作を無効にできます。<pre><code class="lang-xml">&lt;appSettings&gt;&#13;&#10;&lt;add key=&quot;aspnet:RequestQueueLimitPerSession&quot; value=&quot;2147483647&quot;/&gt;&#13;&#10;&lt;/appSettings&gt;&#13;&#10;</code></pre>|
 |スコープ|エッジ|
 |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
index eec4012fe45..ee19679f6d0 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.5 を対象とするアプリケーションの場合、基本多言語面 (BMP: Basic Multilingual Plane) の外部にある文字は、<xref:System.Net.WebUtility.HtmlDecode(System.String)> メソッドに渡されたときに正常に往復します。|
+|詳細|.NET Framework 4.5 を対象とするアプリケーションの場合、基本多言語面 (BMP: Basic Multilingual Plane) の外部にある文字は、<xref:System.Net.WebUtility.HtmlDecode(System.String)> メソッドに渡されたときに正常に往復します。|
 |提案される解決策|この変更は現在のアプリケーションに影響を与えないはずですが、元の動作に戻すには、<code>&lt;httpRuntime&gt;</code> 要素の <code>targetFramework</code> 属性を &quot;4.5&quot; 以外の文字列に設定します。 また、.NET Framework の対象バージョンに関係なくこの動作を制御するために <code>unicodeEncodingConformance</code> 構成要素の <code>unicodeDecodingConformance</code> 属性と <code>&lt;webUtility&gt;</code> 属性を設定することもできます。|
 |スコープ|エッジ|
 |Version|4.5|
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
index 89b2b94b00c..3889c166c29 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|この実行可能ファイルは SHA256 で署名されます。 以前は、コード署名証明書が SHA-1 か SHA-256 に関係なく、SHA 1 で署名されました。 この方法は、次の対象に適用されます。<ul><li>Visual Studio 2012 以降でビルドされたすべてのアプリケーション。</li><li>.NET Framework 4.5 がインストールされているシステム上で、Visual Studio 2010 以前でビルドされたアプリケーション。</li></ul>さらに、.NET Framework 4.5 以降が存在する場合、コンパイル対象となった .NET Framework のバージョンに関係なく、ClickOnce マニフェストはSHA-256 証明書の SHA 256 で署名されます。|
+|詳細|この実行可能ファイルは SHA256 で署名されます。 以前は、コード署名証明書が SHA-1 か SHA-256 に関係なく、SHA 1 で署名されました。 この方法は、次の対象に適用されます。<ul><li>Visual Studio 2012 以降でビルドされたすべてのアプリケーション。</li><li>.NET Framework 4.5 がインストールされているシステム上で、Visual Studio 2010 以前でビルドされたアプリケーション。</li></ul>さらに、.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/core/aescryptoserviceprovider-decryptor-provides-reusable-transform.md b/includes/migration-guide/retargeting/core/aescryptoserviceprovider-decryptor-provides-reusable-transform.md
index b1bdc5a9f5e..84fc837f917 100644
--- a/includes/migration-guide/retargeting/core/aescryptoserviceprovider-decryptor-provides-reusable-transform.md
+++ b/includes/migration-guide/retargeting/core/aescryptoserviceprovider-decryptor-provides-reusable-transform.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.6.2 以降を対象とするアプリでは、<xref:System.Security.Cryptography.AesCryptoServiceProvider> の復号で変換を再利用できます。 <xref:System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(System.Byte[],System.Int32,System.Int32)?displayProperty=name> の呼び出しの後、変換は初期化し直され、再利用することができます。 以前のバージョンの .NET Framework を対象とするアプリでは、<xref:System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(System.Byte[],System.Int32,System.Int32)?displayProperty=name> の呼び出しの後に、<xref:System.Security.Cryptography.CryptoAPITransform.TransformBlock(System.Byte[],System.Int32,System.Int32,System.Byte[],System.Int32)?displayProperty=name> を呼び出して、復号を再利用しようとすると、<xref:System.Security.Cryptography.CryptographicException> をスローするか、破損しているデータが生成されます。|
+|詳細|.NET Framework 4.6.2 以降を対象とするアプリでは、<xref:System.Security.Cryptography.AesCryptoServiceProvider> の復号で変換を再利用できます。 <xref:System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(System.Byte[],System.Int32,System.Int32)?displayProperty=name> の呼び出しの後、変換は初期化し直され、再利用することができます。 以前のバージョンの .NET Framework を対象とするアプリでは、<xref:System.Security.Cryptography.CryptoAPITransform.TransformFinalBlock(System.Byte[],System.Int32,System.Int32)?displayProperty=name> の呼び出しの後に、<xref:System.Security.Cryptography.CryptoAPITransform.TransformBlock(System.Byte[],System.Int32,System.Int32,System.Byte[],System.Int32)?displayProperty=name> を呼び出して、復号を再利用しようとすると、<xref:System.Security.Cryptography.CryptographicException> をスローするか、破損しているデータが生成されます。|
 |提案される解決策|この動作は想定済みであり、この変更の影響は最小限に抑えられているはずです。この変更の影響は前の動作に依存するアプリケーションは、そのアプリケーションの構成ファイルの <code>&lt;runtime&gt;</code> セクションに次の構成設定を追加して、この動作の使用を無効にすることができます。<pre><code class="lang-xml">&lt;runtime&gt;&#13;&#10;&lt;AppContextSwitchOverrides value=&quot;Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=true&quot;/&gt;&#13;&#10;&lt;/runtime&gt;&#13;&#10;</code></pre>また、以前のバージョンの .NET Framework を対象とするものの、.NET Framework 4.6.2 以降のバージョンの .NET Framework で実行されているアプリでは、そのアプリケーションの構成ファイルの <code>&lt;runtime&gt;</code> セクションに次の構成設定を追加して、この動作を有効にできます。<pre><code class="lang-xml">&lt;runtime&gt;&#13;&#10;&lt;AppContextSwitchOverrides value=&quot;Switch.System.Security.Cryptography.AesCryptoServiceProvider.DontCorrectlyResetDecryptor=false&quot;/&gt;&#13;&#10;&lt;/runtime&gt;&#13;&#10;</code></pre>|
 |スコープ|マイナー|
 |Version|4.6.2|
diff --git a/includes/migration-guide/retargeting/core/calls-claimsidentity-constructors.md b/includes/migration-guide/retargeting/core/calls-claimsidentity-constructors.md
index 04cae22c073..aa96a92088d 100644
--- a/includes/migration-guide/retargeting/core/calls-claimsidentity-constructors.md
+++ b/includes/migration-guide/retargeting/core/calls-claimsidentity-constructors.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.6.2 以降、<xref:System.Security.Claims.ClaimsIdentity> コンストラクターと <xref:System.Security.Principal.IIdentity?displayProperty=name> パラメーターの組み合わせで <xref:System.Security.Claims.ClaimsIdentity.Actor?displayProperty=name> プロパティが設定されるしくみに変更があります。 <xref:System.Security.Principal.IIdentity?displayProperty=name> 引数が <xref:System.Security.Claims.ClaimsIdentity> オブジェクトで、その <xref:System.Security.Claims.ClaimsIdentity> オブジェクトの <xref:System.Security.Claims.ClaimsIdentity.Actor?displayProperty=name> プロパティが <code>null</code> ではない場合、<xref:System.Security.Claims.ClaimsIdentity.Clone> メソッドを使用して <xref:System.Security.Claims.ClaimsIdentity.Actor?displayProperty=name> プロパティがアタッチされます。 Framework 4.6.1 以前のバージョンでは、<xref:System.Security.Claims.ClaimsIdentity.Actor?displayProperty=name> プロパティは既存の参照として付けられます。この変更によって、.NET Framework 4.6.2 以降、新しい <xref:System.Security.Claims.ClaimsIdentity> オブジェクトの <xref:System.Security.Claims.ClaimsIdentity.Actor?displayProperty=name> プロパティはコンストラクターの <xref:System.Security.Principal.IIdentity?displayProperty=name> 引数の <xref:System.Security.Claims.ClaimsIdentity.Actor?displayProperty=name> プロパティとは等しくなくなります。 .NET Framework 4.6.1 以前のバージョンでは、等しくなります。|
+|詳細|.NET Framework 4.6.2 以降、<xref:System.Security.Claims.ClaimsIdentity> コンストラクターと <xref:System.Security.Principal.IIdentity?displayProperty=name> パラメーターの組み合わせで <xref:System.Security.Claims.ClaimsIdentity.Actor?displayProperty=name> プロパティが設定されるしくみに変更があります。 <xref:System.Security.Principal.IIdentity?displayProperty=name> 引数が <xref:System.Security.Claims.ClaimsIdentity> オブジェクトで、その <xref:System.Security.Claims.ClaimsIdentity> オブジェクトの <xref:System.Security.Claims.ClaimsIdentity.Actor?displayProperty=name> プロパティが <code>null</code> ではない場合、<xref:System.Security.Claims.ClaimsIdentity.Clone> メソッドを使用して <xref:System.Security.Claims.ClaimsIdentity.Actor?displayProperty=name> プロパティがアタッチされます。 Framework 4.6.1 以前のバージョンでは、<xref:System.Security.Claims.ClaimsIdentity.Actor?displayProperty=name> プロパティは既存の参照として付けられます。この変更によって、.NET Framework 4.6.2 以降、新しい <xref:System.Security.Claims.ClaimsIdentity> オブジェクトの <xref:System.Security.Claims.ClaimsIdentity.Actor?displayProperty=name> プロパティはコンストラクターの <xref:System.Security.Principal.IIdentity?displayProperty=name> 引数の <xref:System.Security.Claims.ClaimsIdentity.Actor?displayProperty=name> プロパティとは等しくなくなります。 .NET Framework 4.6.1 以前のバージョンでは、等しくなります。|
 |提案される解決策|この動作が望ましくない場合、アプリケーション構成ファイルで <code>Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity</code> スイッチを <code>true</code> に設定して以前の動作を復元することができます。 この場合、web.config ファイルの <code>&lt;runtime&gt;</code> セクションに次を追加します。<pre><code class="lang-xml">&lt;configuration&gt;&#13;&#10;&lt;runtime&gt;&#13;&#10;&lt;AppContextSwitchOverrides value=&quot;Switch.System.Security.ClaimsIdentity.SetActorAsReferenceWhenCopyingClaimsIdentity=true&quot; /&gt;&#13;&#10;&lt;/runtime&gt;&#13;&#10;&lt;/configuration&gt;&#13;&#10;</code></pre>|
 |スコープ|エッジ|
 |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
index dbfec183a11..81e31f73ba2 100644
--- a/includes/migration-guide/retargeting/core/currentculture-currentuiculture-flow-across-tasks.md
+++ b/includes/migration-guide/retargeting/core/currentculture-currentuiculture-flow-across-tasks.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.6 より、非同期操作全体をフローする、スレッドの <xref:System.Threading.ExecutionContext?displayProperty=name> に <xref:System.Globalization.CultureInfo.CurrentCulture?displayProperty=name> と <xref:System.Globalization.CultureInfo.CurrentUICulture?displayProperty=name> が格納されます。その結果、<xref:System.Globalization.CultureInfo.CurrentCulture?displayProperty=name> または <xref:System.Globalization.CultureInfo.CurrentUICulture?displayProperty=name> に対する変更は、後で非同期実行されるタスクで反映されます。 これは、すべての非同期タスクで <xref:System.Globalization.CultureInfo.CurrentCulture?displayProperty=name> と <xref:System.Globalization.CultureInfo.CurrentUICulture?displayProperty=name> がリセットされていた、以前のバージョンの .NET Framework の動作とは異なります。|
+|詳細|.NET Framework 4.6 より、非同期操作全体をフローする、スレッドの <xref:System.Threading.ExecutionContext?displayProperty=name> に <xref:System.Globalization.CultureInfo.CurrentCulture?displayProperty=name> と <xref:System.Globalization.CultureInfo.CurrentUICulture?displayProperty=name> が格納されます。その結果、<xref:System.Globalization.CultureInfo.CurrentCulture?displayProperty=name> または <xref:System.Globalization.CultureInfo.CurrentUICulture?displayProperty=name> に対する変更は、後で非同期実行されるタスクで反映されます。 これは、すべての非同期タスクで <xref:System.Globalization.CultureInfo.CurrentCulture?displayProperty=name> と <xref:System.Globalization.CultureInfo.CurrentUICulture?displayProperty=name> がリセットされていた、以前のバージョンの .NET Framework の動作とは異なります。|
 |提案される解決策|この変更の影響を受けるアプリでは、非同期タスクの最初の操作として任意の <xref:System.Globalization.CultureInfo.CurrentCulture?displayProperty=name> または <xref:System.Globalization.CultureInfo.CurrentUICulture?displayProperty=name> を明示的に設定することで問題を回避できます。 あるいは、次の互換性スイッチを設定することで、<xref:System.Globalization.CultureInfo.CurrentCulture?displayProperty=name>/<xref:System.Globalization.CultureInfo.CurrentUICulture?displayProperty=name> をフローしない以前の動作を選択できます。<pre><code class="lang-csharp">AppContext.SetSwitch(&quot;Switch.System.Globalization.NoAsyncCurrentCulture&quot;, true);&#13;&#10;</code></pre>この問題は、.NET Framework 4.6.2 の WPF で修正されました。 また、.NET Frameworks 4.6、4.6.1 では [KB 3139549](https://support.microsoft.com/kb/3139549) を通じて修正されました。 .NET Framework 4.6 以降を対象とするアプリケーションでは WPF アプリケーション (<xref:System.Globalization.CultureInfo.CurrentCulture?displayProperty=name>/<xref:System.Globalization.CultureInfo.CurrentUICulture?displayProperty=name>) の正しい動作が自動的に取得されます。これは、ディスパッチャー操作にわたって維持されます。|
 |スコープ|マイナー|
 |Version|4.6|
diff --git a/includes/migration-guide/retargeting/core/deflatestream-uses-native-apis-for-decompression.md b/includes/migration-guide/retargeting/core/deflatestream-uses-native-apis-for-decompression.md
index 57e8f262e96..404a6d69040 100644
--- a/includes/migration-guide/retargeting/core/deflatestream-uses-native-apis-for-decompression.md
+++ b/includes/migration-guide/retargeting/core/deflatestream-uses-native-apis-for-decompression.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.7.2 以降では、<code>T:System.IO.Compression.DeflateStream</code> クラスの圧縮解除の実装の際に、既定でネイティブの Windows API を使用するように変更されました。 通常は、これによりパフォーマンスが大幅に改善されます。 .NET Framework バージョン 4.7.2 以降を対象とするすべての .NET アプリケーションでは、ネイティブ実装が使用されます。この変更により、次のように動作にいくつか違いが生じる場合があります。<ul><li>例外メッセージが異なる場合があります。 ただし、スローされる例外の種類は変わりません。</li><li>操作を完了するのに十分なメモリがないなど、いくつかの特殊な状況が異なる方法で処理される場合があります。</li><li>gzip ヘッダーの解析には、次のような違いが確認されています (注: 圧縮解除のために設定されている <code>GZipStream</code> のみが影響します)。</li><li>無効なヘッダーの解析時の例外がさまざまなタイミングでスローされる場合があります。</li><li>ネイティブ実装では、gzip ヘッダー内で予約されているいくつかのフラグの値 (つまり、[FLG](http://www.zlib.org/rfc-gzip.html#header-trailer)) が、仕様に基づいて設定されるように強制されます。これにより、以前は無効な値が無視されていた例外がスローされる可能性があります。</li></ul>|
+|詳細|.NET Framework 4.7.2 以降では、<code>T:System.IO.Compression.DeflateStream</code> クラスの圧縮解除の実装の際に、既定でネイティブの Windows API を使用するように変更されました。 通常は、これによりパフォーマンスが大幅に改善されます。 .NET Framework バージョン 4.7.2 以降を対象とするすべての .NET アプリケーションでは、ネイティブ実装が使用されます。この変更により、次のように動作にいくつか違いが生じる場合があります。<ul><li>例外メッセージが異なる場合があります。 ただし、スローされる例外の種類は変わりません。</li><li>操作を完了するのに十分なメモリがないなど、いくつかの特殊な状況が異なる方法で処理される場合があります。</li><li>gzip ヘッダーの解析には、次のような違いが確認されています (注: 圧縮解除のために設定されている <code>GZipStream</code> のみが影響します)。</li><li>無効なヘッダーの解析時の例外がさまざまなタイミングでスローされる場合があります。</li><li>ネイティブ実装では、gzip ヘッダー内で予約されているいくつかのフラグの値 (つまり、[FLG](http://www.zlib.org/rfc-gzip.html#header-trailer)) が、仕様に基づいて設定されるように強制されます。これにより、以前は無効な値が無視されていた例外がスローされる可能性があります。</li></ul>|
 |提案される解決策|ネイティブ API での圧縮解除がアプリの動作に悪影響を与えている場合は、app.config ファイルの <code>runtime</code> セクションに <code>Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression</code> スイッチを追加して <code>true</code> に設定することで、この機能の選択を解除できます。<pre><code class="lang-xml">&lt;?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot; ?&gt;&#13;&#10;&lt;configuration&gt;&#13;&#10;&lt;runtime&gt;&#13;&#10;&lt;AppContextSwitchOverrides&#13;&#10;value=&quot;Switch.System.IO.Compression.DoNotUseNativeZipLibraryForDecompression=true&quot; /&gt;&#13;&#10;&lt;/runtime&gt;&#13;&#10;&lt;/configuration&gt;&#13;&#10;</code></pre>|
 |スコープ|マイナー|
 |Version|4.7.2|
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
index 352027c7d02..73e2f2ba0af 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|C#5 (Visual Studio 2012) 以降では、<code>foreach</code> 反復子変数は、イテレーション内をスコープとします。 このため、変数が <code>foreach</code> のクロージャに含まれないことに依存していたコードは機能しなくなります。 この変更による症状は、デリゲートに渡された反復子変数が、デリゲートが呼び出された時点での値ではなく、デリゲートの作成時点での値として扱われることです。|
+|詳細|C#5 (Visual Studio 2012) 以降では、<code>foreach</code> 反復子変数は、イテレーション内をスコープとします。 このため、変数が <code>foreach</code> のクロージャに含まれないことに依存していたコードは機能しなくなります。 この変更による症状は、デリゲートに渡された反復子変数が、デリゲートが呼び出された時点での値ではなく、デリゲートの作成時点での値として扱われることです。|
 |提案される解決策|理想的には、新しいコンパイラの動作を予期するように、コードを更新する必要があります。 古いセマンティクスが必要な場合は、反復子変数を、ループのスコープ外に明示的に配置される別の変数に置き換えることができます。|
 |スコープ|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
index 9425284d86d..de255891ca2 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|TaskFactory.FromAsync を呼び出すとき、<xref:System.IAsyncResult.CompletedSynchronously> プロパティの実装が正しくなければ、結果のタスクは完了しません。 つまり、実装が同期的に完了した場合にのみ、このプロパティは true を返す必要があります。 以前は、このプロパティは確認されていませんでした。|
+|詳細|TaskFactory.FromAsync を呼び出すとき、<xref:System.IAsyncResult.CompletedSynchronously> プロパティの実装が正しくなければ、結果のタスクは完了しません。 つまり、実装が同期的に完了した場合にのみ、このプロパティは true を返す必要があります。 以前は、このプロパティは確認されていませんでした。|
 |提案される解決策|タスクが同期的に完了したときにのみ、<xref:System.IAsyncResult?displayProperty=name> の実装が <xref:System.IAsyncResult.CompletedSynchronously?displayProperty=name> プロパティに true を返す場合、中断は発生しません。 ユーザーは、所有する <xref:System.IAsyncResult?displayProperty=name> の実装 (ある場合) を見直して、タスクが同期的に完了したかどうかを正しく評価することを確認する必要があります。|
 |スコープ|エッジ|
 |Version|4.5|
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
index 0c4fa8640cc..c10733aba97 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.5 から、<xref:System.Collections.Generic.List%601.ForEach(System.Action{%600})> 列挙子は、呼び出し元のコレクション内の要素が変更された場合、<xref:System.InvalidOperationException?displayProperty=name> 例外をスローします。 以前は、この様な場合、例外はスローされませんでしたが、競合状態になることがありました。|
+|詳細|.NET Framework 4.5 から、<xref:System.Collections.Generic.List%601.ForEach(System.Action{%600})> 列挙子は、呼び出し元のコレクション内の要素が変更された場合、<xref:System.InvalidOperationException?displayProperty=name> 例外をスローします。 以前は、この様な場合、例外はスローされませんでしたが、競合状態になることがありました。|
 |提案される解決策|理想的には、安全な操作ではないため、要素の列挙中にリストを変更しないようにコードを修正する必要があります。 ただし、以前の動作に戻すには、アプリを .NET Framework 4.0 向けにできます。|
 |スコープ|エッジ|
 |Version|4.5|
diff --git a/includes/migration-guide/retargeting/core/long-path-support.md b/includes/migration-guide/retargeting/core/long-path-support.md
index a99a48a404b..ddde3a52a5f 100644
--- a/includes/migration-guide/retargeting/core/long-path-support.md
+++ b/includes/migration-guide/retargeting/core/long-path-support.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|以降とするアプリをターゲットとする .NET Framework 4.6.2、長いパス (最大 32 K の文字) がサポートされている、および 260 文字 (または<code>MAX_PATH</code>) パスの長さの制限がなくなりました。 .NET Framework 4.6.2 を対象として再コンパイルされたアプリの場合は、コードをスローした以前のパス、 <xref:System.IO.PathTooLongException?displayProperty=name> 260 文字をスローがパスを超えたため、<xref:System.IO.PathTooLongException?displayProperty=name>次の条件下でのみ。<ul><li>パスの長さが <xref:System.Int16.MaxValue> (32,767) 文字を超えている。</li><li>オペレーティング システムが <code>COR_E_PATHTOOLONG</code> またはそれと同等のものを返す。</li></ul>.NET Framework 4.6.1 以前を対象とするアプリの場合、パスが 260 文字を超えるたびにランタイムで自動的に <xref:System.IO.PathTooLongException?displayProperty=name> がスローされます。|
+|詳細|以降とするアプリをターゲットとする .NET Framework 4.6.2、長いパス (最大 32 K の文字) がサポートされている、および 260 文字 (または<code>MAX_PATH</code>) パスの長さの制限がなくなりました。 .NET Framework 4.6.2 を対象として再コンパイルされたアプリの場合は、コードをスローした以前のパス、 <xref:System.IO.PathTooLongException?displayProperty=name> 260 文字をスローがパスを超えたため、<xref:System.IO.PathTooLongException?displayProperty=name>次の条件下でのみ。<ul><li>パスの長さが <xref:System.Int16.MaxValue> (32,767) 文字を超えている。</li><li>オペレーティング システムが <code>COR_E_PATHTOOLONG</code> またはそれと同等のものを返す。</li></ul>.NET Framework 4.6.1 以前を対象とするアプリの場合、パスが 260 文字を超えるたびにランタイムで自動的に <xref:System.IO.PathTooLongException?displayProperty=name> がスローされます。|
 |提案される解決策|.NET Framework 4.6.2 を対象とするアプリケーションの場合、長いパスが望ましくないときは、<code>app.config</code> ファイルの <code>&lt;runtime&gt;</code> セクションに次を追加することで長いパスのサポートを無効にできます。<pre><code class="lang-xml">&lt;runtime&gt;&#13;&#10;&lt;AppContextSwitchOverrides value=&quot;Switch.System.IO.BlockLongPaths=true&quot; /&gt;&#13;&#10;&lt;/runtime&gt;&#13;&#10;</code></pre>以前のバージョンの .NET Framework を対象とするが、.NET Framework 4.6.2 以降で実行するアプリの場合、<code>app.config</code> ファイルの <code>&lt;runtime&gt;</code> セクションに次を追加することで長いパスのサポートを選択できます。<pre><code class="lang-xml">&lt;runtime&gt;&#13;&#10;&lt;AppContextSwitchOverrides value=&quot;Switch.System.IO.BlockLongPaths=false&quot; /&gt;&#13;&#10;&lt;/runtime&gt;&#13;&#10;</code></pre>|
 |スコープ|マイナー|
 |Version|4.6.2|
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
index 12f392c7035..0f5f3e552ff 100644
--- a/includes/migration-guide/retargeting/core/path-colon-checks-are-stricter.md
+++ b/includes/migration-guide/retargeting/core/path-colon-checks-are-stricter.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.6.2 では、以前はサポートされていなかったパスをサポートするために (長さと形式の両方で) 数多くの変更が加えられました。 適切なドライブ区切り (コロン) 構文の確認がより正確に行われました。その結果、それ以前は許容されていた、ごく少数のパス API の一部の URI パスがブロックされました。|
+|詳細|.NET Framework 4.6.2 では、以前はサポートされていなかったパスをサポートするために (長さと形式の両方で) 数多くの変更が加えられました。 適切なドライブ区切り (コロン) 構文の確認がより正確に行われました。その結果、それ以前は許容されていた、ごく少数のパス API の一部の URI パスがブロックされました。|
 |提案される解決策|影響を受ける API に URI を渡す場合、まず、文字列を正規のパスに変更します。<ul><li>URL から手動でスキームを削除します (たとえば、URL から <code>file://</code> を削除します)。</li><li><xref:System.Uri> クラスに URI を渡し、<xref:System.Uri.LocalPath> を使用します。</li></ul>あるいは、<code>Switch.System.IO.UseLegacyPathHandling</code> AppContext スイッチを true に設定し、新しいパス正規化を無効にできます。|
 |スコープ|エッジ|
 |Version|4.6.2|
diff --git a/includes/migration-guide/retargeting/core/serialport-background-thread-exceptions.md b/includes/migration-guide/retargeting/core/serialport-background-thread-exceptions.md
index 76c303e042e..a151f78a5b9 100644
--- a/includes/migration-guide/retargeting/core/serialport-background-thread-exceptions.md
+++ b/includes/migration-guide/retargeting/core/serialport-background-thread-exceptions.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|OS 例外がスローされたとき、<xref:System.IO.Ports.SerialPort> ストリームで作成されたバックグラウンド スレッドによってプロセスが終了することがなくなりました。 <br/>.NET Framework 4.7 以前のバージョンを対象とするアプリケーションでは、<xref:System.IO.Ports.SerialPort> ストリームで作成されたバックグラウンド スレッドでオペレーティング システム例外がスローされたとき、プロセスが終了します。 <br/>.NET Framework 4.7.1 以降のバージョンを対象とするアプリケーションでは、バックグラウンド スレッドはアクティブなシリアル ポートに関連付けられている OS イベントを待ち、シリアル ポートが急に削除されるなどした場合にクラッシュすることがあります。|
+|詳細|OS 例外がスローされたとき、<xref:System.IO.Ports.SerialPort> ストリームで作成されたバックグラウンド スレッドによってプロセスが終了することがなくなりました。 <br/>.NET Framework 4.7 以前のバージョンを対象とするアプリケーションでは、<xref:System.IO.Ports.SerialPort> ストリームで作成されたバックグラウンド スレッドでオペレーティング システム例外がスローされたとき、プロセスが終了します。 <br/>.NET Framework 4.7.1 以降のバージョンを対象とするアプリケーションでは、バックグラウンド スレッドはアクティブなシリアル ポートに関連付けられている OS イベントを待ち、シリアル ポートが急に削除されるなどした場合にクラッシュすることがあります。|
 |提案される解決策|.NET Framework 4.7.1 を対象とするアプリケーションの場合、例外処理が望ましくないときは、<code>app.config</code> ファイルの <code>&lt;runtime&gt;</code> セクションに次を追加することで例外処理を無効にできます。<pre><code class="lang-xml">&lt;runtime&gt;&#13;&#10;&lt;AppContextSwitchOverrides value=&quot;Switch.System.IO.Ports.DoNotCatchSerialStreamThreadExceptions=true&quot; /&gt;&#13;&#10;&lt;/runtime&gt;&#13;&#10;</code></pre>以前のバージョンの .NET Framework を対象とするが、.NET Framework 4.7.1 以降で実行するアプリの場合、<code>app.config</code> ファイルの <code>&lt;runtime&gt;</code> セクションに次を追加することで例外処理を選択できます。<pre><code class="lang-xml">&lt;runtime&gt;&#13;&#10;&lt;AppContextSwitchOverrides value=&quot;Switch.System.IO.Ports.DoNotCatchSerialStreamThreadExceptions=false&quot; /&gt;&#13;&#10;&lt;/runtime&gt;&#13;&#10;</code></pre>|
 |スコープ|マイナー|
 |Version|4.7.1|
diff --git a/includes/migration-guide/retargeting/core/stack-traces-obtained-when-using-portable-pdbs-now-include-source-file-line.md b/includes/migration-guide/retargeting/core/stack-traces-obtained-when-using-portable-pdbs-now-include-source-file-line.md
index 2fb71582c2d..c2254f61550 100644
--- a/includes/migration-guide/retargeting/core/stack-traces-obtained-when-using-portable-pdbs-now-include-source-file-line.md
+++ b/includes/migration-guide/retargeting/core/stack-traces-obtained-when-using-portable-pdbs-now-include-source-file-line.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.7.2 以降では、ポータブル PDB の使用時に取得されるスタック トレースに、要求に応じてソース ファイルと行情報が含まれます。 .NET Framework 4.7.2 より前のバージョンでは、明示的に要求された場合でもポータブル PDB の使用時にソース ファイルと行情報は利用できません。|
+|詳細|.NET Framework 4.7.2 以降では、ポータブル PDB の使用時に取得されるスタック トレースに、要求に応じてソース ファイルと行情報が含まれます。 .NET Framework 4.7.2 より前のバージョンでは、明示的に要求された場合でもポータブル PDB の使用時にソース ファイルと行情報は利用できません。|
 |提案される解決策|.NET Framework 4.7.2 を対象とするアプリケーションでは、望ましくない場合、<code>app.config</code> ファイルの <code>&lt;runtime&gt;</code> セクションに以下を追加することで、ポータブル PDB の使用時にソース ファイルと行情報の選択を解除できます。<pre><code class="lang-xml">&lt;runtime&gt;&#13;&#10;&lt;AppContextSwitchOverrides value=&quot;Switch.System.Diagnostics.IgnorePortablePDBsInStackTraces=true&quot; /&gt;&#13;&#10;&lt;/runtime&gt;&#13;&#10;</code></pre>以前のバージョンの .NET Framework を対象とするが、.NET Framework 4.7.2 以降で実行するアプリケーションの場合は、<code>app.config</code> ファイルの <code>&lt;runtime&gt;</code> セクションに以下を追加することで、ポータブル PDB の使用時にソース ファイルと行情報を選択できます。<pre><code class="lang-xml">&lt;runtime&gt;&#13;&#10;&lt;AppContextSwitchOverrides value=&quot;Switch.System.Diagnostics.IgnorePortablePDBsInStackTraces=false&quot; /&gt;&#13;&#10;&lt;/runtime&gt;&#13;&#10;</code></pre>|
 |スコープ|エッジ|
 |Version|4.7.2|
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
index 53716abf0a0..5d545f6eff3 100644
--- a/includes/migration-guide/retargeting/core/systemuri-parsing-adheres-rfc-3987.md
+++ b/includes/migration-guide/retargeting/core/systemuri-parsing-adheres-rfc-3987.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.5 では、URI 解析がいくつかの点で変更されました。 ただし、これらの変更は .NET Framework 4.5 を対象としたコードのみに影響することに注意してください。 バイナリが .NET Framework 4.0 を対象としている場合、以前の動作が実行されます。 .NET Framework 4.5 での URI 解析の変更は次のとおりです。<ul><li>URI 解析は、RFC 3987 の最新の IRI 規則に従って、正規化と文字チェックを実行します。</li><li>Unicode 正規化フォーム C は、URI のホスト部分でのみ実行されます。</li><li>無効な mailto: URI は、例外の原因になります。</li><li>パス セグメントの最後の末尾のドットが保存されるようになりました。</li><li><code>file://</code> URI は <code>?</code> 文字をエスケープしません。</li><li>Unicode 制御文字の <code>U+0080</code> から <code>U+009F</code> まではサポートされません。</li><li>コンマ文字 <code>,</code> または <code>%2c</code> は自動的にエスケープ解除されません。</li></ul>|
+|詳細|.NET Framework 4.5 では、URI 解析がいくつかの点で変更されました。 ただし、これらの変更は .NET Framework 4.5 を対象としたコードのみに影響することに注意してください。 バイナリが .NET Framework 4.0 を対象としている場合、以前の動作が実行されます。 .NET Framework 4.5 での URI 解析の変更は次のとおりです。<ul><li>URI 解析は、RFC 3987 の最新の IRI 規則に従って、正規化と文字チェックを実行します。</li><li>Unicode 正規化フォーム C は、URI のホスト部分でのみ実行されます。</li><li>無効な mailto: URI は、例外の原因になります。</li><li>パス セグメントの最後の末尾のドットが保存されるようになりました。</li><li><code>file://</code> URI は <code>?</code> 文字をエスケープしません。</li><li>Unicode 制御文字の <code>U+0080</code> から <code>U+009F</code> まではサポートされません。</li><li>コンマ文字 <code>,</code> または <code>%2c</code> は自動的にエスケープ解除されません。</li></ul>|
 |提案される解決策|古い .NET Framework 4.0 URI 解析セマンティクスが必要な場合 (めったにありません)、.NET Framework 4.0 を対象とすることによって使用できます。 これは、アセンブリで <xref:System.Runtime.Versioning.TargetFrameworkAttribute?displayProperty=name> を使用することによって、または、[プロジェクトのプロパティ] ページの Visual Studio のプロジェクト システム UI によって実現できます。|
 |スコープ|Major|
 |バージョン|4.5|
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
index c8865c8e669..70ddfb17def 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.5 より、<xref:System.Uri.IsWellFormedUriString(System.String,System.UriKind)> では、最初のセグメントに <code>:</code> を含む相対 URI が形式が正しくないとして処理されます。 これは .NET Framework 4.0 の <xref:System.Uri.IsWellFormedUriString(System.String,System.UriKind)?displayProperty=name> 動作からの変更であり、RFC3986 に準拠する目的で行われました。|
+|詳細|.NET Framework 4.5 より、<xref:System.Uri.IsWellFormedUriString(System.String,System.UriKind)> では、最初のセグメントに <code>:</code> を含む相対 URI が形式が正しくないとして処理されます。 これは .NET Framework 4.0 の <xref:System.Uri.IsWellFormedUriString(System.String,System.UriKind)?displayProperty=name> 動作からの変更であり、RFC3986 に準拠する目的で行われました。|
 |提案される解決策|この変更は (他の多くの URI 変更と同様に) .NET Framework 4.5 (以降) を対象とするアプリケーションにのみ影響を与えます。 以前の動作を維持するには、アプリの対象を .NET Framework 4.0 にします。 あるいは、<xref:System.Uri.IsWellFormedUriString(System.String,System.UriKind)?displayProperty=name> を呼び出す前に URI を調べて <code>:</code> 文字を探し、以前の動作が望ましければそれを削除し、正しい形式として処理させます。|
 |スコープ|マイナー|
 |Version|4.5|
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
index f9d5ce174f5..c92a6a51ddb 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|Entity Framework のバージョンは .NET Framework のバージョンに一致する必要があります。 .NET Framework 4.5 には、Entity Framework 5 をお勧めします。 .NET Framework 4.5 プロジェクトの EF 4.x に <xref:System.ComponentModel.DataAnnotations> に関する既知の問題がいくつかあります。 .NET 4.5 では、別のアセンブリに移動したので、どの注釈を使用するのか判断するという問題があります。|
+|詳細|Entity Framework のバージョンは .NET Framework のバージョンに一致する必要があります。 .NET Framework 4.5 には、Entity Framework 5 をお勧めします。 .NET Framework 4.5 プロジェクトの EF 4.x に <xref:System.ComponentModel.DataAnnotations> に関する既知の問題がいくつかあります。 .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
index 2408a84dd92..0063d1d341b 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|JIT64 Just-In-Time コンパイラとは異なり、(.NET Framework 4.6 で使用される) RyuJIT では、try 領域で IL ret 命令が許可されません。 ECMA-335 仕様により try 領域から戻ることは許可されておらず、そうした IL を生成する既知のマネージド コンパイラはありません。 ただし、JIT64 コンパイラは、リフレクション出力を使用して生成される場合にはこうした IL を実行します。|
+|詳細|JIT64 Just-In-Time コンパイラとは異なり、(.NET Framework 4.6 で使用される) RyuJIT では、try 領域で IL ret 命令が許可されません。 ECMA-335 仕様により try 領域から戻ることは許可されておらず、そうした IL を生成する既知のマネージド コンパイラはありません。 ただし、JIT64 コンパイラは、リフレクション出力を使用して生成される場合にはこうした IL を実行します。|
 |提案される解決策|try 領域に ret オペコードを含む IL をアプリが生成する場合、そのアプリでは .NET Framework 4.5 を対象にして以前の JIT を使用し、この中断を回避できます。 あるいは、try 領域の後に戻るように生成後の IL を更新できます。|
 |スコープ|エッジ|
 |Version|4.6|
diff --git a/includes/migration-guide/retargeting/networking/default-value-servicepointmanagersecurityprotocol.md b/includes/migration-guide/retargeting/networking/default-value-servicepointmanagersecurityprotocol.md
index eacb1055fc8..92913cac273 100644
--- a/includes/migration-guide/retargeting/networking/default-value-servicepointmanagersecurityprotocol.md
+++ b/includes/migration-guide/retargeting/networking/default-value-servicepointmanagersecurityprotocol.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.7 を対象とするアプリから、<xref:System.Net.ServicePointManager.SecurityProtocol?displayProperty=nameWithType> プロパティの既定値が <xref:System.Net.SecurityProtocolType.SystemDefault?displayProperty=nameWithType> になります。 この変更により、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)) を参照してください。</p>以前のバージョンの .NET Framework を対象とするアプリケーションの場合、<xref:System.Net.ServicePointManager.SecurityProtocol?displayProperty=nameWithType> プロパティの既定値は、対象となる .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 を対象とするアプリから、<xref:System.Net.ServicePointManager.SecurityProtocol?displayProperty=nameWithType> プロパティの既定値が <xref:System.Net.SecurityProtocolType.SystemDefault?displayProperty=nameWithType> になります。 この変更により、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)) を参照してください。</p>以前のバージョンの .NET Framework を対象とするアプリケーションの場合、<xref:System.Net.ServicePointManager.SecurityProtocol?displayProperty=nameWithType> プロパティの既定値は、対象となる .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 以降のバージョンを対象とするアプリケーションに影響します。 </br>システム初期設定に依存せず、はっきり定められたプロトコルを使用する場合、<xref:System.Net.ServicePointManager.SecurityProtocol?displayProperty=nameWithType> プロパティの値を明示的に設定できます。</br>この変更が望ましくない場合、アプリケーション構成ファイルの [<runtime>](~/docs/framework/configure-apps/file-schema/runtime/runtime-element.md) セクションに構成設定を追加して、無効にすることができます。 次の例では、<code>&lt;runtime&gt;</code> セクションと無効に切り替える処理 <code>Switch.System.Net.DontEnableSystemDefaultTlsVersions</code> の両方を確認できます。<pre><code class="lang-xml">&lt;runtime&gt;&#13;&#10;&lt;AppContextSwitchOverrides value=&quot;Switch.System.Net.DontEnableSystemDefaultTlsVersions=true&quot; /&gt;&#13;&#10;&lt;/runtime&gt;&#13;&#10;</code></pre>|
 |スコープ|マイナー|
 |Version|4.7|
diff --git a/includes/migration-guide/retargeting/networking/tls-1x-by-default-passes-schsendauxrecord-flag-underlying-schannel-api.md b/includes/migration-guide/retargeting/networking/tls-1x-by-default-passes-schsendauxrecord-flag-underlying-schannel-api.md
index 776f8d94e0c..a0a02da9db8 100644
--- a/includes/migration-guide/retargeting/networking/tls-1x-by-default-passes-schsendauxrecord-flag-underlying-schannel-api.md
+++ b/includes/migration-guide/retargeting/networking/tls-1x-by-default-passes-schsendauxrecord-flag-underlying-schannel-api.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|TLS 1.x を使用するとき、.NET Framework は基になる Windows SCHANNEL API に依存します。 .NET Framework 4.6 以降、[SCH_SEND_AUX_RECORD](https://msdn.microsoft.com/library/windows/desktop/aa379810.aspx) フラグは既定で SCHANNEL に渡されます。 SCHANNEL によって、暗号化するデータが 2 つの別個のレコードに分割されます。1 つ目のレコードはシングル バイトで、2 つ目のレコードは <em>n</em>-1 バイトです。その結果、まれに、データがシングル レコードに置かれていると想定する既存サーバーとクライアントの間の通信が途切れることがあります。|
+|詳細|TLS 1.x を使用するとき、.NET Framework は基になる Windows SCHANNEL API に依存します。 .NET Framework 4.6 以降、[SCH_SEND_AUX_RECORD](https://msdn.microsoft.com/library/windows/desktop/aa379810.aspx) フラグは既定で SCHANNEL に渡されます。 SCHANNEL によって、暗号化するデータが 2 つの別個のレコードに分割されます。1 つ目のレコードはシングル バイトで、2 つ目のレコードは <em>n</em>-1 バイトです。その結果、まれに、データがシングル レコードに置かれていると想定する既存サーバーとクライアントの間の通信が途切れることがあります。|
 |提案される解決策|この変更によって既存サーバーとの接続が途切れる場合、[SCH_SEND_AUX_RECORD](https://msdn.microsoft.com/library/windows/desktop/aa379810.aspx) フラグの送信を無効にし、アプリ構成ファイルの [<runtime>](~/docs/framework/configure-apps/file-schema/runtime/runtime-element.md) セクションで次のスイッチを [<AppContextSwitchOverrides>](~/docs/framework/configure-apps/file-schema/runtime/appcontextswitchoverrides-element.md) 要素に追加することで、データを別個のレコードに分割しない、以前の動作に復元できます。<pre><code class="lang-xml">&lt;runtime&gt;&#13;&#10;&lt;AppContextSwitchOverrides&#13;&#10;value=&quot;Switch.System.Net.DontEnableSchSendAuxRecord=true&quot; /&gt;&#13;&#10;&lt;/runtime&gt;&#13;&#10;</code></pre> <blockquote> [!IMPORTANT] この設定は下位互換性のためにのみ提供されます。 それ以外の目的での使用はお勧めしません。</blockquote> |
 |スコープ|エッジ|
 |Version|4.6|
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
index e52d7864e37..a30d75124c2 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|4.6.2 より前の .NET Framework バージョンでは、RSA 証明書のキー サイズが標準ではない顧客は、拡張メソッドの <xref:System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(System.Security.Cryptography.X509Certificates.X509Certificate2)?displayProperty=name> や <xref:System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(System.Security.Cryptography.X509Certificates.X509Certificate2)?displayProperty=name> でそのキーにアクセスできません。  &quot;The requested key size is not supported (要求されたサイズのキーには対応していません)&quot; というメッセージと共に <xref:System.Security.Cryptography.CryptographicException?displayProperty=name> がスローされます。 .NET Framework 4.6.2 では、この問題が修正されました。 同様に、<xref:System.Security.Cryptography.RSA.ImportParameters(System.Security.Cryptography.RSAParameters)> と <xref:System.Security.Cryptography.RSACng.ImportParameters(System.Security.Cryptography.RSAParameters)> で <xref:System.Security.Cryptography.CryptographicException?displayProperty=name> をスローすることなく非標準サイズのキーが処理されるようになりました。|
+|詳細|4.6.2 より前の .NET Framework バージョンでは、RSA 証明書のキー サイズが標準ではない顧客は、拡張メソッドの <xref:System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey(System.Security.Cryptography.X509Certificates.X509Certificate2)?displayProperty=name> や <xref:System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPrivateKey(System.Security.Cryptography.X509Certificates.X509Certificate2)?displayProperty=name> でそのキーにアクセスできません。  &quot;The requested key size is not supported (要求されたサイズのキーには対応していません)&quot; というメッセージと共に <xref:System.Security.Cryptography.CryptographicException?displayProperty=name> がスローされます。 .NET Framework 4.6.2 では、この問題が修正されました。 同様に、<xref:System.Security.Cryptography.RSA.ImportParameters(System.Security.Cryptography.RSAParameters)> と <xref:System.Security.Cryptography.RSACng.ImportParameters(System.Security.Cryptography.RSAParameters)> で <xref:System.Security.Cryptography.CryptographicException?displayProperty=name> をスローすることなく非標準サイズのキーが処理されるようになりました。|
 |提案される解決策|非標準サイズのキーが使用されるときに <xref:System.Security.Cryptography.CryptographicException?displayProperty=name> がスローされるという以前の動作に依存する例外処理ロジックがある場合、そのロジックを除くことを検討してください。|
 |スコープ|エッジ|
 |Version|4.6.2|
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
index 924dcc73d8f..141e87eba44 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.6.2 より、<xref:System.Security.Cryptography.Xml.SignedXml.GetPublicKey%2A?displayProperty=nameWithType> メソッドによって返されるオブジェクトの具象型が CryptoServiceProvider 実装から Cng 実装に変わりました。これは突然の変更ではなく、 <code>certificate.PublicKey.Key</code> の使用から、<code>certificate.GetAnyPublicKey</code> に転送する内部 <xref:System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey%2A?displayProperty=nameWithType> の使用に実装が変わったためです。|
+|詳細|.NET Framework 4.6.2 より、<xref:System.Security.Cryptography.Xml.SignedXml.GetPublicKey%2A?displayProperty=nameWithType> メソッドによって返されるオブジェクトの具象型が CryptoServiceProvider 実装から Cng 実装に変わりました。これは突然の変更ではなく、 <code>certificate.PublicKey.Key</code> の使用から、<code>certificate.GetAnyPublicKey</code> に転送する内部 <xref:System.Security.Cryptography.X509Certificates.RSACertificateExtensions.GetRSAPublicKey%2A?displayProperty=nameWithType> の使用に実装が変わったためです。|
 |提案される解決策|.NET Framework 4.7.1 で実行されるアプリから、アプリの構成ファイルの [runtime](~/docs/framework/configure-apps/file-schema/runtime/runtime-element.md) セクションに次の構成スイッチを追加することで、.NET Framework 4.6.1 以前のバージョンで既定で使用されていた CryptoServiceProvider 実装を使用できます。<pre><code class="lang-xml">&lt;AppContextSwitchOverrides value=&quot;Switch.System.Security.Cryptography.Xml.SignedXmlUseLegacyCertificatePrivateKey=true&quot; /&gt;&#13;&#10;</code></pre>|
 |スコープ|エッジ|
 |Version|4.6.2|
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
index d129ccaaf1e..e72c5697be7 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|サービスのインスタンスの実行が一度に 1 つのスレッドに制限される再入可能なサービスでは、デッドロックが発生します。 この問題が発生しやすいサービスのコードには、次の <xref:System.ServiceModel.ServiceBehaviorAttribute> が含まれています。<pre><code class="lang-csharp">[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]&#13;&#10;</code></pre>|
+|詳細|サービスのインスタンスの実行が一度に 1 つのスレッドに制限される再入可能なサービスでは、デッドロックが発生します。 この問題が発生しやすいサービスのコードには、次の <xref:System.ServiceModel.ServiceBehaviorAttribute> が含まれています。<pre><code class="lang-csharp">[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]&#13;&#10;</code></pre>|
 |提案される解決策|この問題に対処するために、次の操作を行うことができます。<ul><li>サービスのコンカレンシー モードを <xref:System.ServiceModel.ConcurrencyMode.Single?displayProperty=nameWithType> または &lt;System.ServiceModel.ConcurrencyMode.Multiple?displayProperty=nameWithType&gt; に設定します。 例:</li></ul><pre><code class="lang-csharp">[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)]&#13;&#10;</code></pre><ul><li>最新の更新プログラムを .NET framework 4.6.2 にインストールするか、最新バージョンの .NET Framework にアップグレードします。 これにより、<xref:System.ServiceModel.OperationContext.Current?displayProperty=nameWithType> の <xref:System.Threading.ExecutionContext> のフローが無効になります。 この動作は構成可能です。構成ファイルに次のアプリ設定を追加することと同じです。</li></ul><pre><code class="lang-xml">&lt;appSettings&gt;&#13;&#10;&lt;add key=&quot;Switch.System.ServiceModel.DisableOperationContextAsyncFlow&quot; value=&quot;true&quot; /&gt;&#13;&#10;&lt;/appSettings&gt;&#13;&#10;</code></pre>Rentran サービスの場合、<code>Switch.System.ServiceModel.DisableOperationContextAsyncFlow</code> の値は <code>false</code> に設定しないでください。|
 |スコープ|マイナー|
 |Version|4.6.2|
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
index 95e454fb2b2..db0e3b2bfdc 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|次のすべての条件が満たされている場合は、<xref:System.ServiceModel.OperationContext.Current?displayProperty=nameWithType> が <code>null</code> を返し、<xref:System.NullReferenceException> が発生する可能性があります。<ul><li><xref:System.Threading.Tasks.Task> または <xref:System.Threading.Tasks.Task%601> を返すメソッドで <xref:System.ServiceModel.OperationContext.Current?displayProperty=nameWithType> プロパティの値を取得します。</li><li><code>using</code> 句で <xref:System.ServiceModel.OperationContextScope> オブジェクトをインスタンス化します。</li><li><code>using statement</code> 内で <xref:System.ServiceModel.OperationContext.Current?displayProperty=nameWithType> プロパティの値を取得します。 例:</li></ul><pre><code class="lang-csharp">using (new OperationContextScope(OperationContext.Current))&#13;&#10;{&#13;&#10;OperationContext context = OperationContext.Current;      // OperationContext.Current is null.&#13;&#10;// ...&#13;&#10;}&#13;&#10;</code></pre>|
+|詳細|次のすべての条件が満たされている場合は、<xref:System.ServiceModel.OperationContext.Current?displayProperty=nameWithType> が <code>null</code> を返し、<xref:System.NullReferenceException> が発生する可能性があります。<ul><li><xref:System.Threading.Tasks.Task> または <xref:System.Threading.Tasks.Task%601> を返すメソッドで <xref:System.ServiceModel.OperationContext.Current?displayProperty=nameWithType> プロパティの値を取得します。</li><li><code>using</code> 句で <xref:System.ServiceModel.OperationContextScope> オブジェクトをインスタンス化します。</li><li><code>using statement</code> 内で <xref:System.ServiceModel.OperationContext.Current?displayProperty=nameWithType> プロパティの値を取得します。 例:</li></ul><pre><code class="lang-csharp">using (new OperationContextScope(OperationContext.Current))&#13;&#10;{&#13;&#10;OperationContext context = OperationContext.Current;      // OperationContext.Current is null.&#13;&#10;// ...&#13;&#10;}&#13;&#10;</code></pre>|
 |提案される解決策|この問題に対処するために、次の操作を行うことができます。<ul><li>次のようにコードを変更して、新しい <code>null</code> 以外の <xref:System.ServiceModel.OperationContext.Current%2A> オブジェクトをインスタンス化します。</li></ul><pre><code class="lang-csharp">OperationContext ocx = OperationContext.Current;&#13;&#10;using (new OperationContextScope(OperationContext.Current))&#13;&#10;{&#13;&#10;OperationContext.Current = new OperationContext(ocx.Channel);&#13;&#10;// ...&#13;&#10;}&#13;&#10;</code></pre><ul><li>最新の更新プログラムを .NET framework 4.6.2 にインストールするか、最新バージョンの .NET Framework にアップグレードします。 これにより、<xref:System.ServiceModel.OperationContext.Current?displayProperty=nameWithType> で <xref:System.Threading.ExecutionContext> のフローが無効になり、.NET Framework 4.6.1 以前のバージョンで WCF アプリケーションの動作が復元されます。 この動作は構成可能です。構成ファイルに次のアプリ設定を追加することと同じです。</li></ul><pre><code class="lang-xml">&lt;appSettings&gt;&#13;&#10;&lt;add key=&quot;Switch.System.ServiceModel.DisableOperationContextAsyncFlow&quot; value=&quot;true&quot; /&gt;&#13;&#10;&lt;/appSettings&gt;&#13;&#10;</code></pre>この変更が望ましくなく、アプリケーションが操作コンテキスト間の実行コンテキスト フローに依存している場合は、次のようにそのフローを有効にできます。<pre><code class="lang-xml">&lt;appSettings&gt;&#13;&#10;&lt;add key=&quot;Switch.System.ServiceModel.DisableOperationContextAsyncFlow&quot; value=&quot;false&quot; /&gt;&#13;&#10;&lt;/appSettings&gt;&#13;&#10;</code></pre>|
 |スコープ|エッジ|
 |Version|4.6.2|
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
index ec2c234252f..fb8863323af 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.7 以降、顧客はアプリケーション構成設定を介し、SSL3.0 と TLS1.0 に加え、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 ファイルの <code>&lt;runtime&gt;</code> セクションに次の行を追加することで有効にできます。<pre><code class="lang-xml">&lt;runtime&gt;&#13;&#10;&lt;AppContextSwitchOverrides value=&quot;Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false&quot; /&gt;&#13;&#10;&lt;/runtime&gt;&#13;&#10;</code></pre>|
 |スコープ|エッジ|
 |Version|4.7|
diff --git a/includes/migration-guide/retargeting/wf/avoiding-endless-recursion-for-iworkflowinstancemanagementtransactedcancel.md b/includes/migration-guide/retargeting/wf/avoiding-endless-recursion-for-iworkflowinstancemanagementtransactedcancel.md
index 1d6ac0b2847..68fde06ce38 100644
--- a/includes/migration-guide/retargeting/wf/avoiding-endless-recursion-for-iworkflowinstancemanagementtransactedcancel.md
+++ b/includes/migration-guide/retargeting/wf/avoiding-endless-recursion-for-iworkflowinstancemanagementtransactedcancel.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|<xref:System.ServiceModel.Activities.IWorkflowInstanceManagement.TransactedCancel%2A?displayProperty=nameWithType> または <xref:System.ServiceModel.Activities.IWorkflowInstanceManagement.TransactedTerminate%2A?displayProperty=nameWithType> API を使用してワークフロー サービス インスタンスを取り消すか終了するとき、状況によっては、<code>Workflow</code> ランタイムが要求の処理の一部としてサービス インスタンスの永続化を試みるときの無限再帰のために、ワークフロー インスタンスでスタック オーバーフローが発生する可能性があります。 問題は、別のサービスに対する他の未処理 WCF 要求が完了するのをワークフロー インスタンスが待機している状態の場合に発生します。<code>TransactedCancel</code> および <code>TransactedTerminate</code> 操作は、ワークフロー サービス インスタンスのキューに登録される作業項目を作成します。 これらの作業項目は、<code>TransactedCancel/TransactedTerminate</code> 要求の処理の一部としては実行されません。 ワークフロー サービス インスタンスは他の未処理 WCF 要求が完了するのを待ってビジー状態であるため、作成された作業項目はキューに残ります。 <code>TransactedCancel/TransactedTerminate</code> 操作が完了して、クライアントに制御が返されます。 <code>TransactedCancel/TransactedTerminate</code> 操作に関連付けられているトランザクションは、コミットしようとした場合、ワークフロー サービス インスタンスの状態を永続化する必要があります。 しかし、インスタンスには未処理の <code>WCF</code> 要求があるため、ワークフロー ランタイムはワークフロー サービス インスタンスを永続化できず、無限再帰ループによってスタックがオーバーフローします。<code>TransactedCancel</code> と <code>TransactedTerminate</code> はメモリ内にのみ作業項目を作成するので、トランザクションが存在してもまったく影響ありません。 トランザクションのロールバックは作業項目を破棄しません。この問題に対処するため、.NET Framework 4.7.2 以降では、ワークフロー サービスの <code>web.config/app.config</code> に追加できる <code>AppSetting</code> が導入されています。これは、<code>TransactedCancel</code> および <code>TransactedTerminate</code> のトランザクションを無視するようにサービスに指示します。 これにより、トランザクションはワークフロー インスタンスの永続化を待たずにコミットできます。この機能の AppSetting の名前は <code>microsoft:WorkflowServices:IgnoreTransactionsForTransactedCancelAndTransactedTerminate</code> です。 値 <code>true</code> はトランザクションを無視することを示し、したがってスタック オーバーフローが回避されます。 この AppSetting の既定値は <code>false</code> なので、既存のワークフロー サービス インスタンスに影響はありません。|
+|詳細|<xref:System.ServiceModel.Activities.IWorkflowInstanceManagement.TransactedCancel%2A?displayProperty=nameWithType> または <xref:System.ServiceModel.Activities.IWorkflowInstanceManagement.TransactedTerminate%2A?displayProperty=nameWithType> API を使用してワークフロー サービス インスタンスを取り消すか終了するとき、状況によっては、<code>Workflow</code> ランタイムが要求の処理の一部としてサービス インスタンスの永続化を試みるときの無限再帰のために、ワークフロー インスタンスでスタック オーバーフローが発生する可能性があります。 問題は、別のサービスに対する他の未処理 WCF 要求が完了するのをワークフロー インスタンスが待機している状態の場合に発生します。<code>TransactedCancel</code> および <code>TransactedTerminate</code> 操作は、ワークフロー サービス インスタンスのキューに登録される作業項目を作成します。 これらの作業項目は、<code>TransactedCancel/TransactedTerminate</code> 要求の処理の一部としては実行されません。 ワークフロー サービス インスタンスは他の未処理 WCF 要求が完了するのを待ってビジー状態であるため、作成された作業項目はキューに残ります。 <code>TransactedCancel/TransactedTerminate</code> 操作が完了して、クライアントに制御が返されます。 <code>TransactedCancel/TransactedTerminate</code> 操作に関連付けられているトランザクションは、コミットしようとした場合、ワークフロー サービス インスタンスの状態を永続化する必要があります。 しかし、インスタンスには未処理の <code>WCF</code> 要求があるため、ワークフロー ランタイムはワークフロー サービス インスタンスを永続化できず、無限再帰ループによってスタックがオーバーフローします。<code>TransactedCancel</code> と <code>TransactedTerminate</code> はメモリ内にのみ作業項目を作成するので、トランザクションが存在してもまったく影響ありません。 トランザクションのロールバックは作業項目を破棄しません。この問題に対処するため、.NET Framework 4.7.2 以降では、ワークフロー サービスの <code>web.config/app.config</code> に追加できる <code>AppSetting</code> が導入されています。これは、<code>TransactedCancel</code> および <code>TransactedTerminate</code> のトランザクションを無視するようにサービスに指示します。 これにより、トランザクションはワークフロー インスタンスの永続化を待たずにコミットできます。この機能の AppSetting の名前は <code>microsoft:WorkflowServices:IgnoreTransactionsForTransactedCancelAndTransactedTerminate</code> です。 値 <code>true</code> はトランザクションを無視することを示し、したがってスタック オーバーフローが回避されます。 この AppSetting の既定値は <code>false</code> なので、既存のワークフロー サービス インスタンスに影響はありません。|
 |提案される解決策|AppFabric または別の <xref:System.ServiceModel.Activities.IWorkflowInstanceManagement> クライアントを使っていて、ワークフロー インスタンスを取り消すか終了しようとするとワークフロー サービス インスタンスでスタック オーバーフローが発生する場合は、ワークフロー サービスの web.config/app.config ファイルの <code>&lt;appSettings&gt;</code> セクションに以下を追加できます。<pre><code class="lang-xml">&lt;add key=&quot;microsoft:WorkflowServices:IgnoreTransactionsForTransactedCancelAndTransactedTerminate&quot; value=&quot;true&quot;/&gt;&#13;&#10;</code></pre>この問題が発生しない場合は、これを行う必要はありません。|
 |スコープ|エッジ|
 |Version|4.7.2|
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
index a737c748a35..11ed229c7b4 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.5 では、<xref:System.Action> 型のパラメーターを含む <xref:System.Windows.Threading.Dispatcher.Invoke%2A?displayProperty=nameWithType> に新しいオーバーロードが追加されます。 既存のコードを再コンパイルすると、コンパイラは、<xref:System.Delegate> パラメーターを持つ Dispatcher.Invoke メソッドの呼び出しを、<xref:System.Action> パラメーターを持つ Dispatcher.Invoke メソッドの呼び出しとして解決することができます。 <xref:System.Delegate> パラメーターを持つ Dispatcher.Invoke オーバーロードの呼び出しが <xref:System.Action> パラメーターを持つ Dispatcher.Invoke オーバーロードの呼び出しとして解決された場合、次のような動作の差異が生じることがあります。<ul><li>例外が発生した場合、<xref:System.Windows.Threading.Dispatcher.UnhandledExceptionFilter> イベントと <xref:System.Windows.Threading.Dispatcher.UnhandledException> イベントは発生しません。 代わりに、例外は <xref:System.Threading.Tasks.TaskScheduler.UnobservedTaskException?displayProperty=name> イベントによって処理されます。</li><li><xref:System.Windows.Threading.DispatcherOperation.Result> などの一部のメンバーの呼び出しは、操作が完了するまでブロックされます。</li></ul>|
+|詳細|.NET Framework 4.5 では、<xref:System.Action> 型のパラメーターを含む <xref:System.Windows.Threading.Dispatcher.Invoke%2A?displayProperty=nameWithType> に新しいオーバーロードが追加されます。 既存のコードを再コンパイルすると、コンパイラは、<xref:System.Delegate> パラメーターを持つ Dispatcher.Invoke メソッドの呼び出しを、<xref:System.Action> パラメーターを持つ Dispatcher.Invoke メソッドの呼び出しとして解決することができます。 <xref:System.Delegate> パラメーターを持つ Dispatcher.Invoke オーバーロードの呼び出しが <xref:System.Action> パラメーターを持つ Dispatcher.Invoke オーバーロードの呼び出しとして解決された場合、次のような動作の差異が生じることがあります。<ul><li>例外が発生した場合、<xref:System.Windows.Threading.Dispatcher.UnhandledExceptionFilter> イベントと <xref:System.Windows.Threading.Dispatcher.UnhandledException> イベントは発生しません。 代わりに、例外は <xref:System.Threading.Tasks.TaskScheduler.UnobservedTaskException?displayProperty=name> イベントによって処理されます。</li><li><xref:System.Windows.Threading.DispatcherOperation.Result> などの一部のメンバーの呼び出しは、操作が完了するまでブロックされます。</li></ul>|
 |提案される解決策|あいまいさ (および例外処理またはブロック動作における考えられる相違点) を回避するために、呼び出し元の Dispatcher.Invoke は Invoke 呼び出しの 2 番目のパラメーターとして空の object[] を渡すことで、.NET Framework 4.0 メソッドのオーバーロードに解決されるようにできます。|
 |スコープ|マイナー|
 |Version|4.5|
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
index 754a9135b09..5ea6c54650f 100644
--- a/includes/migration-guide/retargeting/wf/workflow-30-types-are-obsolete.md
+++ b/includes/migration-guide/retargeting/wf/workflow-30-types-are-obsolete.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|Windows Workflow Foundation (WWF) 3.0 API (System.Workflow 名前空間からのもの) は廃止されました。|
+|詳細|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)にあり、詳しいガイダンスは[ここ](https://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/workflowdesignerload-doesnt-remove-symbol-property.md b/includes/migration-guide/retargeting/wf/workflowdesignerload-doesnt-remove-symbol-property.md
index 742b82d3b5d..388ffad4f8d 100644
--- a/includes/migration-guide/retargeting/wf/workflowdesignerload-doesnt-remove-symbol-property.md
+++ b/includes/migration-guide/retargeting/wf/workflowdesignerload-doesnt-remove-symbol-property.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|ワークフロー デザイナーで .NET Framework 4.5 を対象とし、再ホストされた 3.5 ワークフローを <xref:System.Activities.Presentation.WorkflowDesigner.Load> メソッドで読み込むと、ワークフローの保存中に <xref:System.Xaml.XamlDuplicateMemberException?displayProperty=name> がスローされます。|
+|詳細|ワークフロー デザイナーで .NET Framework 4.5 を対象とし、再ホストされた 3.5 ワークフローを <xref:System.Activities.Presentation.WorkflowDesigner.Load> メソッドで読み込むと、ワークフローの保存中に <xref:System.Xaml.XamlDuplicateMemberException?displayProperty=name> がスローされます。|
 |提案される解決策|このバグは、ワークフロー デザイナーで .NET Framework 4.5 を対象とするときにのみ現れるため、<code>WorkflowDesigner.Context.Services.GetService&lt;DesignerConfigurationService&gt;().TargetFrameworkName</code> を 4.0 の .NET Framework に設定することによって回避できます。あるいは、<xref:System.Activities.Presentation.WorkflowDesigner.Load> の代わりに <xref:System.Activities.Presentation.WorkflowDesigner.Load(System.String)> メソッドを使用してワークフローを読み込むことで問題を回避できます。|
 |スコープ|Major|
 |バージョン|4.5|
diff --git a/includes/migration-guide/retargeting/winforms/accessibility-improvements-windows-forms-controls-for-net-472.md b/includes/migration-guide/retargeting/winforms/accessibility-improvements-windows-forms-controls-for-net-472.md
index 227c0261fb2..aeaa2cc6f16 100644
--- a/includes/migration-guide/retargeting/winforms/accessibility-improvements-windows-forms-controls-for-net-472.md
+++ b/includes/migration-guide/retargeting/winforms/accessibility-improvements-windows-forms-controls-for-net-472.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|Windows フォーム フレームワークは、アクセシビリティ テクノロジでの動作の向上により、Windows フォームのお客様のサポートが向上しています。 次のような点が変更されます。<ul><li>ハイ コントラスト モード中の表示が向上する変更。</li><li>DataGridView コントロールと MenuStrip コントロールでのキーボード ナビゲーションが向上する変更。</li><li>ナレーターとのやり取りの変更。</li></ul> | 
+|詳細|Windows フォーム フレームワークは、アクセシビリティ テクノロジでの動作の向上により、Windows フォームのお客様のサポートが向上しています。 次のような点が変更されます。<ul><li>ハイ コントラスト モード中の表示が向上する変更。</li><li>DataGridView コントロールと MenuStrip コントロールでのキーボード ナビゲーションが向上する変更。</li><li>ナレーターとのやり取りの変更。</li></ul> | 
 | 提案される解決策 | <strong>以上の変更を選択する方法と選択しない方法</strong> アプリケーションでこれらの変更を利用するには、.NET Framework 4.7.2 以降で実行する必要があります。 アプリケーションは、次のいずれかの方法でこれらの変更を利用できます。<ul><li>.NET Framework 4.7.2 を対象にして再コンパイルします。 .NET Framework 4.7.2 以降を対象とする Windows フォーム アプリケーションでは、これらのアクセシビリティの変更が既定で有効になります。</li><li>.NET Framework 4.7.1 以前を対象にして、下の例のように、app.config ファイルの <code>&lt;runtime&gt;</code> セクションに次の [AppContext スイッチ](https://docs.microsoft.com/dotnet/framework/configure-apps/file-schema/runtime/appcontextswitchoverrides-element)を追加し、それを <code>false</code> に設定することで、以前のアクセシビリティ動作を無効にします。</li></ul><pre><code class="lang-xml">&lt;?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot;?&gt;&#13;&#10;&lt;configuration&gt;&#13;&#10;&lt;startup&gt;&#13;&#10;&lt;supportedRuntime version=&quot;v4.0&quot; sku=&quot;.NETFramework,Version=v4.7&quot;/&gt;&#13;&#10;&lt;/startup&gt;&#13;&#10;&lt;runtime&gt;&#13;&#10;&lt;!-- AppContextSwitchOverrides value attribute is in the form of &#39;key1=true/false;key2=true/false  --&gt;&#13;&#10;&lt;AppContextSwitchOverrides value=&quot;Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false&quot; /&gt;&#13;&#10;&lt;/runtime&gt;&#13;&#10;&lt;/configuration&gt;&#13;&#10;</code></pre>.NET Framework 4.7.2 で追加されたアクセシビリティ機能にオプトインするには、.NET Framework 4.7.1 のアクセシビリティ機能にもオプトインする必要があることに注意してください。 .NET Framework 4.7.2 以降を対象とするアプリケーションで以前のアクセシビリティ動作を残す場合、この AppContext スイッチを明示的に <code>true</code> に設定することで以前のアクセシビリティ機能を選択できます。<strong>ハイ コントラスト テーマでの OS で定義された色の使用</strong><ul><li><xref:System.Windows.Forms.ToolStripDropDownButton> のドロップダウン矢印が、OS で定義されているハイ コントラスト テーマの色を使うようになりました。</li><li><xref:System.Windows.Forms.ButtonBase.FlatStyle> が <xref:System.Windows.Forms.FlatStyle.Flat?displayProperty=nameWithType> または <xref:System.Windows.Forms.FlatStyle.Popup?displayProperty=nameWithType> に設定された <xref:System.Windows.Forms.Button>、<xref:System.Windows.Forms.RadioButton>、<xref:System.Windows.Forms.CheckBox> コントロールは、ハイ コントラスト テーマが選択されているときは OS で定義された色を使用するようになります。 以前は、テキストと背景の色はコントラストが同じで、見分けるのが困難でした。</li><li><xref:System.Windows.Forms.Control.Enabled> プロパティが <code>false</code> に設定された <xref:System.Windows.Forms.GroupBox> に含まれるコントロールは、OS で定義されているハイ コントラスト テーマの色を使うようになります。</li><li><xref:System.Windows.Forms.ToolStripButton>、<xref:System.Windows.Forms.ToolStripComboBox>、<xref:System.Windows.Forms.ToolStripDropDownButton> コントロールは、ハイ コントラスト モードでの明度コントラストの比率が高くなりました。</li><li><xref:System.Windows.Forms.DataGridViewLinkCell> は <xref:System.Windows.Forms.DataGridViewLinkCell.LinkColor?displayProperty=nameWithType> プロパティに対し OS で定義されているハイ コントラスト テーマの色を既定で使うようになります。</li></ul>注: Windows 10 では、一部のハイ コントラストのシステム カラーの値が変更されています。 Windows フォームのフレームワークは、Win32 フレームワークに基づいています。 最も快適に利用するためには、最新版の Windows で実行し、テスト アプリケーションに app.manifest ファイルを追加して最新の OS 変更を選択し、次のコードのコメントを解除します。<pre><code>&lt;!-- Windows 10 --&gt;&#13;&#10;&lt;supportedOS Id=&quot;{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}&quot; /&gt;&#13;&#10;</code></pre><strong>ナレーター サポートが改善されました</strong><ul><li>ナレーターは、<xref:System.Windows.Forms.ToolStripMenuItem> のテキストを読み上げるときに、<xref:System.Windows.Forms.ToolStripMenuItem.ShortcutKeys?displayProperty=nameWithType> プロパティの値を読み上げるようになります。</li><li><xref:System.Windows.Forms.ToolStripMenuItem> の <xref:System.Windows.Forms.Control.Enabled> プロパティが <code>false</code> に設定されている場合、ナレーターはそれを示すようになります。</li><li>ナレーターは、<xref:System.Windows.Forms.ListView.CheckBoxes?displayProperty=nameWithType> プロパティが <code>true</code> に設定されているとき、チェック ボックスの状態に関するフィードバックを提供するようになります。</li><li>ナレーター スキャン モードのフォーカス順序が、ClickOnce ダウンロード ダイアログ ウィンドウでのコントロールの視覚的な順序と一致するようになります。</li></ul><strong>DataGridView のアクセシビリティ サポートの向上</strong><ul><li><xref:System.Windows.Forms.DataGridView> の行をキーボードを使って並べ替えられるようになります。 ユーザーは、F3 キーを使って現在の列で並べ替えることができます。</li><li><xref:System.Windows.Forms.DataGridView.SelectionMode?displayProperty=nameWithType> が <xref:System.Windows.Forms.DataGridViewSelectionMode.FullRowSelect?displayProperty=nameWithType> に設定されていると、ユーザーが現在の行のセルを Tab で移動するとき、列ヘッダーの色が変わって現在の列を示します。</li><li><xref:System.Windows.Forms.DataGridViewCell.DataGridViewCellAccessibleObject.Parent?displayProperty=nameWithType> プロパティは、正しい親コントロールを返します。</li></ul><strong>視覚的な手掛かりの向上</strong><ul><li><xref:System.Windows.Forms.ButtonBase.Text> プロパティが空の <xref:System.Windows.Forms.RadioButton> および <xref:System.Windows.Forms.CheckBox> コントロールは、フォーカスを受け取るとフォーカス インジケーターを表示するようになりました。</li></ul><strong>強化されたプロパティ グリッドのサポート</strong><ul><li><xref:System.Windows.Forms.PropertyGrid> コントロールの子要素は、PropertyGrid 要素が有効になっている場合にのみ、<xref:System.Windows.Automation.ValuePattern.IsReadOnlyProperty> プロパティに対して <code>true</code> を返すようになりました。</li><li><xref:System.Windows.Forms.PropertyGrid> コントロールの子要素は、PropertyGrid 要素をユーザーが変更できる場合にのみ、<xref:System.Windows.Automation.AutomationElement.IsEnabledProperty> プロパティに対して <code>false</code> を返すようになりました。</li></ul>UI オートメーションの概要については、「[UI オートメーションの概要](https://docs.microsoft.com/dotnet/framework/ui-automation/ui-automation-overview)」を参照してください。<strong>キーボード ナビゲーションの向上</strong><ul><li><xref:System.Windows.Forms.ToolStripButton> は、<xref:System.Windows.Forms.ToolStripPanel.TabStop> プロパティが <code>true</code> に設定された <xref:System.Windows.Forms.ToolStripPanel> 内に含まれているときに、フォーカスできるようになりました</li></ul>|
 |スコープ|Major|
 |Version|4.7.2|
diff --git a/includes/migration-guide/retargeting/winforms/applicationfiltermessage-no-longer-throws-for-re-entrant-implementations.md b/includes/migration-guide/retargeting/winforms/applicationfiltermessage-no-longer-throws-for-re-entrant-implementations.md
index e94feebd39e..bb5619e4e8b 100644
--- a/includes/migration-guide/retargeting/winforms/applicationfiltermessage-no-longer-throws-for-re-entrant-implementations.md
+++ b/includes/migration-guide/retargeting/winforms/applicationfiltermessage-no-longer-throws-for-re-entrant-implementations.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.6.1 以前は、<xref:System.Windows.Forms.Application.AddMessageFilter(System.Windows.Forms.IMessageFilter)?displayProperty=name> または <xref:System.Windows.Forms.Application.RemoveMessageFilter(System.Windows.Forms.IMessageFilter)?displayProperty=name> (さらに <xref:System.Windows.Forms.Application.DoEvents>) を呼び出す<xref:System.Windows.Forms.IMessageFilter.PreFilterMessage(System.Windows.Forms.Message@)> で <xref:System.Windows.Forms.Application.FilterMessage(System.Windows.Forms.Message@)> を呼び出すと、<xref:System.IndexOutOfRangeException?displayProperty=name> が発生していました。<p/>.NET Framework 4.6.1 以降を対象とするアプリケーションでは、この例外がスローされなくなり、上述の再入可能フィルターを使用できます。|
+|詳細|.NET Framework 4.6.1 以前は、<xref:System.Windows.Forms.Application.AddMessageFilter(System.Windows.Forms.IMessageFilter)?displayProperty=name> または <xref:System.Windows.Forms.Application.RemoveMessageFilter(System.Windows.Forms.IMessageFilter)?displayProperty=name> (さらに <xref:System.Windows.Forms.Application.DoEvents>) を呼び出す<xref:System.Windows.Forms.IMessageFilter.PreFilterMessage(System.Windows.Forms.Message@)> で <xref:System.Windows.Forms.Application.FilterMessage(System.Windows.Forms.Message@)> を呼び出すと、<xref:System.IndexOutOfRangeException?displayProperty=name> が発生していました。<p/>.NET Framework 4.6.1 以降を対象とするアプリケーションでは、この例外がスローされなくなり、上述の再入可能フィルターを使用できます。|
 |提案される解決策|上述の再入可能な <xref:System.Windows.Forms.IMessageFilter.PreFilterMessage(System.Windows.Forms.Message@)> の動作に対して <xref:System.Windows.Forms.Application.FilterMessage(System.Windows.Forms.Message@)> はスローされなくなります。 これは、.NET Framework 4.6.1 をターゲットとするアプリケーションにのみ影響します。 .NET Framework 4.6.1 を対象とするアプリは、[DontSupportReentrantFilterMessage](~/docs/framework/migration-guide/mitigation-custom-imessagefilter-prefiltermessage-implementations.md#mitigation) 互換性スイッチを使用することによって、この変更を解除できます (または、以前の Framework をターゲットとしているアプリは、変更を受け入れることができます)。|
 |スコープ|エッジ|
 |Version|4.6.1|
diff --git a/includes/migration-guide/retargeting/winforms/incorrect-implementation-memberdescriptorequals.md b/includes/migration-guide/retargeting/winforms/incorrect-implementation-memberdescriptorequals.md
index e6ae3996f1a..b160c613d03 100644
--- a/includes/migration-guide/retargeting/winforms/incorrect-implementation-memberdescriptorequals.md
+++ b/includes/migration-guide/retargeting/winforms/incorrect-implementation-memberdescriptorequals.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|<xref:System.ComponentModel.MemberDescriptor.Equals%2A?displayProperty=nameWithType> メソッドの元の実装によって、比較対象のオブジェクトからの 2 つの異なる文字列プロパティである、カテゴリ名と説明文字列が比較されます。 この修正は、最初のオブジェクトの <xref:System.ComponentModel.MemberDescriptor.Category> と 2 番目のオブジェクトの <xref:System.ComponentModel.MemberDescriptor.Category> を比較し、最初のオブジェクトの <xref:System.ComponentModel.MemberDescriptor.Description> と 2 番目のオブジェクトの <xref:System.ComponentModel.MemberDescriptor.Description> を比較するものです。|
+|詳細|<xref:System.ComponentModel.MemberDescriptor.Equals%2A?displayProperty=nameWithType> メソッドの元の実装によって、比較対象のオブジェクトからの 2 つの異なる文字列プロパティである、カテゴリ名と説明文字列が比較されます。 この修正は、最初のオブジェクトの <xref:System.ComponentModel.MemberDescriptor.Category> と 2 番目のオブジェクトの <xref:System.ComponentModel.MemberDescriptor.Category> を比較し、最初のオブジェクトの <xref:System.ComponentModel.MemberDescriptor.Description> と 2 番目のオブジェクトの <xref:System.ComponentModel.MemberDescriptor.Description> を比較するものです。|
 |提案される解決策|記述子が等しいときに <code>false</code> を返すことがある <xref:System.ComponentModel.MemberDescriptor.Equals%2A?displayProperty=nameWithType> にアプリケーションが依存しているとき、.NET Framework のバージョン 4.6.2 以降を対象とする場合、いくつかの選択肢があります。<ol><li>コードを変更し、<xref:System.ComponentModel.MemberDescriptor.Equals%2A?displayProperty=nameWithType> メソッドの呼び出しに加え、<xref:System.ComponentModel.MemberDescriptor.Category> フィールドと <xref:System.ComponentModel.MemberDescriptor.Description> フィールドを手動で比較します。</li><li>app.config ファイルに次の値を追加し、この変更を無効にします。</li></ol><pre><code class="lang-xml">&lt;runtime&gt;&#13;&#10;&lt;AppContextSwitchOverrides value=&quot;Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=true&quot; /&gt;&#13;&#10;&lt;/runtime&gt;&#13;&#10;</code></pre>アプリケーションの対象が .NET Framework 4.6.1 以前であるが .NET Framework 4.6.2 以降で実行しているとき、この変更を有効にする場合、app.config ファイルに次の値を追加することで互換性スイッチを <code>false</code> に設定します。<pre><code class="lang-xml">&lt;runtime&gt;&#13;&#10;&lt;AppContextSwitchOverrides value=&quot;Switch.System.MemberDescriptorEqualsReturnsFalseIfEquivalent=false&quot; /&gt;&#13;&#10;&lt;/runtime&gt;&#13;&#10;</code></pre>|
 |スコープ|エッジ|
 |Version|4.6.2|
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
index 7c7d74cf9e0..dec36f96830 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|<code>System.IO.Packaging.PackageDigitalSignatureManager</code> は、WPF パッケージに関連してデジタル署名の機能を提供します。  .NET Framework 4.7 以前のバージョンでは、パッケージのパーツへの署名に使用される既定のアルゴリズム (<xref:System.IO.Packaging.PackageDigitalSignatureManager.DefaultHashAlgorithm?displayProperty=nameWithType>) は SHA1 でした。  最近明らかになった SHA1 のセキュリティに関する懸念事項により、この既定値は .NET Framework 4.7.1 で開始する SHA256 に変更されています。  この変更は、XPS ドキュメントを含むあらゆるパッケージの署名に影響します。|
+|詳細|<code>System.IO.Packaging.PackageDigitalSignatureManager</code> は、WPF パッケージに関連してデジタル署名の機能を提供します。  .NET Framework 4.7 以前のバージョンでは、パッケージのパーツへの署名に使用される既定のアルゴリズム (<xref:System.IO.Packaging.PackageDigitalSignatureManager.DefaultHashAlgorithm?displayProperty=nameWithType>) は SHA1 でした。  最近明らかになった SHA1 のセキュリティに関する懸念事項により、この既定値は .NET Framework 4.7.1 で開始する SHA256 に変更されています。  この変更は、XPS ドキュメントを含むあらゆるパッケージの署名に影響します。|
 |提案される解決策|.NET Framework 4.7.1 より前のフレームワーク バージョンを対象とするときにこの変更を利用する開発者または .NET Framework 4.7.1 以上を対象とするときに以前の機能を必要とする開発者は、次の AppContext フラグを適宜設定することができます。  true の値を設定すると、SHA1 が既定のアルゴリズムとして使用され、false の値を設定すると SHA256 が使用されます。<pre><code class="lang-xml">&lt;configuration&gt;&#13;&#10;&lt;runtime&gt;&#13;&#10;&lt;AppContextSwitchOverrides value=&quot;Switch.MS.Internal.UseSha1AsDefaultHashAlgorithmForDigitalSignatures=true&quot;/&gt;&#13;&#10;&lt;/runtime&gt;&#13;&#10;&lt;/configuration&gt;&#13;&#10;</code></pre>|
 |スコープ|エッジ|
 |Version|4.7.1|
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
index 40d0720e220..afbed6d2f19 100644
--- a/includes/migration-guide/retargeting/wpf/wpf-pointer-based-touch-stack.md
+++ b/includes/migration-guide/retargeting/wpf/wpf-pointer-based-touch-stack.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|この変更で、オプションの WM_POINTER ベースの WPF タッチ/スタイラス スタックを有効にする機能が追加されます。  これを明示的に有効にしていない開発者は、WPF タッチ/スタイラス動作の変更を確認できません。オプションの WM_POINTER ベースのタッチ/スタイラス スタックに関する現在の既知の問題を以下に示します。<ul><li>リアルタイム インクがサポートされない。</li><li>インクと StylusPlugins がまだ機能している間は、UI スレッドで処理されますが、パフォーマンスの低下につながる可能性があります。</li><li>プロモーションの変更により、タッチ/スタイラス イベントからマウス イベントに動作が変更される。</li><li>操作の動作が異なる場合があります。</li><li>ドラッグ/ドロップでは、タッチ入力の適切なフィードバックが表示されません。</li><li>これはスタイラス入力には影響しません。</li><li>ドラッグ/ドロップは、タッチ/スタイラス イベントで開始できなくなりました。</li><li>そのため、マウス入力が検出されるまで、アプリケーションがハングする可能性があります。</li><li>代わりに、開発者はマウス イベントからドラッグ アンド ドロップを開始する必要があります。</li></ul>|
+|詳細|この変更で、オプションの WM_POINTER ベースの WPF タッチ/スタイラス スタックを有効にする機能が追加されます。  これを明示的に有効にしていない開発者は、WPF タッチ/スタイラス動作の変更を確認できません。オプションの WM_POINTER ベースのタッチ/スタイラス スタックに関する現在の既知の問題を以下に示します。<ul><li>リアルタイム インクがサポートされない。</li><li>インクと StylusPlugins がまだ機能している間は、UI スレッドで処理されますが、パフォーマンスの低下につながる可能性があります。</li><li>プロモーションの変更により、タッチ/スタイラス イベントからマウス イベントに動作が変更される。</li><li>操作の動作が異なる場合があります。</li><li>ドラッグ/ドロップでは、タッチ入力の適切なフィードバックが表示されません。</li><li>これはスタイラス入力には影響しません。</li><li>ドラッグ/ドロップは、タッチ/スタイラス イベントで開始できなくなりました。</li><li>そのため、マウス入力が検出されるまで、アプリケーションがハングする可能性があります。</li><li>代わりに、開発者はマウス イベントからドラッグ アンド ドロップを開始する必要があります。</li></ul>|
 |提案される解決策|このスタックを有効にする開発者は、アプリケーションの App.config ファイルに次の行を追加/マージできます。<pre><code class="lang-xml">&lt;configuration&gt;&#13;&#10;&lt;runtime&gt;&#13;&#10;&lt;AppContextSwitchOverrides value=&quot;Switch.System.Windows.Input.Stylus.EnablePointerSupport=true&quot;/&gt;&#13;&#10;&lt;/runtime&gt;&#13;&#10;&lt;/configuration&gt;&#13;&#10;</code></pre>これを削除するか、値を 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
index 94144a9945f..03bd9a82f82 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|場合によっては、データ バインディングの書き込み操作中にプロパティが変更された場合、<xref:System.Windows.Controls.TextBox.Text> プロパティにデータ バインディング プロパティ値の以前の値が反映されることがあります。|
+|詳細|場合によっては、データ バインディングの書き込み操作中にプロパティが変更された場合、<xref:System.Windows.Controls.TextBox.Text> プロパティにデータ バインディング プロパティ値の以前の値が反映されることがあります。|
 |提案される解決策|これによって生じる悪影響はないはずです。 ただし、<xref:System.Windows.FrameworkCompatibilityPreferences.KeepTextBoxDisplaySynchronizedWithTextProperty> プロパティを <code>false</code> に設定して、以前の動作を復元することは可能です。|
 |スコープ|エッジ|
 |Version|4.5|
diff --git a/includes/migration-guide/retargeting/xml/xml-schema-validation-stricter.md b/includes/migration-guide/retargeting/xml/xml-schema-validation-stricter.md
index 10917ec7a99..7ca595ceb54 100644
--- a/includes/migration-guide/retargeting/xml/xml-schema-validation-stricter.md
+++ b/includes/migration-guide/retargeting/xml/xml-schema-validation-stricter.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.5 では、XML スキーマ検証が厳格化されました。 xsd:anyURI を使用して mailto プロトコルなどの URI を検証したときに、URI にスペースが入っていると検証は失敗します。 .NET Framework の以前のバージョンでは、検証は成功していました。 この変更は、.NET Framework 4.5 を対象とするアプリケーションにのみ影響します。|
+|詳細|.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 Framework 4.5 をターゲットにする場合は、無効な URI (およびスペース) が anyURI データ型の属性値として予期されないように、コード レビューを行う必要があります。|
 |スコープ|マイナー|
 |Version|4.5|
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
index d7bcb08e794..0c9b5b338e6 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.6 より前のバージョンには、キーの 1 つが空であった場合、XSD 検証で複合キーの一意制約が検出されないというバグがありました。 .NET Framework 4.6 で、この問題は修正されました。 このため、より正しい検証が行われるようになりますが、以前は検証されていた XML の一部が検証されない可能性もあります。|
+|詳細|.NET Framework 4.6 より前のバージョンには、キーの 1 つが空であった場合、XSD 検証で複合キーの一意制約が検出されないというバグがありました。 .NET Framework 4.6 で、この問題は修正されました。 このため、より正しい検証が行われるようになりますが、以前は検証されていた XML の一部が検証されない可能性もあります。|
 |提案される解決策|より緩やかな .NET Framework 4.0 の検証が必要な場合、検証アプリケーションはバージョン 4.5 (またはそれ以前) の .NET Framework をターゲットにできます。 ただし、.NET Framework 4.6 に再ターゲットするときには、コード レビューを行って、重複する複合キー (この問題の説明で述べられているように) の検証を予期していないことを確認する必要があります。|
 |スコープ|エッジ|
 |Version|4.6|
diff --git a/includes/migration-guide/runtime/asp/httprequestcontentencoding-property-prohibits-utf7.md b/includes/migration-guide/runtime/asp/httprequestcontentencoding-property-prohibits-utf7.md
index 50fec1a78cd..e4305a6ade1 100644
--- a/includes/migration-guide/runtime/asp/httprequestcontentencoding-property-prohibits-utf7.md
+++ b/includes/migration-guide/runtime/asp/httprequestcontentencoding-property-prohibits-utf7.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.5 以降では、<xref:System.Web.HttpRequest?displayProperty=name> の本文では UTF-7 エンコードが禁止されます。 UTF-7 データの受信を必要とするアプリケーションのデータが、正しくデコードされない場合があります。|
+|詳細|.NET Framework 4.5 以降では、<xref:System.Web.HttpRequest?displayProperty=name> の本文では UTF-7 エンコードが禁止されます。 UTF-7 データの受信を必要とするアプリケーションのデータが、正しくデコードされない場合があります。|
 |提案される解決策|理想的には、<xref:System.Web.HttpRequest?displayProperty=name> で UTF-7 エンコードを使用しないようにアプリケーションを更新する必要があります。 または、 [<appSettings>](https://msdn.microsoft.com/library/hh975440(v=vs.110).aspx) 要素の <code>aspnet:AllowUtf7RequestContentEncoding</code> 属性を使用して、レガシ動作に戻すことができます。|
 |スコープ|エッジ|
 |Version|4.5|
diff --git a/includes/migration-guide/runtime/asp/httputilityjavascriptstringencode-escapes-ampersand.md b/includes/migration-guide/runtime/asp/httputilityjavascriptstringencode-escapes-ampersand.md
index 722a76d5fe8..87737679b55 100644
--- a/includes/migration-guide/runtime/asp/httputilityjavascriptstringencode-escapes-ampersand.md
+++ b/includes/migration-guide/runtime/asp/httputilityjavascriptstringencode-escapes-ampersand.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.5 以降では、<xref:System.Web.HttpUtility.JavaScriptStringEncode(System.String)?displayProperty=name> でアンパサンド (&amp;) 文字がエスケープされます。|
+|詳細|.NET Framework 4.5 以降では、<xref:System.Web.HttpUtility.JavaScriptStringEncode(System.String)?displayProperty=name> でアンパサンド (&amp;) 文字がエスケープされます。|
 |提案される解決策|アプリがこのメソッドの以前の動作に依存している場合、構成ファイルの [ASP.NET appSettings 要素](https://msdn.microsoft.com/library/hh975440.aspx) に aspnet:JavaScriptDoNotEncodeAmpersand 設定を追加できます。|
 |スコープ|マイナー|
 |Version|4.5|
diff --git a/includes/migration-guide/runtime/core/allow-unicode-uris-that-resemble-unc-shares.md b/includes/migration-guide/runtime/core/allow-unicode-uris-that-resemble-unc-shares.md
index 6d600dd61ac..33d3fda8604 100644
--- a/includes/migration-guide/runtime/core/allow-unicode-uris-that-resemble-unc-shares.md
+++ b/includes/migration-guide/runtime/core/allow-unicode-uris-that-resemble-unc-shares.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|<xref:System.Uri?displayProperty=fullName> では、UNC 共有名と Unicode 文字の両方を含むファイル URI の構築時に、URI が無効な内部状態にならなくなります。 以下のすべてに該当する場合にのみ、動作が変わります。<ul><li>URI にスキーム <code>file:</code> があり、4 つ以上のスラッシュが続く。</li><li>ホスト名がアンダースコアまたはその他の予約されていないシンボルで始まる。</li><li>URI に Unicode 文字が含まれている。</li></ul>|
+|詳細|<xref:System.Uri?displayProperty=fullName> では、UNC 共有名と Unicode 文字の両方を含むファイル URI の構築時に、URI が無効な内部状態にならなくなります。 以下のすべてに該当する場合にのみ、動作が変わります。<ul><li>URI にスキーム <code>file:</code> があり、4 つ以上のスラッシュが続く。</li><li>ホスト名がアンダースコアまたはその他の予約されていないシンボルで始まる。</li><li>URI に Unicode 文字が含まれている。</li></ul>|
 |提案される解決策|Unicode を含む URI を一貫して操作するアプリケーションでこの動作を使用して、UNC 共有への参照を許可しないようにした可能性があります。 これらのアプリケーションでは代わりに <xref:System.Uri.IsUnc> を使用する必要があります。|
 |スコープ|エッジ|
 |Version|4.7.2|
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
index c2cf7667acc..59b77204f3a 100644
--- a/includes/migration-guide/runtime/core/appdomainsetupdynamicbase-no-longer-randomized-by.md
+++ b/includes/migration-guide/runtime/core/appdomainsetupdynamicbase-no-longer-randomized-by.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.6 より前では、UseRandomizedStringHashAlgorithm がアプリの構成ファイルで有効になっている場合、<xref:System.AppDomainSetup.DynamicBase> の値がアプリケーション ドメイン間、またはプロセス間でランダム化されます。 .NET Framework 4.6 以降では、<xref:System.AppDomainSetup.DynamicBase> は実行されているアプリの異なるインスタンス間、および異なるアプリ ドメイン間で安定した結果を返します。 それでも動的ベースはアプリによって異なります。この変更では、同じアプリの異なるインスタンスのランダムな名前付け要素のみが削除されます。|
+|詳細|.NET Framework 4.6 より前では、UseRandomizedStringHashAlgorithm がアプリの構成ファイルで有効になっている場合、<xref:System.AppDomainSetup.DynamicBase> の値がアプリケーション ドメイン間、またはプロセス間でランダム化されます。 .NET Framework 4.6 以降では、<xref:System.AppDomainSetup.DynamicBase> は実行されているアプリの異なるインスタンス間、および異なるアプリ ドメイン間で安定した結果を返します。 それでも動的ベースはアプリによって異なります。この変更では、同じアプリの異なるインスタンスのランダムな名前付け要素のみが削除されます。|
 |提案される解決策|<code>UseRandomizedStringHashAlgorithm</code> を有効にすると、<xref:System.AppDomainSetup.DynamicBase> がランダム化されなくなることに注意してください。 ランダム ベースが必要な場合は、この API を使用するのではなく、アプリのコードで生成する必要があります。|
 |スコープ|エッジ|
 |Version|4.6|
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
index a5f6cf493f1..a6a99076415 100644
--- a/includes/migration-guide/runtime/core/blockingcollectionlttgttrytakefromany-does-not-throw-anymore.md
+++ b/includes/migration-guide/runtime/core/blockingcollectionlttgttrytakefromany-does-not-throw-anymore.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|入力コレクションの 1 つに完了のマークが付けられた場合、<xref:System.Collections.Concurrent.BlockingCollection%601.TryTakeFromAny(System.Collections.Concurrent.BlockingCollection{%600}[],%600@)> -1 を返さず、<xref:System.Collections.Concurrent.BlockingCollection%601.TakeFromAny(System.Collections.Concurrent.BlockingCollection{%600}[],%600@)>例外をスローしなくなりました。 この変更の結果、コレクションの 1 つが空であったり完了していても、他のコレクションに取得できる項目がある場合にコレクションで作業をすることができるようになりました。|
+|詳細|入力コレクションの 1 つに完了のマークが付けられた場合、<xref:System.Collections.Concurrent.BlockingCollection%601.TryTakeFromAny(System.Collections.Concurrent.BlockingCollection{%600}[],%600@)> -1 を返さず、<xref:System.Collections.Concurrent.BlockingCollection%601.TakeFromAny(System.Collections.Concurrent.BlockingCollection{%600}[],%600@)>例外をスローしなくなりました。 この変更の結果、コレクションの 1 つが空であったり完了していても、他のコレクションに取得できる項目がある場合にコレクションで作業をすることができるようになりました。|
 |提案される解決策|-1 を返す TryTakeFromAny またはスローする TakeFromAny が制御フロー目的で使用されていた場合、ブロッキング コレクションが完了する場合、そのようなコードは、その条件を検出するように <code>.Any(b =&gt; b.IsCompleted)</code> を使用するように変更される必要があります。|
 |スコープ|マイナー|
 |Version|4.5|
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
index e051e4f3070..8df8bfb62f7 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|新しい CodeDOM の機能を使用すると、mscorlib.dll の .NET Framework 4.5 バージョンではなく、mscorlib.dll の対象バージョンに対してコンパイルできるようになります。|
+|詳細|新しい CodeDOM の機能を使用すると、mscorlib.dll の .NET Framework 4.5 バージョンではなく、mscorlib.dll の対象バージョンに対してコンパイルできるようになります。|
 |スコープ|エッジ|
 |Version|4.5|
 |型|ランタイム|
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
index 196e302b8cc..12b45416a85 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|空白のキーワード マスクを持つ ETW EventListeners は、明示的なキーワードを持つプロバイダーからのイベントを正しくキャプチャしません。 .NET Framework 4.5 では、TPL プロバイダーは、明示的なキーワードを提供するようになり、この問題が発生しました。 .NET Framework 4.6 では、EventListeners が更新され、この問題は修正されました。|
+|詳細|空白のキーワード マスクを持つ ETW EventListeners は、明示的なキーワードを持つプロバイダーからのイベントを正しくキャプチャしません。 .NET Framework 4.5 では、TPL プロバイダーは、明示的なキーワードを提供するようになり、この問題が発生しました。 .NET Framework 4.6 では、EventListeners が更新され、この問題は修正されました。|
 |提案される解決策|この問題を回避するには、<xref:System.Diagnostics.Tracing.EventListener.EnableEvents(System.Diagnostics.Tracing.EventSource,System.Diagnostics.Tracing.EventLevel)> の呼び出しを、使用する &quot;任意のキーワード&quot; マスクを明示的に指定する EnableEvents オーバーロード (<code>EnableEvents(eventSource, level, unchecked((EventKeywords)0xFFFFffffFFFFffff))</code>) の呼び出しに置換します。または、この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。|
 |スコープ|エッジ|
 |Version|4.5|
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
index 8e78d743ebe..cfbae139ba0 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|リフレクション オブジェクトはマネージド コードからアウト プロセス DCOM クライアントに渡されなくなりました。 影響を受ける型は次のとおりです。<ul><li><xref:System.Reflection.Assembly?displayProperty=name></li><li><xref:System.Reflection.MemberInfo?displayProperty=name> (およびその派生型、<xref:System.Reflection.FieldInfo?displayProperty=name>、<xref:System.Reflection.MethodInfo?displayProperty=name>、<xref:System.Type?displayProperty=name>、<xref:System.Reflection.TypeInfo?displayProperty=name> など)</li><li><xref:System.Reflection.MethodBody?displayProperty=name></li><li><xref:System.Reflection.Module?displayProperty=name></li><li><xref:System.Reflection.ParameterInfo?displayProperty=name>。</li></ul>オブジェクトの <code>IMarshal</code> の呼び出しは <code>E_NOINTERFACE</code> を返します。|
+|詳細|リフレクション オブジェクトはマネージド コードからアウト プロセス DCOM クライアントに渡されなくなりました。 影響を受ける型は次のとおりです。<ul><li><xref:System.Reflection.Assembly?displayProperty=name></li><li><xref:System.Reflection.MemberInfo?displayProperty=name> (およびその派生型、<xref:System.Reflection.FieldInfo?displayProperty=name>、<xref:System.Reflection.MethodInfo?displayProperty=name>、<xref:System.Type?displayProperty=name>、<xref:System.Reflection.TypeInfo?displayProperty=name> など)</li><li><xref:System.Reflection.MethodBody?displayProperty=name></li><li><xref:System.Reflection.Module?displayProperty=name></li><li><xref:System.Reflection.ParameterInfo?displayProperty=name>。</li></ul>オブジェクトの <code>IMarshal</code> の呼び出しは <code>E_NOINTERFACE</code> を返します。|
 |提案される解決策|非リフレクション オブジェクトで動作するように、マーシャリング コードを更新します。|
 |スコープ|マイナー|
 |Version|4.6|
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
index 31dd618e58c..f34c4417f75 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|<xref:System.Threading.Tasks.Task.System%23IAsyncResult%23AsyncWaitHandle>を除き、<xref:System.Threading.Tasks.Task?displayProperty=name> メソッドでオブジェクトが破棄された後も <xref:System.ObjectDisposedException?displayProperty=name> の例外がスローされることがなくなりました。この変更により、キャッシュされたタスクを使用できるようになりました。 たとえば、メソッドで新しいタスクを割り当てる代わりに、既に完了した操作を表す、キャッシュされたタスクを返すことができます。 これは、タスクの任意のコンシューマーによって破棄されてしまうと、使用不可能になってしまう以前の .NET Framework のバージョンでは不可能でした。|
+|詳細|<xref:System.Threading.Tasks.Task.System%23IAsyncResult%23AsyncWaitHandle>を除き、<xref:System.Threading.Tasks.Task?displayProperty=name> メソッドでオブジェクトが破棄された後も <xref:System.ObjectDisposedException?displayProperty=name> の例外がスローされることがなくなりました。この変更により、キャッシュされたタスクを使用できるようになりました。 たとえば、メソッドで新しいタスクを割り当てる代わりに、既に完了した操作を表す、キャッシュされたタスクを返すことができます。 これは、タスクの任意のコンシューマーによって破棄されてしまうと、使用不可能になってしまう以前の .NET Framework のバージョンでは不可能でした。|
 |提案される解決策|オブジェクトが破棄されたとき、Task メソッドが <xref:System.ObjectDisposedException?displayProperty=name> をスローしなくなったことに注意してください。 アプリが、タスクが破棄されたことを確認するために、この例外に依存していた場合は、<xref:System.Threading.Tasks.Task.Status> を使用してタスクのステータスを明示的に確認するように、アプリを更新する必要があります。|
 |スコープ|マイナー|
 |Version|4.5|
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
index 76bed8f9823..00f42503f30 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|<xref:System.AppDomainSetup.TargetFrameworkName?displayProperty=name> は、以前は、明示的に設定されない限り、既定のアプリケーション ドメインでは null でした。 4.6 以降では、既定のアプリケーション ドメインの <xref:System.AppDomainSetup.TargetFrameworkName?displayProperty=name> プロパティは、TargetFrameworkAttribute (ある場合) から派生された既定値を持ちます。 既定以外のアプリケーション ドメインは、明示的にオーバーライドされない限り、既定のアプリケーション ドメイン (4.6 では既定で null に設定されない) から <xref:System.AppDomainSetup.TargetFrameworkName?displayProperty=name> を継承し続けます。|
+|詳細|<xref:System.AppDomainSetup.TargetFrameworkName?displayProperty=name> は、以前は、明示的に設定されない限り、既定のアプリケーション ドメインでは null でした。 4.6 以降では、既定のアプリケーション ドメインの <xref:System.AppDomainSetup.TargetFrameworkName?displayProperty=name> プロパティは、TargetFrameworkAttribute (ある場合) から派生された既定値を持ちます。 既定以外のアプリケーション ドメインは、明示的にオーバーライドされない限り、既定のアプリケーション ドメイン (4.6 では既定で null に設定されない) から <xref:System.AppDomainSetup.TargetFrameworkName?displayProperty=name> を継承し続けます。|
 |提案される解決策|<xref:System.AppDomainSetup.TargetFrameworkName> が既定で null に設定されることに依然しないように、コードを更新する必要があります。 このプロパティが引き続き null として評価される必要がある場合、明示的にその値に設定できます。|
 |スコープ|エッジ|
 |Version|4.6|
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
index e68c3bab8f7..aa457236a79 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|<xref:System.Data.SqlClient.SqlConnection.Open> および <xref:System.Data.SqlClient.SqlConnection.OpenAsync(System.Threading.CancellationToken)> は、コンピューター上に IFS 以外の Winsock BSP または LSP が存在する Windows 7 コンピューターで実行している場合、.NET Framework 4.5 では失敗します。IFS 以外の BSP または LSP がインストールされているかどうかを確認するには、<code>netsh WinSock Show Catalog</code> コマンドを使用して、返される <code>Winsock Catalog Provider Entry</code> 項目をすべて調べてください。 Service Flags 値の <code>0x20000</code> ビットがセットされている場合、プロバイダーは IFS ハンドルを使用していて、正しく機能します。 <code>0x20000</code> ビットがクリアされている (セットされていない) 場合は、IFS 以外の BSP または LSP です。|
+|詳細|<xref:System.Data.SqlClient.SqlConnection.Open> および <xref:System.Data.SqlClient.SqlConnection.OpenAsync(System.Threading.CancellationToken)> は、コンピューター上に IFS 以外の Winsock BSP または LSP が存在する Windows 7 コンピューターで実行している場合、.NET Framework 4.5 では失敗します。IFS 以外の BSP または LSP がインストールされているかどうかを確認するには、<code>netsh WinSock Show Catalog</code> コマンドを使用して、返される <code>Winsock Catalog Provider Entry</code> 項目をすべて調べてください。 Service Flags 値の <code>0x20000</code> ビットがセットされている場合、プロバイダーは IFS ハンドルを使用していて、正しく機能します。 <code>0x20000</code> ビットがクリアされている (セットされていない) 場合は、IFS 以外の BSP または LSP です。|
 |提案される解決策|このバグは .NET framework 4.5.2 で修正されたため、.NET Framework をアップグレードすることによって回避できます。 または、インストールされている IFS 以外の Winsock LSP を削除することによって回避できます。|
 |スコープ|マイナー|
 |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
index 14576b70c46..4569e1ca5a8 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|AttachDBFilename が指定されたときの DDL API の動作が、次のように変更されました。<ul><li>接続文字列で初期カタログ値を指定する必要がなくなりました。 以前は、AttachDBFilename と初期カタログの両方が必要でした。</li><li>AttachDBFilename と初期カタログの両方が指定され、指定された MDF ファイルが存在した場合、<xref:System.Data.Objects.ObjectContext.DatabaseExists%2A> メソッドは <code>true</code> を返します。 以前は、<code>false</code>が返されていました。</li><li>AttachDBFilename と初期カタログの両方が指定され、指定された MDF ファイルが存在した場合、<xref:System.Data.Objects.ObjectContext.DeleteDatabase%2A> メソッドを呼び出すと、ファイルが削除されます。</li><li>接続文字列で存在しない MDF の AttachDBFilename 値および存在しない初期カタログが指定されたときに <xref:System.Data.Objects.ObjectContext.DeleteDatabase%2A> が呼び出されると、メソッドでは <xref:System.InvalidOperationException> 例外がスローされます。 以前は、<xref:System.Data.SqlClient.SqlException> の例外がスローされていました。</li></ul>|
+|詳細|AttachDBFilename が指定されたときの DDL API の動作が、次のように変更されました。<ul><li>接続文字列で初期カタログ値を指定する必要がなくなりました。 以前は、AttachDBFilename と初期カタログの両方が必要でした。</li><li>AttachDBFilename と初期カタログの両方が指定され、指定された MDF ファイルが存在した場合、<xref:System.Data.Objects.ObjectContext.DatabaseExists%2A> メソッドは <code>true</code> を返します。 以前は、<code>false</code>が返されていました。</li><li>AttachDBFilename と初期カタログの両方が指定され、指定された MDF ファイルが存在した場合、<xref:System.Data.Objects.ObjectContext.DeleteDatabase%2A> メソッドを呼び出すと、ファイルが削除されます。</li><li>接続文字列で存在しない MDF の AttachDBFilename 値および存在しない初期カタログが指定されたときに <xref:System.Data.Objects.ObjectContext.DeleteDatabase%2A> が呼び出されると、メソッドでは <xref:System.InvalidOperationException> 例外がスローされます。 以前は、<xref:System.Data.SqlClient.SqlException> の例外がスローされていました。</li></ul>|
 |提案される解決策|これらの変更により、DDL API を使用するアプリケーションおよびツールの構築が簡単になりました。 これらの変更は、次のシナリオでアプリケーションの互換性に影響を及ぼす可能性があります。<ul><li><code>DROP DATABASE</code> で <xref:System.Data.Objects.ObjectContext.DeleteDatabase%2A> が返されたときに、<xref:System.Data.Objects.ObjectContext.DatabaseExists%2A> を呼び出す代わりに直接 <code>true</code> コマンドを実行するコードをユーザーが作成した場合。 データベースがアタッチされておらず、MDF ファイルが存在する場合、これによって既存のコードが破損します。</li><li>初期カタログと MDF ファイルが存在しない場合に、<xref:System.InvalidOperationException> ではなく <xref:System.Data.SqlClient.SqlException> をスローするように、<xref:System.Data.Objects.ObjectContext.DeleteDatabase%2A> メソッドを要求するコードをユーザーが作成した場合。</li></ul>|
 |スコープ|マイナー|
 |Version|4.5|
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
index f04c0dd935d..6b785951c0e 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|クエリの一部として関連エンティティを含めようとする 0..1 ナビゲーション プロパティを使用して QueryViews に関係するクエリをアプリが実行する場合、Entity Framework で <xref:System.StackOverflowException?displayProperty=name> 例外がスローされなくなりました。 たとえば、<code>.Include(e =&gt; e.RelatedNavProp)</code> を呼び出す場合です。|
+|詳細|クエリの一部として関連エンティティを含めようとする 0..1 ナビゲーション プロパティを使用して QueryViews に関係するクエリをアプリが実行する場合、Entity Framework で <xref:System.StackOverflowException?displayProperty=name> 例外がスローされなくなりました。 たとえば、<code>.Include(e =&gt; e.RelatedNavProp)</code> を呼び出す場合です。|
 |提案される解決策|この変更は、.Include を呼び出すクエリの実行時に 1 - 0..1 の関係にある QueryViews を使用するコードにのみ影響します。 これにより信頼性が向上し、ほとんどすべてのアプリに対して透過的になります。 ただし、予期しない動作が発生する場合、次のエントリをアプリの構成ファイルの <code>&lt;appSettings&gt;</code> セクションに追加することにより、この変更を無効にできます。<pre><code class="lang-xml">&lt;add key=&quot;EntityFramework_SimplifyUserSpecifiedViews&quot; value=&quot;false&quot; /&gt;&#13;&#10;</code></pre>|
 |スコープ|エッジ|
 |Version|4.5.2|
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
index 74530f5003b..f224c173d55 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.7 で変更が導入されたため、.NET Framework 4.7 で実行されているアプリケーションの JIT コンパイラによって生成されたコードが 2 つの <code>T:System.UInt16</code> 値を正しく比較しない場合があります。 詳細については、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 で変更が導入されたため、.NET Framework 4.7 で実行されているアプリケーションの JIT コンパイラによって生成されたコードが 2 つの <code>T:System.UInt16</code> 値を正しく比較しない場合があります。 詳細については、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/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
index b0ea75abd02..a6173fdfd31 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.5 以降では、MEF カタログは IEnumerable を実装するため、シリアライザー (<xref:System.Xml.Serialization.XmlSerializer?displayProperty=name> オブジェクト) の作成には使用できなくなりました。 MEF カタログをシリアル化しようとすると、例外がスローされます。|
+|詳細|.NET Framework 4.5 以降では、MEF カタログは IEnumerable を実装するため、シリアライザー (<xref:System.Xml.Serialization.XmlSerializer?displayProperty=name> オブジェクト) の作成には使用できなくなりました。 MEF カタログをシリアル化しようとすると、例外がスローされます。|
 |提案される解決策|シリアライザーの作成に MEF を使用できなくなりました。|
 |スコープ|Major|
 |バージョン|4.5|
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
index 1cd5b99f8e2..3ded1bb75c5 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.5 以降では、<xref:System.Web.Mail.MailMessage> オブジェクトに非 ASCII 文字を含めることができます。 .NET Framework 4 では、ASCII 文字しかサポートされていません。 非 ASCII 文字が含まれ、.NET Framework 4.5 以降でシリアル化された <xref:System.Web.Mail.MailMessage> オブジェクトは、.NET Framework 4 で逆シリアル化することはできません。|
+|詳細|.NET Framework 4.5 以降では、<xref:System.Web.Mail.MailMessage> オブジェクトに非 ASCII 文字を含めることができます。 .NET Framework 4 では、ASCII 文字しかサポートされていません。 非 ASCII 文字が含まれ、.NET Framework 4.5 以降でシリアル化された <xref:System.Web.Mail.MailMessage> オブジェクトは、.NET Framework 4 で逆シリアル化することはできません。|
 |提案される解決策|<xref:System.Web.Mail.MailMessage> オブジェクトの逆シリアル化時に、コードで例外処理が提供されることを確認します。|
 |スコープ|マイナー|
 |Version|4.5|
diff --git a/includes/migration-guide/runtime/runtime/improved-wcf-chain-trust-certificate-validation-for-nettcp-authentication.md b/includes/migration-guide/runtime/runtime/improved-wcf-chain-trust-certificate-validation-for-nettcp-authentication.md
index d48d9283b03..664abf02765 100644
--- a/includes/migration-guide/runtime/runtime/improved-wcf-chain-trust-certificate-validation-for-nettcp-authentication.md
+++ b/includes/migration-guide/runtime/runtime/improved-wcf-chain-trust-certificate-validation-for-nettcp-authentication.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.7.2 では、WCF とのトランスポート セキュリティで証明書認証を使用するときのチェーン信頼証明書の検証が向上しています。 この改善により、サーバーに対する認証に使用されるクライアント証明書を、クライアント認証用に構成する必要があります。  同様に、サーバーを認証するためのサーバー証明書は、サーバー認証用に構成する必要があります。 この変更では、ルート証明書が無効になっている場合、証明書チェーンの検証が失敗します。 同じ変更が、Windows セキュリティ ロールアップによって .NET Framework 3.5 以降のバージョンにも行われました。 詳細については、[こちら](https://support.microsoft.com/en-us/help/4055269/security-only-update-for-net-framework-3-5-1-4-5-2-4-6-4-6-1-4-6-2-4-7)をご覧ください。この変更は既定で有効になり、構成設定によって無効にできます。|
+|詳細|.NET Framework 4.7.2 では、WCF とのトランスポート セキュリティで証明書認証を使用するときのチェーン信頼証明書の検証が向上しています。 この改善により、サーバーに対する認証に使用されるクライアント証明書を、クライアント認証用に構成する必要があります。  同様に、サーバーを認証するためのサーバー証明書は、サーバー認証用に構成する必要があります。 この変更では、ルート証明書が無効になっている場合、証明書チェーンの検証が失敗します。 同じ変更が、Windows セキュリティ ロールアップによって .NET Framework 3.5 以降のバージョンにも行われました。 詳細については、[こちら](https://support.microsoft.com/en-us/help/4055269/security-only-update-for-net-framework-3-5-1-4-5-2-4-6-4-6-1-4-6-2-4-7)をご覧ください。この変更は既定で有効になり、構成設定によって無効にできます。|
 |提案される解決策|<ul><li>サーバー証明書とクライアント証明書に必要な EKU OID があるかどうかを確認します。 ない場合は、証明書を更新します。</li><li>ルート証明書が無効かどうかを確認します。 無効である場合は、ルート証明書を更新します。</li><li>変更をオプトアウトする方法: 証明書を更新できない場合は、次の構成設定により互換性に影響する変更を一時的に回避できます。ただし、変更をオプトアウトすると、システムはセキュリティの問題に対して脆弱なままになります。</li></ul><pre><code class="lang-xml">&lt;appSettings&gt;&#13;&#10;&lt;add key=&quot;wcf:useLegacyCertificateUsagePolicy&quot; value=&quot;true&quot; /&gt;&#13;&#10;&lt;/appSettings&gt;&#13;&#10;</code></pre>|
 |スコープ|マイナー|
 |Version|4.7.2|
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
index 221d52e4b9c..1dfb07fcaa7 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|予想されるように、.NET Framework 4.6 に対してレジストリ (<code>HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full</code>) に設定されるバージョン キーは、"4.5" ではなく "4.6" で始まります。 これらのレジストリ キーに依存してコンピューターにインストールされている .NET Framework のバージョンを特定するアプリは、4.6 が可能な新しいバージョンであり、前の 4.5.x リリースと互換性があることを認識するように、更新する必要があります。|
+|詳細|予想されるように、.NET Framework 4.6 に対してレジストリ (<code>HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full</code>) に設定されるバージョン キーは、"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/wcf/systemservicemodelwebwebservicehost-object-no-longer-adds-default-endpoint.md b/includes/migration-guide/runtime/wcf/systemservicemodelwebwebservicehost-object-no-longer-adds-default-endpoint.md
index ff0a9897054..7e751a14b91 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|<xref:System.ServiceModel.Web.WebServiceHost> オブジェクトでは、アプリケーション コードによって明示的なエンドポイントが追加された場合に、既定のエンドポイントが追加されなくなりました。|
+|詳細|<xref:System.ServiceModel.Web.WebServiceHost> オブジェクトでは、アプリケーション コードによって明示的なエンドポイントが追加された場合に、既定のエンドポイントが追加されなくなりました。|
 |提案される解決策|ユーザーが既定のエンドポイントに接続できることを期待していて、他の明示的なエンドポイントが <xref:System.ServiceModel.Web.WebServiceHost?displayProperty=name> に追加されている場合は、既定のエンドポイントも明示的に追加する必要があります (<xref:System.ServiceModel.ServiceHostBase.AddDefaultEndpoints?displayProperty=name> を使用して)。|
 |スコープ|マイナー|
 |Version|4.5|
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
index 6064c090e4c..900c0578368 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.7.1 以降では、要素のいずれかが <code>null</code> の場合、<xref:System.ServiceModel.Channels.AddressHeaderCollection.%23ctor(System.Collections.Generic.IEnumerable{System.ServiceModel.Channels.AddressHeader})> コンストラクターで <xref:System.ArgumentException> がスローされます。 .NET Framework 4.7 以前のバージョンでは、例外はスローされません。|
+|詳細|.NET Framework 4.7.1 以降では、要素のいずれかが <code>null</code> の場合、<xref:System.ServiceModel.Channels.AddressHeaderCollection.%23ctor(System.Collections.Generic.IEnumerable{System.ServiceModel.Channels.AddressHeader})> コンストラクターで <xref:System.ArgumentException> がスローされます。 .NET Framework 4.7 以前のバージョンでは、例外はスローされません。|
 |提案される解決策|.NET Framework 4.7.1 以降のバージョンでこの変更に関する互換性の問題が発生した場合は、次の行を app.config ファイルの <code>&lt;runtime&gt;</code> セクションに追加することで、無効にできます。<pre><code class="lang-xml">&lt;configuration&gt;&#13;&#10;&lt;runtime&gt;&#13;&#10;&lt;AppContextSwitchOverrides value=&quot;Switch.System.ServiceModel.DisableAddressHeaderCollectionValidation=true&quot; /&gt;&#13;&#10;&lt;/runtime&gt;&#13;&#10;&lt;/configuration&gt;&#13;&#10;</code></pre>|
 |スコープ|マイナー|
 |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
index f2fc87b70d3..e321d9525f8 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.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 サービスへ接続できません。|
+|詳細|.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 サーバーに接続できるようになります。<ul><li>MD5 アルゴリズムを使用しないように証明書を更新します。 この解決策をお勧めします。</li><li>バインドがソース コードで動的に構成されていない場合は、TLS 1.1 または以前のバージョンのプロトコルを使用するようにアプリケーションの構成ファイルを更新します。 これにより、引き続き MD5 ハッシュ アルゴリズムによる証明書を使用することができます。</li></ul> <blockquote> [!WARNING] MD5 ハッシュ アルゴリズムによる証明書は安全でないと見なされるため、この回避策はお勧めできません。</blockquote> 次の構成ファイルでこれを行います。<pre><code class="lang-xml">&lt;configuration&gt;&#13;&#10;&lt;system.serviceModel&gt;&#13;&#10;&lt;bindings&gt;&#13;&#10;&lt;netTcpBinding&gt;&#13;&#10;&lt;binding&gt;&#13;&#10;&lt;security mode= &quot;None/Transport/Message/TransportWithMessageCredential&quot; &gt;&#13;&#10;&lt;transport clientCredentialType=&quot;None/Windows/Certificate&quot;&#13;&#10;protectionLevel=&quot;None/Sign/EncryptAndSign&quot;&#13;&#10;sslProtocols=&quot;Ssl3/Tls1/Tls11&quot;&gt;&#13;&#10;&lt;/transport&gt;&#13;&#10;&lt;/security&gt;&#13;&#10;&lt;/binding&gt;&#13;&#10;&lt;/netTcpBinding&gt;&#13;&#10;&lt;/bindings&gt;&#13;&#10;&lt;/system.ServiceModel&gt;&#13;&#10;&lt;/configuration&gt;&#13;&#10;</code></pre><ul><li>バインドがソース コードで動的に構成されている場合は、ソース コード内で TLS 1.1 (<xref:System.Security.Authentication.SslProtocols.Tls11?displayProperty=nameWithType>) または以前のバージョンのプロトコルを使用するように <xref:System.ServiceModel.TcpTransportSecurity.SslProtocols?displayProperty=nameWithType> プロパティを更新します。</li></ul> <blockquote> [!WARNING] MD5 ハッシュ アルゴリズムによる証明書は安全でないと見なされるため、この回避策はお勧めできません。</blockquote> |
 |スコープ|マイナー|
 |Version|4.6|
diff --git a/includes/migration-guide/runtime/web/dataannotationsdatatypeattributedisableregex-app-setting-on-by-default-net.md b/includes/migration-guide/runtime/web/dataannotationsdatatypeattributedisableregex-app-setting-on-by-default-net.md
index 7cee7f1bbe4..2c57ea850b4 100644
--- a/includes/migration-guide/runtime/web/dataannotationsdatatypeattributedisableregex-app-setting-on-by-default-net.md
+++ b/includes/migration-guide/runtime/web/dataannotationsdatatypeattributedisableregex-app-setting-on-by-default-net.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET framework 4.6.1 で、データ型属性 (<xref:System.ComponentModel.DataAnnotations.EmailAddressAttribute?displayProperty=nameWithType>、<xref:System.ComponentModel.DataAnnotations.UrlAttribute?displayProperty=nameWithType>、<xref:System.ComponentModel.DataAnnotations.PhoneAttribute?displayProperty=nameWithType> など) で正規表現の使用を無効にするアプリ設定 (<code>&quot;dataAnnotations:dataTypeAttribute:disableRegEx&quot;</code>) が導入されました。 これにより、特定の正規表現を使用するサービス拒否攻撃の可能性を回避できるなど、セキュリティの脆弱性を軽減できます。<br/>.NET Framework 4.6.1 で、正規表現の使用を無効にするこのアプリ設定が、既定で <code>false</code> に設定されました。 .NET Framework 4.7.2 からは、この構成スイッチが既定で <code>true</code> に設定され、.NET Framework 4.7.2 以降を対象とする Web アプリケーションのセキュリティの脆弱性がさらに軽減されています。|
+|詳細|.NET framework 4.6.1 で、データ型属性 (<xref:System.ComponentModel.DataAnnotations.EmailAddressAttribute?displayProperty=nameWithType>、<xref:System.ComponentModel.DataAnnotations.UrlAttribute?displayProperty=nameWithType>、<xref:System.ComponentModel.DataAnnotations.PhoneAttribute?displayProperty=nameWithType> など) で正規表現の使用を無効にするアプリ設定 (<code>&quot;dataAnnotations:dataTypeAttribute:disableRegEx&quot;</code>) が導入されました。 これにより、特定の正規表現を使用するサービス拒否攻撃の可能性を回避できるなど、セキュリティの脆弱性を軽減できます。<br/>.NET Framework 4.6.1 で、正規表現の使用を無効にするこのアプリ設定が、既定で <code>false</code> に設定されました。 .NET Framework 4.7.2 からは、この構成スイッチが既定で <code>true</code> に設定され、.NET Framework 4.7.2 以降を対象とする Web アプリケーションのセキュリティの脆弱性がさらに軽減されています。|
 |提案される解決策|.NET Framework 4.7.2 へのアップグレード後に Web アプリケーションの正規表現が動作しない場合は、<code>&quot;dataAnnotations:dataTypeAttribute:disableRegEx&quot;</code> 設定の値を <code>false</code> に更新して以前の動作に戻すことができます。<pre><code class="lang-xml">&lt;configuration&gt;&#13;&#10;&lt;appsettings&gt;&#13;&#10;...&#13;&#10;&lt;add key=&quot;dataAnnotations:dataTypeAttribute:disableRegEx&quot; value=&quot;false&quot;/&gt;&#13;&#10;...&#13;&#10;&lt;/appsettings&gt;&#13;&#10;&lt;/configuration&gt;&#13;&#10;</code></pre>|
 |スコープ|マイナー|
 |Version|4.7.2|
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
index 54ad40a3ddc..71a8a3d75e3 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|これらのコントロールのホストは、Internet Explorer でブロックされます。|
+|詳細|これらのコントロールのホストは、Internet Explorer でブロックされます。|
 |提案される解決策|Internet Explorer では、マネージド ブラウザーを使用してコントロールをホストするアプリケーションは起動できません。 以前の動作を復元するには、レジストリ サブキー <code>HKLM/SOFTWARE/MICROSOFT/.NETFramework</code> の EnableIEHosting 値を、x86 システム用および x64 システム上の 32 ビット プロセス用に <code>1</code> に設定し、レジストリ サブキー <code>HKLM/SOFTWARE/Wow6432Node/Microsoft/.NETFramework</code> の <code>EnableIEHosting</code> 値を x64 システム上の 64 ビット プロセス用に <code>1</code> に設定します。|
 |スコープ|マイナー|
 |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
index 23ac9fb774b..33ae0dea675 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.6.2 ワークフロー アクティビティの Execute メソッドを使用して例外をスローした場合、以前のバージョンで、<code>null</code>値を<xref:System.Exception.Message>プロパティ、System.Activities ワークフロー ランタイムは、スロー、 <xref:System.NullReferenceException?displayProperty=name>、マスク、元の例外。 .NET Framework 4.7 以前マスクは、例外がスローされます。|
+|詳細|.NET Framework 4.6.2 ワークフロー アクティビティの Execute メソッドを使用して例外をスローした場合、以前のバージョンで、<code>null</code>値を<xref:System.Exception.Message>プロパティ、System.Activities ワークフロー ランタイムは、スロー、 <xref:System.NullReferenceException?displayProperty=name>、マスク、元の例外。 .NET Framework 4.7 以前マスクは、例外がスローされます。|
 |提案される解決策|コードが <xref:System.NullReferenceException?displayProperty=name> の処理に依存する場合は、カスタム アクティビティからスローされる可能性のある例外をキャッチするように変更します。|
 |スコープ|マイナー|
 |Version|4.7|
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
index ac040966522..6a6135e3224 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.7 以降では、SqlWorkflowInstanceStoreSchema.sql スクリプトで SQL Workflow Instance Store (SWIS) に作成されたテーブルにはクラスター化された主キーが使用されます。 そのため、ID では <code>null</code> 値はサポートされません。 SWIS の操作には、この変更による影響はありません。 SQL Server トランザクション レプリケーションをサポートするように更新されました。|
+|詳細|.NET Framework 4.7 以降では、SqlWorkflowInstanceStoreSchema.sql スクリプトで SQL Workflow Instance Store (SWIS) に作成されたテーブルにはクラスター化された主キーが使用されます。 そのため、ID では <code>null</code> 値はサポートされません。 SWIS の操作には、この変更による影響はありません。 SQL Server トランザクション レプリケーションをサポートするように更新されました。|
 |提案される解決策|この変更では、SQL ファイルの SqlWorkflowInstanceStoreSchemaUpgrade.sql を既存のインストールに適用する必要があります。 新しいデータベースのインストールは自動的に変更されます。|
 |スコープ|エッジ|
 |Version|4.7|
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
index eae9c1f982b..6db6665bcc3 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|<code>T:System.InvalidOperationException</code> は、次のシナリオで発生する可能性があります。<ul><li><code>T:System.Windows.Controls.Primitives.Selector</code> の ItemsSource が、<code>T:System.Collections.Specialized.INotifyCollectionChanged</code> のカスタム実装を含むコレクションである。</li><li>選択した項目をコレクションから削除する。</li><li><code>T:System.Collections.Specialized.NotifyCollectionChangedEventArgs</code> の <code>P:System.Collections.Specialized.NotifyCollectionChangedEventArgs.OldStartingIndex</code> が -1 (不明な位置を示す) である。</li></ul>例外のコールスタックは、System.Windows.Threading.Dispatcher.VerifyAccess()、System.Windows.DependencyObject.GetValue(DependencyProperty dp)、System.Windows.Controls.Primitives.Selector.GetIsSelected(DependencyObject element) で始まります。アプリケーションに複数のディスパッチャー スレッドがある場合、この例外は .NET Framework 4.5 で発生する可能性があります。 .NET Framework 4.7 では、1 つのディスパッチャー スレッドのアプリケーションでも例外が発生する場合があります。 この問題は .NET Framework 4.7.1 で修正されます。|
+|詳細|<code>T:System.InvalidOperationException</code> は、次のシナリオで発生する可能性があります。<ul><li><code>T:System.Windows.Controls.Primitives.Selector</code> の ItemsSource が、<code>T:System.Collections.Specialized.INotifyCollectionChanged</code> のカスタム実装を含むコレクションである。</li><li>選択した項目をコレクションから削除する。</li><li><code>T:System.Collections.Specialized.NotifyCollectionChangedEventArgs</code> の <code>P:System.Collections.Specialized.NotifyCollectionChangedEventArgs.OldStartingIndex</code> が -1 (不明な位置を示す) である。</li></ul>例外のコールスタックは、System.Windows.Threading.Dispatcher.VerifyAccess()、System.Windows.DependencyObject.GetValue(DependencyProperty dp)、System.Windows.Controls.Primitives.Selector.GetIsSelected(DependencyObject element) で始まります。アプリケーションに複数のディスパッチャー スレッドがある場合、この例外は .NET Framework 4.5 で発生する可能性があります。 .NET Framework 4.7 では、1 つのディスパッチャー スレッドのアプリケーションでも例外が発生する場合があります。 この問題は .NET Framework 4.7.1 で修正されます。|
 |提案される解決策|.NET Framework 4.7.1 にアップグレードします。|
 |スコープ|マイナー|
 |Version|4.7|
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
index 4a5bebc8e2a..0769c3d55b3 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.0 での実行時の表示と比べて、.NET Framework 4.5 での実行時に <xref:System.Windows.Documents.FlowDocument> 要素でテキストの余分な行が表示されることがあります。 変更によってテキストが正しく表示されなくなったり、読みにくくなったりするようなことはありませんが、以前は <xref:System.Windows.Documents.FlowDocument> のビューから除外されていたテキストが表示される可能性があります。|
+|詳細|.NET Framework 4.0 での実行時の表示と比べて、.NET Framework 4.5 での実行時に <xref:System.Windows.Documents.FlowDocument> 要素でテキストの余分な行が表示されることがあります。 変更によってテキストが正しく表示されなくなったり、読みにくくなったりするようなことはありませんが、以前は <xref:System.Windows.Documents.FlowDocument> のビューから除外されていたテキストが表示される可能性があります。|
 |提案される解決策|場合によっては、表示要素の PageHeight プロパティを 1 ずつ減らすことで、表示行の以前の数を復元できます。|
 |スコープ|エッジ|
 |Version|4.5|
diff --git a/includes/migration-guide/runtime/wpf/horizontal-scrolling-virtualization.md b/includes/migration-guide/runtime/wpf/horizontal-scrolling-virtualization.md
index dc575b6e7da..d72ae2224ce 100644
--- a/includes/migration-guide/runtime/wpf/horizontal-scrolling-virtualization.md
+++ b/includes/migration-guide/runtime/wpf/horizontal-scrolling-virtualization.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|この変更は、メインのスクロール方向と直交する方向で独自に仮想化を行う <xref:System.Windows.Controls.ItemsControl?displayProperty=name> に適用されます (代表的な例は、EnableColumnVirtualization=&quot;True&quot; である <xref:System.Windows.Controls.DataGrid?displayProperty=name> です)。  特定の水平方向スクロール操作の結果が変更され、比較可能な垂直操作の結果により類似した、より直感的な結果が生成されるようになりました。<p/>操作には &quot;ここにスクロール&quot; や &quot;右端&quot; などがあり、水平スクロール バーを右クリックすると表示されるメニューから名前を使用することができます。  これらの両方でオフセット候補が計算され、<xref:System.Windows.Controls.Primitives.IScrollInfo.SetHorizontalOffset(System.Double)> が呼び出されます。<p/>新しいオフセットにスクロールすると、&quot;ここ&quot; または &quot;右端&quot; の概念が変更されている場合があります。これは、新しく非仮想化されたコンテンツで <xref:System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth?displayProperty=name> の値が変更されたためです。<p/>.NET Framework 4.6.2 より前では、もう &quot;ここ&quot; や &quot;右端&quot; にない場合でも、スクロール操作では単にオフセット候補を使用します。  その結果、スクロールつまみの &quot;バウンス&quot; などの効果が得られます。次に例を示します。 たとえば、<xref:System.Windows.Controls.DataGrid?displayProperty=name> で ExtentWidth=1000 および Width=200 であるものとします。  &quot;右端&quot; へのスクロールでは、1000 - 200 = 800 という候補オフセットを使用します。  そのオフセットへのスクロール時に、新しい列が非仮想化されます。これらの列が非常に広いため、<xref:System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth?displayProperty=name> を 2000 に変更したとします。  スクロールは HorizontalOffset=800 で終了し、つまみはスクロールバーの中央付近 (正確には 800/2000 = 40%) に &quot;戻り&quot; ます。<p/>変更するには、この状況が発生したら新しいオフセット候補を再計算してやり直します (垂直方向スクロールの動作は既にこのようになっています)。 <p/>この変更により、エンド ユーザーにはより予測可能で直感的なエクスペリエンスが提供されるようになりますが、水平方向スクロール後の <xref:System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset?displayProperty=name> の正確な値に依存するアプリに影響する可能性もあります。これは、エンド ユーザーによる呼び出しであるか、<xref:System.Windows.Controls.Primitives.IScrollInfo.SetHorizontalOffset(System.Double)> の明示的な呼び出しであるかに関係ありません。|
+|詳細|この変更は、メインのスクロール方向と直交する方向で独自に仮想化を行う <xref:System.Windows.Controls.ItemsControl?displayProperty=name> に適用されます (代表的な例は、EnableColumnVirtualization=&quot;True&quot; である <xref:System.Windows.Controls.DataGrid?displayProperty=name> です)。  特定の水平方向スクロール操作の結果が変更され、比較可能な垂直操作の結果により類似した、より直感的な結果が生成されるようになりました。<p/>操作には &quot;ここにスクロール&quot; や &quot;右端&quot; などがあり、水平スクロール バーを右クリックすると表示されるメニューから名前を使用することができます。  これらの両方でオフセット候補が計算され、<xref:System.Windows.Controls.Primitives.IScrollInfo.SetHorizontalOffset(System.Double)> が呼び出されます。<p/>新しいオフセットにスクロールすると、&quot;ここ&quot; または &quot;右端&quot; の概念が変更されている場合があります。これは、新しく非仮想化されたコンテンツで <xref:System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth?displayProperty=name> の値が変更されたためです。<p/>.NET Framework 4.6.2 より前では、もう &quot;ここ&quot; や &quot;右端&quot; にない場合でも、スクロール操作では単にオフセット候補を使用します。  その結果、スクロールつまみの &quot;バウンス&quot; などの効果が得られます。次に例を示します。 たとえば、<xref:System.Windows.Controls.DataGrid?displayProperty=name> で ExtentWidth=1000 および Width=200 であるものとします。  &quot;右端&quot; へのスクロールでは、1000 - 200 = 800 という候補オフセットを使用します。  そのオフセットへのスクロール時に、新しい列が非仮想化されます。これらの列が非常に広いため、<xref:System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth?displayProperty=name> を 2000 に変更したとします。  スクロールは HorizontalOffset=800 で終了し、つまみはスクロールバーの中央付近 (正確には 800/2000 = 40%) に &quot;戻り&quot; ます。<p/>変更するには、この状況が発生したら新しいオフセット候補を再計算してやり直します (垂直方向スクロールの動作は既にこのようになっています)。 <p/>この変更により、エンド ユーザーにはより予測可能で直感的なエクスペリエンスが提供されるようになりますが、水平方向スクロール後の <xref:System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset?displayProperty=name> の正確な値に依存するアプリに影響する可能性もあります。これは、エンド ユーザーによる呼び出しであるか、<xref:System.Windows.Controls.Primitives.IScrollInfo.SetHorizontalOffset(System.Double)> の明示的な呼び出しであるかに関係ありません。|
 |提案される解決策|<xref:System.Windows.Controls.Primitives.IScrollInfo.HorizontalOffset?displayProperty=name> の予測値を使用するアプリを、非仮想化により <xref:System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth?displayProperty=name> が変更される可能性のある水平方向スクロール後の実際の値 (および <xref:System.Windows.Controls.Primitives.IScrollInfo.ExtentWidth?displayProperty=name> の値) を取得するように変更する必要があります。|
 |スコープ|マイナー|
 |Version|4.6.2|
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
index 2be882f8e1e..dd32db1e7b6 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|場合によっては、.NET Framework 4.5 のバグにより、カスタム DataTemplate を使用していると、ItemsControl (<xref:System.Windows.Controls.ListBox?displayProperty=name>、<xref:System.Windows.Controls.ComboBox?displayProperty=name>、<xref:System.Windows.Controls.DataGrid?displayProperty=name> など) の最後の項目までスクロールできません。 (上へスクロールした後で) もう一度スクロールを試みると、今度はスクロールできます。|
+|詳細|場合によっては、.NET Framework 4.5 のバグにより、カスタム DataTemplate を使用していると、ItemsControl (<xref:System.Windows.Controls.ListBox?displayProperty=name>、<xref:System.Windows.Controls.ComboBox?displayProperty=name>、<xref:System.Windows.Controls.DataGrid?displayProperty=name> など) の最後の項目までスクロールできません。 (上へスクロールした後で) もう一度スクロールを試みると、今度はスクロールできます。|
 |提案される解決策|この問題は .NET Framework 4.5.2 で修正されたため、このバージョン (またはそれ以降のバージョン) の .NET Framework にアップグレードすることによって対処できます。 または、ユーザーは、スクロール バーをこれらのコレクションの最後の項目までドラッグできますが、2 回試みなければならないことがあります。|
 |スコープ|マイナー|
 |Version|4.5|
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
index 366e88dc596..1eafdfac2ed 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|セレクター (複数選択が有効になっている) の <xref:System.Windows.Controls.Primitives.MultiSelector.SelectedItems?displayProperty=name> コレクションに重複部分があるとします。その場合、同じ項目が複数回表示されます。  データ ソースからこれらの項目を削除すると (たとえば、Items.Clear を呼び出すことにより)、<xref:System.Windows.Controls.Primitives.MultiSelector.SelectedItems?displayProperty=name> からそれらの項目を削除できなくなります。最初のインスタンスのみが削除されます。 さらに、<xref:System.Windows.Controls.Primitives.MultiSelector.SelectedItems?displayProperty=name> (SelectedItems.Clear() など) を引き続き使用すると、<xref:System.ArgumentException?displayProperty=name> などの問題が発生する可能性があります。これは、<xref:System.Windows.Controls.Primitives.MultiSelector.SelectedItems?displayProperty=name> に、データ ソース内にはもう存在しない項目が含まれているためです。|
+|詳細|セレクター (複数選択が有効になっている) の <xref:System.Windows.Controls.Primitives.MultiSelector.SelectedItems?displayProperty=name> コレクションに重複部分があるとします。その場合、同じ項目が複数回表示されます。  データ ソースからこれらの項目を削除すると (たとえば、Items.Clear を呼び出すことにより)、<xref:System.Windows.Controls.Primitives.MultiSelector.SelectedItems?displayProperty=name> からそれらの項目を削除できなくなります。最初のインスタンスのみが削除されます。 さらに、<xref:System.Windows.Controls.Primitives.MultiSelector.SelectedItems?displayProperty=name> (SelectedItems.Clear() など) を引き続き使用すると、<xref:System.ArgumentException?displayProperty=name> などの問題が発生する可能性があります。これは、<xref:System.Windows.Controls.Primitives.MultiSelector.SelectedItems?displayProperty=name> に、データ ソース内にはもう存在しない項目が含まれているためです。|
 |提案される解決策|可能であれば、.NET Framework 4.6.2 にアップグレードします。|
 |スコープ|マイナー|
 |Version|4.5|
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
index 8a32b3d5734..c387e30ac08 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|項目が選択された <xref:System.Windows.Controls.ListBox?displayProperty=name> にバインドされるコレクションで <xref:System.Collections.ObjectModel.ObservableCollection%601.Move(System.Int32,System.Int32)> または <xref:System.Collections.ObjectModel.ObservableCollection%601.MoveItem(System.Int32,System.Int32)> を呼び出すと、<xref:System.Windows.Controls.ListBox?displayProperty=name> 項目の今後の選択または選択解除で不規則な動作が発生する可能性があります。|
+|詳細|項目が選択された <xref:System.Windows.Controls.ListBox?displayProperty=name> にバインドされるコレクションで <xref:System.Collections.ObjectModel.ObservableCollection%601.Move(System.Int32,System.Int32)> または <xref:System.Collections.ObjectModel.ObservableCollection%601.MoveItem(System.Int32,System.Int32)> を呼び出すと、<xref:System.Windows.Controls.ListBox?displayProperty=name> 項目の今後の選択または選択解除で不規則な動作が発生する可能性があります。|
 |提案される解決策|<xref:System.Collections.ObjectModel.ObservableCollection%601.Move(System.Int32,System.Int32)> ではなく <xref:System.Collections.ObjectModel.Collection%601.Remove(%600)?displayProperty=name> と <xref:System.Collections.ObjectModel.Collection%601.Insert(System.Int32,%600)?displayProperty=name> を呼び出すことで、この問題は解決されます。 または、この問題は .NET Framework 4.6 で修正されたため、このバージョンの .NET Framework にアップグレードすることによって対処できます。|
 |スコープ|マイナー|
 |Version|4.5|
diff --git a/includes/migration-guide/runtime/wpf/resizing-grid-can-hang.md b/includes/migration-guide/runtime/wpf/resizing-grid-can-hang.md
index 1cc80bccf93..8c51ecb77c7 100644
--- a/includes/migration-guide/runtime/wpf/resizing-grid-can-hang.md
+++ b/includes/migration-guide/runtime/wpf/resizing-grid-can-hang.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|次の状況では、<code>T:System.Windows.Controls.Grid</code> のレイアウト中に無限ループが発生する可能性があります。<ul><li>行の定義に、MinHeight と MaxHeight の両方を宣言する、2 つの * 行が含まれている。</li><li>* 行のコンテンツが対応する MaxHeight を超えていない。</li><li>最初の MinHeight (その他の固定または自動の行を含む) がグリッドの利用可能な高さを超えている。</li><li>アプリの対象を .NET Framework 4.7 とする、または <code>Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=false</code> を設定して、4.7 割り当てアルゴリズムを利用することを選択する。</li></ul>また、3 つ以上の行または列でループが発生します。 .NET Framework 4.7.1 でこの問題が解決されます。|
+|詳細|次の状況では、<code>T:System.Windows.Controls.Grid</code> のレイアウト中に無限ループが発生する可能性があります。<ul><li>行の定義に、MinHeight と MaxHeight の両方を宣言する、2 つの * 行が含まれている。</li><li>* 行のコンテンツが対応する MaxHeight を超えていない。</li><li>最初の MinHeight (その他の固定または自動の行を含む) がグリッドの利用可能な高さを超えている。</li><li>アプリの対象を .NET Framework 4.7 とする、または <code>Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=false</code> を設定して、4.7 割り当てアルゴリズムを利用することを選択する。</li></ul>また、3 つ以上の行または列でループが発生します。 .NET Framework 4.7.1 でこの問題が解決されます。|
 |提案される解決策|.NET Framework 4.7.1 にアップグレードします。  4.7 割り当てアルゴリズムが必要でない場合は、次の構成設定を使用することもできます。<pre><code class="lang-xml">&lt;runtime&gt;&#13;&#10;&lt;AppContextSwitchOverrides value=&quot;Switch.System.Windows.Controls.Grid.StarDefinitionsCanExceedAvailableSpace=true&quot; /&gt;&#13;&#10;&lt;/runtime&gt;&#13;&#10;</code></pre>|
 |スコープ|エッジ|
 |Version|4.7|
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
index c5fd54942c5..611f068ea2c 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework v4.5 では、仮想化されたスタック パネル内の WPF <xref:System.Windows.Controls.TreeView?displayProperty=name> をスクロールすると、ビューポートに余白があった場合 (たとえば、<xref:System.Windows.Controls.TreeView?displayProperty=name> 内の項目間や、ItemsPresenter 要素上)、ハングすることがあります。 さらに、場合によっては、ビュー内にサイズの異なる項目があると、余白がない場合でも、不安定になることがあります。|
+|詳細|.NET Framework v4.5 では、仮想化されたスタック パネル内の WPF <xref:System.Windows.Controls.TreeView?displayProperty=name> をスクロールすると、ビューポートに余白があった場合 (たとえば、<xref:System.Windows.Controls.TreeView?displayProperty=name> 内の項目間や、ItemsPresenter 要素上)、ハングすることがあります。 さらに、場合によっては、ビュー内にサイズの異なる項目があると、余白がない場合でも、不安定になることがあります。|
 |提案される解決策|このバグは、.NET Framework 4.5.1 にアップグレードすることによって回避できます。 または、含まれているすべての項目が同じサイズである場合は、仮想化されたスタック パネル内のビュー コレクション (<xref:System.Windows.Controls.TreeView?displayProperty=name> など) から余白を削除できます。|
 |スコープ|Major|
 |バージョン|4.5|
diff --git a/includes/migration-guide/runtime/wpf/wpf-printing-stack-update.md b/includes/migration-guide/runtime/wpf/wpf-printing-stack-update.md
index 0c376108bca..32870b1dc34 100644
--- a/includes/migration-guide/runtime/wpf/wpf-printing-stack-update.md
+++ b/includes/migration-guide/runtime/wpf/wpf-printing-stack-update.md
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|<xref:System.Printing.PrintQueue?displayProperty=name> を使う WPF の印刷 API は、非推奨になった XPS 印刷 API ではなく Windows ドキュメント印刷パッケージ API を呼び出すようになりました。 この変更はサービス性を考慮して行われたもので、ユーザーも開発者も、動作または API の使用の変化を目にすることはありません。 Windows 10 Creators Update で実行すると、新しい印刷スタックは既定で有効になります。 以前のバージョンの Windows では、以前の印刷スタックが引き続き同じように動作します。|
+|詳細|<xref:System.Printing.PrintQueue?displayProperty=name> を使う WPF の印刷 API は、非推奨になった XPS 印刷 API ではなく Windows ドキュメント印刷パッケージ API を呼び出すようになりました。 この変更はサービス性を考慮して行われたもので、ユーザーも開発者も、動作または API の使用の変化を目にすることはありません。 Windows 10 Creators Update で実行すると、新しい印刷スタックは既定で有効になります。 以前のバージョンの Windows では、以前の印刷スタックが引き続き同じように動作します。|
 |提案される解決策|Windows 10 Creators Update で以前のスタックを使用するには、<code>HKEY_CURRENT_USER\Software\Microsoft\.NETFramework\Windows Presentation Foundation\Printing</code> レジストリ キーの <code>UseXpsOMPrinting</code> REG_DWORD 値を <code>1</code> に設定します。|
 |スコープ|エッジ|
 |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
index ebabdc4fd1c..76588b35612 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|この問題は 4.5.2 から発生するようになり、<code>wisptis.exe</code> が生成され、マウス入力がフリーズする可能性があります。|
+|詳細|この問題は 4.5.2 から発生するようになり、<code>wisptis.exe</code> が生成され、マウス入力がフリーズする可能性があります。|
 |提案される解決策|この問題はサービス リリースの .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
index 02105e9fd62..29f561717d5 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|これには、次の WPF スペル チェックのいくつかの問題が含まれます。<ul><li>WPF スペル チェックで <xref:System.Runtime.InteropServices.COMException?displayProperty=name> がスローされる場合がある。</li><li>"別のユーザーとして実行" を使用してアプリケーションが起動された場合、WPF スペル チェックが <xref:System.UnauthorizedAccessException> で失敗する。</li><li>WPF スペル チェックで、ドイツ語の "Hausnummer" などの複合語のスペル ミスが正しく識別されない。</li></ul>|
+|詳細|これには、次の WPF スペル チェックのいくつかの問題が含まれます。<ul><li>WPF スペル チェックで <xref:System.Runtime.InteropServices.COMException?displayProperty=name> がスローされる場合がある。</li><li>"別のユーザーとして実行" を使用してアプリケーションが起動された場合、WPF スペル チェックが <xref:System.UnauthorizedAccessException> で失敗する。</li><li>WPF スペル チェックで、ドイツ語の "Hausnummer" などの複合語のスペル ミスが正しく識別されない。</li></ul>|
 |提案される解決策|問題 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
index 20ea16189a0..d313d3fdd97 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|プラットフォームのスペル チェック機能は入力言語リストに存在する言語でしか使用できないため、 Windows 10 での実行時には、WPF テキスト対応コントロール向けのスペル チェック機能が動作しないことがあります。Windows 10 では、使用可能なキーボードのリストに言語を追加すると、対応するオンデマンド機能 (FOD) パッケージが自動的にダウンロードおよびインストールされ、スペル チェック機能が提供されます。 入力言語リストに言語を追加することで、スペル チェック機能がサポートされます。|
+|詳細|プラットフォームのスペル チェック機能は入力言語リストに存在する言語でしか使用できないため、 Windows 10 での実行時には、WPF テキスト対応コントロール向けのスペル チェック機能が動作しないことがあります。Windows 10 では、使用可能なキーボードのリストに言語を追加すると、対応するオンデマンド機能 (FOD) パッケージが自動的にダウンロードおよびインストールされ、スペル チェック機能が提供されます。 入力言語リストに言語を追加することで、スペル チェック機能がサポートされます。|
 |提案される解決策|Windows 10 でスペルチェックを動作させるには、スペルチェック対象の言語またはテキストを入力言語として追加する必要があることに注意してください。|
 |スコープ|エッジ|
 |Version|4.6|
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
index 3c36c4ce809..55fa16ce44a 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|Windows 8 以上で実行している .NET Framework 4.6 では、マルチ モニターのシナリオで 1 つのディスプレイの外部にウィンドウを拡張すると、ウィンドウ全体がクリッピングなしでレンダリングされます。 これは、1 つのディスプレイを超える WPF ウィンドウをクリッピングする、以前のバージョンの .NET Framework とは異なります。|
+|詳細|Windows 8 以上で実行している .NET Framework 4.6 では、マルチ モニターのシナリオで 1 つのディスプレイの外部にウィンドウを拡張すると、ウィンドウ全体がクリッピングなしでレンダリングされます。 これは、1 つのディスプレイを超える WPF ウィンドウをクリッピングする、以前のバージョンの .NET Framework とは異なります。|
 |提案される解決策|この動作 (クリッピングするかどうか) は、アプリケーションの構成ファイルの <code>&lt;appSettings&gt;</code> で <code>&lt;EnableMultiMonitorDisplayClipping&gt;</code> 要素を使用するか、アプリの起動時に <code>EnableMultiMonitorDisplayClipping</code> プロパティを設定することで明示的に設定できます。|
 |スコープ|マイナー|
 |Version|4.6|
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
index 06ac0b08868..61cdd419e0a 100644
--- 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
@@ -2,7 +2,7 @@
 
 |   |   |
 |---|---|
-|説明|.NET Framework 4.5 では、XSLT ファイルが複雑すぎるときのエラー メッセージのテキストが &quot;スタイル シートが複雑すぎます&quot; になります。以前のバージョンのエラー メッセージは &quot;XSLT コンパイル エラー&quot; でした。エラー メッセージのテキストに依存するアプリケーション コードは機能しなくなります。 ただし、例外の種類は同じなので、この変更による実質的な影響はありません。|
+|詳細|.NET Framework 4.5 では、XSLT ファイルが複雑すぎるときのエラー メッセージのテキストが &quot;スタイル シートが複雑すぎます&quot; になります。以前のバージョンのエラー メッセージは &quot;XSLT コンパイル エラー&quot; でした。エラー メッセージのテキストに依存するアプリケーション コードは機能しなくなります。 ただし、例外の種類は同じなので、この変更による実質的な影響はありません。|
 |提案される解決策|このエラー条件からの例外メッセージに依存しているアプリケーション コードを、新しいメッセージを予期するように更新するか、(さらに望ましくは) 変更されていない例外の種類 (<xref:System.Xml.Xsl.XsltException?displayProperty=name>) のみに依存するようにコードを更新します。|
 |スコープ|エッジ|
 |Version|4.5|
diff --git a/includes/topic-appliesto-net-core-all.md b/includes/topic-appliesto-net-core-all.md
index b8bd16e5359..05438ad4a57 100644
--- a/includes/topic-appliesto-net-core-all.md
+++ b/includes/topic-appliesto-net-core-all.md
@@ -1 +1 @@
-**このトピックの対象: ✓** .NET Core SDK 1.x **✓** .NET Core SDK 2.0
+**このトピックの対象: ✓** .NET Core SDK 1.x **✓** .NET Core SDK 2.x