Fix a bunch of "See x for more information"

3836425+corob-msft@users.noreply.github.com · 3836425+corob-msft@users.noreply.github.com · commit a87038beaa8d · 2022-03-02T08:59:09.000-08:00
diff --git a/docs/assembler/inline/masm-macro-directives-in-inline-assembly.md b/docs/assembler/inline/masm-macro-directives-in-inline-assembly.md
@@ -9,7 +9,7 @@ ms.assetid: 83643a09-1699-40a8-8ef2-13502bc4ac2c
 
 **Microsoft Specific**
 
-The inline assembler isn't a macro assembler. You can't use MASM macro directives (`MACRO`, `REPT`, `IRC`, `IRP`, and `ENDM`) or macro operators (**`<>`**, **`!`**, **`&`**, **`%`**, and `.TYPE`). An **`__asm`** block can use C preprocessor directives, however. See [Using C or C++ in `__asm` blocks](../../assembler/inline/using-c-or-cpp-in-asm-blocks.md) for more information.
+The inline assembler isn't a macro assembler. You can't use MASM macro directives (`MACRO`, `REPT`, `IRC`, `IRP`, and `ENDM`) or macro operators (**`<>`**, **`!`**, **`&`**, **`%`**, and `.TYPE`). An **`__asm`** block can use C preprocessor directives, however. For more information, see [Using C or C++ in `__asm` blocks](../../assembler/inline/using-c-or-cpp-in-asm-blocks.md).
 
 **END Microsoft Specific**
 
diff --git a/docs/build/adding-references-in-visual-cpp-projects.md b/docs/build/adding-references-in-visual-cpp-projects.md
@@ -12,7 +12,7 @@ C++ projects often need to call functions or access data in a binary file such a
 
 ## Consuming libraries downloaded via vcpkg
 
-To consume a library that you have downloaded by using the **vcpkg** package manager, you can ignore the instructions below. See [vcpkg.io](https://vcpkg.io/) for more information.
+To consume a library that you have downloaded by using the **vcpkg** package manager, you can ignore the instructions below. For more information, see [vcpkg.io](https://vcpkg.io/).
 
 ## Consuming static libraries
 
@@ -33,7 +33,7 @@ If the DLL gets built as part of the same solution as the application, follow th
 
 If the DLL isn't part of the application solution, you need: the DLL file, the header(s) with prototypes for the exported functions and classes, and a LIB file that provides the necessary linking information.
 
-1. Copy the DLL to the output folder of your project, or to another folder in the standard Windows search path for DLLs. See [Dynamic-Link Library Search Order](/windows/win32/dlls/dynamic-link-library-search-order).
+1. Copy the DLL to the output folder of your project, or to another folder in the standard Windows search path for DLLs. For more information, see [Dynamic-Link Library Search Order](/windows/win32/dlls/dynamic-link-library-search-order).
 2. Follow steps 1-3 for static libraries to provide the paths to the headers and LIB file.
 
 ## COM objects
diff --git a/docs/build/cppproperties-schema-reference.md b/docs/build/cppproperties-schema-reference.md
@@ -6,7 +6,7 @@ helpviewer_keywords: ["CppProperties.json file [C++]"]
 ---
 # CppProperties.json reference
 
-Open Folder projects that don't use CMake can store project configuration settings for IntelliSense in a *CppProperties.json* file. (CMake projects use a [CMakeSettings.json](customize-cmake-settings.md) file.) A configuration consists of name/value pairs and defines #include paths, compiler switches, and other parameters. See [Open Folder projects for C++](open-folder-projects-cpp.md) for more information about how to add configurations in an Open Folder project. The following sections summarize the various settings. For a complete description of the schema, navigate to *CppProperties_schema.json*, whose full path is given at the top of the code editor when *CppProperties.json* is open.
+Open Folder projects that don't use CMake can store project configuration settings for IntelliSense in a *CppProperties.json* file. (CMake projects use a [CMakeSettings.json](customize-cmake-settings.md) file.) A configuration consists of name/value pairs and defines #include paths, compiler switches, and other parameters. For more information about how to add configurations in an Open Folder project, see [Open Folder projects for C++](open-folder-projects-cpp.md). The following sections summarize the various settings. For a complete description of the schema, navigate to *CppProperties_schema.json*, whose full path is given at the top of the code editor when *CppProperties.json* is open.
 
 ## Configuration properties
 
diff --git a/docs/build/creating-precompiled-header-files.md b/docs/build/creating-precompiled-header-files.md
@@ -171,7 +171,7 @@ Beginning at the top of the diagram, both STABLEHDRS and BOUNDRY are NMAKE macro
 
 only if the precompiled header file (STABLE.pch) does not exist or if you make changes to the files listed in the two macros. In either case, the precompiled header file will contain code only from the files listed in the STABLEHDRS macro. List the last file you want precompiled in the BOUNDRY macro.
 
-The files you list in these macros can be either header files or C or C++ source files. (A single PCH file cannot be used with both C and C++ modules.) Note that you can use the **hdrstop** macro to stop precompilation at some point within the BOUNDRY file. See [hdrstop](../preprocessor/hdrstop.md) for more information.
+The files you list in these macros can be either header files or C or C++ source files. (A single PCH file cannot be used with both C and C++ modules.) Note that you can use the **hdrstop** macro to stop precompilation at some point within the BOUNDRY file. For more information, see [hdrstop](../preprocessor/hdrstop.md).
 
 Continuing down the diagram, APPLIB.obj represents the support code used in your final application. It is created from APPLIB.cpp, the files listed in the UNSTABLEHDRS macro, and precompiled code from the precompiled header.
 
diff --git a/docs/build/launch-vs-schema-reference-cpp.md b/docs/build/launch-vs-schema-reference-cpp.md
@@ -37,7 +37,7 @@ To create the file, right-click on an executable file in **Solution Explorer** a
 |--|--|--|
 | `program` | string | Full path to program executable on the remote machine. When using CMake, the macro `${debugInfo.fullTargetPath}` can be used as the value of this field. |
 | `processId` | integer | Optional process ID to attach the debugger to. |
-| `sourceFileMap` | object | Optional source file mappings passed to the debug engine. Format: `{ "\<Compiler source location>": "\<Editor source location>" }` or `{ "\<Compiler source location>": { "editorPath": "\<Editor source location>", "useForBreakpoints": true } }`. Example: `{ "/home/user/foo": "C:\\foo" }` or `{ "/home/user/foo": { "editorPath": "c:\\foo", "useForBreakpoints": true } }`. See [Source file map options](#source_file_map_options). |
+| `sourceFileMap` | object | Optional source file mappings passed to the debug engine. Format: `{ "\<Compiler source location>": "\<Editor source location>" }` or `{ "\<Compiler source location>": { "editorPath": "\<Editor source location>", "useForBreakpoints": true } }`. Example: `{ "/home/user/foo": "C:\\foo" }` or `{ "/home/user/foo": { "editorPath": "c:\\foo", "useForBreakpoints": true } }`. For more information, see [Source file map options](#source_file_map_options). |
 | `additionalProperties` | string | One of the sourceFileMapOptions. (See below.) |
 | `MIMode` | string | Indicates the type of MI-enabled console debugger that the MIDebugEngine will connect to. Allowed values are `"gdb"`, `"lldb"`. |
 | `args` | array | Command-line arguments passed to the program. |
@@ -48,7 +48,7 @@ To create the file, right-click on an executable file in **Solution Explorer** a
 | `remoteMachineName` | string | The remote Linux machine that hosts gdb and the program to debug. Use the Connection Manager for adding new Linux machines. When using CMake, the macro `${debugInfo.remoteMachineName}` can be used as the value of this field. |
 | `miDebuggerPath` | string | The path to the MI-enabled debugger (such as gdb). When unspecified, it will search PATH first for the debugger. |
 | `miDebuggerServerAddress` | string | Network address of the MI-enabled debugger server to connect to. Example: `"localhost:1234"`. |
-| `setupCommands` | array | One or more GDB/LLDB commands to execute to set up the underlying debugger. Example: `"setupCommands": [ { "text": "-enable-pretty-printing", "description": "Enable GDB pretty printing", "ignoreFailures": true }]`. See [Launch setup commands](#launch_setup_commands). |
+| `setupCommands` | array | One or more GDB/LLDB commands to execute to set up the underlying debugger. Example: `"setupCommands": [ { "text": "-enable-pretty-printing", "description": "Enable GDB pretty printing", "ignoreFailures": true }]`. For more information, see [Launch setup commands](#launch_setup_commands). |
 | `customLaunchSetupCommands` | array | If provided, this value replaces the default commands used to launch a target with some other commands. For example, use "-target-attach" to attach to a target process. An empty command list replaces the launch commands with nothing, which can be useful if the debugger is being provided launch options as command-line options. Example: `"customLaunchSetupCommands": [ { "text": "target-run", "description": "run target", "ignoreFailures": false }]`. |
 | `launchCompleteCommand` | string | The command to execute after the debugger is fully set up, to cause the target process to run. Allowed values are "exec-run", "exec-continue", "None". The default value is "exec-run". |
 | `debugServerPath` | string | Optional full path to debug server to launch. Defaults to null. |
diff --git a/docs/build/reference/advanced-property-page.md b/docs/build/reference/advanced-property-page.md
@@ -42,7 +42,7 @@ To programmatically access this property, see <xref:Microsoft.VisualStudio.VCPro
 
 Allows you to specify a non-default location for the log file that's created whenever you build a project. The default location is specified by the macros `$(IntDir)$(MSBuildProjectName).log`.
 
-You can use project macros to change the directory location. See [Common macros for build commands and properties](common-macros-for-build-commands-and-properties.md).
+You can use project macros to change the directory location. For more information, see [Common macros for build commands and properties](common-macros-for-build-commands-and-properties.md).
 
 ### Preferred Build Tool Architecture
 
diff --git a/docs/build/reference/bscmake-options.md b/docs/build/reference/bscmake-options.md
@@ -40,7 +40,7 @@ Displays a summary of the BSCMAKE command-line syntax.
 Includes unreferenced symbols. By default, BSCMAKE doesn't record any symbols that are defined but not referenced. If an *`.sbr`* file has been packed, this option has no effect for that input file because the compiler has already removed the unreferenced symbols.
 
 **/n**\
-Forces a nonincremental build. Use **/n** to force a full build of the browse information file whether a *`.bsc`* file exists or not, and to prevent *`.sbr`* files from being truncated. See [How BSCMAKE Builds a .bsc File](how-bscmake-builds-a-dot-bsc-file.md).
+Forces a nonincremental build. Use **/n** to force a full build of the browse information file whether a *`.bsc`* file exists or not, and to prevent *`.sbr`* files from being truncated. For more information, see [How BSCMAKE builds a `.bsc` file](how-bscmake-builds-a-dot-bsc-file.md).
 
 **/NOLOGO**\
 Suppresses the BSCMAKE copyright message.
diff --git a/docs/build/run-time-library-behavior.md b/docs/build/run-time-library-behavior.md
@@ -41,7 +41,7 @@ extern "C" BOOL WINAPI DllMain (
 Some libraries wrap the `DllMain` function for you. For example, in a regular MFC DLL, implement the `CWinApp` object's `InitInstance` and `ExitInstance` member functions to perform initialization and termination required by your DLL. For more details, see the [Initialize regular MFC DLLs](#initializing-regular-dlls) section.
 
 > [!WARNING]
-> There are significant limits on what you can safely do in a DLL entry point. See [General Best Practices](/windows/win32/Dlls/dynamic-link-library-best-practices) for specific Windows APIs that are unsafe to call in `DllMain`. If you need anything but the simplest initialization then do that in an initialization function for the DLL. You can require applications to call the initialization function after `DllMain` has run and before they call any other functions in the DLL.
+> There are significant limits on what you can safely do in a DLL entry point. For more information about specific Windows APIs that are unsafe to call in `DllMain`, see [General Best Practices](/windows/win32/Dlls/dynamic-link-library-best-practices). If you need anything but the simplest initialization then do that in an initialization function for the DLL. You can require applications to call the initialization function after `DllMain` has run and before they call any other functions in the DLL.
 
 <a name="initializing-non-mfc-dlls"></a>
 
diff --git a/docs/build/walkthrough-build-debug-wsl2.md b/docs/build/walkthrough-build-debug-wsl2.md
@@ -104,13 +104,13 @@ You've now built and debugged a C++ app with WSL 2 and Visual Studio 2022.
 
 Visual Studio only provides native support for WSL 2 for CMake projects that use `CMakePresets.json` as the active configuration file. To migrate from `CMakeSettings.json` to `CMakePresets.json`, see [Enable CMake Presets integration in Visual Studio](cmake-presets-vs.md#-enable--cmakepresetsjson-integration-in-visual-studio).
 
-If you're targeting a WSL 2 distribution and you don't want to use the WSL 2 toolset, then in the Visual Studio Remote Settings vendor map in `CMakePresets.json`, set **forceWSL1Toolset** to **true** . See [Visual Studio Remote Settings vendor map](cmake-presets-json-reference.md#visual-studio-remote-settings-vendor-map) for details.
+If you're targeting a WSL 2 distribution and you don't want to use the WSL 2 toolset, then in the Visual Studio Remote Settings vendor map in `CMakePresets.json`, set **forceWSL1Toolset** to **true** . For more information, see [Visual Studio Remote Settings vendor map](cmake-presets-json-reference.md#visual-studio-remote-settings-vendor-map).
 
 If **forceWSL1Tooslet** is set to **true**, then Visual Studio won't maintain a copy of your source files in the WSL file system. Instead, it will access source files in the mounted Windows drive (`/mnt/`…).
 
 In most cases, it’s best to use the WSL 2 toolset with WSL 2 distributions because WSL 2 is slower when project files are instead stored in the Windows file system. To learn more about file system performance in WSL 2, see [Comparing WSL 1 and WSL 2](/windows/wsl/compare-versions).
 
-Specify advanced settings such as the path to the directory on WSL 2 where the project will be copied, copy source options, and rsync command arguments, in the Visual Studio Remote Settings vendor map in `CMakePresets.json`. See [Visual Studio Remote Settings vendor map](cmake-presets-json-reference.md#visual-studio-remote-settings-vendor-map) for details.
+Specify advanced settings such as the path to the directory on WSL 2 where the project will be copied, copy source options, and rsync command arguments, in the Visual Studio Remote Settings vendor map in `CMakePresets.json`. For more information, see [Visual Studio Remote Settings vendor map](cmake-presets-json-reference.md#visual-studio-remote-settings-vendor-map).
 
 System headers are still automatically copied to the Windows file system to supply the native IntelliSense experience. You can customize the headers that are included or excluded from this copy in the Visual Studio Remote Settings vendor map in `CMakePresets.json`.
 
