random cleanup (dotnet#40555)

docs/core/diagnostics/symbols.md

@@ -6,41 +6,41 @@ ms.date: 02/08/2021
 
 # Symbols
 
-Symbols are useful for debugging and other diagnostic tools. The contents of symbol files vary between languages, compilers, and platforms. At a very high level symbols are a mapping between the source code and the binary produced by the compiler. These mappings are used by tools like [Visual Studio](/visualstudio/debugger/what-is-debugging) and [Visual Studio Code](https://code.visualstudio.com/Docs/editor/debugging) to resolve source line number information or local variable names.
+Symbols are useful for debugging and other diagnostic tools. The contents of symbol files vary between languages, compilers, and platforms. At a high level, symbols are a mapping between the source code and the binary produced by the compiler. These mappings are used by tools like [Visual Studio](/visualstudio/debugger/what-is-debugging) and [Visual Studio Code](https://code.visualstudio.com/Docs/editor/debugging) to resolve source line number information or local variable names.
 
 The [Windows documentation on symbols](/windows/win32/dxtecharts/debugging-with-symbols) contain more detailed information on symbols for Windows, although many of the concepts apply to other platforms as well.
 
-## Learn about .NET's Portable PDB format
+## Learn about .NET's portable PDB format
 
-.NET Core introduces a new symbol file (PDB) format - the portable PDB. Unlike traditional PDBs which are Windows-only, portable PDBs can be created and read on all platforms.
+.NET Core introduced a new symbol file (PDB) format - the portable PDB. Unlike traditional PDBs, which are Windows-only, portable PDBs can be created and read on all platforms.
 
 ### What is a PDB?
 
 A PDB file is an auxiliary file produced by a compiler to provide other tools, especially debuggers, information about what is in the main executable file and how it was produced. For example, a debugger reads a PDB to map foo.cs line 12 to the right executable location so that it can set a breakpoint. The Windows PDB format has been around a long time, and it evolved from other native debugging symbol formats which were even older. It started out its life as a format for native (C/C++) programs. For the first release of the .NET Framework, the Windows PDB format was extended to support .NET.
 
-The Portable PDB format was introduced in .NET Core, and it's used by default when targeting .NET Core and .NET 5+. When targeting .NET Framework, you can enable Portable PDB symbols by specifying `<DebugType>portable</DebugType>` in your project file. The Portable PDB format is based on ECMA-335 metadata format. For more information, see [Portable PDB v1.0: Format Specification](https://github.com/dotnet/runtime/blob/main/docs/design/specs/PortablePdb-Metadata.md). Diagnostic tools can use the <xref:System.Reflection.Metadata> library to read Portable PDB files (for an example, see <xref:System.Reflection.Metadata.Document?displayProperty=nameWithType>).
+The Portable PDB format was introduced in .NET Core, and it's used by default when targeting .NET. When targeting .NET Framework, you can enable portable PDB symbols by specifying `<DebugType>portable</DebugType>` in your project file. The portable PDB format is based on ECMA-335 metadata format. For more information, see [Portable PDB v1.0: Format Specification](https://github.com/dotnet/runtime/blob/main/docs/design/specs/PortablePdb-Metadata.md). Diagnostic tools can use the <xref:System.Reflection.Metadata> library to read portable PDB files (for an example, see <xref:System.Reflection.Metadata.Document?displayProperty=nameWithType>).
 
 ## Use the correct PDB format for your scenario
 
-Neither portable PDBs nor Windows PDBs are supported everywhere, so you need to consider where your project will want to be used and debugged to decide which format to use. If you have a project that you want to be able to use and debug in both formats, you can use different build configurations and build the project twice to support both types of consumer.
+Neither portable PDBs nor Windows PDBs are supported everywhere. To decide which format to use, consider where your project will be used and debugged. If you have a project that you want to be able to use and debug in both formats, you can use different build configurations and build the project twice to support both types of consumer.
 
-### Support for Portable PDBs
+### Support for portable PDBs
 
-Portable PDBs can be read on any operating systems and is the recommended symbol format for managed code, but there are a number of legacy tools and applications where they aren't supported:
+A portable PDB can be read on any operating system and is the recommended symbol format for managed code. However, there are a number of legacy tools and applications where they aren't supported:
 
 * Applications targeting .NET Framework 4.7.1 or earlier: printing stack traces with mappings back to line numbers (such as in an ASP.NET error page). The name of methods is unaffected, only the source file names and line numbers are unsupported.
 
-* Using .NET decompilers such as ildasm or .NET reflector and expecting to see source line mappings or local parameter names.
+* When you use .NET decompilers such as ildasm or .NET reflector, you won't see source line mappings or local parameter names.
 
-* The latest versions of [DIA](/visualstudio/debugger/debug-interface-access/debug-interface-access-sdk) and tools using it for reading symbols, such as WinDBG support Portable PDBs, but older versions do not.
+* The latest versions of [DIA](/visualstudio/debugger/debug-interface-access/debug-interface-access-sdk) and tools that use DIA for reading symbols, such as WinDBG, support portable PDBs, but older versions don't.
 
-* There may be older versions of profilers that do not support portable PDBs.
+* There might be older versions of profilers that don't support portable PDBs.
 
-To use portable PDBs on tools that do not support them, you can try using [Pdb2Pdb](https://github.com/dotnet/symreader-converter#pdb2pdb) which converts between Portable PDBs and Windows PDBs.
+To use portable PDBs on tools that do not support them, you can use [Pdb2Pdb](https://github.com/dotnet/symreader-converter#pdb2pdb), which converts between portable PDBs and Windows PDBs.
 
 ### Support for Windows PDBs
 
-Windows PDBs can only be written or read on Windows. Using Windows PDBs for managed code is obsolete and is only needed for legacy tools. It is recommended that you use portable PDBs instead of Windows PDBs as some newer compiler features that are implemented for only portable PDBs.
+Windows PDBs can only be written or read on Windows. Using Windows PDBs for managed code is obsolete and is only needed for legacy tools. It is recommended that you use portable PDBs instead of Windows PDBs, as some newer compiler features are implemented only for portable PDBs.
 
 ## See also
 

docs/csharp/advanced-topics/interop/walkthrough-office-programming.md

@@ -104,7 +104,7 @@ In Visual Studio, select **Clean Solution** on the **Build** menu. Otherwise, th
 
 1. Run the application again, but don't select **Clean Solution**.
 1. Select the **Start**. Locate **Microsoft Visual Studio \<version>** and open a developer command prompt.
-1. Type `ildasm` in the Developer Command Prompt for Visual Studio window, and then press ENTER. The IL DASM window appears.
+1. Type `ildasm` in the Developer Command Prompt for Visual Studio window, and then press <kbd>Enter</kbd>. The IL DASM window appears.
 1. On the **File** menu in the IL DASM window, select **File** > **Open**. Double-click **Visual Studio \<version>**, and then double-click **Projects**. Open the folder for your project, and look in the bin/Debug folder for *your project name*.dll. Double-click *your project name*.dll. A new window displays your project's attributes, in addition to references to other modules and assemblies. The assembly includes the namespaces `Microsoft.Office.Interop.Excel` and `Microsoft.Office.Interop.Word`. By default in Visual Studio, the compiler imports the types you need from a referenced PIA into your assembly. For more information, see [How to: View Assembly Contents](../../../standard/assembly/view-contents.md).
 1. Double-click the **MANIFEST** icon. A window appears that contains a list of assemblies that contain items referenced by the project. `Microsoft.Office.Interop.Excel` and `Microsoft.Office.Interop.Word` aren't in the list. Because you imported the types your project needs into your assembly, you aren't required to install references to a PIA. Importing the types into your assembly makes deployment easier. The PIAs don't have to be present on the user's computer. An application doesn't require deployment of a specific version of a PIA. Applications can work with multiple versions of Office, provided that the necessary APIs exist in all versions. Because deployment of PIAs is no longer necessary, you can create an application in advanced scenarios that works with multiple versions of Office, including earlier versions. Your code can't use any APIs that aren't available in the version of Office you're working with. It isn't always clear whether a particular API was available in an earlier version. Working with earlier versions of Office isn't recommended.
 1. Close the manifest window and the assembly window.