Merge branch 'master' into live

Author: Greg Van Liew

TOC.md

@@ -16,7 +16,7 @@
 ### [Create and configure datasets in Visual Studio](create-and-configure-datasets-in-visual-studio.md)
 #### [Typed vs. untyped datasets](typed-vs-untyped-datasets.md)
 #### [Relationships in datasets](relationships-in-datasets.md)
-#### [Walkthrough: Creating a DataSet in the Dataset Designer](walkthrough-creating-a-dataset-in-the-dataset-designer.md)
+#### [Walkthrough: Creating a DataSet with the Dataset Designer](walkthrough-creating-a-dataset-with-the-dataset-designer.md)
 #### [Walkthrough: Creating a DataTable in the Dataset Designer](walkthrough-creating-a-datatable-in-the-dataset-designer.md)
 ### [Fill datasets by using TableAdapters](fill-datasets-by-using-tableadapters.md)
 #### [Create and configure TableAdapters](create-and-configure-tableadapters.md)

docs/data-tools/TOC.md

@@ -34,7 +34,7 @@ Adds a custom message to the graphics diagnostics *HUD* (Head-Up Display).
 
 ## Syntax  
 
-```cpp  
+```C++  
 void AddMessage(  
   wchar_t const * szMessage  
 );  

docs/debugger/addmessage.md

@@ -73,14 +73,14 @@ An assertion, or `Assert` statement, tests a condition, which you specify as an
 ##  <a name="BKMK_The_Debug_Assert_method"></a> The Debug.Assert method  
  Use the <xref:System.Diagnostics.Debug.Assert%2A?displayProperty=fullName> method freely to test conditions that should hold true if your code is correct. For example, suppose you have written an integer divide function. By the rules of mathematics, the divisor can never be zero. You might test this using an assertion:  
 
-```vb  
+```VB  
 Function IntegerDivide(ByVal dividend As Integer, ByVal divisor As Integer) As Integer  
     Debug.Assert(divisor <> 0)  
     Return CInt(dividend / divisor)  
 End Function  
 ```  
 
-```c#  
+```CSharp  
 int IntegerDivide ( int dividend , int divisor )  
     { Debug.Assert ( divisor != 0 );  
         return ( dividend / divisor ); }  
@@ -90,29 +90,29 @@ int IntegerDivide ( int dividend , int divisor )
 
  Here is another example. You have a class that implements a checking account, as follows:  
 
-```vb  
+```VB  
 Dim amount, balance As Double  
 balance = savingsAccount.balance  
 Debug.Assert(amount <= balance)  
 SavingsAccount.Withdraw(amount)  
 ```  
 
-```c#  
+```CSharp  
 float balance = savingsAccount.Balance;  
 Debug.Assert ( amount <= balance );  
 savingsAccount.Withdraw ( amount );  
 ```  
 
  Before you withdraw money from the account, you want to make sure that the account balance is sufficient to cover the amount you are preparing to withdraw. You might write an assertion to check the balance:  
 
-```vb  
+```VB  
 Dim amount, balance As Double  
 balance = savingsAccount.balance  
 Trace.Assert(amount <= balance)  
 SavingsAccount.Withdraw(amount)  
 ```  
 
-```c#  
+```CSharp  
 float balance = savingsAccount.Balance;  
 Trace.Assert ( amount <= balance );  
 savingsAccount.Withdraw ( amount );  
@@ -127,24 +127,24 @@ savingsAccount.Withdraw ( amount );
 ##  <a name="BKMK_Side_effects_of_Debug_Assert"></a> Side effects of Debug.Assert  
  When you use <xref:System.Diagnostics.Debug.Assert%2A?displayProperty=fullName>, make sure that any code inside `Assert` does not change the results of the program if `Assert` is removed. Otherwise, you might accidentally introduce a bug that only shows up in the Release version of your program. Be especially careful about asserts that contain function or procedure calls, such as the following example:  
 
-```vb  
+```VB  
 ' unsafe code  
 Debug.Assert (meas(i) <> 0 )  
 ```  
 
-```c#  
+```CSharp  
 // unsafe code  
 Debug.Assert (meas(i) != 0 );  
 ```  
 
  This use of <xref:System.Diagnostics.Debug.Assert%2A?displayProperty=fullName> might appear safe at first glance, but suppose the function meas updates a counter each time it is called. When you build the Release version, this call to meas is eliminated, so the counter does not get updated. This is an example of a function with a side effect. Eliminating a call to a function that has side effects could result in a bug that only appears in the Release version. To avoid such problems, do not place function calls in a <xref:System.Diagnostics.Debug.Assert%2A?displayProperty=fullName> statement. Use a temporary variable instead:  
 
-```vb  
+```VB  
 temp = meas( i )  
 Debug.Assert (temp <> 0)  
 ```  
 
-```c#  
+```CSharp  
 temp = meas( i );  
 Debug.Assert ( temp != 0 );  
 ```  
@@ -175,37 +175,37 @@ Debug.Assert ( temp != 0 );
 ##  <a name="BKMK_Assert_arguments"></a> Assert arguments  
  <xref:System.Diagnostics.Trace.Assert%2A?displayProperty=fullName> and <xref:System.Diagnostics.Debug.Assert%2A?displayProperty=fullName> take up to three arguments. The first argument, which is mandatory, is the condition you want to check. If you call <xref:System.Diagnostics.Trace.Assert(System.Boolean)?displayProperty=fullName> or <xref:System.Diagnostics.Debug.Assert(System.Boolean)?displayProperty=fullName> with only one argument, the `Assert` method checks the condition and, if the result is false, outputs the contents of the call stack to the **Output** window. The following example shows <xref:System.Diagnostics.Trace.Assert(System.Boolean)?displayProperty=fullName> and <xref:System.Diagnostics.Debug.Assert(System.Boolean)?displayProperty=fullName>:  
 
-```vb  
+```VB  
 Debug.Assert(stacksize > 0)  
 Trace.Assert(stacksize > 0)  
 ```  
 
-```c#  
+```CSharp  
 Debug.Assert ( stacksize > 0 );  
 Trace.Assert ( stacksize > 0 );   
 ```  
 
  The second and third arguments, if present, must be strings. If you call <xref:System.Diagnostics.Trace.Assert%2A?displayProperty=fullName> or <xref:System.Diagnostics.Debug.Assert%2A?displayProperty=fullName> with two or three arguments, the first argument is a condition. The method checks the condition and, if the result is false, outputs the second string and third strings. The following example shows <xref:System.Diagnostics.Debug.Assert(System.Boolean,System.String)?displayProperty=fullName> and <xref:System.Diagnostics.Trace.Assert(System.Boolean,System.String)?displayProperty=fullName> used with two arguments:  
 
-```vb  
+```VB  
 Debug.Assert(stacksize > 0, "Out of stack space")  
 Trace.Assert(stacksize > 0, "Out of stack space")  
 ```  
 
-```c#  
+```CSharp  
 Debug.Assert ( stacksize > 0, "Out of stack space" );  
 Trace.Assert ( stacksize > 0, "Out of stack space" );  
 ```  
 
  The following example shows <xref:System.Diagnostics.Debug.Assert%2A> and <xref:System.Diagnostics.Trace.Assert%2A>:  
 
-```vb  
+```VB  
 Debug.Assert(stacksize > 0, "Out of stack space. Bytes left:" , Format(size, "G"))  
 Trace.Assert(stacksize > 0, "Out of stack space. Bytes left:" , Format(size, "G"))  
 Trace.Assert(stacksize > 0, "Out of stack space. Bytes left:", "inctemp failed on third call" )  
 ```  
 
-```c#  
+```CSharp  
 Debug.Assert ( stacksize > 100, "Out of stack space" , "Failed in inctemp" );  
 Trace.Assert ( stacksize > 0, "Out of stack space", "Failed in inctemp" );   
 ```  

docs/debugger/assertions-in-managed-code.md

@@ -1,7 +1,7 @@
 ---
 title: "Inspect Variables in the Debugger | Microsoft Docs"
 ms.custom: ""
-ms.date: "11/04/2016"
+ms.date: "02/07/2017"
 ms.reviewer: ""
 ms.suite: ""
 ms.technology: 
@@ -11,12 +11,6 @@ ms.topic: "hero-article"
 f1_keywords: 
   - "vs.debug.autos"
   - "vs.debug.locals"
-dev_langs: 
-  - "FSharp"
-  - "VB"
-  - "CSharp"
-  - "C++"
-  - "JScript"
 helpviewer_keywords: 
   - "debugger, variable windows"
   - "debugging [Visual Studio], variable windows"
@@ -44,49 +38,49 @@ translation.priority.mt:
 # Inspecting Variables in the Autos and Locals Windows
 The **Autos** window (while debugging, **CTRL+ALT+V, A**, or **Debug / Windows / Autos**) and the **Locals** window (while debugging, **CTRL+ALT+V, L**, or **Debug / Windows / Locals**) are quite useful when you want to see variable values while you are debugging. The **Locals** window displays variables that are defined in the local  scope, which is generally the function or method that is currently being executed. The **Autos** window displays variables used around the current line (the place where the debugger is stopped). Exactly which variables displayed is different in different languages. See What variables appear in the Autos Window? below.  
 
- If you need more information about basic debugging, see [Getting Started with the Debugger](../debugger/getting-started-with-the-debugger.md).  
+If you need more information about basic debugging, see [Getting Started with the Debugger](../debugger/getting-started-with-the-debugger.md).  
 
 ## Looking at objects in the Autos and Locals windows  
- Arrays and objects are displayed in the Autos and Locals windows as tree controls. Click on the arrow to the left of the variable name to expand the view to show fields and properties. Here is an example of a [FileStream](http://msdn.microsoft.com/Library/a8737776-e545-4867-91ed-51c7f031fa19) object in the **Locals** window:  
+Arrays and objects are displayed in the Autos and Locals windows as tree controls. Click on the arrow to the left of the variable name to expand the view to show fields and properties. Here is an example of a [FileStream](http://msdn.microsoft.com/Library/a8737776-e545-4867-91ed-51c7f031fa19) object in the **Locals** window:  
 
- ![Locals-FileStream](../debugger/media/locals-filestream.png "Locals-FileStream")  
+![Locals-FileStream](../debugger/media/locals-filestream.png "Locals-FileStream")  
 
 ## What variables appear in the Autos window?  
  You can use the **Autos** window in C#, Visual Basic, and C++ code. The **Autos** window does not support JavaScript or F#.  
 
- In C# and Visual Basic, the **Autos** window displays any  variable used on the current or preceding line. For example, if you declare four variables and set them as follows:  
-  
-```c#  
-public static void Main()  
-{  
-    int a, b, c, d;  
-    a = 1;  
-    b = 2;  
-    c = 3;  
-    d = 4;  
-}  
-```  
-  
+ In C# and Visual Basic, the **Autos** window displays any  variable used on the current or preceding line. For example, if you declare four variables and set them as follows:
+
+```CSharp
+    public static void Main()
+    {
+       int a, b, c, d;
+       a = 1;
+       b = 2;
+       c = 3;
+       d = 4;
+    }
+```
+
  If you set a breakpoint on the line `c = 3`; and run the debugger, when execution stops the **Autos** window will look like this:  
-  
+
  ![Autos-CSharp](../debugger/media/autos-csharp.png "Autos-CSharp")  
-  
+
  Note that the value of `c` is 0, because the line `c = 3` has not yet been executed.  
-  
- In C++ the **Autos** window displays the variables used at least three lines before the current line (the line at which execution is stopped). If you declare six variables:  
-  
-```cpp  
-void main() {  
-    int a, b, c, d, e, f;  
-    a = 1;  
-    b = 2;  
-    c = 3;  
-    d = 4;  
-    e = 5;  
-    f = 6;  
-}  
-```  
-  
+
+ In C++ the **Autos** window displays the variables used at least three lines before the current line (the line at which execution is stopped). If you declare six variables:
+
+```C++
+    void main() {
+        int a, b, c, d, e, f;
+        a = 1;
+        b = 2;
+        c = 3;
+        d = 4;
+        e = 5;
+        f = 6;
+    }
+```
+
  If you set a breakpoint on the line `e = 5;` and run the debugger, when execution stops the **Autos** window will look like this:  
   
  ![Autos-Cplus](../debugger/media/autos-cplus.png "Autos-Cplus")  
@@ -99,8 +93,8 @@ void main() {
  In .NET and C++ code you can examine return values when you step over or out of a method call. This functionality is useful when the result of a method call is not stored in a local variable, for example when a method is used as a parameter or as a return value of another    method.  
   
  The following C# code adds the return values of two functions:  
-  
-```c#  
+
+```CSharp
 static void Main(string[] args)  
 {  
     int a, b, c, d;  
@@ -120,29 +114,28 @@ private static int subtractVars(int i, int j)
 {  
     return j - i;  
 }  
-  
-```  
-  
+```
+
  Set a breakpoint on the int `x = sumVars(a, b) + subtractVars(c, d);` line.  
 
  Start debugging, and when execution breaks at the first breakpoint, press **F10 (Step Over)**. You should see the following in the **Autos** window:  
 
  ![AutosReturnValueCSharp2](../debugger/media/autosreturnvaluecsharp2.png "AutosReturnValueCSharp2")  
 
 ## Why are variable values sometimes red in Locals and Autos windows?  
- You may notice that the value of a variable is sometimes red in the **Locals** and **Autos** windows. These are variable values that have been changed since the last evaluation. The change could be from a previous debugging session, or because the value was changed in the window.  
+You may notice that the value of a variable is sometimes red in the **Locals** and **Autos** windows. These are variable values that have been changed since the last evaluation. The change could be from a previous debugging session, or because the value was changed in the window.  
 
 ## Changing the numeric format of a variable window  
- The default numeric format is decimal, but you can change it to hexadecimal. Right-click inside a **Locals** or **Autos** window and select **Hexadecimal Display**. The change affects all debugger windows.  
+The default numeric format is decimal, but you can change it to hexadecimal. Right-click inside a **Locals** or **Autos** window and select **Hexadecimal Display**. The change affects all debugger windows.  
 
 ## Editing a Value in a Variable Window  
- You can edit the values of most variables that appear in the **Autos**, **Locals**, **Watch**, and **QuickWatch** windows. For information about **Watch** and **QuickWatch** windows, see [Watch and QuickWatch Windows](../debugger/watch-and-quickwatch-windows.md). Just double-click the value you want to change and add the new the value.  
-  
- You can enter an expression for a value, for example `a + b`. The debugger accepts most valid language expressions.  
+You can edit the values of most variables that appear in the **Autos**, **Locals**, **Watch**, and **QuickWatch** windows. For information about **Watch** and **QuickWatch** windows, see [Watch and QuickWatch Windows](../debugger/watch-and-quickwatch-windows.md). Just double-click the value you want to change and add the new the value.  
 
- In native C++ code, you might have to qualify the context of a variable name. For more information, see [Context Operator (C++)](../debugger/context-operator-cpp.md).  
+You can enter an expression for a value, for example `a + b`. The debugger accepts most valid language expressions.  
 
- However, you should exercise caution when changing values. Here are some possible issues:  
+In native C++ code, you might have to qualify the context of a variable name. For more information, see [Context Operator (C++)](../debugger/context-operator-cpp.md).  
+ 
+However, you should exercise caution when changing values. Here are some possible issues:  
 
 -   Evaluating some expressions can change the value of a variable or otherwise affect the state of your program. For example, evaluating `var1 = ++var2` changes the value of `var1` and `var2`.  
 
@@ -151,11 +144,11 @@ private static int subtractVars(int i, int j)
 -   Editing floating-point values can result in minor inaccuracies because of decimal-to-binary conversion of fractional components. Even a seemingly harmless edit can result in changes to some of the least significant bits in the floating-point variable.  
 
 ## Debug Location toolbar  
- You can use the **Debug Location** toolbar to select the desired function, thread, or process. Set a breakpoint and start debugging. (If you do not see this toolbar, you can enable it by clicking in an empty part of the toolbar area. You should see a list of toolbars; select **Debug Location**). When the breakpoint is hit, execution stops and you can see the Debug Location toolbar, which is the bottom row of the following graphic:  
+You can use the **Debug Location** toolbar to select the desired function, thread, or process. Set a breakpoint and start debugging. (If you do not see this toolbar, you can enable it by clicking in an empty part of the toolbar area. You should see a list of toolbars; select **Debug Location**). When the breakpoint is hit, execution stops and you can see the Debug Location toolbar, which is the bottom row of the following graphic:
 
- ![DebugLocationToolbar](../debugger/media/debuglocationtoolbar.png "DebugLocationToolbar")  
+![DebugLocationToolbar](../debugger/media/debuglocationtoolbar.png "DebugLocationToolbar")  
 
- You can also change the context to different function calls, threads, or processes by  double-clicking the element in the **Call Stack** window, the **Threads** window, or the **Processes** window.  
+You can also change the context to different function calls, threads, or processes by  double-clicking the element in the **Call Stack** window, the **Threads** window, or the **Processes** window.  
 
 ## See Also  
  [Debugger Windows](../debugger/debugger-windows.md)

docs/debugger/autos-and-locals-windows.md

@@ -34,7 +34,7 @@ Begins a capture interval that will end with `EndCapture`.
 
 ## Syntax  
 
-```cpp  
+```C++  
 void BeginCapture();  
 ```  
 

docs/debugger/begincapture.md

@@ -34,7 +34,7 @@ Captures the remainder of the current frame to the graphics log file.
 
 ## Syntax  
 
-```cpp  
+```C++  
 void CaptureCurrentFrame();  
 ```  
 

docs/debugger/capturecurrentframe.md

@@ -55,21 +55,21 @@ You can use the context operator in C++ to qualify a breakpoint location, variab
 
      For example, to set a breakpoint at the `SomeFunction` function of EXAMPLE.dll:  
 
-    ```cpp  
+    ```C++  
     {,,EXAMPLE.dll}SomeFunction  
     ```  
 
 2.  *module*!*expression*  
 
-    ```cpp  
+    ```C++  
     EXAMPLE.dll!SomeFunction  
     ```  
 
 -   *module* is the name of a module. You can use a full path to disambiguate between modules with the same name.  
 
      If the *module* path includes a comma, an embedded space, or a brace, you must use quotation marks around the path so that the context parser can properly recognize the string. Single quotation marks are considered part of a Windows file name, so you must use double quotation marks. For example,  
 
-    ```cpp  
+    ```C++  
     {,,"a long, long, library name.dll"} g_Var  
     ```  
 

docs/debugger/context-operator-cpp.md

@@ -34,7 +34,7 @@ Copies the contents of the active graphics log (.vsglog) file into a new file.
 
 ## Syntax  
 
-```cpp  
+```C++  
 void Copy(  
   wchar_t const * szNewVSGLog  
 );  

docs/debugger/copy-programmatic-capture.md

@@ -38,7 +38,7 @@ Specifies the symbol's basic type.
 
 ## Syntax  
 
-```cpp#  
+```C++  
 enum BasicType {   
    btNoType   = 0,  
    btVoid     = 1,  

docs/debugger/debug-interface-access/basictype.md

@@ -54,7 +54,7 @@ These string constants can be used to identify various sections of a program deb
 ## Example  
  Here is an example using one of these symbols:  
 
-```cpp#  
+```C++  
 HRESULT GetSymbolTable(IDiaEnumTables *pEnumTables, IDiaTable **pTable)  
 {  
     HRESULT hr;  

docs/debugger/debug-interface-access/constants-debug-interface-access-sdk.md

@@ -38,7 +38,7 @@ Specifies the scope of visibility (access level) of member functions and variabl
 
 ## Syntax  
 
-```cpp#  
+```C++  
 typedef enum CV_access_e {   
    CV_private   = 1,  
    CV_protected = 2,