Merge pull request #6340 from dotnet/master

Update Live with current Master

Author: Ron Petrusha

.openpublishing.redirection.json

@@ -1321,6 +1321,14 @@
         {
             "source_path":"docs/fsharp/language-reference/signatures.md",
             "redirect_url":"/dotnet/fsharp/language-reference/signature-files"
+        },
+        {
+            "source_path":"docs/csharp/programming-guide/concepts/threading/thread-timers.md",
+            "redirect_url":"/dotnet/standard/threading/timers"
+        },
+        {
+            "source_path":"docs/visual-basic/programming-guide/concepts/threading/thread-timers.md",
+            "redirect_url":"/dotnet/standard/threading/timers"
         }
     ]
 }

docs/core/versions/selection.md

@@ -27,9 +27,9 @@ The rest of this document examines those four scenarios.
 
 SDK commands include `dotnet new`, `dotnet build` or `dotnet run`. The `dotnet` CLI must choose an SDK version for any command. The .NET Core CLI uses the latest SDK installed on the machine by default. You'll use the .NET Core SDK v2.1.301 when it's installed, even if the project you are working with targets the .NET Core Runtime 2.0. Note that this is true for preview versions as well as released versions. You can take advantage of the latest SDK features and improvements while targeting earlier .NET Core runtime versions. You can target multiple runtime versions of .NET Core on different projects, using the same SDK tools for all projects.
 
-On rare occasions, you may need to use an earlier version of the SDK. You specify that version in a [*global.json* file](../tools/global-json.md). The "use latest" policy means you only use *global.json* to specify a .NET Core version earlier than the latest installed version.
+On rare occasions, you may need to use an earlier version of the SDK. You specify that version in a [*global.json* file](../tools/global-json.md). The "use latest" policy means you only use *global.json* to specify a .NET Core SDK version earlier than the latest installed version.
 
-*global.json* can be placed anywhere in the file hierarchy. The CLI searches upward from the project directory for the first *global.json* it finds. You control which projects a given *global.json* applies to by its place in the file system. The .NET CLI searches for a *global.json* file iteratively navigating the path upward from the current working directory. The first *global.json* file found specifies the version used. If that version is installed, that version is used. If the SDK specified in the *global.json* is not found, the .NET CLI rolls forward to the latest SDK installed. This is the same as the default behavior, when no *global.json** file is found.
+*global.json* can be placed anywhere in the file hierarchy. The CLI searches upward from the project directory for the first *global.json* it finds. You control which projects a given *global.json* applies to by its place in the file system. The .NET CLI searches for a *global.json* file iteratively navigating the path upward from the current working directory. The first *global.json* file found specifies the version used. If that version is installed, that version is used. If the SDK specified in the *global.json* is not found, the .NET CLI rolls forward to the latest SDK installed. This is the same as the default behavior, when no *global.json* file is found.
 
 The following example shows the *global.json* syntax:
 
@@ -45,7 +45,7 @@ The process for selecting an SDK version is:
 
 1. `dotnet` searches for a *global.json* file iteratively reverse-navigating the path upward from the current working directory.
 1. `dotnet` uses the SDK specified in the first *global.json* found.
-1. `dotnet` binds to the latest installed SDK if no *global.json* is found.
+1. `dotnet` uses the latest installed SDK if no *global.json* is found.
 
 You can learn more about selecting an SDK version in the [matching rules](../tools/global-json.md) section of the topic on *global.json*.
 
@@ -79,21 +79,21 @@ A few usage examples demonstrate the behavior:
 
 - 2.0.4 is required. 2.0.5 is the highest patch version installed. 2.0.5 is used.
 - 2.0.4 is required. No 2.0.* versions are installed. 1.1.1 is the highest runtime installed. An error message is displayed.
-- 2.04 is required. 2.0.0 is the latest version installed. An error message is displayed.
+- 2.0.4 is required. 2.0.0 is the highest version installed. An error message is displayed.
 - 2.0.4 is required. No 2.0.* versions are installed. 2.2.2 is the highest 2.x runtime version installed. 2.2.2 is used.
 - 2.0.4 is required. No 2.x versions are installed. 3.0.0 (not a currently available version) is installed. An error message is displayed.
 
 Minor version roll-forward has one side-effect that may affect end users. Consider the following scenario:
 
 - 2.0.4 is required. No 2.0.* versions are installed. 2.2.2 is installed. 2.2.2 is used.
-- 2.0.5 is later installed. 2.0.5 will be used for subsequent application launches, not 2.2.2. The latest patch is preferred over an updated minor version.
-- It's possible that 2.0.5 and 2.2.2 might behave differently, particularly for scenarios like serializing binary data.
+- 2.0.5 is later installed. 2.0.5 will be used for subsequent application launches, not 2.2.2. The latest patch of the required minor version is preferred over a higher minor version.
+- It's possible that 2.0.5 and 2.2.2 behave differently, particularly for scenarios like serializing binary data.
 
 ## Self-contained deployments include the selected runtime
 
 You can publish an application as a [**self-contained distribution**](../deploying/index.md#self-contained-deployments-scd). This approach bundles the .NET Core runtime and libraries with your application. Self-contained deployments don't have a dependency on runtime environments. Runtime version selection occurs at publishing time, not run time.
 
-The publishing process selects the latest patch version of the given runtime family. For example, `dotnet publish` will select .NET Core 2.0.4 if it is the latest patch version in the .NET Core 2.0 runtime family. The target framework (including the latest installed security patches) are packaged with the application.
+The publishing process selects the latest patch version of the given runtime family. For example, `dotnet publish` will select .NET Core 2.0.4 if it is the latest patch version in the .NET Core 2.0 runtime family. The target framework (including the latest installed security patches) is packaged with the application.
 
 It's an error if the minimum version specified for an application isn't satisfied. `dotnet publish` binds to the latest runtime patch version (within a given major.minor version family). `dotnet publish` doesn't support the roll-forward semantics of `dotnet run`. For more information about patches and self-contained deployments, see the article on [runtime patch selection](../deploying/runtime-patch-selection.md) in deploying .NET Core applications.
 
@@ -103,4 +103,4 @@ Self-contained deployments may require a specific patch version. You can overrid
 <RuntimeFrameworkVersion>2.0.4</RuntimeFrameworkVersion>
 ```
 
-The `RuntimeFrameworkVersion` element  overrides the default version policy. For self-contained deployments, the `RuntimeFrameworkVersion` specifies the *exact* runtime framework version. For framework dependent applications, the `RuntimeFrameworkVersion` specifies the *minimum* patch level of the framework.
+The `RuntimeFrameworkVersion` element  overrides the default version policy. For self-contained deployments, the `RuntimeFrameworkVersion` specifies the *exact* runtime framework version. For framework dependent applications, the `RuntimeFrameworkVersion` specifies the *minimum* required runtime framework version.

docs/core/whats-new/dotnet-core-2-1.md

@@ -212,11 +212,11 @@ The sockets implementation introduced in .NET Core 2.1 has a number of advantage
 <xref:System.Net.Http.SocketsHttpHandler> is the default implementation in .NET Core 2.1. However, you can configure your application to use the older <xref:System.Net.Http.HttpClientHandler> class by calling the <xref:System.AppContext.SetSwitch%2A?displayProperty="nameWithType"> method:
 
 ```csharp
-AppContext.SetSwitch("System.Net.Http.useSocketsHttpHandler", false);
+AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false);
 ```
 
 ```vb
-AppContext.SetSwitch("System.Net.Http.useSocketsHttpHandler", False)
+AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", False)
 ```
 
 You can also use an environment variable to opt out of using sockets implementations based on <xref:System.Net.Http.SocketsHttpHandler>. To do this, set the `DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER` to either `false` or 0.

docs/csharp/language-reference/keywords/foreach-in.md

@@ -29,11 +29,11 @@ The following example shows usage of the `foreach` statement with an instance of
 
 The next example uses the `foreach` statement with an instance of the <xref:System.Span%601?displayProperty=nameWithType> type, which doesn't implement any interfaces:
 
-[!code-csharp[span example](~/samples/snippets/csharp/keywords/IterationKeywordsExamples.cs#2)]
+[!code-csharp-interactive[span example](~/samples/snippets/csharp/keywords/IterationKeywordsExamples.cs#2)]
 
 Beginning with C# 7.3, if the enumerator's `Current` property returns a [reference return value](../../programming-guide/classes-and-structs/ref-returns.md) (`ref T` where `T` is the type of the collection element), you can declare the iteration variable with the `ref` or `ref readonly` modifier. The following example uses a `ref` iteration variable to set the value of each item in a stackalloc array. The `ref readonly` version iterates the collection to print all the values. The `readonly` declaration uses an implicit local variable declaration. Implicit variable declarations can be used with either `ref` or `ref readonly` declarations, as can explicitly typed variable declarations.
 
-[!code-csharp[ref span example](~/samples/snippets/csharp/keywords/IterationKeywordsExamples.cs#RefSpan)]
+[!code-csharp-interactive[ref span example](~/samples/snippets/csharp/keywords/IterationKeywordsExamples.cs#RefSpan)]
 
 ## C# language specification
 

docs/csharp/programming-guide/concepts/linq/linq-to-xml-overview.md

@@ -22,7 +22,7 @@ XML has been widely adopted as a way to format data in many contexts. For exampl
 
  Another advantage of [!INCLUDE[sqltecxlinq](~/includes/sqltecxlinq-md.md)] is the ability to use query results as parameters to <xref:System.Xml.Linq.XElement> and <xref:System.Xml.Linq.XAttribute> object constructors enables a powerful approach to creating XML trees. This approach, called *functional construction*, enables developers to easily transform XML trees from one shape to another.  
 
- For example, you might have a typical XML purchase order as described in [Sample XML File: Typical Purchase Order (LINQ to XML)](http://msdn.microsoft.com/library/0606c09f-6e43-4f8d-95c8-e8e2e08d2348). By using [!INCLUDE[sqltecxlinq](~/includes/sqltecxlinq-md.md)], you could run the following query to obtain the part number attribute value for every item element in the purchase order:  
+ For example, you might have a typical XML purchase order as described in [Sample XML File: Typical Purchase Order (LINQ to XML)](sample-xml-file-typical-purchase-order-linq-to-xml-1.md). By using [!INCLUDE[sqltecxlinq](~/includes/sqltecxlinq-md.md)], you could run the following query to obtain the part number attribute value for every item element in the purchase order:  
 
 ```csharp  
 IEnumerable<string> partNos =  

docs/csharp/programming-guide/concepts/threading/index.md

@@ -35,7 +35,6 @@ Threading enables your C# program to perform concurrent processing so that you c
 |[Parameters and Return Values for Multithreaded Procedures (C#)](../../../../csharp/programming-guide/concepts/threading/parameters-and-return-values-for-multithreaded-procedures.md)|Describes how to pass and return parameters with multithreaded applications.|  
 |[Walkthrough: Multithreading with the BackgroundWorker Component (C#)](../../../../csharp/programming-guide/concepts/threading/walkthrough-multithreading-with-the-backgroundworker-component.md)|Shows how to create a simple multithreaded application.|  
 |[Thread Synchronization (C#)](../../../../csharp/programming-guide/concepts/threading/thread-synchronization.md)|Describes how to control the interactions of threads.|  
-|[Thread Timers (C#)](../../../../csharp/programming-guide/concepts/threading/thread-timers.md)|Describes how to run procedures on separate threads at fixed intervals.|  
 |[Thread Pooling (C#)](../../../../csharp/programming-guide/concepts/threading/thread-pooling.md)|Describes how to use a pool of worker threads that are managed by the system.|  
 |[How to: Use a Thread Pool (C#)](../../../../csharp/programming-guide/concepts/threading/how-to-use-a-thread-pool.md)|Demonstrates synchronized use of multiple threads in the thread pool.|  
 |[Threading](../../../../../docs/standard/threading/index.md)|Describes how to implement threading in the .NET Framework.|

docs/csharp/programming-guide/concepts/threading/parameters-and-return-values-for-multithreaded-procedures.md

@@ -109,7 +109,7 @@ private void BackgroundWorker1_RunWorkerCompleted(
 }  
 ```  
 
- You can provide parameters and return values to thread-pool threads by using the optional `ByVal` state-object variable of the <xref:System.Threading.ThreadPool.QueueUserWorkItem%2A> method. Thread-timer threads also support a state object for this purpose. For information on thread pooling and thread timers, see [Thread Pooling (C#)](../../../../csharp/programming-guide/concepts/threading/thread-pooling.md) and [Thread Timers (C#)](../../../../csharp/programming-guide/concepts/threading/thread-timers.md).  
+ You can provide parameters and return values to thread-pool threads by using the optional `ByVal` state-object variable of the <xref:System.Threading.ThreadPool.QueueUserWorkItem%2A> method. Thread-timer threads also support a state object for this purpose. For information on thread pooling and thread timers, see [Thread Pooling (C#)](../../../../csharp/programming-guide/concepts/threading/thread-pooling.md) and [Timers](../../../../standard/threading/timers.md).  
 
 ## See Also  
  [Walkthrough: Multithreading with the BackgroundWorker Component (C#)](../../../../csharp/programming-guide/concepts/threading/walkthrough-multithreading-with-the-backgroundworker-component.md)  

docs/csharp/programming-guide/concepts/threading/thread-timers.md

@@ -3,6 +3,5 @@
 ## [Parameters and Return Values for Multithreaded Procedures](parameters-and-return-values-for-multithreaded-procedures.md)
 ## [Walkthrough: Multithreading with the BackgroundWorker Component](walkthrough-multithreading-with-the-backgroundworker-component.md)
 ## [Thread Synchronization](thread-synchronization.md)
-## [Thread Timers](thread-timers.md)
 ## [Thread Pooling](thread-pooling.md)
 ### [How to: Use a Thread Pool](how-to-use-a-thread-pool.md)

docs/csharp/programming-guide/concepts/threading/toc.md

@@ -1,3 +1,4 @@
+#region everything
 namespace WrapTwoInterfaceEvents
 {
     using System;
@@ -29,6 +30,7 @@ public class Shape : IDrawingObject, IShape
         // Explicit interface implementation required.
         // Associate IDrawingObject's event with
         // PreDrawEvent
+        #region IDrawingObjectOnDraw
         event EventHandler IDrawingObject.OnDraw
         {
             add
@@ -46,6 +48,8 @@ event EventHandler IDrawingObject.OnDraw
                 }
             }
         }
+        #endregion
+
         // Explicit interface implementation required.
         // Associate IShape's event with
         // PostDrawEvent
@@ -133,3 +137,4 @@ Sub1 receives the IDrawingObject event.
     Drawing a shape.
     Sub2 receives the IShape event.
 */
+#endregion