dotnet · gewarren · Dec 2, 2025 · Nov 28, 2025
@@ -17,16 +17,16 @@ Explicit assembly binding redirection in an application configuration file requi
 
  The permission is not required if assembly redirection is performed in a publisher policy file that is controlled by the component publisher, or in the machine configuration file that is controlled by the administrator. However, the permission is required for an application to explicitly ignore publisher policy using the [\<publisherPolicy apply="no"/>](./file-schema/runtime/publisherpolicy-element.md) element in the application configuration file.
 
- The following table shows the default security settings for the **BindingRedirects** flag.
+ The following table shows the default security settings for the `BindingRedirects` flag.
 
 | Zone                         | BindingRedirects flag setting |
 |------------------------------|-------------------------------|
-| Trusted Zone (local machine) | **ON**                        |
-| Intranet Zone                | **ON**                        |
-| Internet Zone                | **OFF**                       |
-| Untrusted zones              | **OFF**                       |
+| Trusted Zone (local machine) | `ON`                        |
+| Intranet Zone                | `ON`                        |
+| Internet Zone                | `OFF`                       |
+| Untrusted zones              | `OFF`                       |
 
- An administrator can change these security settings to support or restrict specific scenarios on a given computer. There are no tools for changing the **BindingRedirects** flag setting from the default; an administrator must manually edit the Security.config file on a user's computer.
+ An administrator can change these security settings to support or restrict specific scenarios on a given computer. There are no tools for changing the `BindingRedirects` flag setting from the default; an administrator must manually edit the Security.config file on a user's computer.
 
 ## See also
 

@@ -63,7 +63,7 @@ You can enable automatic binding redirects in existing apps that target older ve
    - In Visual Studio, select the project in **Solution Explorer**, and then choose **Open Folder in File Explorer** from the shortcut menu. In File Explorer, find the project (.csproj or .vbproj) file and open it in Notepad.
    - In Visual Studio, in **Solution Explorer**, right-click the project and choose **Unload Project**. Right-click the unloaded project again, and then choose **Edit [projectname.csproj]**.
 
-2. Add the following element to the first configuration property group (under the \<PropertyGroup> tag):
+2. Add the following element to the first configuration property group (under the `<PropertyGroup>` tag):
 
    ```xml
    <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
@@ -106,5 +106,5 @@ To add binding redirects to a **web.config** file:
 
 ## See also
 
-- [\<bindingRedirect> Element](./file-schema/runtime/bindingredirect-element.md)
+- [`<bindingRedirect>` Element](./file-schema/runtime/bindingredirect-element.md)
 - [Redirecting Assembly Versions](redirect-assembly-versions.md)
@@ -19,7 +19,7 @@ Developers might want to make sure that a shared assembly they are building work
 
  For example, assume that you are building a shared assembly called MySharedAssembly and the output directory is C:\MySharedAssembly\Debug. You can put C:\MySharedAssembly\Debug in the DEVPATH variable. You must then specify the [\<developmentMode>](./file-schema/runtime/developmentmode-element.md) element in the machine configuration file. This element tells the common language runtime to use DEVPATH to locate assemblies.
 
- The shared assembly must be discoverable by the runtime.  To specify a private directory for resolving assembly references use the [\<codeBase> Element](./file-schema/runtime/codebase-element.md) or [\<probing> Element](./file-schema/runtime/probing-element.md) in a configuration file, as described in [Specifying an Assembly's Location](specify-assembly-location.md).  You can also put the assembly in a subdirectory of the application directory. For more information, see [How the Runtime Locates Assemblies](../deployment/how-the-runtime-locates-assemblies.md).
+ The shared assembly must be discoverable by the runtime.  To specify a private directory for resolving assembly references use the [`<codeBase>` Element](./file-schema/runtime/codebase-element.md) or [`<probing>` Element](./file-schema/runtime/probing-element.md) in a configuration file, as described in [Specifying an Assembly's Location](specify-assembly-location.md).  You can also put the assembly in a subdirectory of the application directory. For more information, see [How the Runtime Locates Assemblies](../deployment/how-the-runtime-locates-assemblies.md).
 
 > [!NOTE]
 > This is an advanced feature, intended only for development.

@@ -54,7 +54,7 @@ This article describes the syntax of configuration files and provides informatio
 
  The machine configuration file, *Machine.config*, contains settings that apply to an entire computer. This file is located in the %*runtime install path*%\Config directory. *Machine.config* contains configuration settings for machine-wide assembly binding, built-in [remoting channels](/previous-versions/dotnet/netframework-4.0/dkfd3wha(v=vs.100)), and ASP.NET.
 
- The configuration system first looks in the machine configuration file for the [**\<appSettings>** element](./file-schema/appsettings/index.md) and other configuration sections that a developer might define. It then looks in the application configuration file. To keep the machine configuration file manageable, it is best to put these settings in the application configuration file. However, putting the settings in the machine configuration file can make your system more maintainable. For example, if you have a third-party component that both your client and server application uses, it is easier to put the settings for that component in one place. In this case, the machine configuration file is the appropriate place for the settings, so you don't have the same settings in two different files.
+ The configuration system first looks in the machine configuration file for the [`<appSettings>` element](./file-schema/appsettings/index.md) and other configuration sections that a developer might define. It then looks in the application configuration file. To keep the machine configuration file manageable, it is best to put these settings in the application configuration file. However, putting the settings in the machine configuration file can make your system more maintainable. For example, if you have a third-party component that both your client and server application uses, it is easier to put the settings for that component in one place. In this case, the machine configuration file is the appropriate place for the settings, so you don't have the same settings in two different files.
 
 > [!NOTE]
 > Deploying an application using XCOPY will not copy the settings in the machine configuration file.

@@ -15,15 +15,15 @@ ms.assetid: 01327c69-c5e1-4ef6-b73f-0a58351f0492
 
 There are four ways a developer can create a cryptography object using the Windows SDK:
 
-- Create an object by using the **new** operator.
+- Create an object by using the `new` operator.
 
-- Create an object that implements a particular cryptography algorithm by calling the **Create** method on the abstract class for that algorithm.
+- Create an object that implements a particular cryptography algorithm by calling the `Create` method on the abstract class for that algorithm.
 
 - Create an object that implements a particular cryptography algorithm by calling the <xref:System.Security.Cryptography.CryptoConfig.CreateFromName%2A?displayProperty=nameWithType> method.
 
-- Create an object that implements a class of cryptographic algorithms (such as a symmetric block cipher) by calling the **Create** method on the abstract class for that type of algorithm (such as <xref:System.Security.Cryptography.SymmetricAlgorithm>).
+- Create an object that implements a class of cryptographic algorithms (such as a symmetric block cipher) by calling the `Create` method on the abstract class for that type of algorithm (such as <xref:System.Security.Cryptography.SymmetricAlgorithm>).
 
- For example, suppose a developer wants to compute the SHA1 hash of a set of bytes. The <xref:System.Security.Cryptography> namespace contains two implementations of the SHA1 algorithm, one purely managed implementation and one that wraps CryptoAPI. The developer can choose to instantiate a particular SHA1 implementation (such as the <xref:System.Security.Cryptography.SHA1Managed>) by calling the **new** operator. However, if it does not matter which class the common language runtime loads as long as the class implements the SHA1 hash algorithm, the developer can create an object by calling the <xref:System.Security.Cryptography.SHA1.Create%2A?displayProperty=nameWithType> method. This method calls **System.Security.Cryptography.CryptoConfig.CreateFromName("System.Security.Cryptography.SHA1")**, which must return an implementation of the SHA1 hash algorithm.
+ For example, suppose a developer wants to compute the SHA1 hash of a set of bytes. The <xref:System.Security.Cryptography> namespace contains two implementations of the SHA1 algorithm, one purely managed implementation and one that wraps CryptoAPI. The developer can choose to instantiate a particular SHA1 implementation (such as the <xref:System.Security.Cryptography.SHA1Managed>) by calling the `new` operator. However, if it does not matter which class the common language runtime loads as long as the class implements the SHA1 hash algorithm, the developer can create an object by calling the <xref:System.Security.Cryptography.SHA1.Create%2A?displayProperty=nameWithType> method. This method calls **System.Security.Cryptography.CryptoConfig.CreateFromName("System.Security.Cryptography.SHA1")**, which must return an implementation of the SHA1 hash algorithm.
 
  The developer can also call **System.Security.Cryptography.CryptoConfig.CreateFromName("SHA1")** because, by default, cryptography configuration includes short names for the algorithms shipped in the .NET Framework.
 
@@ -57,9 +57,9 @@ There are four ways a developer can create a cryptography object using the Windo
 </configuration>
 ```
 
- You can specify the name of the attribute in the [<cryptoClass\> element](./file-schema/cryptography/cryptoclass-element.md) (the previous example names the attribute `MySHA1Hash`). The value of the attribute in the **\<cryptoClass>** element is a string that the common language runtime uses to find the class. You can use any string that meets the requirements specified in [Specifying Fully Qualified Type Names](../../fundamentals/reflection/specifying-fully-qualified-type-names.md).
+ You can specify the name of the attribute in the [`<cryptoClass>` element](./file-schema/cryptography/cryptoclass-element.md) (the previous example names the attribute `MySHA1Hash`). The value of the attribute in the `<cryptoClass>` element is a string that the common language runtime uses to find the class. You can use any string that meets the requirements specified in [Specifying Fully Qualified Type Names](../../fundamentals/reflection/specifying-fully-qualified-type-names.md).
 
- Many algorithm names can map to the same class. The [\<nameEntry> element](./file-schema/cryptography/nameentry-element.md) maps a class to one friendly algorithm name. The **name** attribute can be either a string that is used when calling the **System.Security.Cryptography.CryptoConfig.CreateFromName** method or the name of an abstract cryptography class in the <xref:System.Security.Cryptography> namespace. The value of the **class** attribute is the name of the attribute in the **\<cryptoClass>** element.
+ Many algorithm names can map to the same class. The [`<nameEntry>` element](./file-schema/cryptography/nameentry-element.md) maps a class to one friendly algorithm name. The `name` attribute can be either a string that is used when calling the **System.Security.Cryptography.CryptoConfig.CreateFromName** method or the name of an abstract cryptography class in the <xref:System.Security.Cryptography> namespace. The value of the `class` attribute is the name of the attribute in the `<cryptoClass>` element.
 
 > [!NOTE]
 > You can get an SHA1 algorithm by calling the <xref:System.Security.Cryptography.SHA1.Create%2A?displayProperty=nameWithType> or the **Security.CryptoConfig.CreateFromName("SHA1")** method. Each method guarantees only that it returns an object that implements the SHA1 algorithm. You do not have to map each friendly name of an algorithm to the same class in the configuration file.

@@ -36,7 +36,7 @@ Digital signatures ensure that data is not tampered with when it is sent from on
 </configuration>
 ```
 
- The [\<oidEntry> element](./file-schema/cryptography/oidentry-element.md) contains two attributes. The **OID** attribute is the object identifier number. The **name** attribute is the value of the **name** attribute from the [\<nameEntry> element](./file-schema/cryptography/nameentry-element.md). There must be a mapping from an algorithm name to a class before an object identifier can be mapped to a simple name.
+ The [`<oidEntry>` element](./file-schema/cryptography/oidentry-element.md) contains two attributes. The `OID` attribute is the object identifier number. The `name` attribute is the value of the `name` attribute from the [`<nameEntry>` element](./file-schema/cryptography/nameentry-element.md). There must be a mapping from an algorithm name to a class before an object identifier can be mapped to a simple name.
 
 ## See also
 

@@ -176,7 +176,7 @@ For example, to redirect one reference to a .NET Framework 3.5 assembly and anot
 ## See also
 
 - [How to: Enable and Disable Automatic Binding Redirection](how-to-enable-and-disable-automatic-binding-redirection.md)
-- [\<bindingRedirect> Element](./file-schema/runtime/bindingredirect-element.md)
+- [`<bindingRedirect>` Element](./file-schema/runtime/bindingredirect-element.md)
 - [Assembly Binding Redirection Security Permission](assembly-binding-redirection-security-permission.md)
 - [Assemblies in .NET](../../standard/assembly/index.md)
 - [Programming with Assemblies](../../standard/assembly/index.md)

@@ -20,9 +20,9 @@ There are two ways to specify an assembly's location:
 
  You can also use the [.NET Framework Configuration Tool (Mscorcfg.msc)](/previous-versions/dotnet/netframework-4.0/2bc0cxhc(v=vs.100)) to specify assembly locations or specify locations for the common language runtime to probe for assemblies.
 
-## Using the \<codeBase> Element
+## Using the `<codeBase>` Element
 
- You can use the **\<codeBase>** element only in machine configuration or publisher policy files that also redirect the assembly version. When the runtime determines which assembly version to use, it applies the code base setting from the file that determines the version. If no code base is indicated, the runtime probes for the assembly in the normal way. For details, see [How the Runtime Locates Assemblies](../deployment/how-the-runtime-locates-assemblies.md).
+ You can use the `<codeBase>` element only in machine configuration or publisher policy files that also redirect the assembly version. When the runtime determines which assembly version to use, it applies the code base setting from the file that determines the version. If no code base is indicated, the runtime probes for the assembly in the normal way. For details, see [How the Runtime Locates Assemblies](../deployment/how-the-runtime-locates-assemblies.md).
 
  The following example shows how to specify an assembly's location.
 
@@ -42,12 +42,12 @@ There are two ways to specify an assembly's location:
 </configuration>
 ```
 
- The **version** attribute is required for all strong-named assemblies but should be omitted for assemblies that are not strong-named. The **\<codeBase>** element requires the **href** attribute. You cannot specify version ranges in the **\<codeBase>** element.
+ The `version` attribute is required for all strong-named assemblies but should be omitted for assemblies that aren't strong-named. The `<codeBase>` element requires the `href` attribute. You cannot specify version ranges in the `<codeBase>` element.
 
 > [!NOTE]
 > If you are supplying a code base hint for an assembly that is not strong-named, the hint must point to the application base or a subdirectory of the application base directory.
 
-## Using the \<probing> Element
+## Using the `<probing>` Element
 
  The runtime locates assemblies that do not have a code base by probing. For more information about probing, see [How the Runtime Locates Assemblies](../deployment/how-the-runtime-locates-assemblies.md).
 
@@ -63,7 +63,7 @@ There are two ways to specify an assembly's location:
 </configuration>
 ```
 
- The **privatePath** attribute contains the directories that the runtime should search for assemblies. If the application is located at C:\Program Files\MyApp, the runtime will look for assemblies that do not specify a code base in C:\Program Files\MyApp\Bin, C:\Program Files\MyApp\Bin2\Subbin, and C:\Program Files\MyApp\Bin3. The directories specified in **privatePath** must be subdirectories of the application base directory.
+ The `privatePath` attribute contains the directories that the runtime should search for assemblies. If the application is located at C:\Program Files\MyApp, the runtime will look for assemblies that do not specify a code base in C:\Program Files\MyApp\Bin, C:\Program Files\MyApp\Bin2\Subbin, and C:\Program Files\MyApp\Bin3. The directories specified in `privatePath` must be subdirectories of the application base directory.
 
 ## See also