diff --git a/docs/assembler/masm/dot-fpo.md b/docs/assembler/masm/dot-fpo.md
index 0e523fb9bf..7c70aab623 100644
--- a/docs/assembler/masm/dot-fpo.md
+++ b/docs/assembler/masm/dot-fpo.md
@@ -4,35 +4,34 @@ title: ".FPO"
 ms.date: "11/05/2019"
 f1_keywords: [".FPO"]
 helpviewer_keywords: [".FPO directive"]
-ms.assetid: 35f4cd61-32f9-4262-b657-73f04f775d09
 ---
 # .FPO (32-bit MASM)
 
-The **.FPO** directive controls the emission of debug records to the .debug$F segment or section. (32-bit MASM only.)
+The `.FPO` directive controls the emission of debug records to the `.debug$F` segment or section. Use this directive with 32-bit MASM only.
 
 ## Syntax
 
-> **.FPO** (*cdwLocals*, *cdwParams*, *cbProlog*, *cbRegs*, *fUseBP*, *cbFrame*)
+> `.FPO` (*`cdwLocals`*, *`cdwParams`*, *`cbProlog`*, *`cbRegs`*, *`fUseBP`*, *`cbFrame`*)
 
 ### Parameters
 
-*cdwLocals*\
-Number of local variables, an unsigned 32 bit value.
+*`cdwLocals`*\
+Number of local variables, an unsigned 32-bit value.
 
-*cdwParams*\
-Size of the parameters in DWORDS, an unsigned 16 bit value.
+*`cdwParams`*\
+Size of the parameters in DWORDS, an unsigned 16-bit value.
 
-*cbProlog*\
-Number of bytes in the function prolog code, an unsigned 8 bit value.
+*`cbProlog`*\
+Number of bytes in the function prolog code, an unsigned 8-bit value.
 
-*cbRegs*\
+*`cbRegs`*\
 Number registers saved.
 
-*fUseBP*\
-Indicates whether the EBP register has been allocated. either 0 or 1.
+*`fUseBP`*\
+Indicates whether the EBP register is allocated. Use either 0 or 1.
 
-*cbFrame*\
-Indicates the frame type.  See [FPO_DATA](/windows/win32/api/winnt/ns-winnt-fpo_data) for more information.
+*`cbFrame`*\
+Indicates the frame type. For more information, see [`FPO_DATA`](/windows/win32/api/winnt/ns-winnt-fpo_data).
 
 ## See also
 
diff --git a/docs/build/reference/choosing-the-format-of-netmodule-input-files.md b/docs/build/reference/choosing-the-format-of-netmodule-input-files.md
index 708f741e6a..86c167a0fb 100644
--- a/docs/build/reference/choosing-the-format-of-netmodule-input-files.md
+++ b/docs/build/reference/choosing-the-format-of-netmodule-input-files.md
@@ -2,32 +2,31 @@
 description: "Learn more about: Choosing the Format of .netmodule Input Files"
 title: "Choosing the Format of .netmodule Input Files"
 ms.date: "11/04/2016"
-ms.assetid: 4653d1bd-300f-4083-86f5-d1a06f44e61c
 ---
-# Choosing the Format of .netmodule Input Files
+# Choosing the format of .netmodule input files
 
-An MSIL .obj file (compiled with [/clr](clr-common-language-runtime-compilation.md)) can also be used as a .netmodule file.  .obj files contain metadata and native symbols.  .netmodules only contain metadata.
+You can use an MSIL `.obj` file (compiled with [`/clr`](clr-common-language-runtime-compilation.md)) as a `.netmodule` file. `.obj` files contain metadata and native symbols. `.netmodules` only contain metadata.
 
-You can pass an MSIL .obj file to any other Visual Studio compiler via the /addmodule compiler option (but be aware that the .obj file becomes part of the resulting assembly and must be shipped with the assembly).  For example, Visual C# and Visual Basic have the /addmodule compiler option.
+Pass an MSIL `.obj` file to any other Visual Studio compiler with the `/addmodule` compiler option. The `.obj` file becomes part of the resulting assembly and must be shipped with the assembly. For example, Visual C# and Visual Basic have the `/addmodule` compiler option.
 
 > [!NOTE]
-> In most cases, you will need to pass to the linker the .obj file from the compilation that created the .net module.  Passing a .dll or .netmodule MSIL module file to the linker may result in LNK1107.
+> In most cases, you need to pass to the linker the `.obj` file from the compilation that created the .net module. Passing a `.dll` or `.netmodule` MSIL module file to the linker might result in LNK1107.
 
-.obj files, along with their associated .h files, which you reference via #include in source, allow C++ applications to consume the native types in the module, whereas in a .netmodule file, only the managed types can be consumed by a C++ application.  If you attempt to pass a .obj file to #using, information about native types will not be available; #include the .obj file's .h file instead.
+`.obj` files, along with their associated `.h` files, which you reference via #include in source, allow C++ applications to consume the native types in the module. In a `.netmodule` file, only the managed types can be consumed by a C++ application. If you attempt to pass a `.obj` file to #using, information about native types isn't available. Instead, #include the `.obj` file's `.h` file.
 
 Other Visual Studio compilers can only consume managed types from a module.
 
-Use the following to determine whether you need to use a .netmodule or a .obj file as module input to the MSVC linker:
+Use the following guidance to determine whether you need to use a `.netmodule` or a `.obj` file as module input to the MSVC linker:
 
-- If you are building with a Visual Studio compiler other than Visual C++, produce a .netmodule and use the .netmodule as input to the linker.
+- If you're building with a Visual Studio compiler other than Visual C++, produce a `.netmodule` and use the `.netmodule` as input to the linker.
 
-- If you are using the MSVC compiler to produce modules and if the module(s) will be used to build something other than a library, use the .obj files produced by the compiler as module input to the linker; do not use the .netmodule file as input.
+- If you're using the MSVC compiler to produce modules and if the modules are used to build something other than a library, use the `.obj` files produced by the compiler as module input to the linker. Don't use the `.netmodule` file as input.
 
-- If your modules will be used to build a native (not a managed) library, use .obj files as module input to the linker and generate a .lib library file.
+- If your modules are used to build a native (not a managed) library, use `.obj` files as module input to the linker and generate a `.lib` library file.
 
-- If your modules will be used to build a managed library, and if all module input to the linker will be verifiable (produced with /clr:safe), use .obj files as module input to the linker and generate a .dll (assembly) or .netmodule (module) library file.
+- If your modules are used to build a managed library, and if all module input to the linker is verifiable (produced with `/clr:safe`), use `.obj` files as module input to the linker and generate a `.dll` (assembly) or `.netmodule` (module) library file.
 
-- If your modules will be used to build a managed library, and if one or more modules input to the linker will be produced with just /clr, use .obj files as module input to the linker and generate a .dll (assembly).  If you want to expose managed types from the library and if you also want C++ applications to consume the native types in the library, your library will consist of the .obj files for the libraries component modules (you will also want to ship the .h files for each module, so they can be referenced with #include from source code).
+- If your modules are used to build a managed library, and if one or more modules input to the linker are produced with just `/clr`, use `.obj` files as module input to the linker and generate a `.dll` (assembly). If you want to expose managed types from the library and if you also want C++ applications to consume the native types in the library, your library consists of the `.obj` files for the libraries component modules. You also want to ship the `.h` files for each module, so they can be referenced with #include from source code.
 
 ## See also
 
diff --git a/docs/build/reference/ln-create-msil-module.md b/docs/build/reference/ln-create-msil-module.md
index c1a892c54b..b5cd351176 100644
--- a/docs/build/reference/ln-create-msil-module.md
+++ b/docs/build/reference/ln-create-msil-module.md
@@ -4,11 +4,10 @@ title: "/LN (Create MSIL Module)"
 ms.date: "11/04/2016"
 f1_keywords: ["/LN"]
 helpviewer_keywords: ["-LN compiler option [C++]", "/LN compiler option [C++]"]
-ms.assetid: 4f38f4f4-3176-4caf-8200-5c7585dc1ed3
 ---
 # /LN (Create MSIL Module)
 
-Specifies that an assembly manifest should not be inserted into the output file.
+Specifies that the compiler shouldn't insert an assembly manifest into the output file.
 
 ## Syntax
 
@@ -18,27 +17,27 @@ Specifies that an assembly manifest should not be inserted into the output file.
 
 ## Remarks
 
-By default, **/LN** is not in effect (an assembly manifest is inserted into the output file).
+By default, `/LN` isn't in effect, and the compiler inserts an assembly manifest into the output file.
 
-When **/LN** is used, one of the [/clr (Common Language Runtime Compilation)](clr-common-language-runtime-compilation.md) options must also be used.
+When you use `/LN`, you must also use one of the [/clr (Common Language Runtime Compilation)](clr-common-language-runtime-compilation.md) options.
 
-A managed program that does not have an assembly metadata in the manifest is called a module. If you compile with [/c (Compile Without Linking)](c-compile-without-linking.md) and **/LN**, specify [/NOASSEMBLY (Create a MSIL Module)](noassembly-create-a-msil-module.md) in the linker phase to create the output file.
+A managed program that doesn't have assembly metadata in the manifest is called a module. If you compile with [/c (Compile Without Linking)](c-compile-without-linking.md) and `/LN`, specify [`/NOASSEMBLY `(Create a MSIL Module)](noassembly-create-a-msil-module.md) in the linker phase to create the output file.
 
-You may want to create modules if you want to take a component-based approach to building assemblies.  That is, you can author types and compile them into modules.  Then, you can generate an assembly from one or more modules.  For more information on creating assemblies from modules, see [.netmodule Files as Linker Input](netmodule-files-as-linker-input.md) or [Al.exe (Assembly Linker)](/dotnet/framework/tools/al-exe-assembly-linker).
+Create modules if you want to take a component-based approach to building assemblies. You can author types and compile them into modules. Then, you can generate an assembly from one or more modules. For more information on creating assemblies from modules, see [`.netmodule` Files as Linker Input](netmodule-files-as-linker-input.md) or [`Al.exe `(Assembly Linker)](/dotnet/framework/tools/al-exe-assembly-linker).
 
-The default file extension for a module is .netmodule.
+The default file extension for a module is `.netmodule`.
 
-In releases before Visual Studio 2005, a module was created with **/clr:noAssembly**.
+In releases before Visual Studio 2005, you created a module with `/clr:noAssembly`.
 
-The MSVC linker accepts .netmodule files as input and the output file produced by the linker will be an assembly or .netmodule with no run-time dependence on any of the .netmodules that were input to the linker.  For more information, see [.netmodule Files as Linker Input](netmodule-files-as-linker-input.md).
+The MSVC linker accepts `.netmodule` files as input. The output file produced by the linker is an assembly or `.netmodule` with no run-time dependence on any of the `.netmodule`s that you input to the linker. For more information, see [`.netmodule `Files as Linker Input](netmodule-files-as-linker-input.md).
 
 ### To set this compiler option in the Visual Studio development environment
 
-- Specify [/NOASSEMBLY (Create a MSIL Module)](noassembly-create-a-msil-module.md) in the linker phase to create the output file.
+- Specify [`/NOASSEMBLY` (Create a MSIL Module)](noassembly-create-a-msil-module.md) in the linker phase to create the output file.
 
 ### To set this compiler option programmatically
 
-- This compiler option cannot be changed programmatically.
+- You can't change this compiler option programmatically.
 
 ## See also
 
diff --git a/docs/extensions/safe-cast-cpp-component-extensions.md b/docs/extensions/safe-cast-cpp-component-extensions.md
index 800fe8605f..a35a3a2af9 100644
--- a/docs/extensions/safe-cast-cpp-component-extensions.md
+++ b/docs/extensions/safe-cast-cpp-component-extensions.md
@@ -5,11 +5,10 @@ ms.date: "10/12/2018"
 ms.topic: "reference"
 f1_keywords: ["safe_cast", "safe_cast_cpp", "stdcli::language::safe_cast"]
 helpviewer_keywords: ["safe_cast keyword [C++]"]
-ms.assetid: 4fa688bf-a8ec-49bc-a4c5-f48134efa4f7
 ---
 # safe_cast (C++/CLI and C++/CX)
 
-The **safe_cast** operation returns the specified expression as the specified type, if successful; otherwise, throws `InvalidCastException`.
+The **`safe_cast`** operation returns the specified expression as the specified type. If the operation isn't successful, it throws an `InvalidCastException`.
 
 ## All Runtimes
 
@@ -23,7 +22,7 @@ The **safe_cast** operation returns the specified expression as the specified ty
 
 ## Windows Runtime
 
-**safe_cast** allows you to change the type of a specified expression. In situations where you fully expect a variable or parameter to be convertible to a certain type, you can use **safe_cast** without a **try-catch** block to detect programming errors during development. For more information, see [Casting (C++/CX)](../cppcx/casting-c-cx.md).
+Use **`safe_cast`** to change the type of a specified expression. If you expect a variable or parameter to be convertible to a certain type, use **`safe_cast`** without a **try-catch** block to detect programming errors during development. For more information, see [Casting (C++/CX)](../cppcx/casting-c-cx.md).
 
 ### Syntax
 
@@ -41,7 +40,7 @@ An expression that evaluates to a handle to a reference or value type, a value t
 
 ### Remarks
 
-**safe_cast** throws `InvalidCastException` if it cannot convert *expression* to the type specified by *type-id*. To catch `InvalidCastException`, specify the [/EH (Exception Handling Model)](../build/reference/eh-exception-handling-model.md) compiler option, and use a **try/catch** statement.
+**`safe_cast`** throws `InvalidCastException` if it can't convert *expression* to the type specified by *type-id*. To catch `InvalidCastException`, specify the [/EH (Exception Handling Model)](../build/reference/eh-exception-handling-model.md) compiler option, and use a **try/catch** statement.
 
 ### Requirements
 
@@ -49,7 +48,7 @@ Compiler option: `/ZW`
 
 ### Examples
 
-The following code example demonstrates how to use **safe_cast** with the Windows Runtime.
+The following code example demonstrates how to use **`safe_cast`** with the Windows Runtime.
 
 ```cpp
 // safe_cast_ZW.cpp
@@ -83,7 +82,7 @@ Caught expected exception: InvalidCastException
 
 ## Common Language Runtime
 
-**safe_cast** allows you to change the type of an expression and generate verifiable MSIL code.
+**`safe_cast`** changes the type of an expression and generates verifiable MSIL code.
 
 ### Syntax
 
@@ -93,30 +92,29 @@ Caught expected exception: InvalidCastException
 
 ### Parameters
 
-*type-id*<br/>
+*`type-id`*\
 A handle to a reference or value type, a value type, or a tracking reference to a reference or value type.
 
-*expression*<br/>
+*`expression`*
 An expression that evaluates to a handle to a reference or value type, a value type, or a tracking reference to a reference or value type.
 
 ### Remarks
 
 The expression `safe_cast<`*type-id*`>(`*expression*`)` converts the operand *expression* to an object of type *type-id*.
 
-The compiler will accept a [static_cast](../cpp/static-cast-operator.md) in most places that it will accept a **safe_cast**.  However, **safe_cast** is guaranteed to produce verifiable MSIL, whereas a **`static_cast`** could produce unverifiable MSIL.  See [Pure and Verifiable Code (C++/CLI)](../dotnet/pure-and-verifiable-code-cpp-cli.md) and [Peverify.exe (PEVerify Tool)](/dotnet/framework/tools/peverify-exe-peverify-tool) for more information on verifiable code.
+The compiler accepts a [`static_cast`](../cpp/static-cast-operator.md) in most places that it accepts a **`safe_cast`**. However, **`safe_cast`** always produces verifiable MSIL, whereas a **`static_cast`** might produce unverifiable MSIL. For more information on verifiable code, see [Pure and Verifiable Code (C++/CLI)](../dotnet/pure-and-verifiable-code-cpp-cli.md) and [`Peverify.exe` (PEVerify Tool)](/dotnet/framework/tools/peverify-exe-peverify-tool).
 
-Like **`static_cast`**, **safe_cast** invokes user-defined conversions.
+Like **`static_cast`**, **`safe_cast`** invokes user-defined conversions.
 
 For more information about casts, see [Casting Operators](../cpp/casting-operators.md).
 
-**safe_cast** does not apply a **`const_cast`** (cast away **`const`**).
+**`safe_cast`** doesn't apply a **`const_cast`** (cast away **`const`**).
 
-**safe_cast** is in the cli namespace.  See [Platform, default, and cli Namespaces](platform-default-and-cli-namespaces-cpp-component-extensions.md) for more information.
+**`safe_cast`** is in the cli namespace. For more information, see [Platform, default, and cli Namespaces](platform-default-and-cli-namespaces-cpp-component-extensions.md).
 
-For more information on **safe_cast**, see:
+For more information on **`safe_cast`**, see:
 
 - [C-Style Casts with /clr (C++/CLI)](c-style-casts-with-clr-cpp-cli.md)
-
 - [How to: Use safe_cast in C++/CLI](../dotnet/how-to-use-safe-cast-in-cpp-cli.md)
 
 ### Requirements
@@ -125,7 +123,7 @@ Compiler option: `/clr`
 
 ### Examples
 
-One example of where the compiler will not accept a **`static_cast`** but will accept a **safe_cast** is for casts between unrelated interface types.  With **safe_cast**, the compiler will not issue a conversion error and will perform a check at runtime to see if the cast is possible
+One example of where the compiler doesn't accept a **`static_cast`** but accepts a **`safe_cast`** is for casts between unrelated interface types. With **`safe_cast`**, the compiler doesn't issue a conversion error and performs a check at runtime to see if the cast is possible.
 
 ```cpp
 // safe_cast.cpp
diff --git a/docs/overview/compiler-versions.md b/docs/overview/compiler-versions.md
index 60666e3f29..b167daf235 100644
--- a/docs/overview/compiler-versions.md
+++ b/docs/overview/compiler-versions.md
@@ -79,51 +79,51 @@ When the major version changed between Visual Studio 2013 and Visual Studio 2015
 
 An example of a minor change is from Visual Studio 2022 17.1 to Visual Studio 2022 17.2. In that case, `_MSC_VER` changed from 1931 to 1932.
 
-The following table lists the Visual C++ compiler `_MSC_VER` for each Visual Studio release:
-
-| Visual Studio version | `_MSC_VER` |
-|--|--|
-| Visual Studio 6.0 | 1200 |
-| Visual Studio .NET 2002 (7.0) | 1300 |
-| Visual Studio .NET 2003 (7.1) | 1310 |
-| Visual Studio 2005 (8.0) | 1400 |
-| Visual Studio 2008 (9.0) | 1500 |
-| Visual Studio 2010 (10.0) | 1600 |
-| Visual Studio 2012 (11.0) | 1700 |
-| Visual Studio 2013 (12.0) | 1800 |
-| Visual Studio 2015 (14.0) | 1900 |
-| Visual Studio 2017 RTW (15.0) | 1910 |
-| Visual Studio 2017 version 15.3 | 1911 |
-| Visual Studio 2017 version 15.5 | 1912 |
-| Visual Studio 2017 version 15.6 | 1913 |
-| Visual Studio 2017 version 15.7 | 1914 |
-| Visual Studio 2017 version 15.8 | 1915 |
-| Visual Studio 2017 version 15.9 | 1916 |
-| Visual Studio 2019 RTW 16.0 | 1920 |
-| Visual Studio 2019 version 16.1 | 1921 |
-| Visual Studio 2019 version 16.2 | 1922 |
-| Visual Studio 2019 version 16.3 | 1923 |
-| Visual Studio 2019 version 16.4 | 1924 |
-| Visual Studio 2019 version 16.5 | 1925 |
-| Visual Studio 2019 version 16.6 | 1926 |
-| Visual Studio 2019 version 16.7 | 1927 |
-| Visual Studio 2019 version 16.8, 16.9 <sup>a</sup> | 1928 |
-| Visual Studio 2019 version 16.10, 16.11 <sup>b</sup> | 1929 |
-| Visual Studio 2022 RTW 17.0 | 1930 |
-| Visual Studio 2022 version 17.1 | 1931 |
-| Visual Studio 2022 version 17.2 | 1932 |
-| Visual Studio 2022 version 17.3 | 1933 |
-| Visual Studio 2022 version 17.4 | 1934 |
-| Visual Studio 2022 version 17.5 | 1935 |
-| Visual Studio 2022 version 17.6 | 1936 |
-| Visual Studio 2022 version 17.7 | 1937 |
-| Visual Studio 2022 version 17.8 | 1938 |
-| Visual Studio 2022 version 17.9 | 1939 |
-| Visual Studio 2022 version 17.10 | 1940 |
-| Visual Studio 2022 version 17.11 | 1941 |
-| Visual Studio 2022 version 17.12 | 1942 |
-| Visual Studio 2022 version 17.13 | 1943 |
-| Visual Studio 2022 version 17.14 | 1944 |
+The following table lists the Visual Studio version corresponding to each Visual C++ compiler (`_MSC_VER`) and MSVC toolset release:
+
+| Visual Studio version | `_MSC_VER` | MSVC toolset version |
+|--|--|--|
+| Visual Studio 6.0 | 1200 | 6.0 |
+| Visual Studio .NET 2002 (7.0) | 1300 | 7.0 |
+| Visual Studio .NET 2003 (7.1) | 1310 | 7.1 |
+| Visual Studio 2005 (8.0) | 1400 | 8.0 |
+| Visual Studio 2008 (9.0) | 1500 | 9.0 |
+| Visual Studio 2010 (10.0) | 1600 | 10.0 |
+| Visual Studio 2012 (11.0) | 1700 | 11.0 |
+| Visual Studio 2013 (12.0) | 1800 | 12.0 |
+| Visual Studio 2015 (14.0) | 1900 | 14.0 |
+| Visual Studio 2017 RTW (15.0) | 1910 | 14.10 |
+| Visual Studio 2017 version 15.3 | 1911 | 14.11 |
+| Visual Studio 2017 version 15.5 | 1912 | 14.12 |
+| Visual Studio 2017 version 15.6 | 1913 | 14.13 |
+| Visual Studio 2017 version 15.7 | 1914 | 14.14 |
+| Visual Studio 2017 version 15.8 | 1915 | 14.15 |
+| Visual Studio 2017 version 15.9 | 1916 | 14.16 |
+| Visual Studio 2019 RTW 16.0 | 1920 | 14.20 |
+| Visual Studio 2019 version 16.1 | 1921 | 14.21 |
+| Visual Studio 2019 version 16.2 | 1922 | 14.22 |
+| Visual Studio 2019 version 16.3 | 1923 | 14.23 |
+| Visual Studio 2019 version 16.4 | 1924 | 14.24 |
+| Visual Studio 2019 version 16.5 | 1925 | 14.25 |
+| Visual Studio 2019 version 16.6 | 1926 | 14.26 |
+| Visual Studio 2019 version 16.7 | 1927 | 14.27 |
+| Visual Studio 2019 version 16.8, 16.9 <sup>a</sup> | 1928 | 14.28 |
+| Visual Studio 2019 version 16.10, 16.11 <sup>b</sup> | 1929 | 14.29 |
+| Visual Studio 2022 RTW 17.0 | 1930 | 14.30 |
+| Visual Studio 2022 version 17.1 | 1931 | 14.31 |
+| Visual Studio 2022 version 17.2 | 1932 | 14.32 |
+| Visual Studio 2022 version 17.3 | 1933 | 14.33 |
+| Visual Studio 2022 version 17.4 | 1934 | 14.34 |
+| Visual Studio 2022 version 17.5 | 1935 | 14.35 |
+| Visual Studio 2022 version 17.6 | 1936 | 14.36 |
+| Visual Studio 2022 version 17.7 | 1937 | 14.37 |
+| Visual Studio 2022 version 17.8 | 1938 | 14.38 |
+| Visual Studio 2022 version 17.9 | 1939 | 14.39 |
+| Visual Studio 2022 version 17.10 | 1940 | 14.40 |
+| Visual Studio 2022 version 17.11 | 1941 | 14.41 |
+| Visual Studio 2022 version 17.12 | 1942 | 14.42 |
+| Visual Studio 2022 version 17.13 | 1943 | 14.43 |
+| Visual Studio 2022 version 17.14 | 1944 | 14.44 |
 
 <sup>a</sup> Visual Studio 2019 16.8 and 16.9 share the same major and minor versions (and so have the same value for `_MSC_VER`). To distinguish them, use `_MSC_FULL_VER`. The minimum value of `_MSC_FULL_VER` for Visual Studio 2019 16.8 is 192829333. The minimum value of `_MSC_FULL_VER` for Visual Studio 2019 16.9 is 192829910.
 
