Prevent tags from loc

docs/core/compatibility/serialization/7.0/binaryformatter-apis-produce-errors.md

@@ -49,7 +49,7 @@ The best course of action is to migrate away from `BinaryFormatter` due to its s
 If you must suppress the errors, you can do so by following the guidelines in the [original obsoletion article](../5.0/binaryformatter-serialization-obsolete.md#recommended-action). You can also disable the error project-wide by setting a project property that converts the error back to a warning (to match the .NET 5/6 behavior).
 
 > [!WARNING]
-> Setting this property might change host behavior. See [\<EnableUnsafeBinaryFormatterSerialization> property](#enableunsafebinaryformatterserialization-property).
+> Setting this property might change host behavior. See [`<EnableUnsafeBinaryFormatterSerialization>` property](#enableunsafebinaryformatterserialization-property).
 
 ```csharp
 <PropertyGroup>
@@ -61,7 +61,7 @@ If you must suppress the errors, you can do so by following the guidelines in th
 > [!NOTE]
 > If your project compiles with "warnings as errors" enabled, compilation will still fail. (This matches the behavior that shipped in the .NET 5 and .NET 6 SDKs.) If that's the case, you'll still need to suppress the `SYSLIB0011` warning in source or in your project file's `<NoWarn>` element.
 
-### \<EnableUnsafeBinaryFormatterSerialization> property
+### `<EnableUnsafeBinaryFormatterSerialization>` property
 
 The `<EnableUnsafeBinaryFormatterSerialization` property was introduced in .NET 5. With .NET 7, the behavior of this switch has changed to control *both compilation and host* run-time behavior. The meaning of this switch differs based on the project type, as described in the following table.
 

docs/core/deploying/runtime-store.md

@@ -108,7 +108,7 @@ When the deployment is *trimmed* on publish, only the specific versions of the m
 
 ## Specifying target manifests in the project file
 
-An alternative to specifying target manifests with the [`dotnet publish`](../tools/dotnet-publish.md) command is to specify them in the project file as a semicolon-separated list of paths under a **\<TargetManifestFiles>** tag.
+An alternative to specifying target manifests with the [`dotnet publish`](../tools/dotnet-publish.md) command is to specify them in the project file as a semicolon-separated list of paths under a `<TargetManifestFiles>` tag.
 
 ```xml
 <PropertyGroup>
@@ -126,7 +126,7 @@ For .NET Core 2.0, the runtime package store feature is used implicitly by an AS
 
 The runtime package store is installed on the host when the .NET SDK is installed. Other installers may provide the runtime package store, including Zip/tarball installations of the .NET SDK, `apt-get`, Red Hat Yum, the .NET Core Windows Server Hosting bundle, and manual runtime package store installations.
 
-When deploying a [framework-dependent deployment](index.md#framework-dependent-deployment) app, make sure that the target environment has the .NET SDK installed. If the app is deployed to an environment that doesn't include ASP.NET Core, you can opt out of the implicit store by specifying  **\<PublishWithAspNetCoreTargetManifest>** set to `false` in the project file as in the following example:
+When deploying a [framework-dependent deployment](index.md#framework-dependent-deployment) app, make sure that the target environment has the .NET SDK installed. If the app is deployed to an environment that doesn't include ASP.NET Core, you can opt out of the implicit store by specifying  `<PublishWithAspNetCoreTargetManifest>` set to `false` in the project file as in the following example:
 
 ```xml
 <PropertyGroup>
@@ -135,7 +135,7 @@ When deploying a [framework-dependent deployment](index.md#framework-dependent-d
 ```
 
 > [!NOTE]
-> For [self-contained deployment](index.md#self-contained-deployment) apps, it's assumed that the target system doesn't necessarily contain the required manifest packages. Therefore, **\<PublishWithAspNetCoreTargetManifest>** cannot be set to `true` for an self-contained app.
+> For [self-contained deployment](index.md#self-contained-deployment) apps, it's assumed that the target system doesn't necessarily contain the required manifest packages. Therefore, `<PublishWithAspNetCoreTargetManifest>` cannot be set to `true` for an self-contained app.
 
 ## See also
 

docs/core/extensions/best-practices-for-developing-world-ready-apps.md

@@ -88,7 +88,7 @@ This section describes the best practices to follow when developing world-ready
 
 1. Specify the values for the `requestEncoding`, `responseEncoding`, `fileEncoding`, `culture`, and `uiCulture` attributes in the following three places in an ASP.NET application:
 
-    - In the globalization section of a _Web.config_ file. This file is external to the ASP.NET application. For more information, see [\<globalization> element](/previous-versions/dotnet/netframework-4.0/hy4kkhe0(v=vs.100)).
+    - In the globalization section of a _Web.config_ file. This file is external to the ASP.NET application. For more information, see [`<globalization>` element](/previous-versions/dotnet/netframework-4.0/hy4kkhe0(v=vs.100)).
     - In a page directive. Note that, when an application is in a page, the file has already been read. Therefore, it is too late to specify fileEncoding and requestEncoding. Only `uiCulture`, `culture`, and `responseEncoding` can be specified in a page directive.
     - Programmatically in application code. This setting can vary per request. As with a page directive, by the time the application's code is reached, it is too late to specify `fileEncoding` and `requestEncoding`. Only `uiCulture`, `culture`, and `responseEncoding` can be specified in the application code.
 

docs/core/tools/dependencies.md

@@ -9,7 +9,7 @@ ms.date: 01/28/2021
 
 This article explains how to add and remove package dependencies by editing the project file or by using the CLI.
 
-## The \<PackageReference> element
+## The `<PackageReference>` element
 
 The `<PackageReference>` project file element has the following structure:
 

docs/core/tutorials/library-with-visual-studio-code.md

@@ -33,7 +33,7 @@ Start by creating a .NET class library project named "StringLibrary" and an asso
 
 1. Name the project **StringLibrary** and select **Create Project**.
 
-1. Press Enter at the prompt **Project will be created in \<path>**.
+1. Press <kbd>Enter</kbd> at the prompt **Project will be created in \<path>**.
 
 1. Check to make sure that the library targets .NET 9. In **Explorer**, open *StringLibrary/StringLibrary.csproj*.
 

docs/core/unmanaged-api/debugging/icordebug/icordebugprocess6-enablevirtualmodulesplitting-method.md

@@ -42,11 +42,11 @@ The modules found in a container.
 regular modules
 Modules that were not merged at build time. They are neither container modules nor sub-modules.
 
-Both container modules and sub-modules are represented by ICorDebugModule interface objects. However, the behavior of the interface is slightly different in each case, as the \<x-ref to section> section describes.
+Both container modules and sub-modules are represented by `ICorDebugModule` interface objects. However, the behavior of the interface is slightly different in each case.
 
 ## Modules and assemblies
 
-Multi-module assemblies are not supported for assembly merging scenarios, so there is a one-to-one relationship between a module and an assembly. Each ICorDebugModule object, regardless of whether it represents a container module or a sub-module, has a corresponding ICorDebugAssembly object. The [ICorDebugModule::GetAssembly](icordebugmodule-getassembly-method.md) method converts from the module to the assembly. To map in the other direction, the [ICorDebugAssembly::EnumerateModules](icordebugassembly-enumeratemodules-method.md) method enumerates only 1 module. Because assembly and module form a tightly coupled pair in this case, the terms assembly and module become largely interchangeable.
+Multi-module assemblies are not supported for assembly merging scenarios, so there is a one-to-one relationship between a module and an assembly. Each `ICorDebugModule` object, regardless of whether it represents a container module or a sub-module, has a corresponding ICorDebugAssembly object. The [ICorDebugModule::GetAssembly](icordebugmodule-getassembly-method.md) method converts from the module to the assembly. To map in the other direction, the [ICorDebugAssembly::EnumerateModules](icordebugassembly-enumeratemodules-method.md) method enumerates only 1 module. Because assembly and module form a tightly coupled pair in this case, the terms assembly and module become largely interchangeable.
 
 ## Behavioral differences
 
@@ -102,7 +102,7 @@ The following table shows how virtual module splitting affects the behavior of o
 |[ICorDebugClass::GetModule](icordebugclass-getmodule-method.md)|Returns the sub-module this class was originally defined in.|Returns the container module this class was merged into.|
 |ICorDebugModuleDebugEvent::GetModule|Returns the container module that was loaded. Sub-modules are not given load events regardless of this setting.|Returns the container module that was loaded.|
 |[ICorDebugAppDomain::EnumerateAssemblies](icordebugappdomain-enumerateassemblies-method.md)|Returns a list of sub-assemblies and regular assemblies; no container assemblies are included. **Note:**  If any container assembly is missing symbols, none of its sub-assemblies will be enumerated. If any regular assembly is missing symbols, it may or may not be enumerated.|Returns a list of container assemblies and regular assemblies; no sub-assemblies are included. **Note:**  If any regular assembly is missing symbols, it may or may not be enumerated.|
-|[ICorDebugCode::GetCode](icordebugcode-getcode-method.md) (when referring to IL code only)|Returns IL that would be valid in a pre-merge assembly image. Specifically, any inline metadata tokens will correctly be TypeRef or MemberRef tokens when the types being referred to are not defined in the virtual module containing the IL. These TypeRef or MemberRef tokens can be looked up in the [IMetaDataImport](../../metadata/interfaces/imetadataimport-interface.md) object for the corresponding virtual ICorDebugModule object.|Returns the IL in the post-merge assembly image.|
+|[ICorDebugCode::GetCode](icordebugcode-getcode-method.md) (when referring to IL code only)|Returns IL that would be valid in a pre-merge assembly image. Specifically, any inline metadata tokens will correctly be TypeRef or MemberRef tokens when the types being referred to are not defined in the virtual module containing the IL. These TypeRef or MemberRef tokens can be looked up in the [IMetaDataImport](../../metadata/interfaces/imetadataimport-interface.md) object for the corresponding virtual `ICorDebugModule` object.|Returns the IL in the post-merge assembly image.|
 
 ## Requirements