diff --git a/xml/System.Reflection.Context/CustomReflectionContext.xml b/xml/System.Reflection.Context/CustomReflectionContext.xml index 0e55d5bf7d5..63d27743ad5 100644 --- a/xml/System.Reflection.Context/CustomReflectionContext.xml +++ b/xml/System.Reflection.Context/CustomReflectionContext.xml @@ -34,8 +34,35 @@ Represents a customizable reflection context. - For more information about this API, see Supplemental API remarks for CustomReflectionContext. - + provides a way for you to add or remove custom attributes from reflection objects, or add dummy properties to those objects, without re-implementing the complete reflection model. The default simply wraps reflection objects without making any changes, but by subclassing and overriding the relevant methods, you can add, remove, or change the attributes that apply to any reflected parameter or member, or add new properties to a reflected type. + + For example, suppose that your code follows the convention of applying a particular attribute to factory methods, but you are now required to work with third-party code that lacks attributes. You can use to specify a rule for identifying the objects that should have attributes and to supply the objects with those attributes when they are viewed from your code. + + To use effectively, the code that uses the reflected objects must support the notion of specifying a reflection context, instead of assuming that all reflected objects are associated with the runtime reflection context. Many reflection methods in .NET provide a parameter for this purpose. + + To modify the attributes that are applied to a reflected parameter or member, override the or method. These methods take the reflected object and the list of attributes under its current reflection context, and return the list of attributes it should have under the custom reflection context. + +> [!WARNING] +> methods should not access the list of attributes of a reflected object or method directly by calling the method on the provided or instance, but should instead use the `declaredAttributes` list, which is passed as a parameter to the method overloads. + + To add properties to a reflected type, override the method. The method accepts a parameter that specifies the reflected type, and returns a list of additional properties. You should use the method to create property objects to return. You can specify delegates when creating the property that will serve as the property accessor, and you can omit one of the accessors to create a read-only or write-only property. Note that such dummy properties have no metadata or Common Intermediate Language (CIL) backing. + +> [!WARNING] +> Be cautious about equality among reflected objects when you work with reflection contexts, because objects may represent the same reflected object in multiple contexts. You can use the method to obtain a particular reflection context's version of a reflected object. + +> [!WARNING] +> A object alters the attributes returned by a particular reflection object, such as those obtained by the method. It does not alter the custom attribute data returned by the method, and these two lists will not match when you use a custom reflection context. + +## Examples + The following example demonstrates how to subclass to add a custom attribute to all the members of a given type whose names begin with "To". To run this code, paste it into an empty console project, and make sure to include a reference to System.Reflection.Context.dll. + + :::code language="csharp" source="~/snippets/csharp/System.Reflection.Context/CustomReflectionContext/Overview/program.cs" id="Snippet1"::: + + ]]> + diff --git a/xml/System.Reflection.Emit/AssemblyBuilder.xml b/xml/System.Reflection.Emit/AssemblyBuilder.xml index 359596f8c31..c8e078fcbc2 100644 --- a/xml/System.Reflection.Emit/AssemblyBuilder.xml +++ b/xml/System.Reflection.Emit/AssemblyBuilder.xml @@ -386,9 +386,8 @@ The following code example shows how to define and use a dynamic assembly. The e . @@ -413,15 +412,10 @@ The following code example shows how to define and use a dynamic assembly. The e -or- - The length of is greater than the system-defined maximum length. - - -or- - - .NET Framework only: A module with the same has already been defined in this assembly. - + The length of is greater than the system-defined maximum length. is . - .NET Core and .NET 5+ only: A dynamic module has already been defined in this assembly. + A dynamic module has already been defined in this assembly. The caller does not have the required permission. The assembly for default symbol writer cannot be loaded. @@ -458,7 +452,7 @@ The following code example shows how to define and use a dynamic assembly. The e The name of the dynamic module. When overridden in a derived class, defines a dynamic module in this assembly. A representing the defined dynamic module. - .NET Core and .NET 5+ support only one module per assembly. + Only one module per assembly is supported. @@ -870,7 +864,7 @@ The following code example shows how to define and use a dynamic assembly. The e The name of the requested dynamic module. When overridden in a derived class, returns the dynamic module with the specified name. A representing the requested dynamic module. - .NET Core and .NET 5+ support only one module per assembly.. + Only one module per assembly is supported. @@ -1524,8 +1518,6 @@ The following code example shows how to define and use a dynamic assembly. The e ## Remarks This method does not return a complete list of referenced assemblies. For example, if you apply a custom attribute to the , the assembly in which the attribute was defined is included in the list returned by this method. However, if you use a object to specify the type of a method parameter, that type is not included. - To get a complete list of referenced assemblies, save the assembly, load it into another application domain, and call the method. - ]]> @@ -1870,14 +1862,8 @@ The following code example shows how to define and use a dynamic assembly. The e Gets a value that indicates whether this dynamic assembly is held in a collectible . if this dynamic assembly is held in a collectible ; otherwise, . - - - + To be added. + diff --git a/xml/System.Reflection.Emit/AssemblyBuilderAccess.xml b/xml/System.Reflection.Emit/AssemblyBuilderAccess.xml index 6f9c8954d8d..d018cfc9a8e 100644 --- a/xml/System.Reflection.Emit/AssemblyBuilderAccess.xml +++ b/xml/System.Reflection.Emit/AssemblyBuilderAccess.xml @@ -50,7 +50,7 @@ Defines the access modes for a dynamic assembly. - This enumeration defines only two fields ( and ) in .NET. In .NET Framework, it defines an additional three fields (, , and ). For more information, see AssemblyBuilder class remarks. + For more information about this enumeration, see AssemblyBuilder class remarks. diff --git a/xml/System.Reflection.Emit/ConstructorBuilder.xml b/xml/System.Reflection.Emit/ConstructorBuilder.xml index 986aa484fe4..df42179c245 100644 --- a/xml/System.Reflection.Emit/ConstructorBuilder.xml +++ b/xml/System.Reflection.Emit/ConstructorBuilder.xml @@ -746,9 +746,7 @@ method has been called. In the .NET Framework versions 1.0 and 1.1, is thrown. In the .NET Framework version 2.0, is thrown. - - + This property is not supported until after the method has been called. ## Examples The code sample illustrates the use of `GetParameters`. @@ -758,10 +756,6 @@ ]]> - - has not been called on this constructor's type, in the .NET Framework versions 1.0 and 1.1. - - has not been called on this constructor's type, in the .NET Framework version 2.0. diff --git a/xml/System.Reflection.Emit/DynamicMethod.xml b/xml/System.Reflection.Emit/DynamicMethod.xml index 0a28c8596c8..87c0c9f3f08 100644 --- a/xml/System.Reflection.Emit/DynamicMethod.xml +++ b/xml/System.Reflection.Emit/DynamicMethod.xml @@ -61,7 +61,6 @@ The following code example creates a dynamic method that takes two parameters. T How to: Define and Execute Dynamic Methods Security Issues in Reflection Emit - Walkthrough: Emitting Code in Partial Trust Scenarios @@ -145,7 +144,7 @@ The following code example creates a dynamic method that takes two parameters. T constructor. @@ -153,19 +152,13 @@ The following code example creates a dynamic method that takes two parameters. T This constructor specifies the method attributes and , and the calling convention . -> [!NOTE] -> This constructor was introduced in the .NET Framework 3.5 or later. - ]]> An element of is or . is . - .NET Framework and .NET Core versions older than 2.1: - is a type for which returns . How to: Define and Execute Dynamic Methods Security Issues in Reflection Emit - Walkthrough: Emitting Code in Partial Trust Scenarios @@ -236,13 +229,13 @@ The following code example creates a dynamic method that takes two parameters. T A object that specifies the return type of the dynamic method, or if the method has no return type. An array of objects specifying the types of the parameters of the dynamic method, or if the method has no parameters. - to skip JIT visibility checks on types and members accessed by the MSIL of the dynamic method, with this restriction: the trust level of the assemblies that contain those types and members must be equal to or less than the trust level of the call stack that emits the dynamic method; otherwise, . + to skip JIT visibility checks on types and members accessed by the MSIL of the dynamic method; otherwise, . Initializes an anonymously hosted dynamic method, specifying the method name, return type, parameter types, and whether just-in-time (JIT) visibility checks should be skipped for types and members accessed by the Microsoft intermediate language (MSIL) of the dynamic method. with the flag. This is always true when the code is executed with full trust. For partially trusted code, it is true only if the host explicitly grants the permission. - - > [!IMPORTANT] - > If the permission has not been granted, a security exception is thrown when is called or when the dynamic method is invoked, not when this constructor is called. No special permissions are required to emit the dynamic method. +- The call stack that emits the dynamic method is granted with the flag. This is always true when the code is executed with full trust. - For example, a dynamic method that is created with `restrictedSkipVisibility` set to `true` can access a private member of any assembly on the call stack if the call stack has been granted restricted member access. If the dynamic method is created with partially trusted code on the call stack, it cannot access a private member of a type in a .NET Framework assembly, because such assemblies are fully trusted. + For example, a dynamic method that is created with `restrictedSkipVisibility` set to `true` can access a private member of any assembly on the call stack if the call stack has been granted restricted member access. If the dynamic method is created with partially trusted code on the call stack, it cannot access a private member of a type in a .NET assembly, because such assemblies are fully trusted. If `restrictedSkipVisibility` is `false`, JIT visibility checks are enforced. The code in the dynamic method has access to public methods of public classes, and exceptions are thrown if it tries to access types or members that are `private`, `protected`, or `internal`. @@ -263,19 +253,13 @@ The following code example creates a dynamic method that takes two parameters. T This constructor specifies the method attributes and , and the calling convention . -> [!NOTE] -> This constructor was introduced in the .NET Framework 3.5 or later. - ]]> An element of is or . is . - .NET Framework and .NET Core versions older than 2.1: - is a type for which returns . How to: Define and Execute Dynamic Methods Security Issues in Reflection Emit - Walkthrough: Emitting Code in Partial Trust Scenarios @@ -377,8 +361,6 @@ The following code example creates a dynamic method that takes two parameters. T -or- is . - .NET Framework and .NET Core versions older than 2.1: - is a type for which returns . How to: Define and Execute Dynamic Methods Security Issues in Reflection Emit @@ -475,9 +457,6 @@ The following code example creates a dynamic method that takes two parameters. T The example code creates an instance of `Example` and then creates two delegates. The first is of type `UseLikeStatic`, which has the same parameters as the dynamic method. The second is of type `UseLikeInstance`, which lacks the first parameter (of type `Example`). This delegate is created using the method overload; the second parameter of that method overload is an instance of `Example`, in this case the instance just created, which is bound to the newly created delegate. Whenever that delegate is invoked, the dynamic method acts on the bound instance of `Example`. -> [!NOTE] -> This is an example of the relaxed rules for delegate binding introduced in .NET Framework 2.0, along with new overloads of the method. For more information, see the class. - The `UseLikeStatic` delegate is invoked, passing in the instance of `Example` that is bound to the `UseLikeInstance` delegate. Then the `UseLikeInstance` delegate is invoked, so that both delegates act on the same instance of `Example`. The changes in the values of the internal field are displayed after each call. Finally, a `UseLikeInstance` delegate is bound to an instance of `DerivedFromExample`, and the delegate calls are repeated. :::code language="csharp" source="~/snippets/csharp/System.Reflection.Emit/DynamicMethod/.ctor/source.cs" id="Snippet1"::: @@ -496,8 +475,6 @@ The following code example creates a dynamic method that takes two parameters. T -or- is . - .NET Framework and .NET Core versions older than 2.1: - is a type for which returns . How to: Define and Execute Dynamic Methods Security Issues in Reflection Emit @@ -598,8 +575,6 @@ The following code example creates a dynamic method that takes two parameters. T -or- is . - .NET Framework and .NET Core versions older than 2.1: - is a type for which returns . How to: Define and Execute Dynamic Methods Security Issues in Reflection Emit @@ -700,8 +675,6 @@ The following code example creates a dynamic method that takes two parameters. T -or- is . - .NET Framework and .NET Core versions older than 2.1: - is a type for which returns . How to: Define and Execute Dynamic Methods Security Issues in Reflection Emit @@ -1212,9 +1185,6 @@ The following code example creates a dynamic method that takes two parameters. T The example code creates an instance of `Example` and then creates two delegates. The first is of type `UseLikeStatic`, which has the same parameters as the dynamic method. The second is of type `UseLikeInstance`, which lacks the first parameter (of type `Example`). This delegate is created using the method overload; the second parameter of that method overload is an instance of `Example`, in this case the instance just created, which is bound to the newly created delegate. Whenever that delegate is invoked, the dynamic method acts on the bound instance of `Example`. -> [!NOTE] -> This is an example of the relaxed rules for delegate binding introduced in .NET Framework 2.0, along with new overloads of the method. For more information, see the class. - The `UseLikeStatic` delegate is invoked, passing in the instance of `Example` that is bound to the `UseLikeInstance` delegate. Then the `UseLikeInstance` delegate is invoked, so that both delegates act on the same instance of `Example`. The changes in the values of the internal field are displayed after each call. Finally, a `UseLikeInstance` delegate is bound to an instance of `DerivedFromExample`, and the delegate calls are repeated. :::code language="csharp" source="~/snippets/csharp/System.Reflection.Emit/DynamicMethod/.ctor/source.cs" id="Snippet1"::: @@ -1823,8 +1793,6 @@ The following code example creates a dynamic method that takes two parameters. T ## Remarks The objects returned by this method are for information only. Use the method to set or change the characteristics of the parameters. - - ## Examples The following code example displays the parameters of a dynamic method. This code example is part of a larger example provided for the class. @@ -1881,8 +1849,6 @@ The following code example creates a dynamic method that takes two parameters. T ## Remarks If this property is set to `true`, the emitted Microsoft intermediate language (MSIL) includes initialization of local variables. If it is set to `false`, local variables are not initialized and the generated code is unverifiable. - - ## Examples The following code example displays the property of a dynamic method. This code example is part of a larger example provided for the class. @@ -1958,7 +1924,7 @@ The following code example creates a dynamic method that takes two parameters. T If the dynamic method has no parameters, the value of `parameters` should be `null`. Otherwise the number, type, and order of elements in the parameters array should be identical to the number, type, and order of parameters of the dynamic method. > [!NOTE] -> This method overload is called by the method overload inherited from the class, so the preceding remarks apply to both overloads. +> This method overload is called by the method overload inherited from the class, so the preceding remarks apply to both overloads. This method does not demand permissions directly, but invoking the dynamic method can result in security demands, depending on the method. For example, no demands are made for anonymously hosted dynamic methods that are created with the `restrictedSkipVisibility` parameter set to `false`. On the other hand, if you create a method with `restrictedSkipVisibility` set to `true` so it can access a hidden member of a target assembly, the method will cause a demand for the permissions of the target assembly plus with the flag. @@ -2084,46 +2050,31 @@ The following code example creates a dynamic method that takes two parameters. T ## Remarks The , , and properties report the transparency level of the dynamic method as determined by the common language runtime (CLR). The combinations of these properties are shown in the following table: -|Security level|IsSecurityCritical|IsSecuritySafeCritical|IsSecurityTransparent| -|--------------------|------------------------|----------------------------|---------------------------| -|Critical|`true`|`false`|`false`| -|Safe critical|`true`|`true`|`false`| -|Transparent|`false`|`false`|`true`| +| Security level | IsSecurityCritical | IsSecuritySafeCritical | IsSecurityTransparent | +|----------------|--------------------|------------------------|-----------------------| +| Critical | `true` | `false` | `false` | +| Safe critical | `true` | `true` | `false` | +| Transparent | `false` | `false` | `true` | Using these properties is much simpler than examining the security annotations of an assembly and its types, checking the current trust level, and attempting to duplicate the runtime's rules. The transparency of a dynamic method depends on the module it is associated with. If the dynamic method is associated with a type rather than a module, its transparency depends on the module that contains the type. Dynamic methods do not have security annotations, so they are assigned the default transparency for the associated module. - Anonymously hosted dynamic methods are always transparent, because the system-provided module that contains them is transparent. - - The transparency of a dynamic method that is associated with a trusted assembly (that is, a strong-named assembly that is installed in the global assembly cache) is described in the following table. - |Assembly annotation|Level 1 transparency|Level 2 transparency| - |-------------------------|--------------------------|--------------------------| - |Fully transparent|Transparent|Transparent| - |Fully critical|Critical|Critical| - |Mixed transparency|Transparent|Transparent| - |Security-agnostic|Safe-critical|Critical| - - For example, if you associate a dynamic method with a type that is in mscorlib.dll, which has level 2 mixed transparency, the dynamic method is transparent and cannot execute critical code. For information about transparency levels, see [Security-Transparent Code, Level 1](/dotnet/framework/misc/security-transparent-code-level-1) and [Security-Transparent Code, Level 2](/dotnet/framework/misc/security-transparent-code-level-2). + | Assembly annotation | Level 1 transparency | Level 2 transparency | + |---------------------|----------------------|----------------------| + | Fully transparent | Transparent | Transparent | + | Fully critical | Critical | Critical | + | Mixed transparency | Transparent | Transparent | + | Security-agnostic | Safe-critical | Critical | - > [!NOTE] - > Associating a dynamic method with a module in a trusted level 1 assembly that is security-agnostic, such as System.dll, does not permit elevation of trust. If the grant set of the code that calls the dynamic method does not include the grant set of System.dll (that is, full trust), is thrown when the dynamic method is called. - -- The transparency of a dynamic method that is associated with a partially trusted assembly depends on how the assembly is loaded. If the assembly is loaded with partial trust (for example, into a sandboxed application domain), the runtime ignores the security annotations of the assembly. The assembly and all its types and members, including dynamic methods, are treated as transparent. The runtime pays attention to security annotations only if the partial-trust assembly is loaded with full trust (for example, into the default application domain of a desktop application). In that case, the runtime assigns the dynamic method the default transparency for methods according to the assembly's annotations. - - For more information about reflection emit and transparency, see [Security Issues in Reflection Emit](/dotnet/framework/reflection-and-codedom/security-issues-in-reflection-emit). For information about transparency, see [Security Changes](/dotnet/framework/security/security-changes). + For example, if you associate a dynamic method with a type that is in mscorlib.dll, which has level 2 mixed transparency, the dynamic method is transparent and cannot execute critical code. ]]> The dynamic method doesn't have a method body. - - - Security Issues in Reflection Emit - Security Considerations for Reflection - Security Changes in the .NET Framework Version 4.0 - Security-Transparent Code, Level 1 - Security-Transparent Code, Level 2 @@ -2166,46 +2117,29 @@ The following code example creates a dynamic method that takes two parameters. T ## Remarks The , , and properties report the transparency level of the dynamic method as determined by the common language runtime (CLR). The combinations of these properties are shown in the following table: -|Security level|IsSecurityCritical|IsSecuritySafeCritical|IsSecurityTransparent| -|--------------------|------------------------|----------------------------|---------------------------| -|Critical|`true`|`false`|`false`| -|Safe critical|`true`|`true`|`false`| -|Transparent|`false`|`false`|`true`| +| Security level | IsSecurityCritical | IsSecuritySafeCritical | IsSecurityTransparent | +|----------------|--------------------|------------------------|-----------------------| +| Critical | `true` | `false` | `false` | +| Safe critical | `true` | `true` | `false` | +| Transparent | `false` | `false` | `true` | Using these properties is much simpler than examining the security annotations of an assembly and its types, checking the current trust level, and attempting to duplicate the runtime's rules. The transparency of a dynamic method depends on the module it is associated with. If the dynamic method is associated with a type rather than a module, its transparency depends on the module that contains the type. Dynamic methods do not have security annotations, so they are assigned the default transparency for the associated module. - Anonymously hosted dynamic methods are always transparent, because the system-provided module that contains them is transparent. - - The transparency of a dynamic method that is associated with a trusted assembly (that is, a strong-named assembly that is installed in the global assembly cache) is described in the following table. - |Assembly annotation|Level 1 transparency|Level 2 transparency| - |-------------------------|--------------------------|--------------------------| - |Fully transparent|Transparent|Transparent| - |Fully critical|Critical|Critical| - |Mixed transparency|Transparent|Transparent| - |Security-agnostic|Safe-critical|Critical| - - For example, if you associate a dynamic method with a type that is in mscorlib.dll, which has level 2 mixed transparency, the dynamic method is transparent and cannot execute critical code. For information about transparency levels, see [Security-Transparent Code, Level 1](/dotnet/framework/misc/security-transparent-code-level-1) and [Security-Transparent Code, Level 2](/dotnet/framework/misc/security-transparent-code-level-2). - - > [!NOTE] - > Associating a dynamic method with a module in a trusted level 1 assembly that is security-agnostic, such as System.dll, does not permit elevation of trust. If the grant set of the code that calls the dynamic method does not include the grant set of System.dll (that is, full trust), is thrown when the dynamic method is called. - -- The transparency of a dynamic method that is associated with a partially trusted assembly depends on how the assembly is loaded. If the assembly is loaded with partial trust (for example, into a sandboxed application domain), the runtime ignores the security annotations of the assembly. The assembly and all its types and members, including dynamic methods, are treated as transparent. The runtime pays attention to security annotations only if the partial-trust assembly is loaded with full trust (for example, into the default application domain of a desktop application). In that case, the runtime assigns the dynamic method the default transparency for methods according to the assembly's annotations. - - For more information about reflection emit and transparency, see [Security Issues in Reflection Emit](/dotnet/framework/reflection-and-codedom/security-issues-in-reflection-emit). For information about transparency, see [Security Changes](/dotnet/framework/security/security-changes). + | Assembly annotation | Level 1 transparency | Level 2 transparency | + |---------------------|----------------------|----------------------| + | Fully transparent | Transparent | Transparent | + | Fully critical | Critical | Critical | + | Mixed transparency | Transparent | Transparent | + | Security-agnostic | Safe-critical | Critical | ]]> The dynamic method doesn't have a method body. - - - Security Issues in Reflection Emit - Security Considerations for Reflection - Security Changes in the .NET Framework Version 4.0 - Security-Transparent Code, Level 1 - Security-Transparent Code, Level 2 @@ -2248,46 +2182,29 @@ The following code example creates a dynamic method that takes two parameters. T ## Remarks The , , and properties report the transparency level of the dynamic method as determined by the common language runtime (CLR). The combinations of these properties are shown in the following table: -|Security level|IsSecurityCritical|IsSecuritySafeCritical|IsSecurityTransparent| -|--------------------|------------------------|----------------------------|---------------------------| -|Critical|`true`|`false`|`false`| -|Safe critical|`true`|`true`|`false`| -|Transparent|`false`|`false`|`true`| +| Security level | IsSecurityCritical | IsSecuritySafeCritical | IsSecurityTransparent | +|----------------|--------------------|------------------------|-----------------------| +| Critical | `true` | `false` | `false` | +| Safe critical | `true` | `true` | `false` | +| Transparent | `false` | `false` | `true` | Using these properties is much simpler than examining the security annotations of an assembly and its types, checking the current trust level, and attempting to duplicate the runtime's rules. The transparency of a dynamic method depends on the module it is associated with. If the dynamic method is associated with a type rather than a module, its transparency depends on the module that contains the type. Dynamic methods do not have security annotations, so they are assigned the default transparency for the associated module. - Anonymously hosted dynamic methods are always transparent, because the system-provided module that contains them is transparent. - - The transparency of a dynamic method that is associated with a trusted assembly (that is, a strong-named assembly that is installed in the global assembly cache) is described in the following table. - |Assembly annotation|Level 1 transparency|Level 2 transparency| - |-------------------------|--------------------------|--------------------------| - |Fully transparent|Transparent|Transparent| - |Fully critical|Critical|Critical| - |Mixed transparency|Transparent|Transparent| - |Security-agnostic|Safe-critical|Critical| - - For example, if you associate a dynamic method with a type that is in mscorlib.dll, which has level 2 mixed transparency, the dynamic method is transparent and cannot execute critical code. For information about transparency levels, see [Security-Transparent Code, Level 1](/dotnet/framework/misc/security-transparent-code-level-1) and [Security-Transparent Code, Level 2](/dotnet/framework/misc/security-transparent-code-level-2). - - > [!NOTE] - > Associating a dynamic method with a module in a trusted level 1 assembly that is security-agnostic, such as System.dll, does not permit elevation of trust. If the grant set of the code that calls the dynamic method does not include the grant set of System.dll (that is, full trust), is thrown when the dynamic method is called. - -- The transparency of a dynamic method that is associated with a partially trusted assembly depends on how the assembly is loaded. If the assembly is loaded with partial trust (for example, into a sandboxed application domain), the runtime ignores the security annotations of the assembly. The assembly and all its types and members, including dynamic methods, are treated as transparent. The runtime pays attention to security annotations only if the partial-trust assembly is loaded with full trust (for example, into the default application domain of a desktop application). In that case, the runtime assigns the dynamic method the default transparency for methods according to the assembly's annotations. - - For more information about reflection emit and transparency, see [Security Issues in Reflection Emit](/dotnet/framework/reflection-and-codedom/security-issues-in-reflection-emit). For information about transparency, see [Security Changes](/dotnet/framework/security/security-changes). + | Assembly annotation | Level 1 transparency | Level 2 transparency | + |---------------------|----------------------|----------------------| + | Fully transparent | Transparent | Transparent | + | Fully critical | Critical | Critical | + | Mixed transparency | Transparent | Transparent | + | Security-agnostic | Safe-critical | Critical | ]]> The dynamic method doesn't have a method body. - - - Security Issues in Reflection Emit - Security Considerations for Reflection - Security Changes in the .NET Framework Version 4.0 - Security-Transparent Code, Level 1 - Security-Transparent Code, Level 2 diff --git a/xml/System.Reflection.Emit/EnumBuilder.xml b/xml/System.Reflection.Emit/EnumBuilder.xml index a92d791790a..7e6a6232bdd 100644 --- a/xml/System.Reflection.Emit/EnumBuilder.xml +++ b/xml/System.Reflection.Emit/EnumBuilder.xml @@ -65,18 +65,9 @@ [!NOTE] -> In the .NET Framework versions 1.0 and 1.1, it is necessary to define enumerations using because emits enumerations whose elements are of type instead of the enumeration type. In the .NET Framework version 2.0, emits enumerations whose elements have the correct type. - - - ## Examples - The following code example demonstrates the construction of an enumeration within a dynamic assembly, using `EnumBuilder`. The example defines an enumeration named `Elevation`, with an underlying type of , and creates two elements: `Low`, with a value of 0, and `High`, with a value of 1. After the type has been created, the assembly is saved with the name `TempAssembly.dll`. You can use the [Ildasm.exe (IL Disassembler)](/dotnet/framework/tools/ildasm-exe-il-disassembler) to examine the contents of this assembly. -> [!NOTE] -> Prior to the .NET Framework version 2.0, this code example does not produce a correct enumeration. +The following code example demonstrates the construction of an enumeration within a dynamic assembly, using `EnumBuilder`. The example defines an enumeration named `Elevation`, with an underlying type of , and creates two elements: `Low`, with a value of 0, and `High`, with a value of 1. After the type has been created, the assembly is saved with the name `TempAssembly.dll`. You can use the [Ildasm.exe (IL Disassembler)](/dotnet/framework/tools/ildasm-exe-il-disassembler) to examine the contents of this assembly. :::code language="csharp" source="~/snippets/csharp/System.Reflection.Emit/EnumBuilder/Overview/modulebuilder_defineenum.cs" id="Snippet1"::: :::code language="vb" source="~/snippets/visualbasic/System.Reflection.Emit/EnumBuilder/Overview/modulebuilder_defineenum.vb" id="Snippet1"::: @@ -600,17 +591,9 @@ The following code sample demonstrates the use of the `AssemblyQualifiedName` pr ## Remarks The defined field will have the field attributes , , and set. -> [!NOTE] -> In the .NET Framework versions 1.0 and 1.1, it is necessary to define enumerations using because emits enumerations whose elements are of type instead of the enumeration type. In the .NET Framework version 2.0, emits enumerations whose elements have the correct type. - - - ## Examples The following code example demonstrates the construction of an enumeration within a dynamic assembly, using `EnumBuilder`. The example defines an enumeration named `Elevation`, with an underlying type of , and creates two elements: `Low`, with a value of 0, and `High`, with a value of 1. After the type has been created, the assembly is saved with the name `TempAssembly.dll`. You can use the [Ildasm.exe (IL Disassembler)](/dotnet/framework/tools/ildasm-exe-il-disassembler) to examine the contents of this assembly. -> [!NOTE] -> Prior to the .NET Framework version 2.0, this code example does not produce a correct enumeration. - :::code language="csharp" source="~/snippets/csharp/System.Reflection.Emit/EnumBuilder/Overview/modulebuilder_defineenum.cs" id="Snippet1"::: :::code language="vb" source="~/snippets/visualbasic/System.Reflection.Emit/EnumBuilder/Overview/modulebuilder_defineenum.vb" id="Snippet1"::: diff --git a/xml/System.Reflection.Emit/FieldBuilder.xml b/xml/System.Reflection.Emit/FieldBuilder.xml index d140ef73b33..05e323038c4 100644 --- a/xml/System.Reflection.Emit/FieldBuilder.xml +++ b/xml/System.Reflection.Emit/FieldBuilder.xml @@ -738,7 +738,8 @@ . This is not CLS-compliant, but it can be useful in interop scenarios. + +`defaultValue` is restricted to the following types: `Boolean`, `SByte`, `Int16`, `Int32`, `Int64`, `Byte`, `UInt16`, `UInt32`, `UInt64`, `Single`, `Double`, `DateTime`, `Char`, `String`, and `Enum`. If the field type is a reference type, CLS compliance requires `defaultValue` to be `null`. However, `defaultValue` can be non-null for a reference type as long as the value can be assigned to that reference type. For example, an `Int32` value can be assigned to a field of type . This is not CLS-compliant, but it can be useful in interop scenarios. ]]> diff --git a/xml/System.Reflection.Emit/ILGenerator.xml b/xml/System.Reflection.Emit/ILGenerator.xml index f8d0c6529dc..13e7de462ed 100644 --- a/xml/System.Reflection.Emit/ILGenerator.xml +++ b/xml/System.Reflection.Emit/ILGenerator.xml @@ -1882,7 +1882,6 @@ The following code example emits two methods, a `varargs` method and a method th does not specify a method call. is . - The calling convention for the method is not , but optional parameter types are supplied. This exception is thrown in the .NET Framework versions 1.0 and 1.1, In subsequent versions, no exception is thrown. @@ -2455,8 +2454,6 @@ The following code example emits two methods, a `varargs` method and a method th property is accessed before any MSIL instructions have been emitted, it returns 0 (zero). When MSIL is generated for dynamic languages, this property can be used to map offsets in the MSIL stream to source code line numbers. The resulting information can be used to provide stack traces when exceptions are thrown. diff --git a/xml/System.Reflection.Emit/MethodBuilder.xml b/xml/System.Reflection.Emit/MethodBuilder.xml index 60bf1e986b3..83fbe3dd743 100644 --- a/xml/System.Reflection.Emit/MethodBuilder.xml +++ b/xml/System.Reflection.Emit/MethodBuilder.xml @@ -490,9 +490,6 @@ The following example uses the class Parameter numbering begins with 1, so `position` is 1 for the first parameter. If `position` is zero, this method affects the return value. -> [!NOTE] -> In the .NET Framework versions 1.0 and 1.1, an exception is thrown if `position` is zero, so this method cannot be used to modify attributes of the return value in those versions. - ]]> The method has no parameters. diff --git a/xml/System.Reflection.Emit/ModuleBuilder.xml b/xml/System.Reflection.Emit/ModuleBuilder.xml index 2d116aa9683..0926dd8fa63 100644 --- a/xml/System.Reflection.Emit/ModuleBuilder.xml +++ b/xml/System.Reflection.Emit/ModuleBuilder.xml @@ -313,13 +313,6 @@ [!IMPORTANT] -> Earlier versions of the .NET Framework throw instead of when `url` is `null`. - - - ## Examples The following code sample illustrates the use of `DefineDocument` to attach an external symbol document (in this case, a raw IL file) to a dynamic module. @@ -329,7 +322,7 @@ ]]> - is . This is a change from earlier versions of the .NET Framework. + is . This method is called on a dynamic module that is not a debug module. @@ -420,15 +413,9 @@ For more information about the built-in integer types that can be specified as the underlying types of enumerations, see [Class Library Overview](/dotnet/standard/class-library-overview). -> [!NOTE] -> In the .NET Framework versions 1.0 and 1.1, it is necessary to define enumerations using because emits enumerations whose elements are of type instead of the enumeration type. In the .NET Framework version 2.0, emits enumerations whose elements have the correct type. - ## Examples The following example illustrates the use of `DefineEnum` to implement an enumeration class in a dynamic module. The example defines an enumeration named `Elevation` that has an underlying type of , and creates two elements: `Low`, with a value of 0, and `High`, with a value of 1. After the type has been created, the assembly is saved with the name `TempAssembly.dll`. You can use the [Ildasm.exe (IL Disassembler)](/dotnet/framework/tools/ildasm-exe-il-disassembler) to examine the contents of this assembly. -> [!NOTE] -> Prior to the .NET Framework version 2.0, this code example does not produce a correct enumeration. - :::code language="csharp" source="~/snippets/csharp/System.Reflection.Emit/EnumBuilder/Overview/modulebuilder_defineenum.cs" id="Snippet1"::: :::code language="vb" source="~/snippets/visualbasic/System.Reflection.Emit/EnumBuilder/Overview/modulebuilder_defineenum.vb" id="Snippet1"::: diff --git a/xml/System.Reflection.Emit/OpCodes.xml b/xml/System.Reflection.Emit/OpCodes.xml index e1e225e9006..a9ebcc8950e 100644 --- a/xml/System.Reflection.Emit/OpCodes.xml +++ b/xml/System.Reflection.Emit/OpCodes.xml @@ -113,13 +113,13 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; `value1` is added to `value2`. +3. `value2` and `value1` are popped from the stack; `value1` is added to `value2`. -4. The result is pushed onto the stack. +4. The result is pushed onto the stack. Overflow is not detected for integer operations (for proper overflow handling, see ). @@ -129,26 +129,26 @@ The acceptable operand types and their corresponding result data type are listed in the table below. If there is no entry for a particular type combination (for example, `int32` and `float`; `int32` and `int64`), it is an invalid Microsoft Intermediate Language (MSIL) and generates an error. -|operand|value1 type|value2 type|result type| -|-------------|-----------------|-----------------|-----------------| -|add|`int32`|`int32`|`int32`| -|add|`int32`|`native int`|`native int`| -|add|`int32`|`&`|`&`| -|add|`int32`|`*`|`*`| -|add|`int64`|`int64`|`int64`| -|add|`native int`|`int32`|`native int`| -|add|`native int`|`native int`|`native int`| -|add|`native int`|`&`|`&`| -|add|`native int`|`*`|`*`| -|add|`F`|`F`|`F`| -|add|`&`|`int32`|`&`| -|add|`&`|`native int`|`&`| -|add|`*`|`int32`|`*`| -|add|`*`|`native int`|`*`| +| operand | value1 type | value2 type | result type | +|---------|--------------|--------------|--------------| +| add | `int32` | `int32` | `int32` | +| add | `int32` | `native int` | `native int` | +| add | `int32` | `&` | `&` | +| add | `int32` | `*` | `*` | +| add | `int64` | `int64` | `int64` | +| add | `native int` | `int32` | `native int` | +| add | `native int` | `native int` | `native int` | +| add | `native int` | `&` | `&` | +| add | `native int` | `*` | `*` | +| add | `F` | `F` | `F` | +| add | `&` | `int32` | `&` | +| add | `&` | `native int` | `&` | +| add | `*` | `int32` | `*` | +| add | `*` | `native int` | `*` | The following method overload can use the `add` opcode: -- +- ]]> @@ -205,13 +205,13 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; `value1` is added to `value2` with a check for overflow. +3. `value2` and `value1` are popped from the stack; `value1` is added to `value2` with a check for overflow. -4. The result is pushed onto the stack. +4. The result is pushed onto the stack. is thrown if the result is not represented in the result type. @@ -238,7 +238,7 @@ The following method overload can use the `add.ovf` opcode: -- +- ]]> @@ -295,13 +295,13 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; `value1` is added to `value2` with a check for overflow. +3. `value2` and `value1` are popped from the stack; `value1` is added to `value2` with a check for overflow. -4. The result is pushed onto the stack. +4. The result is pushed onto the stack. is thrown if the result is not represented in the result type. @@ -328,7 +328,7 @@ The following method overload can use the `add.ovf.un` opcode: -- +- ]]> @@ -385,13 +385,13 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value1` and `value2` are popped from the stack; the bitwise AND of the two values is computed. +3. `value1` and `value2` are popped from the stack; the bitwise AND of the two values is computed. -4. The result is pushed onto the stack. +4. The result is pushed onto the stack. The `and` instruction computes the bitwise AND of the top two values on the stack and leaves the result on the stack. @@ -399,7 +399,7 @@ The following method overload can use the `and` opcode: -- +- ]]> @@ -460,7 +460,7 @@ The following method overload can use the `arglist` opcode: -- +- ]]> @@ -517,11 +517,11 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; if `value1` is equal to `value2`, the branch operation is performed. +3. `value2` and `value1` are popped from the stack; if `value1` is equal to `value2`, the branch operation is performed. The `beq` instruction transfers control to the specified target instruction if `value1` is equal to `value2`. The effect is the same as performing a `ceq` instruction followed by a `brtrue` branch to the specific target instruction. The target instruction is represented as a 4-byte signed offset from the beginning of the instruction following the current instruction. @@ -533,7 +533,7 @@ The following method overload can use the `beq` opcode: -- +- ]]> @@ -590,11 +590,11 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; if `value1` is equal to `value2`, the branch operation is performed. +3. `value2` and `value1` are popped from the stack; if `value1` is equal to `value2`, the branch operation is performed. The `beq.s` instruction transfers control to the specified target instruction if `value1` is equal to `value2`. The effect is the same as performing a `ceq` instruction followed by a `brtrue` branch to the specific target instruction. The target instruction is represented as a 1-byte signed offset from the beginning of the instruction following the current instruction. @@ -606,7 +606,7 @@ The following method overload can use the `beq.s` opcode: -- +- ]]> @@ -663,11 +663,11 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; if `value1` is greater than or equal to `value2`, the branch operation is performed. +3. `value2` and `value1` are popped from the stack; if `value1` is greater than or equal to `value2`, the branch operation is performed. The `bge` instruction transfers control to the specified target instruction if `value1` is greater than or equal to `value2`. The effect is identical to performing a `clt` instruction (`clt.un` for floats) followed by a `brfalse` branch to the specific target instruction. The target instruction is represented as a 4-byte signed offset from the beginning of the instruction following the current instruction. @@ -675,7 +675,7 @@ The following method overload can use the `bge` opcode: -- +- ]]> @@ -732,11 +732,11 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; if `value1` is greater than or equal to `value2`, the branch operation is performed. +3. `value2` and `value1` are popped from the stack; if `value1` is greater than or equal to `value2`, the branch operation is performed. The `bge.s` instruction transfers control to the specified target instruction if `value1` is greater than or equal to `value2`. The effect is identical to performing a `clt` instruction (`clt.un` for floats) followed by a `brfalse` branch to the specific target instruction. The target instruction is represented as a 1-byte signed offset from the beginning of the instruction following the current instruction. @@ -744,7 +744,7 @@ The following method overload can use the `bge.s` opcode: -- +- ]]> @@ -801,11 +801,11 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; if `value1` is greater than or equal to `value2`, the branch operation is performed. +3. `value2` and `value1` are popped from the stack; if `value1` is greater than or equal to `value2`, the branch operation is performed. The `bge.un` instruction transfers control to the specified target instruction if `value1` is greater than or equal to `value2`, when compared using unsigned integer or unordered float values. The effect is identical to performing a `clt.un` instruction (`clt` for floats) followed by a `brfalse` branch to the specific target instruction. The target instruction is represented as a 4-byte signed offset from the beginning of the instruction following the current instruction. @@ -813,7 +813,7 @@ The following method overload can use the `bge.un` opcode: -- +- ]]> @@ -870,11 +870,11 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; if `value1` is greater than or equal to `value2`, the branch operation is performed. +3. `value2` and `value1` are popped from the stack; if `value1` is greater than or equal to `value2`, the branch operation is performed. The `bge.un.s` instruction transfers control to the specified target instruction if `value1` is greater than or equal to `value2`, when compared using unsigned integer or unordered float values. The effect is identical to performing a `clt.un` instruction (`clt` for floats) followed by a `brfalse` branch to the specific target instruction. The target instruction is represented as a 1-byte signed offset from the beginning of the instruction following the current instruction. @@ -882,7 +882,7 @@ The following method overload can use the `bge.un.s` opcode: -- +- ]]> @@ -939,11 +939,11 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; if `value1` is greater than `value2`, the branch operation is performed. +3. `value2` and `value1` are popped from the stack; if `value1` is greater than `value2`, the branch operation is performed. The `bgt` instruction transfers control to the specified target instruction if `value1` is greater than `value2`. The effect is identical to performing a `cgt` instruction followed by a `brtrue` branch to the specific target instruction. The target instruction is represented as a 4-byte signed offset from the beginning of the instruction following the current instruction. @@ -951,7 +951,7 @@ The following method overload can use the `bgt` opcode: -- +- ]]> @@ -1008,11 +1008,11 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; if `value1` is greater than `value2`, the branch operation is performed. +3. `value2` and `value1` are popped from the stack; if `value1` is greater than `value2`, the branch operation is performed. The `bgt.s` instruction transfers control to the specified target instruction if `value1` is greater than `value2`. The effect is identical to performing a `cgt` instruction followed by a `brtrue` branch to the specific target instruction. The target instruction is represented as a 1-byte signed offset from the beginning of the instruction following the current instruction. @@ -1020,7 +1020,7 @@ The following method overload can use the `bgt.s` opcode: -- +- ]]> @@ -1077,11 +1077,11 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; if `value1` is greater than `value2`, the branch operation is performed. +3. `value2` and `value1` are popped from the stack; if `value1` is greater than `value2`, the branch operation is performed. The `bgt.un` instruction transfers control to the specified target instruction if `value1` is greater than `value2`, when compared using unsigned integer or unordered float values. The effect is identical to performing a `cgt.un` instruction followed by a `brtrue` branch to the specific target instruction. The target instruction is represented as a 4-byte signed offset from the beginning of the instruction following the current instruction. @@ -1089,7 +1089,7 @@ The following method overload can use the `bgt.un` opcode: -- +- ]]> @@ -1146,11 +1146,11 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; if `value1` is greater than `value2`, the branch operation is performed. +3. `value2` and `value1` are popped from the stack; if `value1` is greater than `value2`, the branch operation is performed. The `bgt.un.s` instruction transfers control to the specified target instruction if `value1` is greater than `value2`, when compared using unsigned integer or unordered float values. The effect is identical to performing a `cgt.un` instruction followed by a `brtrue` branch to the specific target instruction. The target instruction is represented as a 1-byte signed offset from the beginning of the instruction following the current instruction. @@ -1158,7 +1158,7 @@ The following method overload can use the `bgt.un.s` opcode: -- +- ]]> @@ -1215,11 +1215,11 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; if `value1` is less than or equal to `value2`, the branch operation is performed. +3. `value2` and `value1` are popped from the stack; if `value1` is less than or equal to `value2`, the branch operation is performed. The `ble` instruction transfers control to the specified target instruction if `value1` is less than or equal to `value2`. The effect is identical to performing a `cgt` instruction (`cgt.un` for floats) followed by a `brfalse` branch to the specific target instruction. The target instruction is represented as a 4-byte signed offset from the beginning of the instruction following the current instruction. @@ -1227,7 +1227,7 @@ The following method overload can use the `ble` opcode: -- +- ]]> @@ -1284,11 +1284,11 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; if `value1` is less than or equal to `value2`, the branch operation is performed. +3. `value2` and `value1` are popped from the stack; if `value1` is less than or equal to `value2`, the branch operation is performed. The `ble.s` instruction transfers control to the specified target instruction if `value1` is less than or equal to `value2`. The effect is identical to performing a `cgt` instruction (`cgt.un` for floats) instruction followed by a`brfalse` branch to the specific target instruction. The target instruction is represented as a 1-byte signed offset from the beginning of the instruction following the current instruction. @@ -1296,7 +1296,7 @@ The following method overload can use the `ble.s` opcode: -- +- ]]> @@ -1353,11 +1353,11 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; if `value1` is less than or equal to `value2`, the branch operation is performed. +3. `value2` and `value1` are popped from the stack; if `value1` is less than or equal to `value2`, the branch operation is performed. The `ble.un` instruction transfers control to the specified target instruction if `value1` is less than or equal to `value2`, when compared using unsigned integer or unordered float values. The effect is identical to performing a `cgt.un` instruction (`cgt` for floats) followed by a `brfalse` branch to the specific target instruction. The target instruction is represented as a 4-byte signed offset from the beginning of the instruction following the current instruction. @@ -1365,7 +1365,7 @@ The following method overload can use the `ble.un` opcode: -- +- ]]> @@ -1422,11 +1422,11 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; if `value1` is less than or equal to `value2`, the branch operation is performed. +3. `value2` and `value1` are popped from the stack; if `value1` is less than or equal to `value2`, the branch operation is performed. The `ble.un.s` instruction transfers control to the specified target instruction if `value1` is less than or equal to `value2`, when compared using unsigned integer or unordered float values. The effect is identical to performing a `cgt.un` instruction (`cgt` for floats) followed by a `brfalse` branch to the specific target instruction. The target instruction is represented as a 1-byte signed offset from the beginning of the instruction following the current instruction. @@ -1434,7 +1434,7 @@ The following method overload can use the `ble.un.s` opcode: -- +- ]]> @@ -1491,11 +1491,11 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; if `value1` is less than `value2`, the branch operation is performed. +3. `value2` and `value1` are popped from the stack; if `value1` is less than `value2`, the branch operation is performed. The `blt` instruction transfers control to the specified target instruction if `value1` is less than or equal to `value2`. The effect is identical to performing a `clt` instruction followed by a `brtrue` branch to the specific target instruction. The target instruction is represented as a 4-byte signed offset from the beginning of the instruction following the current instruction. @@ -1503,7 +1503,7 @@ The following method overload can use the `blt` opcode: -- +- ]]> @@ -1560,11 +1560,11 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; if `value1` is less than `value2`, the branch operation is performed. +3. `value2` and `value1` are popped from the stack; if `value1` is less than `value2`, the branch operation is performed. The `blt.s` instruction transfers control to the specified target instruction if `value1` is less than `value2`. The effect is identical to performing a `clt` instruction followed by a `brtrue` branch to the specific target instruction. The target instruction is represented as a 1-byte signed offset from the beginning of the instruction following the current instruction. @@ -1572,7 +1572,7 @@ The following method overload can use the `blt.s` opcode: -- +- ]]> @@ -1629,11 +1629,11 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; if `value1` is less than `value2`, the branch operation is performed. +3. `value2` and `value1` are popped from the stack; if `value1` is less than `value2`, the branch operation is performed. The `blt.un` instruction transfers control to the specified target instruction if `value1` is less than `value2`, when compared using unsigned integer or unordered float values. The effect is identical to performing a `clt.un` instruction followed by a `brtrue` branch to the specific target instruction. The target instruction is represented as a 4-byte signed offset from the beginning of the instruction following the current instruction. @@ -1641,7 +1641,7 @@ The following method overload can use the `blt.un` opcode: -- +- ]]> @@ -1698,11 +1698,11 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; if `value1` is less than `value2`, the branch operation is performed. +3. `value2` and `value1` are popped from the stack; if `value1` is less than `value2`, the branch operation is performed. The `blt.un` instruction transfers control to the specified target instruction if `value1` is less than `value2`, when compared using unsigned integer or unordered float values. The effect is identical to performing a `clt.un` instruction followed by a `brtrue` branch to the specific target instruction. The target instruction is represented as a 4-byte signed offset from the beginning of the instruction following the current instruction. @@ -1710,7 +1710,7 @@ The following method overload can use the `blt.un.s` opcode: -- +- ]]> @@ -1767,11 +1767,11 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; if `value1` is not equal to `value2`, the branch operation is performed. +3. `value2` and `value1` are popped from the stack; if `value1` is not equal to `value2`, the branch operation is performed. The `bne.un` instruction transfers control to the specified target instruction if `value1` is not equal to `value2`, when compared using unsigned integer or unordered float values. The effect is identical to performing a `ceq` instruction followed by a `brfalse` branch to the specific target instruction. The target instruction is represented as a 4-byte signed offset from the beginning of the instruction following the current instruction. @@ -1779,7 +1779,7 @@ The following method overload can use the `bne.un` opcode: -- +- ]]> @@ -1836,11 +1836,11 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; if `value1` is not equal to `value2`, the branch operation is performed. +3. `value2` and `value1` are popped from the stack; if `value1` is not equal to `value2`, the branch operation is performed. The `bne.un` instruction transfers control to the specified target instruction if `value1` is not equal to `value2`, when compared using unsigned integer or unordered float values. The effect is identical to performing a `ceq` instruction followed by a `brfalse` branch to the specific target instruction. The target instruction is represented as a 4-byte signed offset from the beginning of the instruction following the current instruction. @@ -1848,7 +1848,7 @@ The following method overload can use the `bne.un.s` opcode: -- +- ]]> @@ -1905,11 +1905,11 @@ The stack transitional behavior, in sequential order, is: -1. A value type is pushed onto the stack. +1. A value type is pushed onto the stack. -2. The value type is popped from the stack; the `box` operation is performed. +2. The value type is popped from the stack; the `box` operation is performed. -3. An object reference to the resulting "boxed" value type is pushed onto the stack. +3. An object reference to the resulting "boxed" value type is pushed onto the stack. A value type has two separate representations within the Common Language Infrastructure (CLI): @@ -1925,7 +1925,7 @@ The following method overload can use the `box` opcode: -- +- ]]> @@ -1988,7 +1988,7 @@ The following method overload can use the `br` opcode: -- +- ]]> @@ -2051,7 +2051,7 @@ The following method overload can use the `br.s` opcode: -- +- ]]> @@ -2116,7 +2116,7 @@ The following method overload can use the `break` opcode: -- +- ]]> @@ -2173,9 +2173,9 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack by a previous operation. +1. `value` is pushed onto the stack by a previous operation. -2. `value` is popped from the stack; if `value` is `false`, branch to `target`. +2. `value` is popped from the stack; if `value` is `false`, branch to `target`. The `brfalse` instruction (and its aliases `brnull` and `brzero`) transfers control to the specified target instruction if `value` (of type `int32`, `int64`, object reference `O`, managed pointer `&`, transient pointer `*`, `native int`) is zero (`false`). If `value` is non-zero (`true`) execution continues at the next instruction. @@ -2185,7 +2185,7 @@ The following method overload can use the `brfalse` opcode: -- +- ]]> @@ -2242,9 +2242,9 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack by a previous operation. +1. `value` is pushed onto the stack by a previous operation. -2. `value` is popped from the stack; if `value` is `false`, branch to `target`. +2. `value` is popped from the stack; if `value` is `false`, branch to `target`. The `brfalse.s` instruction (and its aliases `brnull` and `brzero`) transfers control to the specified target instruction if `value` (of type `int32`, `int64`, object reference `O`, managed pointer `&`, transient pointer `*`, `native int`) is zero (`false`). If `value` is non-zero (`true`) execution continues at the next instruction. @@ -2254,7 +2254,7 @@ The following method overload can use the `brfalse.s` opcode: -- +- ]]> @@ -2311,9 +2311,9 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack by a previous operation. +1. `value` is pushed onto the stack by a previous operation. -2. `value` is popped from the stack; if `value` is `true`, branch to `target`. +2. `value` is popped from the stack; if `value` is `true`, branch to `target`. The `brtrue` instruction transfers control to the specified target instruction if `value` (type `native int`) is nonzero (`true`). If `value` is zero (`false`) execution continues at the next instruction. @@ -2325,7 +2325,7 @@ The following method overload can use the `brtrue` opcode: -- +- ]]> @@ -2382,9 +2382,9 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack by a previous operation. +1. `value` is pushed onto the stack by a previous operation. -2. `value` is popped from the stack; if `value` is `true`, branch to `target`. +2. `value` is popped from the stack; if `value` is `true`, branch to `target`. The `brtrue.s` instruction transfers control to the specified target instruction if `value` (type `native int`) is nonzero (`true`). If `value` is zero (`false`) execution continues at the next instruction. @@ -2396,7 +2396,7 @@ The following method overload can use the `brtrue.s` opcode: -- +- ]]> @@ -2453,11 +2453,11 @@ The stack transitional behavior, in sequential order, is: -1. Method arguments `arg1` through `argN` are pushed onto the stack. +1. Method arguments `arg1` through `argN` are pushed onto the stack. -2. Method arguments `arg1` through `argN` are popped from the stack; the method call is performed with these arguments and control is transferred to the method referred to by the method descriptor. When complete, a return value is generated by the callee method and sent to the caller. +2. Method arguments `arg1` through `argN` are popped from the stack; the method call is performed with these arguments and control is transferred to the method referred to by the method descriptor. When complete, a return value is generated by the callee method and sent to the caller. -3. The return value is pushed onto the stack. +3. The return value is pushed onto the stack. The `call` instruction calls the method indicated by the method descriptor passed with the instruction. The method descriptor is a metadata token that indicates the method to call and the number, type, and order of the arguments that have been placed on the stack to be passed to that method as well as the calling convention to be used. The `call` instruction can be immediately preceded by a `tail` () prefix instruction to specify that the current method state should be released before transferring control. If the call transfers control to a method of higher trust than the origin method, the stack frame is not released. Instead, the execution continues silently as if the `tail` had not been supplied. The metadata token carries sufficient information to determine whether the call is to a static method, an instance method, a virtual method, or a global function. In all of these cases the destination address is determined entirely from the method descriptor (contrast this with the instruction for calling virtual methods, where the destination address also depends upon the runtime type of the instance reference pushed before the ). @@ -2476,11 +2476,11 @@ The following method overloads can use the `call` opcode: -- +- -- +- -- +- > [!NOTE] > The method is provided for `varargs` calls. Use the method for normal calls. @@ -2540,13 +2540,13 @@ The stack transitional behavior, in sequential order, is: -1. Method arguments `arg1` through `argN` are pushed onto the stack. +1. Method arguments `arg1` through `argN` are pushed onto the stack. -2. The method entry pointer is pushed onto the stack. +2. The method entry pointer is pushed onto the stack. -3. Method arguments `arg1` through `argN` and the method entry pointer are popped from the stack; the call to the method is performed. When complete, a return value is generated by the callee method and sent to the caller. +3. Method arguments `arg1` through `argN` and the method entry pointer are popped from the stack; the call to the method is performed. When complete, a return value is generated by the callee method and sent to the caller. -4. The return value is pushed onto the stack. +4. The return value is pushed onto the stack. The `calli` instruction calls the method entry pointer with the arguments `arg1` through `argN`. The types of these arguments are described by the specific calling convention (`callSiteDesc`). The `calli` instruction may be immediately preceded by a `tail` prefix () to specify that the current method state should be released before transferring control. If the call would transfer control to a method of higher trust than the origin method the stack frame will not be released; instead, the execution will continue silently as if the `tail` had not been supplied. @@ -2560,9 +2560,9 @@ The following methods can be used to perform a `calli` instruction on the stack. Note that `calli` should be called through the below methods rather than using the class to place the instruction directly on the stack. -- for calls using a managed calling convention. +- for calls using a managed calling convention. -- for calls using an unmanaged calling convention. +- for calls using an unmanaged calling convention. ]]> @@ -2619,13 +2619,13 @@ The stack transitional behavior, in sequential order, is: -1. An object reference `obj` is pushed onto the stack. +1. An object reference `obj` is pushed onto the stack. -2. Method arguments `arg1` through `argN` are pushed onto the stack. +2. Method arguments `arg1` through `argN` are pushed onto the stack. -3. Method arguments `arg1` through `argN` and the object reference `obj` are popped from the stack; the method call is performed with these arguments and control is transferred to the method in `obj` referred to by the method metadata token. When complete, a return value is generated by the callee method and sent to the caller. +3. Method arguments `arg1` through `argN` and the object reference `obj` are popped from the stack; the method call is performed with these arguments and control is transferred to the method in `obj` referred to by the method metadata token. When complete, a return value is generated by the callee method and sent to the caller. -4. The return value is pushed onto the stack. +4. The return value is pushed onto the stack. The `callvirt` instruction calls a late-bound method on an object. That is, the method is chosen based on the runtime type of `obj` rather than the compile-time class visible in the method pointer. `Callvirt` can be used to call both virtual and instance methods. The `callvirt` instruction may be immediately preceded by a `tail` () prefix to specify that the current stack frame should be released before transferring control. If the call would transfer control to a method of higher trust than the original method the stack frame will not be released. @@ -2648,9 +2648,9 @@ The following method overload can use the `callvirt` opcode: -- +- -- +- ]]> @@ -2707,11 +2707,11 @@ The stack transitional behavior, in sequential order, is: -1. An object reference is pushed onto the stack. +1. An object reference is pushed onto the stack. -2. The object reference is popped from the stack; the referenced object is cast as the specified `class`. +2. The object reference is popped from the stack; the referenced object is cast as the specified `class`. -3. If successful, a new object reference is pushed onto the stack. +3. If successful, a new object reference is pushed onto the stack. The `castclass` instruction attempts to cast the object reference (type `O`) atop the stack to a specified class. The new class is specified by a metadata token indicating the desired class. If the class of the object on the top of the stack does not implement the new class (assuming the new class is an interface) and is not a derived class of the new class then an is thrown. If the object reference is a null reference, `castclass` succeeds and returns the new object as a null reference. @@ -2721,7 +2721,7 @@ The following method overload can use the `castclass` opcode: -- +- ]]> @@ -2778,13 +2778,13 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; `value1` is compared to `value2`. +3. `value2` and `value1` are popped from the stack; `value1` is compared to `value2`. -4. If `value1` is equal to `value2`, 1 is pushed onto the stack; otherwise 0 is pushed onto the stack. +4. If `value1` is equal to `value2`, 1 is pushed onto the stack; otherwise 0 is pushed onto the stack. The `ceq` instruction compares `value1` and `value2`. If `value1` is equal to `value2`, then 1 (of type `int32`) is pushed on the stack. Otherwise 0 (of type `int32`) is pushed on the stack. @@ -2792,7 +2792,7 @@ The following method overload can use the `ceq` opcode: -- +- ]]> @@ -2849,13 +2849,13 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; `cgt` tests if `value1` is greater than `value2`. +3. `value2` and `value1` are popped from the stack; `cgt` tests if `value1` is greater than `value2`. -4. If `value1` is greater than `value2`, 1 is pushed onto the stack; otherwise 0 is pushed onto the stack. +4. If `value1` is greater than `value2`, 1 is pushed onto the stack; otherwise 0 is pushed onto the stack. The `cgt` instruction compares `value1` and `value2`. If `value1` is strictly greater than `value2`, then an `int32` value of 1 is pushed on the stack. Otherwise, an `int32` value of 0 is pushed on the stack. @@ -2863,7 +2863,7 @@ The following method overload can use the `cgt` opcode: -- +- ]]> @@ -2920,13 +2920,13 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; `cgt.un` tests if `value1` is greater than `value2`. +3. `value2` and `value1` are popped from the stack; `cgt.un` tests if `value1` is greater than `value2`. -4. If `value1` is greater than `value2`, 1 is pushed onto the stack; otherwise 0 is pushed onto the stack. +4. If `value1` is greater than `value2`, 1 is pushed onto the stack; otherwise 0 is pushed onto the stack. An `int32` value of 1 is pushed on the stack if any of the following is `true` : @@ -2938,7 +2938,7 @@ The following method overload can use the `cgt.un` opcode: -- +- ]]> @@ -2995,11 +2995,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the `ckfinite` instruction is performed on it. +2. `value` is popped from the stack and the `ckfinite` instruction is performed on it. -3. `value` is pushed back onto the stack if no exception is thrown. +3. `value` is pushed back onto the stack if no exception is thrown. The `ckfinite instruction` throws if `value` (a floating-point number) is either a "not a number" value (NaN) or a `+-` infinity value. `Ckfinite` leaves the value on the stack if no exception is thrown. Execution is unspecified if `value` is not a floating-point number. @@ -3009,7 +3009,7 @@ The following method overload can use the `ckfinite` opcode: -- +- ]]> @@ -3066,13 +3066,13 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; `clt` tests if `value1` is less than `value2`. +3. `value2` and `value1` are popped from the stack; `clt` tests if `value1` is less than `value2`. -4. If `value1` is less than `value2`, 1 is pushed onto the stack; otherwise 0 is pushed onto the stack. +4. If `value1` is less than `value2`, 1 is pushed onto the stack; otherwise 0 is pushed onto the stack. The `clt` instruction compares `value1` and `value2`. If `value1` is strictly less than `value2`, then an `int32` value of 1 is pushed on the stack. Otherwise, an `int32` value of 0 is pushed on the stack. @@ -3080,7 +3080,7 @@ The following method overload can use the `clt` opcode: -- +- ]]> @@ -3137,17 +3137,17 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; `clt.un` tests if `value1` is less than `value2`. +3. `value2` and `value1` are popped from the stack; `clt.un` tests if `value1` is less than `value2`. -4. If `value1` is less than `value2`, 1 is pushed onto the stack; otherwise 0 is pushed onto the stack. +4. If `value1` is less than `value2`, 1 is pushed onto the stack; otherwise 0 is pushed onto the stack. The `clt.un` instruction compares `value1` and `value2`. An `int32` value of 1 is pushed on the stack if any of the following is true: -- `value1` is strictly less than `value2` (as for `clt`). +- `value1` is strictly less than `value2` (as for `clt`). - For floating-point numbers, `value1` is not ordered with respect to `value2`. @@ -3157,7 +3157,7 @@ The following method overload can use the `clt.un` opcode: -- +- ]]> @@ -3215,9 +3215,9 @@ The state of the MSIL stack at this point must be as follows: -1. A managed pointer, `ptr`, is pushed onto the stack. The type of `ptr` must be a managed pointer (`&`) to `thisType`. Note that this is different from the case of an unprefixed `callvirt` instruction, which expects a reference of `thisType`. +1. A managed pointer, `ptr`, is pushed onto the stack. The type of `ptr` must be a managed pointer (`&`) to `thisType`. Note that this is different from the case of an unprefixed `callvirt` instruction, which expects a reference of `thisType`. -2. Method arguments `arg1` through `argN` are pushed onto the stack, just as with an unprefixed `callvirt` instruction. +2. Method arguments `arg1` through `argN` are pushed onto the stack, just as with an unprefixed `callvirt` instruction. The `constrained` prefix is designed to allow `callvirt` instructions to be made in a uniform way independent of whether `thisType` is a value type or a reference type. @@ -3241,7 +3241,7 @@ The following method overload can use the `constrained` opcode: -- +- ]]> @@ -3298,11 +3298,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. +2. `value` is popped from the stack and the conversion operation is attempted. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.i` opcode converts the `value` on top of the stack to the type specified in the opcode, and leave that converted value on the top of the stack. Integer values of less than 4 bytes are extended to `int32` when they are loaded onto the evaluation stack (unless `conv.i` or `conv.u` is used, in which case the result is also `native int`). Floating-point values are converted to the `F` type. @@ -3314,7 +3314,7 @@ The following method overload can use the `conv.i` opcode: -- +- ]]> @@ -3371,11 +3371,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. +2. `value` is popped from the stack and the conversion operation is attempted. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.i1` opcode converts the `value` on top of the stack to the type specified in the opcode, and leave that converted value on the top of the stack. Integer values of less than 4 bytes are extended to `int32` when they are loaded onto the evaluation stack (unless `conv.i` or `conv.u` is used, in which case the result is also `native int`). Floating-point values are converted to the `F` type. @@ -3387,7 +3387,7 @@ The following method overload can use the `conv.i1` opcode: -- +- ]]> @@ -3444,11 +3444,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. +2. `value` is popped from the stack and the conversion operation is attempted. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.i2` opcode converts the `value` on top of the stack to the type specified in the opcode, and leave that converted value on the top of the stack. Integer values of less than 4 bytes are extended to `int32` when they are loaded onto the evaluation stack (unless `conv.i` or `conv.u` is used, in which case the result is also `native int`). Floating-point values are converted to the `F` type. @@ -3460,7 +3460,7 @@ The following method overload can use the `conv.i2` opcode: -- +- ]]> @@ -3517,11 +3517,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. +2. `value` is popped from the stack and the conversion operation is attempted. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.i4` opcode converts the `value` on top of the stack to the type specified in the opcode, and leave that converted value on the top of the stack. Integer values of less than 4 bytes are extended to `int32` when they are loaded onto the evaluation stack (unless `conv.i` or `conv.u` is used, in which case the result is also `native int`). Floating-point values are converted to the `F` type. @@ -3533,7 +3533,7 @@ The following method overload can use the `conv.i4` opcode: -- +- ]]> @@ -3590,11 +3590,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. +2. `value` is popped from the stack and the conversion operation is attempted. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.i8` opcode converts the `value` on top of the stack to the type specified in the opcode, and leave that converted value on the top of the stack. Integer values of less than 4 bytes are extended to `int32` when they are loaded onto the evaluation stack (unless `conv.i` or `conv.u` is used, in which case the result is also `native int`). Floating-point values are converted to the `F` type. @@ -3606,7 +3606,7 @@ The following method overload can use the `conv.i8` opcode: -- +- ]]> @@ -3663,11 +3663,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. +2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.ovf.i` opcode converts the `value` on top of the stack to the type specified in the opcode, and places that converted value on the top of the stack. If the value is too large or too small to be represented by the target type, an exception is thrown. @@ -3677,7 +3677,7 @@ The following method overload can use the `conv.ovf.i` opcode: -- +- ]]> @@ -3734,11 +3734,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. +2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.ovf.i.un` opcode converts the `value` on top of the stack to the type specified in the opcode, and places that converted value on the top of the stack. If the value is too large or too small to be represented by the target type, an exception is thrown. @@ -3748,7 +3748,7 @@ The following method overload can use the `conv.ovf.i.un` opcode: -- +- ]]> @@ -3805,11 +3805,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. +2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.ovf.i1` opcode converts the `value` on top of the stack to the type specified in the opcode, and places that converted value on the top of the stack. If the value is too large or too small to be represented by the target type, an exception is thrown. @@ -3819,7 +3819,7 @@ The following method overload can use the `conv.ovf.i1` opcode: -- +- ]]> @@ -3876,11 +3876,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. +2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.ovf.i1.un` opcode converts the `value` on top of the stack to the type specified in the opcode, and places that converted value on the top of the stack. If the value is too large or too small to be represented by the target type, an exception is thrown. @@ -3890,7 +3890,7 @@ The following method overload can use the `conv.ovf.i1.un` opcode: -- +- ]]> @@ -3947,11 +3947,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. +2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.ovf.i2` opcode converts the `value` on top of the stack to the type specified in the opcode, and places that converted value on the top of the stack. If the value is too large or too small to be represented by the target type, an exception is thrown. @@ -3961,7 +3961,7 @@ The following method overload can use the `conv.ovf.i2` opcode: -- +- ]]> @@ -4018,11 +4018,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. +2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.ovf.i2.un` opcode converts the `value` on top of the stack to the type specified in the opcode, and places that converted value on the top of the stack. If the value is too large or too small to be represented by the target type, an exception is thrown. @@ -4032,7 +4032,7 @@ The following method overload can use the `conv.ovf.i2.un` opcode: -- +- ]]> @@ -4089,11 +4089,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. +2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.ovf.i4` opcode converts the `value` on top of the stack to the type specified in the opcode, and places that converted value on the top of the stack. If the value is too large or too small to be represented by the target type, an exception is thrown. @@ -4103,7 +4103,7 @@ The following method overload can use the `conv.ovf.i4` opcode: -- +- ]]> @@ -4160,11 +4160,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. +2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.ovf.i4.un` opcode converts the `value` on top of the stack to the type specified in the opcode, and places that converted value on the top of the stack. If the value is too large or too small to be represented by the target type, an exception is thrown. @@ -4174,7 +4174,7 @@ The following method overload can use the `conv.ovf.i4.un` opcode: -- +- ]]> @@ -4231,11 +4231,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. +2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.ovf.i8` opcode converts the `value` on top of the stack to the type specified in the opcode, and places that converted value on the top of the stack. If the value is too large or too small to be represented by the target type, an exception is thrown. @@ -4245,7 +4245,7 @@ The following method overload can use the `conv.ovf.i8` opcode: -- +- ]]> @@ -4302,11 +4302,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. +2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.ovf.i8.un` opcode converts the `value` on top of the stack to the type specified in the opcode, and places that converted value on the top of the stack. If the value is too large or too small to be represented by the target type, an exception is thrown. @@ -4316,7 +4316,7 @@ The following method overload can use the `conv.ovf.i8.un` opcode: -- +- ]]> @@ -4373,11 +4373,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. +2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.ovf.u` opcode converts the `value` on top of the stack to the type specified in the opcode, and places that converted value on the top of the stack. If the value is too large or too small to be represented by the target type, an exception is thrown. @@ -4387,7 +4387,7 @@ The following method overload can use the `conv.ovf.u` opcode: -- +- ]]> @@ -4444,11 +4444,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. +2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.ovf.u.un` opcode converts the `value` on top of the stack to the type specified in the opcode, and places that converted value on the top of the stack. If the value is too large or too small to be represented by the target type, an exception is thrown. @@ -4458,7 +4458,7 @@ The following method overload can use the `conv.uvf.u.un` opcode: -- +- ]]> @@ -4515,11 +4515,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. +2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.ovf.u1` opcode converts the `value` on top of the stack to the type specified in the opcode, and places that converted value on the top of the stack. If the value is too large or too small to be represented by the target type, an exception is thrown. @@ -4529,7 +4529,7 @@ The following method overload can use the `conv.ovf.u1` opcode: -- +- ]]> @@ -4586,11 +4586,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. +2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.ovf.u1.un` opcode converts the `value` on top of the stack to the type specified in the opcode, and places that converted value on the top of the stack. If the value is too large or too small to be represented by the target type, an exception is thrown. @@ -4600,7 +4600,7 @@ The following method overload can use the `conv.ovf.u1.un` opcode: -- +- ]]> @@ -4657,11 +4657,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. +2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.ovf.u2` opcode converts the `value` on top of the stack to the type specified in the opcode, and places that converted value on the top of the stack. If the value is too large or too small to be represented by the target type, an exception is thrown. @@ -4671,7 +4671,7 @@ The following method overload can use the `conv.ovf.u2` opcode: -- +- ]]> @@ -4728,11 +4728,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. +2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.ovf.u2.un` opcode converts the `value` on top of the stack to the type specified in the opcode, and places that converted value on the top of the stack. If the value is too large or too small to be represented by the target type, an exception is thrown. @@ -4742,7 +4742,7 @@ The following method overload can use the `conv.ovf.u2.un` opcode: -- +- ]]> @@ -4799,11 +4799,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. +2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.ovf.u4` opcode converts the `value` on top of the stack to the type specified in the opcode, and places that converted value on the top of the stack. If the value is too large or too small to be represented by the target type, an exception is thrown. @@ -4813,7 +4813,7 @@ The following method overload can use the `conv.ovf.u4` opcode: -- +- ]]> @@ -4870,11 +4870,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. +2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.ovf.u4.un` opcode converts the `value` on top of the stack to the type specified in the opcode, and places that converted value on the top of the stack. If the value is too large or too small to be represented by the target type, an exception is thrown. @@ -4884,7 +4884,7 @@ The following method overload can use the `conv.ovf.u4.un` opcode: -- +- ]]> @@ -4941,11 +4941,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. +2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.ovf.u8` opcode converts the `value` on top of the stack to the type specified in the opcode, and places that converted value on the top of the stack. If the value is too large or too small to be represented by the target type, an exception is thrown. @@ -4955,7 +4955,7 @@ The following method overload can use the `conv.ovf.u8` opcode: -- +- ]]> @@ -5012,11 +5012,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. +2. `value` is popped from the stack and the conversion operation is attempted. If overflow occurs, an exception is thrown. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.ovf.u8.un` opcode converts the `value` on top of the stack to the type specified in the opcode, and places that converted value on the top of the stack. If the value is too large or too small to be represented by the target type, an exception is thrown. @@ -5026,7 +5026,7 @@ The following method overload can use the `conv.ovf.u8.un` opcode: -- +- ]]> @@ -5083,11 +5083,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. +2. `value` is popped from the stack and the conversion operation is attempted. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.r.un` opcode converts the `value` on top of the stack to the type specified in the opcode, and leave that converted value on the top of the stack. Integer values of less than 4 bytes are extended to `int32` when they are loaded onto the evaluation stack (unless `conv.i` or `conv.u` is used, in which case the result is also `native int`). Floating-point values are converted to the `F` type. @@ -5099,7 +5099,7 @@ The following method overload can use the `conv.r.un` opcode: -- +- ]]> @@ -5156,11 +5156,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. +2. `value` is popped from the stack and the conversion operation is attempted. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.r4` opcode converts the `value` on top of the stack to the type specified in the opcode, and leave that converted value on the top of the stack. Integer values of less than 4 bytes are extended to `int32` when they are loaded onto the evaluation stack (unless `conv.i` or `conv.u` is used, in which case the result is also `native int`). Floating-point values are converted to the `F` type. @@ -5172,7 +5172,7 @@ The following method overload can use the `conv.r4` opcode: -- +- ]]> @@ -5229,11 +5229,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. +2. `value` is popped from the stack and the conversion operation is attempted. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.r8` opcode converts the `value` on top of the stack to the type specified in the opcode, and leave that converted value on the top of the stack. Integer values of less than 4 bytes are extended to `int32` when they are loaded onto the evaluation stack (unless `conv.i` or `conv.u` is used, in which case the result is also `native int`). Floating-point values are converted to the `F` type. @@ -5245,7 +5245,7 @@ The following method overload can use the `conv.r8` opcode: -- +- ]]> @@ -5302,11 +5302,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. +2. `value` is popped from the stack and the conversion operation is attempted. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.u` opcode converts the `value` on top of the stack to the type specified in the opcode, and leave that converted value on the top of the stack. Integer values of less than 4 bytes are extended to `int32` when they are loaded onto the evaluation stack (unless `conv.i` or `conv.u` is used, in which case the result is also `native int`). Floating-point values are converted to the `F` type. @@ -5318,7 +5318,7 @@ The following method overload can use the `conv.u` opcode: -- +- ]]> @@ -5375,11 +5375,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. +2. `value` is popped from the stack and the conversion operation is attempted. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.u1` opcode converts the `value` on top of the stack to the type specified in the opcode, and leave that converted value on the top of the stack. Integer values of less than 4 bytes are extended to `int32` when they are loaded onto the evaluation stack (unless `conv.i` or `conv.u` is used, in which case the result is also `native int`). Floating-point values are converted to the `F` type. @@ -5391,7 +5391,7 @@ The following method overload can use the `conv.u1` opcode: -- +- ]]> @@ -5448,11 +5448,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. +2. `value` is popped from the stack and the conversion operation is attempted. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.u2` opcode converts the `value` on top of the stack to the type specified in the opcode, and leave that converted value on the top of the stack. Integer values of less than 4 bytes are extended to `int32` when they are loaded onto the evaluation stack (unless `conv.i` or `conv.u` is used, in which case the result is also `native int`). Floating-point values are converted to the `F` type. @@ -5464,7 +5464,7 @@ The following method overload can use the `conv.u2` opcode: -- +- ]]> @@ -5521,11 +5521,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. +2. `value` is popped from the stack and the conversion operation is attempted. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.u4` opcode converts the `value` on top of the stack to the type specified in the opcode, and leave that converted value on the top of the stack. Integer values of less than 4 bytes are extended to `int32` when they are loaded onto the evaluation stack (unless `conv.i` or `conv.u` is used, in which case the result is also `native int`). Floating-point values are converted to the `F` type. @@ -5537,7 +5537,7 @@ The following method overload can use the `conv.u4` opcode: -- +- ]]> @@ -5594,11 +5594,11 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and the conversion operation is attempted. +2. `value` is popped from the stack and the conversion operation is attempted. -3. If the conversion is successful, the resulting value is pushed onto the stack. +3. If the conversion is successful, the resulting value is pushed onto the stack. The `conv.u8` opcode converts the `value` on top of the stack to the type specified in the opcode, and leave that converted value on the top of the stack. Integer values of less than 4 bytes are extended to `int32` when they are loaded onto the evaluation stack (unless `conv.i` or `conv.u` is used, in which case the result is also `native int`). Floating-point values are converted to the `F` type. @@ -5610,7 +5610,7 @@ The following method overload can use the `conv.u8` opcode: -- +- ]]> @@ -5667,13 +5667,13 @@ The stack transitional behavior, in sequential order, is: -1. The destination address is pushed onto the stack. +1. The destination address is pushed onto the stack. -2. The source address is pushed onto the stack. +2. The source address is pushed onto the stack. -3. The number of bytes to copy is pushed onto the stack. +3. The number of bytes to copy is pushed onto the stack. -4. The number of bytes, the source address, and the destination address are popped from the stack; the specified number of bytes are copied from the source address to the destination address. +4. The number of bytes, the source address, and the destination address are popped from the stack; the specified number of bytes are copied from the source address to the destination address. The `cpblk` instruction copies a number (type `unsigned int32`) of bytes from a source address (of type `*`, `native int`, or `&`) to a destination address (of type `*`, `native int`, or `&`). The behavior of `cpblk` is unspecified if the source and destination areas overlap. @@ -5685,7 +5685,7 @@ The following method overload can use the `cpblk` opcode: -- +- ]]> @@ -5742,11 +5742,11 @@ The stack transitional behavior, in sequential order, is: -1. The destination object reference is pushed onto the stack. +1. The destination object reference is pushed onto the stack. -2. The source object reference is pushed onto the stack. +2. The source object reference is pushed onto the stack. -3. The two object references are popped from the stack; the value type at the address of the source object is copied to the address of the destination object. +3. The two object references are popped from the stack; the value type at the address of the source object is copied to the address of the destination object. The behavior of `cpobj` is unspecified if the source and destination object references are not pointers to instances of the class represented by the class token `classTok` (a `typeref` or `typedef`), or if `classTok` does not represent a value type. @@ -5754,7 +5754,7 @@ The following method overload can use the `cpobj` opcode: -- +- ]]> @@ -5811,13 +5811,13 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; `value1` is divided by `value2`. +3. `value2` and `value1` are popped from the stack; `value1` is divided by `value2`. -4. The result is pushed onto the stack. +4. The result is pushed onto the stack. `result` = `value1` div value2 satisfies the following conditions: @@ -5841,7 +5841,7 @@ The following method overload can use the `div` opcode: -- +- ]]> @@ -5898,19 +5898,19 @@ The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; `value1` is divided by `value2`. +3. `value2` and `value1` are popped from the stack; `value1` is divided by `value2`. -4. The result is pushed onto the stack. +4. The result is pushed onto the stack. The `div.un` instruction computes `value1` divided by `value2`, both taken as unsigned integers, and pushes the `result` on the stack. The following method overload can use the `div.un` opcode: -- +- ]]> @@ -5967,19 +5967,19 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped off of the stack for duplication. +2. `value` is popped off of the stack for duplication. -3. `value` is pushed back onto the stack. +3. `value` is pushed back onto the stack. -4. A duplicate value is pushed onto the stack. +4. A duplicate value is pushed onto the stack. The `dup` instruction duplicates the top element of the stack, and leaves two identical values atop it. The following method overload can use the `dup` opcode: -- +- ]]> @@ -6036,15 +6036,15 @@ The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack; `endfilter` is executed and control is transferred to the exception handler. +2. `value` is popped from the stack; `endfilter` is executed and control is transferred to the exception handler. `Value` (which must be of type `int32` and is one of a specific set of values) is returned from the filter clause. It should be one of: -- `exception_continue_search` (`value` = 0) to continue searching for an exception handler +- `exception_continue_search` (`value` = 0) to continue searching for an exception handler -- `exception_execute_handler` (`value` = 1) to start the second phase of exception handling where finally blocks are run until the handler associated with this filter clause is located. Upon discovery, the handler is executed. +- `exception_execute_handler` (`value` = 1) to start the second phase of exception handling where finally blocks are run until the handler associated with this filter clause is located. Upon discovery, the handler is executed. Other integer values will produce unspecified results. @@ -6054,7 +6054,7 @@ The following method overload can use the `endfilter` opcode: -- +- ]]> @@ -6121,9 +6121,9 @@ The following method overload can use the `endfinally` (`endfault`) opcode, as well as the `ILGenerator` method . -- +- -- +- ]]> @@ -6180,13 +6180,13 @@ The stack transitional behavior, in sequential order, is: -1. A starting address is pushed onto the stack. +1. A starting address is pushed onto the stack. -2. An initialization value is pushed onto the stack. +2. An initialization value is pushed onto the stack. -3. The number of bytes to initialize is pushed onto the stack. +3. The number of bytes to initialize is pushed onto the stack. -4. The number of bytes, the initialization value, and the starting address are popped from the stack, and the initialization is performed as per their values. +4. The number of bytes, the initialization value, and the starting address are popped from the stack, and the initialization is performed as per their values. The `initblk` instruction sets the number (`unsigned int32`) of bytes starting at the specified address (of type `native int`, `&`, or `*`) to the initialization value (of type `unsigned int8`). `initblk` assumes that the starting address is aligned to the natural size of the machine. @@ -6196,7 +6196,7 @@ The following method overload can use the `initblk` opcode: -- +- ]]> @@ -6253,9 +6253,9 @@ The stack transitional behavior, in sequential order, is: -1. The address of the value type to initialize is pushed onto the stack. +1. The address of the value type to initialize is pushed onto the stack. -2. The address is popped from the stack; the value type at the specified address is initialized as type `typeTok`. +2. The address is popped from the stack; the value type at the specified address is initialized as type `typeTok`. The `initobj` instruction initializes each field of the value type specified by the pushed address (of type `native int`, `&`, or `*`) to a null reference or a 0 of the appropriate primitive type. After this method is called, the instance is ready for a constructor method to be called. If `typeTok` is a reference type, this instruction has the same effect as `ldnull` followed by `stind.ref`. @@ -6263,7 +6263,7 @@ The following method overload can use the `initobj` opcode: -- +- ]]> @@ -6320,11 +6320,11 @@ The stack transitional behavior, in sequential order, is: -1. An object reference is pushed onto the stack. +1. An object reference is pushed onto the stack. -2. The object reference is popped from the stack and tested to see if it is an instance of the class passed in `class`. +2. The object reference is popped from the stack and tested to see if it is an instance of the class passed in `class`. -3. The result (either an object reference or a null reference) is pushed onto the stack. +3. The result (either an object reference or a null reference) is pushed onto the stack. `Class` is a metadata token indicating the desired class. If the class of the object on the top of the stack implements `class` (if `class` is an interface) or is a derived class of `class` (if `class` is a regular class) then it is cast to type `class` and the result is pushed on the stack, exactly as though had been called. Otherwise, a null reference is pushed on the stack. If the object reference itself is a null reference, then `isinst` likewise returns a null reference. @@ -6332,7 +6332,7 @@ The following method overload can use the `isinst` opcode: -- +- ]]> @@ -6397,7 +6397,7 @@ The following method overload can use the `jmp` opcode: -- +- ]]> @@ -6454,7 +6454,7 @@ The stack transitional behavior, in sequential order, is: -1. The argument value at `index` is pushed onto the stack. +1. The argument value at `index` is pushed onto the stack. The `ldarg` instruction pushes the argument indexed at `index`, where arguments are indexed from 0 onwards, onto the evaluation stack. The `ldarg` instruction can be used to load a value type or a primitive value onto the stack by copying it from an incoming argument. The type of the argument value is the same as the type of the argument, as specified by the current method's signature. @@ -6464,7 +6464,7 @@ The following method overload can use the `ldarg` opcode: -- +- ]]> @@ -6521,7 +6521,7 @@ The stack transitional behavior, in sequential order, is: -1. The argument value at index 0 is pushed onto the stack. +1. The argument value at index 0 is pushed onto the stack. The `ldarg.0` instruction is an efficient encoding for loading the argument value at index 0. @@ -6531,7 +6531,7 @@ The following method overload can use the `ldarg.0` opcode: -- +- ]]> @@ -6588,7 +6588,7 @@ The stack transitional behavior, in sequential order, is: -1. The argument value at index 1 is pushed onto the stack. +1. The argument value at index 1 is pushed onto the stack. The `ldarg.1` instruction is an efficient encoding for loading the argument value at index 1. @@ -6598,7 +6598,7 @@ The following method overload can use the `ldarg.1` opcode: -- +- ]]> @@ -6655,7 +6655,7 @@ The stack transitional behavior, in sequential order, is: -1. The argument value at index 2 is pushed onto the stack. +1. The argument value at index 2 is pushed onto the stack. The `ldarg.2` instruction is an efficient encoding for loading the argument value at index 2. @@ -6665,7 +6665,7 @@ The following method overload can use the `ldarg.2` opcode: -- +- ]]> @@ -6722,7 +6722,7 @@ The stack transitional behavior, in sequential order, is: -1. The argument value at index 3 is pushed onto the stack. +1. The argument value at index 3 is pushed onto the stack. The `ldarg.3` instruction is an efficient encoding for loading the argument value at index 3. @@ -6732,7 +6732,7 @@ The following method overload can use the `ldarg.3` opcode: -- +- ]]> @@ -6789,7 +6789,7 @@ The stack transitional behavior, in sequential order, is: -1. The argument value at `index` is pushed onto the stack. +1. The argument value at `index` is pushed onto the stack. The `ldarg.s` instruction is an efficient encoding for loading arguments indexed from 4 through 255. @@ -6801,7 +6801,7 @@ The following method overload can use the `ldarg.s` opcode: -- +- ]]> @@ -6858,7 +6858,7 @@ The stack transitional behavior, in sequential order, is: -1. The address `addr` of the argument indexed by `index` is pushed onto the stack. +1. The address `addr` of the argument indexed by `index` is pushed onto the stack. The `ldarga` instruction fetches the address (of type `&`) of the argument indexed by `index`, where arguments are indexed from 0 onwards. The address `addr` is always aligned to a natural boundary on the target machine. The argument is stored in unmanaged memory, so the return value can be converted to an unmanaged pointer without pinning. @@ -6868,7 +6868,7 @@ The following method overload can use the `ldarga` opcode: -- +- ]]> @@ -6925,7 +6925,7 @@ The stack transitional behavior, in sequential order, is: -1. The address `addr` of the argument indexed by `index` is pushed onto the stack. +1. The address `addr` of the argument indexed by `index` is pushed onto the stack. `ldarga.s` (the short form of `ldarga`) should be used for argument numbers 0 through 255, and is a more efficient encoding. @@ -6937,7 +6937,7 @@ The following method overload can use the `ldarga.s` opcode: -- +- ]]> @@ -6994,7 +6994,7 @@ The stack transitional behavior, in sequential order, is: -1. The value `num` is pushed onto the stack. +1. The value `num` is pushed onto the stack. Note that there are special short (and hence more efficient) encodings for the integers -128 through 127, and especially short encodings for -1 through 8. All short encodings push 4 byte integers on the stack. Longer encodings are used for 8 byte integers and 4 and 8 byte floating-point numbers, as well as 4-byte values that do not fit in the short forms. There are three ways to push an 8 byte integer constant onto the stack @@ -7006,7 +7006,7 @@ The following method overload can use the `ldc.i4` opcode: -- +- ]]> @@ -7063,13 +7063,13 @@ The stack transitional behavior, in sequential order, is: -1. The value 0 is pushed onto the stack. +1. The value 0 is pushed onto the stack. This is a special short encoding for the push of the integer value 0. All special short encodings push 4 byte integers on the stack. The following method overload can use the `ldc.i4.0` opcode: -- +- ]]> @@ -7126,13 +7126,13 @@ The stack transitional behavior, in sequential order, is: -1. The value 1 is pushed onto the stack. +1. The value 1 is pushed onto the stack. This is a special short encoding for the push of the integer value 1. All special short encodings push 4 byte integers on the stack. The following method overload can use the `ldc.i4.1` opcode: -- +- ]]> @@ -7189,13 +7189,13 @@ The stack transitional behavior, in sequential order, is: -1. The value 2 is pushed onto the stack. +1. The value 2 is pushed onto the stack. This is a special short encoding for the push of the integer value 2. All special short encodings push 4 byte integers on the stack. The following method overload can use the `ldc.i4.2` opcode: -- +- ]]> @@ -7252,13 +7252,13 @@ The stack transitional behavior, in sequential order, is: -1. The value 3 is pushed onto the stack. +1. The value 3 is pushed onto the stack. This is a special short encoding for the push of the integer value 3. All special short encodings push 4 byte integers on the stack. The following method overload can use the `ldc.i4.3` opcode: -- +- ]]> @@ -7315,13 +7315,13 @@ The stack transitional behavior, in sequential order, is: -1. The value 4 is pushed onto the stack. +1. The value 4 is pushed onto the stack. This is a special short encoding for the push of the integer value 4. All special short encodings push 4 byte integers on the stack. The following method overload can use the `ldc.i4.4` opcode: -- +- ]]> @@ -7378,13 +7378,13 @@ The stack transitional behavior, in sequential order, is: -1. The value 5 is pushed onto the stack. +1. The value 5 is pushed onto the stack. This is a special short encoding for the push of the integer value 5. All special short encodings push 4 byte integers on the stack. The following method overload can use the `ldc.i4.5` opcode: -- +- ]]> @@ -7441,13 +7441,13 @@ The stack transitional behavior, in sequential order, is: -1. The value 6 is pushed onto the stack. +1. The value 6 is pushed onto the stack. This is a special short encoding for the push of the integer value 6. All special short encodings push 4 byte integers on the stack. The following method overload can use the `ldc.i4.6` opcode: -- +- ]]> @@ -7504,13 +7504,13 @@ The stack transitional behavior, in sequential order, is: -1. The value 7 is pushed onto the stack. +1. The value 7 is pushed onto the stack. This is a special short encoding for the push of the integer value 7. All special short encodings push 4 byte integers on the stack. The following method overload can use the `ldc.i4.7` opcode: -- +- ]]> @@ -7567,13 +7567,13 @@ The stack transitional behavior, in sequential order, is: -1. The value 8 is pushed onto the stack. +1. The value 8 is pushed onto the stack. This is a special short encoding for the push of the integer value 8. All special short encodings push 4 byte integers on the stack. The following method overload can use the `ldc.i4.8` opcode: -- +- ]]> @@ -7630,13 +7630,13 @@ The stack transitional behavior, in sequential order, is: -1. The value -1 is pushed onto the stack. +1. The value -1 is pushed onto the stack. This is a special short encoding for the push of the integer value -1. All special short encodings push 4 byte integers on the stack. The following method overload can use the `ldc.i4.m1` opcode: -- +- ]]> @@ -7693,7 +7693,7 @@ The stack transitional behavior, in sequential order, is: -1. The value `num` is pushed onto the stack. +1. The value `num` is pushed onto the stack. `ldc.i4.s` is a more efficient encoding for pushing the integers from -128 to 127 onto the evaluation stack. @@ -7757,13 +7757,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. The value `num` is pushed onto the stack. +1. The value `num` is pushed onto the stack. This encoding pushes an `int64` value onto the stack. The following method overload can use the `ldc.i8` opcode: -- +- ]]> @@ -7820,13 +7820,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. The value `num` is pushed onto the stack. +1. The value `num` is pushed onto the stack. This encoding pushes a `float32` value onto the stack. The following method overload can use the `ldc.r4` opcode: -- +- ]]> @@ -7883,13 +7883,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. The value `num` is pushed onto the stack. +1. The value `num` is pushed onto the stack. This encoding pushes a `float64` value onto the stack. The following method overload can use the `ldc.r8` opcode: -- +- ]]> @@ -7945,13 +7945,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An object reference `array` is pushed onto the stack. +1. An object reference `array` is pushed onto the stack. -2. An index value `index` is pushed onto the stack. +2. An index value `index` is pushed onto the stack. -3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. +3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. -4. The value is pushed onto the stack. +4. The value is pushed onto the stack. The `ldelem` instruction loads the value of the element with index `index` (type `native int`) in the zero-based one-dimensional array `array` and places it on the top of the stack. Arrays are objects, and hence represented by a value of type `O`. @@ -7963,7 +7963,7 @@ The following method overloads c The following method overload can use the `ldelem` opcode: -- +- ]]> @@ -8020,13 +8020,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An object reference `array` is pushed onto the stack. +1. An object reference `array` is pushed onto the stack. -2. An index value `index` is pushed onto the stack. +2. An index value `index` is pushed onto the stack. -3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. +3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. -4. The value is pushed onto the stack. +4. The value is pushed onto the stack. The `ldelem.i` instruction loads the value of the element with index `index` (type `native int`) in the zero-based one-dimensional array `array` and places it on the top of the stack. Arrays are objects and hence represented by a value of type `O`. @@ -8042,7 +8042,7 @@ The following method overloads c The following method overload can use the `ldelem.i` opcode: -- +- ]]> @@ -8099,13 +8099,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An object reference `array` is pushed onto the stack. +1. An object reference `array` is pushed onto the stack. -2. An index value `index` is pushed onto the stack. +2. An index value `index` is pushed onto the stack. -3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. +3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. -4. The value is pushed onto the stack. +4. The value is pushed onto the stack. The `ldelem.i1` instruction loads the value of the element with index `index` (type `native int`) in the zero-based one-dimensional array `array` and places it on the top of the stack. Arrays are objects and hence represented by a value of type `O`. @@ -8121,7 +8121,7 @@ The following method overloads c The following method overload can use the `ldelem.i1` opcode: -- +- ]]> @@ -8178,13 +8178,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An object reference `array` is pushed onto the stack. +1. An object reference `array` is pushed onto the stack. -2. An index value `index` is pushed onto the stack. +2. An index value `index` is pushed onto the stack. -3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. +3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. -4. The value is pushed onto the stack. +4. The value is pushed onto the stack. The `ldelem.i2` instruction loads the value of the element with index `index` (type `native int`) in the zero-based one-dimensional array `array` and places it on the top of the stack. Arrays are objects and hence represented by a value of type `O`. @@ -8200,7 +8200,7 @@ The following method overloads c The following method overload can use the `ldelem.i2` opcode: -- +- ]]> @@ -8257,13 +8257,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An object reference `array` is pushed onto the stack. +1. An object reference `array` is pushed onto the stack. -2. An index value `index` is pushed onto the stack. +2. An index value `index` is pushed onto the stack. -3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. +3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. -4. The value is pushed onto the stack. +4. The value is pushed onto the stack. The `ldelem.i4` instruction loads the value of the element with index `index` (type `native int`) in the zero-based one-dimensional array `array` and places it on the top of the stack. Arrays are objects and hence represented by a value of type `O`. @@ -8279,7 +8279,7 @@ The following method overloads c The following method overload can use the `ldelem.i4` opcode: -- +- ]]> @@ -8336,13 +8336,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An object reference `array` is pushed onto the stack. +1. An object reference `array` is pushed onto the stack. -2. An index value `index` is pushed onto the stack. +2. An index value `index` is pushed onto the stack. -3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. +3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. -4. The value is pushed onto the stack. +4. The value is pushed onto the stack. The `ldelem.i8` instruction loads the value of the element with index `index` (type `native int`) in the zero-based one-dimensional array `array` and places it on the top of the stack. Arrays are objects and hence represented by a value of type `O`. @@ -8358,7 +8358,7 @@ The following method overloads c The following method overload can use the `ldelem.i8` opcode: -- +- ]]> @@ -8415,13 +8415,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An object reference `array` is pushed onto the stack. +1. An object reference `array` is pushed onto the stack. -2. An index value `index` is pushed onto the stack. +2. An index value `index` is pushed onto the stack. -3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. +3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. -4. The value is pushed onto the stack. +4. The value is pushed onto the stack. The `ldelem.r4` instruction loads the value of the element with index `index` (type `native int`) in the zero-based one-dimensional array `array` and places it on the top of the stack. Arrays are objects and hence represented by a value of type `O`. @@ -8437,7 +8437,7 @@ The following method overloads c The following method overload can use the `ldelem.r4` opcode: -- +- ]]> @@ -8494,13 +8494,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An object reference `array` is pushed onto the stack. +1. An object reference `array` is pushed onto the stack. -2. An index value `index` is pushed onto the stack. +2. An index value `index` is pushed onto the stack. -3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. +3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. -4. The value is pushed onto the stack. +4. The value is pushed onto the stack. The `ldelem.r8` instruction loads the value of the element with index `index` (type `native int`) in the zero-based one-dimensional array `array` and places it on the top of the stack. Arrays are objects and hence represented by a value of type `O`. @@ -8516,7 +8516,7 @@ The following method overloads c The following method overload can use the `ldelem.r8` opcode: -- +- ]]> @@ -8573,13 +8573,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An object reference `array` is pushed onto the stack. +1. An object reference `array` is pushed onto the stack. -2. An index value `index` is pushed onto the stack. +2. An index value `index` is pushed onto the stack. -3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. +3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. -4. The value is pushed onto the stack. +4. The value is pushed onto the stack. The `ldelem.ref` instruction loads the value of the element with index `index` (type `native int`) in the zero-based one-dimensional array `array` and places it on the top of the stack. Arrays are objects and hence represented by a value of type `O`. @@ -8593,7 +8593,7 @@ The following method overloads c The following method overload can use the `ldelem.ref` opcode: -- +- ]]> @@ -8650,13 +8650,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An object reference `array` is pushed onto the stack. +1. An object reference `array` is pushed onto the stack. -2. An index value `index` is pushed onto the stack. +2. An index value `index` is pushed onto the stack. -3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. +3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. -4. The value is pushed onto the stack. +4. The value is pushed onto the stack. The `ldelem.u1` instruction loads the value of the element with index `index` (type `native int`) in the zero-based one-dimensional array `array` and places it on the top of the stack. Arrays are objects and hence represented by a value of type `O`. @@ -8672,7 +8672,7 @@ The following method overloads c The following method overload can use the `ldelem.u1` opcode: -- +- ]]> @@ -8729,13 +8729,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An object reference `array` is pushed onto the stack. +1. An object reference `array` is pushed onto the stack. -2. An index value `index` is pushed onto the stack. +2. An index value `index` is pushed onto the stack. -3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. +3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. -4. The value is pushed onto the stack. +4. The value is pushed onto the stack. The `ldelem.u2` instruction loads the value of the element with index `index` (type `native int`) in the zero-based one-dimensional array `array` and places it on the top of the stack. Arrays are objects and hence represented by a value of type `O`. @@ -8751,7 +8751,7 @@ The following method overloads c The following method overload can use the `ldelem.u2` opcode: -- +- ]]> @@ -8808,13 +8808,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An object reference `array` is pushed onto the stack. +1. An object reference `array` is pushed onto the stack. -2. An index value `index` is pushed onto the stack. +2. An index value `index` is pushed onto the stack. -3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. +3. `index` and `array` are popped from the stack; the value stored at position `index` in `array` is looked up. -4. The value is pushed onto the stack. +4. The value is pushed onto the stack. The `ldelem.u4` instruction loads the value of the element with index `index` (type `native int`) in the zero-based one-dimensional array `array` and places it on the top of the stack. Arrays are objects and hence represented by a value of type `O`. @@ -8830,7 +8830,7 @@ The following method overloads c The following method overload can use the `ldelem.u4` opcode: -- +- ]]> @@ -8887,13 +8887,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An object reference `array` is pushed onto the stack. +1. An object reference `array` is pushed onto the stack. -2. An index value `index` is pushed onto the stack. +2. An index value `index` is pushed onto the stack. -3. `index` and `array` are popped from the stack; the address stored at position `index` in `array` is looked up. +3. `index` and `array` are popped from the stack; the address stored at position `index` in `array` is looked up. -4. The address is pushed onto the stack. +4. The address is pushed onto the stack. The `ldelema` is used to retrieve the address of an object at a particular index in an array of objects (of type `class`). The `ldelema` instruction loads the address of the value at index `index` (type `native int`) in the zero-based one-dimensional array `array` and places it on the top of the stack. Arrays are objects and hence represented by a value of type `O`. The value must be of type `class` passed with the instruction. @@ -8909,7 +8909,7 @@ The following method overloads c The following method overload can use the `ldelema` opcode: -- +- ]]> @@ -8966,11 +8966,11 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An object reference (or pointer) is pushed onto the stack. +1. An object reference (or pointer) is pushed onto the stack. -2. The object reference (or pointer) is popped from the stack; the value of the specified field in the object is found. +2. The object reference (or pointer) is popped from the stack; the value of the specified field in the object is found. -3. The value stored in the field is pushed onto the stack. +3. The value stored in the field is pushed onto the stack. The `ldfld` instruction pushes the value of a field located in an object onto the stack. The object must be on the stack as an object reference (type `O`), a managed pointer (type `&`), an unmanaged pointer (type `native int`), a transient pointer (type `*`), or an instance of a value type. The use of an unmanaged pointer is not permitted in verifiable code. The object's field is specified by a metadata token that must refer to a field member. The return type is the same as the one associated with the field. The field may be either an instance field (in which case the object must not be a null reference) or a static field. @@ -8982,7 +8982,7 @@ The following method overloads c The following method overload can use the `ldfld` opcode: -- +- ]]> @@ -9039,11 +9039,11 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An object reference (or pointer) is pushed onto the stack. +1. An object reference (or pointer) is pushed onto the stack. -2. The object reference (or pointer) is popped from the stack; the address of the specified field in the object is found. +2. The object reference (or pointer) is popped from the stack; the address of the specified field in the object is found. -3. The address of the specified field is pushed onto the stack. +3. The address of the specified field is pushed onto the stack. The `ldflda` instruction pushes the address of a field located in an object onto the stack. The object must be on the stack as an object reference (type `O`), a managed pointer (type `&`), an unmanaged pointer (type `native int`), a transient pointer (type `*`), or an instance of a value type. The use of an unmanaged pointer is not permitted in verifiable code. The object's field is specified by a metadata token that must refer to a field member. @@ -9051,15 +9051,13 @@ The following method overloads c The `ldflda` instruction can be preceded by either or both of the and prefixes. - is thrown if the object is not within the application domain from which it is being accessed. The address of a field that is not inside the accessing application domain cannot be loaded. - is thrown if the object is null and the field is not static. is thrown if the specified field is not found in the metadata. This is typically checked when Microsoft Intermediate Language (MSIL) instructions are converted to native code, not at run time. The following method overload can use the `ldflda` opcode: -- +- ]]> @@ -9116,7 +9114,7 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. The unmanaged pointer to a specific method is pushed onto the stack. +1. The unmanaged pointer to a specific method is pushed onto the stack. The specific method (`method`) can be called using the instruction if it references a managed method (or a stub that transitions from managed to unmanaged code). @@ -9124,7 +9122,7 @@ The following method overloads c The following method overload can use the `ldftn` opcode: -- +- ]]> @@ -9181,11 +9179,11 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. -2. The address is popped from the stack; the value located at the address is fetched. +2. The address is popped from the stack; the value located at the address is fetched. -3. The fetched value is pushed onto the stack. +3. The fetched value is pushed onto the stack. The `ldind.i` instruction indirectly loads a `native int` value from the specified address (of type `native int`, `&`, or *) onto the stack as a `native int`. @@ -9201,7 +9199,7 @@ The following method overloads c The following method overload can use the `ldind.i` opcode: -- +- ]]> @@ -9258,11 +9256,11 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. -2. The address is popped from the stack; the value located at the address is fetched. +2. The address is popped from the stack; the value located at the address is fetched. -3. The fetched value is pushed onto the stack. +3. The fetched value is pushed onto the stack. The `ldind.i1` instruction indirectly loads an `int8` value from the specified address (of type `native int`, `&`, or *) onto the stack as an `int32`. @@ -9278,7 +9276,7 @@ The following method overloads c The following method overload can use the `ldind.i1` opcode: -- +- ]]> @@ -9335,11 +9333,11 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. -2. The address is popped from the stack; the value located at the address is fetched. +2. The address is popped from the stack; the value located at the address is fetched. -3. The fetched value is pushed onto the stack. +3. The fetched value is pushed onto the stack. The `ldind.i2` instruction indirectly loads an `int16` value from the specified address (of type `native int`, `&`, or *) onto the stack as an `int32`. @@ -9355,7 +9353,7 @@ The following method overloads c The following method overload can use the `ldind.i2` opcode: -- +- ]]> @@ -9412,11 +9410,11 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. -2. The address is popped from the stack; the value located at the address is fetched. +2. The address is popped from the stack; the value located at the address is fetched. -3. The fetched value is pushed onto the stack. +3. The fetched value is pushed onto the stack. The `ldind.i4` instruction indirectly loads an `int32` value from the specified address (of type `native int`, `&`, or *) onto the stack as an `int32`. @@ -9432,7 +9430,7 @@ The following method overloads c The following method overload can use the `ldind.i4` opcode: -- +- ]]> @@ -9489,11 +9487,11 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. -2. The address is popped from the stack; the value located at the address is fetched. +2. The address is popped from the stack; the value located at the address is fetched. -3. The fetched value is pushed onto the stack. +3. The fetched value is pushed onto the stack. The `ldind.i8` instruction indirectly loads an `int64` value from the specified address (of type `native int`, `&`, or *) onto the stack as an `int64`. @@ -9509,7 +9507,7 @@ The following method overloads c The following method overload can use the `ldind.i8` opcode: -- +- ]]> @@ -9566,11 +9564,11 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. -2. The address is popped from the stack; the value located at the address is fetched. +2. The address is popped from the stack; the value located at the address is fetched. -3. The fetched value is pushed onto the stack. +3. The fetched value is pushed onto the stack. The `ldind.r4` instruction indirectly loads a `float32` value from the specified address (of type `native int`, `&`, or *) onto the stack as a type `F`. @@ -9586,7 +9584,7 @@ The following method overloads c The following method overload can use the `ldind.r4` opcode: -- +- ]]> @@ -9643,11 +9641,11 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. -2. The address is popped from the stack; the value located at the address is fetched. +2. The address is popped from the stack; the value located at the address is fetched. -3. The fetched value is pushed onto the stack. +3. The fetched value is pushed onto the stack. The `ldind.r8` instruction indirectly loads a `float64` value from the specified address (of type `native int`, `&`, or *) onto the stack as a `float64`. @@ -9663,7 +9661,7 @@ The following method overloads c The following method overload can use the `ldind.r8` opcode: -- +- ]]> @@ -9720,11 +9718,11 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. -2. The address is popped from the stack; the object reference located at the address is fetched. +2. The address is popped from the stack; the object reference located at the address is fetched. -3. The fetched reference is pushed onto the stack. +3. The fetched reference is pushed onto the stack. The `ldind.ref` instruction indirectly loads the object reference the specified address (of type `native int`, `&`, or *) onto the stack as type `O`. @@ -9740,7 +9738,7 @@ The following method overloads c The following method overload can use the `ldind.ref` opcode: -- +- ]]> @@ -9797,11 +9795,11 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. -2. The address is popped from the stack; the value located at the address is fetched. +2. The address is popped from the stack; the value located at the address is fetched. -3. The fetched value is pushed onto the stack. +3. The fetched value is pushed onto the stack. The `ldind.u1` instruction indirectly loads an `unsigned int8` value from the specified address (of type`native int`, `&`, or *) onto the stack as an `int32`. @@ -9817,7 +9815,7 @@ The following method overloads c The following method overload can use the `ldind.u1` opcode: -- +- ]]> @@ -9874,11 +9872,11 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. -2. The address is popped from the stack; the value located at the address is fetched. +2. The address is popped from the stack; the value located at the address is fetched. -3. The fetched value is pushed onto the stack. +3. The fetched value is pushed onto the stack. The `ldind.u2` instruction indirectly loads an `unsigned int16` value from the specified address (of type `native int`, `&`, or *) onto the stack as an `int32`. @@ -9894,7 +9892,7 @@ The following method overloads c The following method overload can use the `ldind.u2` opcode: -- +- ]]> @@ -9951,11 +9949,11 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. -2. The address is popped from the stack; the value located at the address is fetched. +2. The address is popped from the stack; the value located at the address is fetched. -3. The fetched value is pushed onto the stack. +3. The fetched value is pushed onto the stack. The `ldind.u4` instruction indirectly loads an `unsigned int32` value from the specified address (of type `native int`, `&`, or *) onto the stack as an `int32`. @@ -9971,7 +9969,7 @@ The following method overloads c The following method overload can use the `ldind.u4` opcode: -- +- ]]> @@ -10028,11 +10026,11 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An object reference to an array is pushed onto the stack. +1. An object reference to an array is pushed onto the stack. -2. The array reference is popped from the stack and the length is computed. +2. The array reference is popped from the stack and the length is computed. -3. The length is pushed onto the stack. +3. The length is pushed onto the stack. Arrays are objects and hence represented by a value of type `O`. The length is returned as a `natural unsigned int`. @@ -10040,7 +10038,7 @@ The following method overloads c The following method overload can use the `ldlen` opcode: -- +- ]]> @@ -10097,7 +10095,7 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. The local variable value at the specified index is pushed onto the stack. +1. The local variable value at the specified index is pushed onto the stack. The `ldloc` instruction pushes the contents of the local variable number at the passed index onto the evaluation stack, where the local variables are numbered 0 onwards. Local variables are initialized to 0 before entering the method only if the initialize flag on the method is true. There are 65,535 (2^16-1) local variables possible (0-65,534). Index 65,535 is not valid since likely implementations will use a 2-byte integer to track both a local's index, along with the total number of locals for a given method. If an index of 65535 had been made valid, it would require a wider integer to track the number of locals in such a method. @@ -10107,9 +10105,9 @@ The following method overloads c The following method overloads can use the `ldloc` opcode: -- +- -- +- ]]> @@ -10166,7 +10164,7 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. The local variable value at the index 0 is pushed onto the stack. +1. The local variable value at the index 0 is pushed onto the stack. `ldloc.0` is an especially efficient encoding for , allowing access to the local variable at index 0. @@ -10174,7 +10172,7 @@ The following method overloads c The following method overload can use the `ldloc.0` opcode: -- +- ]]> @@ -10231,7 +10229,7 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. The local variable value at the index 1 is pushed onto the stack. +1. The local variable value at the index 1 is pushed onto the stack. `ldloc.1` is an especially efficient encoding for , allowing access to the local variable at index 1. @@ -10239,7 +10237,7 @@ The following method overloads c The following method overload can use the `ldloc.1` opcode: -- +- ]]> @@ -10296,7 +10294,7 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. The local variable value at the index 2 is pushed onto the stack. +1. The local variable value at the index 2 is pushed onto the stack. `ldloc.2` is an especially efficient encoding for , allowing access to the local variable at index 2. @@ -10304,7 +10302,7 @@ The following method overloads c The following method overload can use the `ldloc.2` opcode: -- +- ]]> @@ -10361,7 +10359,7 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. The local variable value at the index 3 is pushed onto the stack. +1. The local variable value at the index 3 is pushed onto the stack. `ldloc.3` is an especially efficient encoding for , allowing access to the local variable at index 3. @@ -10369,7 +10367,7 @@ The following method overloads c The following method overload can use the `ldloc.3` opcode: -- +- ]]> @@ -10426,7 +10424,7 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. The local variable value at the specified index is pushed onto the stack. +1. The local variable value at the specified index is pushed onto the stack. The `ldloc.s` instruction pushes the contents of the local variable number at the passed index onto the evaluation stack, where the local variables are numbered 0 onwards. Local variables are initialized to 0 before entering the method if the initialize flag on the method is true. There are 256 (2^8) local variables possible (0-255) in the short form, which is a more efficient encoding than `ldloc`. @@ -10434,9 +10432,9 @@ The following method overloads c The following method overloads can use the `ldloc.s` opcode: -- +- -- +- ]]> @@ -10493,13 +10491,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. The address of the local variable at the specified index is pushed onto the stack. +1. The address of the local variable at the specified index is pushed onto the stack. The `ldloca` instruction pushes the address of the local variable number at the passed index onto the stack, where local variables are numbered 0 onwards. The value pushed on the stack is already aligned correctly for use with instructions like and . The result is a managed pointer (type `&`). The local variable is stored in unmanaged memory, so the return value can be converted to an unmanaged pointer without pinning. The following method overload can use the `ldloca` opcode: -- +- ]]> @@ -10556,7 +10554,7 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. The address of the local variable at the specified index is pushed onto the stack. +1. The address of the local variable at the specified index is pushed onto the stack. The `ldloca.s` instruction pushes the address of the local variable number at the passed index onto the stack, where local variables are numbered 0 onwards. The value pushed on the stack is already aligned correctly for use with instructions like and . The result is a managed pointer (type `&`). The local variable is stored in unmanaged memory, so the return value can be converted to an unmanaged pointer without pinning. @@ -10564,7 +10562,7 @@ The following method overloads c The following method overload can use the `ldloca.s` opcode: -- +- ]]> @@ -10621,7 +10619,7 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. A null object reference is pushed onto the stack. +1. A null object reference is pushed onto the stack. `ldnull` pushes a null reference (type `O`) on the stack. This is used to initialize locations before they are populated with data, or when they become deprecated. @@ -10629,7 +10627,7 @@ The following method overloads c The following method overload can use the `ldnull` opcode: -- +- ]]> @@ -10686,11 +10684,11 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. The address of a value type object is pushed onto the stack. +1. The address of a value type object is pushed onto the stack. -2. The address is popped from the stack and the instance at that particular address is looked up. +2. The address is popped from the stack and the instance at that particular address is looked up. -3. The value of the object stored at that address is pushed onto the stack. +3. The value of the object stored at that address is pushed onto the stack. The `ldobj` instruction is used to pass a value type as a parameter. @@ -10702,7 +10700,7 @@ The following method overloads c The following method overload can use the `ldobj` opcode: -- +- ]]> @@ -10759,7 +10757,7 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. The value of the specific field is pushed onto the stack. +1. The value of the specific field is pushed onto the stack. The `ldsfld` instruction pushes the value of a static (shared among all instances of a class) field on the stack. The return type is that associated with the passed metadata token `field`. @@ -10767,7 +10765,7 @@ The following method overloads c The following method overload can use the `ldsfld` opcode: -- +- ]]> @@ -10824,7 +10822,7 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. The address of a specific field is pushed onto the stack. +1. The address of a specific field is pushed onto the stack. The `ldsflda` instruction pushes the address of a static (shared among all instances of a class) field on the stack. The address may be represented as a transient pointer (type `*`) if the metadata token `field` refers to a type whose memory is managed. Otherwise, it corresponds to an unmanaged pointer (type `native int`). Note that `field` may be a static global with an assigned relative virtual address (the offset of the field from the base address at which its containing PE file is loaded into memory) where the memory is unmanaged. @@ -10834,7 +10832,7 @@ The following method overloads c The following method overload can use the `ldsflda` opcode: -- +- ]]> @@ -10891,7 +10889,7 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An object reference to a string is pushed onto the stack. +1. An object reference to a string is pushed onto the stack. The `ldstr` instruction pushes an object reference (type `O`) to a new string object representing the specific string literal stored in the metadata. The `ldstr` instruction allocates the requisite amount of memory and performs any format conversion required to convert the string literal from the form used in the file to the string format required at runtime. @@ -10899,7 +10897,7 @@ The following method overloads c The following method overload can use the `ldstr` opcode: -- +- ]]> @@ -10956,7 +10954,7 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. The passed token is converted to a `RuntimeHandle` and pushed onto the stack. +1. The passed token is converted to a `RuntimeHandle` and pushed onto the stack. The `ldtoken` instruction pushes a `RuntimeHandle` for the specified metadata token. A `RuntimeHandle` can be a `fieldref/fielddef`, a `methodref/methoddef`, or a `typeref/typedef`. @@ -10966,11 +10964,11 @@ The following method overloads c The following method overloads can use the `ldtoken` opcode: -- +- -- +- -- +- ]]> @@ -11027,11 +11025,11 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. An object reference is pushed onto the stack. +1. An object reference is pushed onto the stack. -2. The object reference is popped from the stack and the address of the entry point to the method (as specified by the metadata token `method`) is looked up. +2. The object reference is popped from the stack and the address of the entry point to the method (as specified by the metadata token `method`) is looked up. -3. The pointer to `method` is pushed onto the stack. +3. The pointer to `method` is pushed onto the stack. The resulting unmanaged pointer pushed onto the stack by the `ldvirtftn` instruction can be called using the instruction if it references a managed method (or a stub that transitions from managed to unmanaged code). @@ -11039,7 +11037,7 @@ The following method overloads c The following method overload can use the `ldvirtftn` opcode: -- +- ]]> @@ -11106,7 +11104,7 @@ The following method overloads c The following method overloads can use the `leave` opcode: -- +- ]]> @@ -11173,7 +11171,7 @@ The following method overloads c The following method overload can use the `leave.s` opcode: -- +- ]]> @@ -11230,11 +11228,11 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. The number of bytes to be allocated is pushed onto the stack. +1. The number of bytes to be allocated is pushed onto the stack. -2. The number of bytes is popped from the stack; an amount of memory corresponding to the size is allocated from the local heap. +2. The number of bytes is popped from the stack; an amount of memory corresponding to the size is allocated from the local heap. -3. A pointer to the first byte of the allocated memory is pushed onto the stack. +3. A pointer to the first byte of the allocated memory is pushed onto the stack. The `localloc` instruction allocates `size` (type `natural unsigned int`) bytes from the local dynamic memory pool and returns the address (a transient pointer, type `*`) of the first allocated byte. The block of memory returned is initialized to 0 only if the initialize flag on the method is `true`. When the current method executes a , the local memory pool is made available for reuse. @@ -11246,7 +11244,7 @@ The following method overloads c The following method overload can use the `localloc` opcode: -- +- ]]> @@ -11303,11 +11301,11 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. A pointer to piece of data is pushed onto the stack. +1. A pointer to piece of data is pushed onto the stack. -2. The pointer is popped and converted to a typed reference of type `class`. +2. The pointer is popped and converted to a typed reference of type `class`. -3. The typed reference is pushed onto the stack. +3. The typed reference is pushed onto the stack. The `mkrefany` instruction supports the passing of dynamically typed references. The pointer must be of type `&`, `*`, or `native int`, and hold the valid address of a piece of data. `Class` is the class token describing the type of the data referenced by the pointer. `Mkrefany` pushes a typed reference on the stack, providing an opaque descriptor of the pointer and the type `class`. @@ -11317,7 +11315,7 @@ The following method overloads c The following method overload can use the `mkrefany` opcode: -- +- ]]> @@ -11374,13 +11372,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; `value1` is multiplied by `value2`. +3. `value2` and `value1` are popped from the stack; `value1` is multiplied by `value2`. -4. The result is pushed onto the stack. +4. The result is pushed onto the stack. The `mul` instruction multiplies `value1` by `value2` and pushes the result on the stack. Integer operations silently truncate the upper bits on overflow. @@ -11390,7 +11388,7 @@ The following method overloads c The following method overload can use the `mul` opcode: -- +- ]]> @@ -11447,13 +11445,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; `value1` is multiplied by `value2`, with an overflow check. +3. `value2` and `value1` are popped from the stack; `value1` is multiplied by `value2`, with an overflow check. -4. The result is pushed onto the stack. +4. The result is pushed onto the stack. The `mul.ovf` instruction multiplies integer `value1` by integer `value2` and pushes the result on the stack. An exception is thrown if the result will not fit in the result type. @@ -11461,7 +11459,7 @@ The following method overloads c The following method overload can use the `mul.ovf` opcode: -- +- ]]> @@ -11518,13 +11516,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack; `value1` is multiplied by `value2`, with an overflow check. +3. `value2` and `value1` are popped from the stack; `value1` is multiplied by `value2`, with an overflow check. -4. The result is pushed onto the stack. +4. The result is pushed onto the stack. The `mul.ovf.un` instruction multiplies unsigned integer `value1` by unsigned integer `value2` and pushes the result on the stack. An exception is thrown if the result will not fit in the result type. @@ -11532,7 +11530,7 @@ The following method overloads c The following method overload can use the `mul.ovf.un` opcode: -- +- ]]> @@ -11589,11 +11587,11 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. A value is pushed onto the stack. +1. A value is pushed onto the stack. -2. A value is popped from the stack and negated. +2. A value is popped from the stack and negated. -3. The result is pushed onto the stack. +3. The result is pushed onto the stack. The `neg` instruction negates value and pushes the result on top of the stack. The return type is the same as the operand type. @@ -11603,7 +11601,7 @@ The following method overloads c The following method overload can use the `neg` opcode: -- +- ]]> @@ -11660,11 +11658,9 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. The number of elements in the array is pushed onto the stack. - -2. The number of elements is popped from the stack and the array is created. - -3. An object reference to the new array is pushed onto the stack. +1. The number of elements in the array is pushed onto the stack. +2. The number of elements is popped from the stack and the array is created. +3. An object reference to the new array is pushed onto the stack. The `newarr` instruction pushes an object reference (type `O`) to a new zero-based, one-dimensional array whose elements are of type `etype` (a metadata token describing the type). The number of elements in the new array should be specified as a `native int`. Valid array indexes range from zero to the maximum number of elements minus one. @@ -11672,15 +11668,13 @@ The following method overloads c Zero-based, one-dimensional arrays of numbers are created using a metadata token referencing the appropriate value type (, and so on). Elements of the array are initialized to 0 of the appropriate type. - Nonzero-based one-dimensional arrays and multidimensional arrays are created using rather than `newarr`. More commonly, they are created using the methods of the class in the .NET Framework. + Nonzero-based one-dimensional arrays and multidimensional arrays are created using rather than `newarr`. More commonly, they are created using the methods of the class. is thrown if there is insufficient memory to satisfy the request. is thrown if `numElems` is less than 0. - The following method overload can use the `newarr` opcode: - -- + The method uses the `newarr` opcode. ]]> @@ -11737,11 +11731,11 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. Arguments `arg1` through `argn` are pushed on the stack in sequence. +1. Arguments `arg1` through `argn` are pushed on the stack in sequence. -2. Arguments `argn` through `arg1` are popped from the stack and passed to `ctor` for object creation. +2. Arguments `argn` through `arg1` are popped from the stack and passed to `ctor` for object creation. -3. A reference to the new object is pushed onto the stack. +3. A reference to the new object is pushed onto the stack. The `newobj` instruction creates a new object or a new instance of a value type. `Ctor` is a metadata token (a `methodref` or `methoddef` that must be marked as a constructor) that indicates the name, class and signature of the constructor to call. @@ -11759,7 +11753,7 @@ The following method overloads c The following method overload can use the `newobj` opcode: -- +- ]]> @@ -11820,7 +11814,7 @@ The following method overloads c The following method overload can use the `nop` opcode: -- +- ]]> @@ -11877,17 +11871,17 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. `value` is pushed onto the stack. +1. `value` is pushed onto the stack. -2. `value` is popped from the stack and its bitwise complement computed. +2. `value` is popped from the stack and its bitwise complement computed. -3. The result is pushed onto the stack. +3. The result is pushed onto the stack. The `not` instruction computes the bitwise complement of an integer value and pushes the result onto the stack. The return type is the same as the operand type. The following method overload can use the `not` opcode: -- +- ]]> @@ -11944,13 +11938,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack and their bitwise OR computed. +3. `value2` and `value1` are popped from the stack and their bitwise OR computed. -4. The result is pushed onto the stack. +4. The result is pushed onto the stack. The `or` instruction computes the bitwise OR of two values atop the stack, pushing the result onto the stack. @@ -11958,7 +11952,7 @@ The following method overloads c The following method overload can use the `or` opcode: -- +- ]]> @@ -12015,13 +12009,13 @@ The following method overloads c The stack transitional behavior, in sequential order, is: -1. The top value is popped from the stack. +1. The top value is popped from the stack. The `pop` instruction removes the top element from the stack. The following method overload can use the `pop` opcode: -- +- ]]> @@ -12413,9 +12407,9 @@ The following method overloads c This prefix can only appear immediately preceding the `ldelema` instruction and calls to the special `Address` method on arrays. Its effect on the subsequent operation is twofold: -1. At run time, no type check operation is performed. Note that there is normally an implicit type check for the `ldelema` and `stelem` instructions when used on reference type arrays. There is never a run-time type check for value classes, so `readonly` is a no-op in that case. +1. At run time, no type check operation is performed. Note that there is normally an implicit type check for the `ldelema` and `stelem` instructions when used on reference type arrays. There is never a run-time type check for value classes, so `readonly` is a no-op in that case. -2. The verifier treats the result of the address-of operation as a managed pointer with restricted mutability. +2. The verifier treats the result of the address-of operation as a managed pointer with restricted mutability. The pointer is said to have restricted mutability because the defining type controls whether the value can be mutated. For value classes that expose no public fields or methods that update the value in place, the pointer is read-only (hence the name of the prefix). In particular, the classes representing primitive types (for example, System.Int32) do not expose mutators and thus are read-only. @@ -12449,7 +12443,7 @@ callvirt m The following method overload can use the `readonly` opcode: -- +- ]]> @@ -12506,11 +12500,11 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. A value type reference is pushed onto the stack. +1. A value type reference is pushed onto the stack. -2. The typed reference is popped from the stack and its corresponding type token retrieved. +2. The typed reference is popped from the stack and its corresponding type token retrieved. -3. The type token is pushed onto the stack. +3. The type token is pushed onto the stack. A typed reference contains a type token and an address to an object instance. @@ -12518,7 +12512,7 @@ callvirt m The following method overload can use the `refanytype` opcode: -- +- ]]> @@ -12575,11 +12569,11 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. A value type reference is pushed onto the stack. +1. A value type reference is pushed onto the stack. -2. The typed reference is popped from the stack and the corresponding address retrieved. +2. The typed reference is popped from the stack and the corresponding address retrieved. -3. The address is pushed onto the stack. +3. The address is pushed onto the stack. A typed reference contains a type token and an address to an object instance. @@ -12591,7 +12585,7 @@ callvirt m The following method overload can use the `refanyval` opcode: -- +- ]]> @@ -12649,13 +12643,13 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. A `value1` is pushed onto the stack. +1. A `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack and the remainder of `value1` `div` `value2` computed. +3. `value2` and `value1` are popped from the stack and the remainder of `value1` `div` `value2` computed. -4. The result is pushed onto the stack. +4. The result is pushed onto the stack. `result` = `value1` `rem` `value2` satisfies the following conditions: @@ -12671,7 +12665,7 @@ callvirt m The following method overload can use the `rem` opcode: -- +- ]]> @@ -12728,13 +12722,13 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack and the remainder of `value1` `div` `value2` computed. +3. `value2` and `value1` are popped from the stack and the remainder of `value1` `div` `value2` computed. -4. The result is pushed onto the stack. +4. The result is pushed onto the stack. `result` = `value1` `rem.un` `value2` satisfies the following conditions: @@ -12750,7 +12744,7 @@ callvirt m The following method overload can use the `rem.un` opcode: -- +- ]]> @@ -12807,9 +12801,9 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. The return value is popped from the callee evaluation stack. +1. The return value is popped from the callee evaluation stack. -2. The return value obtained in step 1 is pushed onto the caller evaluation stack. +2. The return value obtained in step 1 is pushed onto the caller evaluation stack. If the return value is not present on the callee evaluation stack, no value is returned (no stack transition behaviors for either the callee or caller method). @@ -12819,7 +12813,7 @@ callvirt m The following method overload can use the `ret` opcode: -- +- ]]> @@ -12880,7 +12874,7 @@ callvirt m The following method overload can use the `rethrow` opcode: -- +- ]]> @@ -12937,13 +12931,13 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. A value is pushed onto the stack. +1. A value is pushed onto the stack. -2. The amount of bits to be shifted is pushed onto the stack. +2. The amount of bits to be shifted is pushed onto the stack. -3. The number of bits to be shifted and the value are popped from the stack; the value is shifted left by the specified number of bits. +3. The number of bits to be shifted and the value are popped from the stack; the value is shifted left by the specified number of bits. -4. The result is pushed onto the stack. +4. The result is pushed onto the stack. The `shl` instruction shifts the value (type `int32`, `int64` or `native int`) left by the specified number of bits. The number of bits is a value of type `int32` or `native int`. The return value is unspecified if the number of bits to be shifted is greater than or equal to the width (in bits) of the supplied value. @@ -12951,7 +12945,7 @@ callvirt m The following method overload can use the `shl` opcode: -- +- ]]> @@ -13008,13 +13002,13 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. A value is pushed onto the stack. +1. A value is pushed onto the stack. -2. The amount of bits to be shifted is pushed onto the stack. +2. The amount of bits to be shifted is pushed onto the stack. -3. The number of bits to be shifted and the value are popped from the stack; the value is shifted right by the specified number of bits. +3. The number of bits to be shifted and the value are popped from the stack; the value is shifted right by the specified number of bits. -4. The result is pushed onto the stack. +4. The result is pushed onto the stack. The `shr.un` instruction shifts the value (type `int32`, `int64` or `native int`) right by the specified number of bits. The number of bits is a value of type `int32` or `native int`. The return value is unspecified if the number of bits to be shifted is greater than or equal to the width (in bits) of the supplied value. @@ -13022,7 +13016,7 @@ callvirt m The following method overload can use the `shr` opcode: -- +- ]]> @@ -13079,13 +13073,13 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. A value is pushed onto the stack. +1. A value is pushed onto the stack. -2. The amount of bits to be shifted is pushed onto the stack. +2. The amount of bits to be shifted is pushed onto the stack. -3. The number of bits to be shifted and the value are popped from the stack; the value is shifted right by the specified number of bits. +3. The number of bits to be shifted and the value are popped from the stack; the value is shifted right by the specified number of bits. -4. The result is pushed onto the stack. +4. The result is pushed onto the stack. The `shr.un` instruction shifts the value (type `int32`, `int64` or `native int`) right by the specified number of bits. The number of bits is a value of type `int32`, `int64` or `native int`. The return value is unspecified if the number of bits to be shifted is greater than or equal to the width (in bits) of the supplied value. @@ -13093,7 +13087,7 @@ callvirt m The following method overload can use the `shr.un` opcode: -- +- ]]> @@ -13150,7 +13144,7 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. The size (in bytes) of the supplied value type (`valType`) is pushed onto the stack. +1. The size (in bytes) of the supplied value type (`valType`) is pushed onto the stack. `valType` must be a metadata token (a `typeref` or `typedef`) that specifies a value type, reference type, or generic type parameter. @@ -13158,7 +13152,7 @@ callvirt m The following method overload can use the `sizeof` opcode: -- +- ]]> @@ -13216,7 +13210,7 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. The value currently on top of the stack is popped and placed in argument slot `num`. +1. The value currently on top of the stack is popped and placed in argument slot `num`. The `starg` instruction pops a value from the stack and places it in argument slot `num`. The type of the value must match the type of the argument, as specified in the current method's signature. @@ -13226,7 +13220,7 @@ callvirt m The following method overload can use the `starg` opcode: -- +- ]]> @@ -13283,7 +13277,7 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. The value currently on top of the stack is popped and placed in argument slot `num`. +1. The value currently on top of the stack is popped and placed in argument slot `num`. The `starg.s` instruction pops a value from the stack and places it in argument slot `num`. The type of the value must match the type of the argument, as specified in the current method's signature. @@ -13295,7 +13289,7 @@ callvirt m The following method overload can use the `starg.s` opcode: -- +- ]]> @@ -13351,13 +13345,13 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An object reference to an array, `array`, is pushed onto the stack. +1. An object reference to an array, `array`, is pushed onto the stack. -2. An index value, `index`, to an element in `array` is pushed onto the stack. +2. An index value, `index`, to an element in `array` is pushed onto the stack. -3. A value of the type specified in the instruction is pushed onto the stack. +3. A value of the type specified in the instruction is pushed onto the stack. -4. The value, the index, and the array reference are popped from the stack; the value is put into the array element at the given index. +4. The value, the index, and the array reference are popped from the stack; the value is put into the array element at the given index. The `stelem` instruction replaces the value of the element at the supplied zero-based index in the one-dimensional array `array` with the value. The value has the type specified by the token `typeTok` in the instruction. @@ -13371,7 +13365,7 @@ callvirt m The following method overload can use the `stelem` opcode: -- +- ]]> @@ -13428,13 +13422,13 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An object reference to an array, `array`, is pushed onto the stack. +1. An object reference to an array, `array`, is pushed onto the stack. -2. A valid index to an element in `array` is pushed onto the stack. +2. A valid index to an element in `array` is pushed onto the stack. -3. A value is pushed onto the stack. +3. A value is pushed onto the stack. -4. The value, the index, and the array reference are popped from the stack; the value is put into the array element at the given index. +4. The value, the index, and the array reference are popped from the stack; the value is put into the array element at the given index. The `stelem.i` instruction replaces the value of the element `index` in the one-dimensional array `array` with the `native int` value pushed onto the stack. @@ -13448,7 +13442,7 @@ callvirt m The following method overload can use the `stelem.i` opcode: -- +- ]]> @@ -13505,13 +13499,13 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An object reference to an array, `array`, is pushed onto the stack. +1. An object reference to an array, `array`, is pushed onto the stack. -2. A valid index to an element in `array` is pushed onto the stack. +2. A valid index to an element in `array` is pushed onto the stack. -3. A value is pushed onto the stack. +3. A value is pushed onto the stack. -4. The value, the index, and the array reference are popped from the stack; the value is put into the array element at the given index. +4. The value, the index, and the array reference are popped from the stack; the value is put into the array element at the given index. The `stelem.i1` instruction replaces the value of the element `index` in the one-dimensional array `array` with the `int8` value pushed onto the stack. @@ -13525,7 +13519,7 @@ callvirt m The following method overload can use the `stelem.i1` opcode: -- +- ]]> @@ -13582,13 +13576,13 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An object reference to an array, `array`, is pushed onto the stack. +1. An object reference to an array, `array`, is pushed onto the stack. -2. A valid index to an element in `array` is pushed onto the stack. +2. A valid index to an element in `array` is pushed onto the stack. -3. A value is pushed onto the stack. +3. A value is pushed onto the stack. -4. The value, the index, and the array reference are popped from the stack; the value is put into the array element at the given index. +4. The value, the index, and the array reference are popped from the stack; the value is put into the array element at the given index. The `stelem.i2` instruction replaces the value of the element `index` in the one-dimensional array `array` with the `int16` value pushed onto the stack. @@ -13602,7 +13596,7 @@ callvirt m The following method overload can use the `stelem.i2` opcode: -- +- ]]> @@ -13659,13 +13653,13 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An object reference to an array, `array`, is pushed onto the stack. +1. An object reference to an array, `array`, is pushed onto the stack. -2. A valid index to an element in `array` is pushed onto the stack. +2. A valid index to an element in `array` is pushed onto the stack. -3. A value is pushed onto the stack. +3. A value is pushed onto the stack. -4. The value, the index, and the array reference are popped from the stack; the value is put into the array element at the given index. +4. The value, the index, and the array reference are popped from the stack; the value is put into the array element at the given index. The `stelem.i4` instruction replaces the value of the element `index` in the one-dimensional array `array` with the `int32` value pushed onto the stack. @@ -13679,7 +13673,7 @@ callvirt m The following method overload can use the `stelem.i4` opcode: -- +- ]]> @@ -13736,13 +13730,13 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An object reference to an array, `array`, is pushed onto the stack. +1. An object reference to an array, `array`, is pushed onto the stack. -2. A valid index to an element in `array` is pushed onto the stack. +2. A valid index to an element in `array` is pushed onto the stack. -3. A value is pushed onto the stack. +3. A value is pushed onto the stack. -4. The value, the index, and the array reference are popped from the stack; the value is put into the array element at the given index. +4. The value, the index, and the array reference are popped from the stack; the value is put into the array element at the given index. The `stelem.i8` instruction replaces the value of the element `index` in the one-dimensional array `array` with the `int64` value pushed onto the stack. @@ -13756,7 +13750,7 @@ callvirt m The following method overload can use the `stelem.i8` opcode: -- +- ]]> @@ -13813,13 +13807,13 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An object reference to an array, `array`, is pushed onto the stack. +1. An object reference to an array, `array`, is pushed onto the stack. -2. A valid index to an element in `array` is pushed onto the stack. +2. A valid index to an element in `array` is pushed onto the stack. -3. A value is pushed onto the stack. +3. A value is pushed onto the stack. -4. The value, the index, and the array reference are popped from the stack; the value is put into the array element at the given index. +4. The value, the index, and the array reference are popped from the stack; the value is put into the array element at the given index. The `stelem.r4` instruction replaces the value of the element `index` in the one-dimensional array `array` with the `float32` value pushed onto the stack. @@ -13833,7 +13827,7 @@ callvirt m The following method overload can use the `stelem.r4` opcode: -- +- ]]> @@ -13890,13 +13884,13 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An object reference to an array, `array`, is pushed onto the stack. +1. An object reference to an array, `array`, is pushed onto the stack. -2. A valid index to an element in `array` is pushed onto the stack. +2. A valid index to an element in `array` is pushed onto the stack. -3. A value is pushed onto the stack. +3. A value is pushed onto the stack. -4. The value, the index, and the array reference are popped from the stack; the value is put into the array element at the given index. +4. The value, the index, and the array reference are popped from the stack; the value is put into the array element at the given index. The `stelem.r8` instruction replaces the value of the element `index` in the one-dimensional array `array` with the `float64` value pushed onto the stack. @@ -13910,7 +13904,7 @@ callvirt m The following method overload can use the `stelem.r8` opcode: -- +- ]]> @@ -13967,13 +13961,13 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An object reference to an array, `array`, is pushed onto the stack. +1. An object reference to an array, `array`, is pushed onto the stack. -2. A valid index to an element in `array` is pushed onto the stack. +2. A valid index to an element in `array` is pushed onto the stack. -3. A value is pushed onto the stack. +3. A value is pushed onto the stack. -4. The value, the index, and the array reference are popped from the stack; the value is put into the array element at the given index. +4. The value, the index, and the array reference are popped from the stack; the value is put into the array element at the given index. The `stelem.ref` instruction replaces the value of the element at the supplied index in the one-dimensional array `array` with the `ref` (type `O`) value pushed onto the stack. @@ -13989,7 +13983,7 @@ callvirt m The following method overload can use the `stelem.ref` opcode: -- +- ]]> @@ -14046,11 +14040,11 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An object reference or pointer is pushed onto the stack. +1. An object reference or pointer is pushed onto the stack. -2. A value is pushed onto the stack. +2. A value is pushed onto the stack. -3. The value and the object reference/pointer are popped from the stack; the value of `field` in the object is replaced with the supplied value. +3. The value and the object reference/pointer are popped from the stack; the value of `field` in the object is replaced with the supplied value. The `stfld` instruction replaces the value of a field of an object (type `O`) or via a pointer (type `native int`, `&`, or `*`) with a given value. `Field` is a metadata token that refers to a field member reference. The `stfld` instruction can have a prefix of either or both of and . @@ -14060,7 +14054,7 @@ callvirt m The following method overload can use the `stfld` opcode: -- +- ]]> @@ -14117,11 +14111,11 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. -2. A value is pushed onto the stack. +2. A value is pushed onto the stack. -3. The value and the address are popped from the stack; the value is stored at the address. +3. The value and the address are popped from the stack; the value is stored at the address. The `stind.i` instruction stores a `native int` value at the supplied address (type `native int`, `*`, or `&`). @@ -14131,7 +14125,7 @@ callvirt m The following method overload can use the `stind.i` opcode: -- +- ]]> @@ -14188,11 +14182,11 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. -2. A value is pushed onto the stack. +2. A value is pushed onto the stack. -3. The value and the address are popped from the stack; the value is stored at the address. +3. The value and the address are popped from the stack; the value is stored at the address. The `stind.i1` instruction stores an `int8` value at the supplied address (type `native int`, `*`, or `&`). @@ -14202,7 +14196,7 @@ callvirt m The following method overload can use the `stind.i1` opcode: -- +- ]]> @@ -14259,11 +14253,11 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. -2. A value is pushed onto the stack. +2. A value is pushed onto the stack. -3. The value and the address are popped from the stack; the value is stored at the address. +3. The value and the address are popped from the stack; the value is stored at the address. The `stind.i2` instruction stores an `int16` value at the supplied address (type `native int`, `*`, or `&`). @@ -14273,7 +14267,7 @@ callvirt m The following method overload can use the `stind.i2` opcode: -- +- ]]> @@ -14330,11 +14324,11 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. -2. A value is pushed onto the stack. +2. A value is pushed onto the stack. -3. The value and the address are popped from the stack; the value is stored at the address. +3. The value and the address are popped from the stack; the value is stored at the address. The `stind.i4` instruction stores an `int32` value at the supplied address (type `native int`, `*`, or `&`). @@ -14344,7 +14338,7 @@ callvirt m The following method overload can use the `stind.i4` opcode: -- +- ]]> @@ -14401,11 +14395,11 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. -2. A value is pushed onto the stack. +2. A value is pushed onto the stack. -3. The value and the address are popped from the stack; the value is stored at the address. +3. The value and the address are popped from the stack; the value is stored at the address. The `stind.i8` instruction stores an `int64` value at the supplied address (type `native int`, `*`, or `&`). @@ -14415,7 +14409,7 @@ callvirt m The following method overload can use the `stind.i8` opcode: -- +- ]]> @@ -14472,11 +14466,11 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. -2. A value is pushed onto the stack. +2. A value is pushed onto the stack. -3. The value and the address are popped from the stack; the value is stored at the address. +3. The value and the address are popped from the stack; the value is stored at the address. The `stind.r4` instruction stores a `float32` value at the supplied address (type `native int`, `*`, or `&`). @@ -14486,7 +14480,7 @@ callvirt m The following method overload can use the `stind.r4` opcode: -- +- ]]> @@ -14543,11 +14537,11 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. -2. A value is pushed onto the stack. +2. A value is pushed onto the stack. -3. The value and the address are popped from the stack; the value is stored at the address. +3. The value and the address are popped from the stack; the value is stored at the address. The `stind.r8` instruction stores a `float64` value at the supplied address (type `native int`, `*`, or `&`). @@ -14557,7 +14551,7 @@ callvirt m The following method overload can use the `stind.r8` opcode: -- +- ]]> @@ -14614,11 +14608,11 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. -2. A value is pushed onto the stack. +2. A value is pushed onto the stack. -3. The value and the address are popped from the stack; the value is stored at the address. +3. The value and the address are popped from the stack; the value is stored at the address. The `stind.ref` instruction stores an object reference value at the supplied address (type `native int`, `*`, or `&`). @@ -14628,7 +14622,7 @@ callvirt m The following method overload can use the `stind.ref` opcode: -- +- ]]> @@ -14685,7 +14679,7 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. A value is popped off of the stack and placed in local variable `index`. +1. A value is popped off of the stack and placed in local variable `index`. The `stloc` instruction pops the top value off the evaluation stack and moves it into local variable number `index`, where local variables are numbered 0 onwards. The type of the value must match the type of the local variable as specified in the current method's local signature. @@ -14695,9 +14689,8 @@ callvirt m The following method overloads can use the `stloc` opcode: -- - -- +- +- ]]> @@ -14754,7 +14747,7 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. A value is popped off of the stack and placed in the local variable indexed by 0. +1. A value is popped off of the stack and placed in the local variable indexed by 0. The `stloc.0` instruction pops the top value off the evaluation stack and moves it into the local variable indexed by 0. The type of the value must match the type of the local variable as specified in the current method's local signature. @@ -14764,7 +14757,7 @@ callvirt m The following method overload can use the `stloc.0` opcode: -- +- ]]> @@ -14815,13 +14808,13 @@ callvirt m ## Remarks The following table lists the instruction's hexadecimal and Microsoft Intermediate Language (MSIL) assembly format, along with a brief reference summary: -|Format|Assembly Format|Description| -|------------|---------------------|-----------------| -|0B|stloc.1|Pops a value from the stack into local variable 1.| +| Format | Assembly Format | Description | +|--------|-----------------|----------------------------------------------------| +| 0B | stloc.1 | Pops a value from the stack into local variable 1. | The stack transitional behavior, in sequential order, is: -1. A value is popped off of the stack and placed in the local variable indexed by 1. +1. A value is popped off of the stack and placed in the local variable indexed by 1. The `stloc.1` instruction pops the top value off the evaluation stack and moves it into the local variable indexed by 1. The type of the value must match the type of the local variable as specified in the current method's local signature. @@ -14831,7 +14824,7 @@ callvirt m The following method overload can use the `stloc.1` opcode: -- +- ]]> @@ -14882,13 +14875,13 @@ callvirt m ## Remarks The following table lists the instruction's hexadecimal and Microsoft Intermediate Language (MSIL) assembly format, along with a brief reference summary: -|Format|Assembly Format|Description| -|------------|---------------------|-----------------| -|0C|stloc.2|Pops a value from the stack into local variable 2| +| Format | Assembly Format | Description | +|--------|-----------------|---------------------------------------------------| +| 0C | stloc.2 | Pops a value from the stack into local variable 2 | The stack transitional behavior, in sequential order, is: -1. A value is popped off of the stack and placed in the local variable indexed by 2. +1. A value is popped off of the stack and placed in the local variable indexed by 2. The `stloc.2` instruction pops the top value off the evaluation stack and moves it into the local variable indexed by 2. The type of the value must match the type of the local variable as specified in the current method's local signature. @@ -14898,7 +14891,7 @@ callvirt m The following method overload can use the `stloc.2` opcode: -- +- ]]> @@ -14949,13 +14942,11 @@ callvirt m ## Remarks The following table lists the instruction's hexadecimal and Microsoft Intermediate Language (MSIL) assembly format, along with a brief reference summary: -|Format|Assembly Format|Description| -|------------|---------------------|-----------------| -|0D|stloc.3|Pops a value from the stack into local variable 3| - - The stack transitional behavior, in sequential order, is: +| Format | Assembly Format | Description | +|--------|-----------------|---------------------------------------------------| +| 0D | stloc.3 | Pops a value from the stack into local variable 3 | -1. A value is popped off of the stack and placed in the local variable indexed by 3. + The stack transitional behavior, in sequential order, is that a value is popped off of the stack and placed in the local variable indexed by 3. The `stloc.3` instruction pops the top value off the evaluation stack and moves it into the local variable indexed by 3. The type of the value must match the type of the local variable as specified in the current method's local signature. @@ -14965,7 +14956,7 @@ callvirt m The following method overload can use the `stloc.3` opcode: -- +- ]]> @@ -15020,9 +15011,7 @@ callvirt m |------------|---------------------|-----------------| |13 < `unsigned int8` >|stloc.s `index`|Pops a value from the stack and stores it in local variable `index`, short form.| - The stack transitional behavior, in sequential order, is: - -1. A value is popped off of the stack and placed in local variable `index`. + The stack transitional behavior, is that a value is popped off of the stack and placed in local variable `index`. The `stloc.s` instruction pops the top value off the evaluation stack and moves it into local variable number `index`, where local variables are numbered 0 onwards. The type of the value must match the type of the local variable as specified in the current method's local signature. @@ -15032,9 +15021,8 @@ callvirt m The following method overloads can use the `stloc.s` opcode: -- - -- +- +- ]]> @@ -15085,17 +15073,15 @@ callvirt m ## Remarks The following table lists the instruction's hexadecimal and Microsoft Intermediate Language (MSIL) assembly format, along with a brief reference summary: -|Format|Assembly Format|Description| -|------------|---------------------|-----------------| -|81 < `T` >|stobj `class`|Stores a value of type `class` from the stack into memory.| +| Format | Assembly Format | Description | +|------------|-----------------|------------------------------------------------------------| +| 81 < `T` > | stobj `class` | Stores a value of type `class` from the stack into memory. | The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. - -2. A value type object of type `class` is pushed onto the stack. - -3. The object and the address are popped from the stack; the value type object is stored at the address. +1. An address is pushed onto the stack. +2. A value type object of type `class` is pushed onto the stack. +3. The object and the address are popped from the stack; the value type object is stored at the address. The `stobj` instruction copies the value type object into the address specified by the address (a pointer of type `native int`, `*`, or `&`). The number of bytes copied depends on the size of the class represented by `class`, a metadata token representing a value type. @@ -15105,7 +15091,7 @@ callvirt m The following method overload can use the `stobj` opcode: -- +- ]]> @@ -15156,15 +15142,14 @@ callvirt m ## Remarks The following table lists the instruction's hexadecimal and Microsoft Intermediate Language (MSIL) assembly format, along with a brief reference summary: -|Format|Assembly Format|Description| -|------------|---------------------|-----------------| -|80 < `T` >|stsfld `field`|Replaces the value in `field` with a supplied value.| +| Format | Assembly Format | Description | +|------------|-----------------|------------------------------------------------------| +| 80 < `T` > | stsfld `field` | Replaces the value in `field` with a supplied value. | The stack transitional behavior, in sequential order, is: -1. A value is pushed onto the stack. - -2. A value is popped from the stack and stored in `field`. +1. A value is pushed onto the stack. +2. A value is popped from the stack and stored in `field`. The `stsfld` instruction replaces the value of a static field with a value from the stack. `field` is a metadata token that must refer to a static field member. @@ -15174,7 +15159,7 @@ callvirt m The following method overload can use the `stsfld` opcode: -- +- ]]> @@ -15225,19 +15210,16 @@ callvirt m ## Remarks The following table lists the instruction's hexadecimal and Microsoft Intermediate Language (MSIL) assembly format, along with a brief reference summary: -|Format|Assembly Format|Description| -|------------|---------------------|-----------------| -|59|sub|Subtracts one value from another, returning a new numeric value.| +| Format | Assembly Format | Description | +|--------|-----------------|------------------------------------------------------------------| +| 59 | sub | Subtracts one value from another, returning a new numeric value. | The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. - -2. `value2` is pushed onto the stack. - -3. `value2` and `value1` are popped from the stack; `value2` is subtracted from `value1`. - -4. The result is pushed onto the stack. +1. `value1` is pushed onto the stack. +2. `value2` is pushed onto the stack. +3. `value2` and `value1` are popped from the stack; `value2` is subtracted from `value1`. +4. The result is pushed onto the stack. Overflow is not detected for integer operations (for proper overflow handling, see ). @@ -15247,7 +15229,7 @@ callvirt m The following method overload can use the `sub` opcode: -- +- ]]> @@ -15298,27 +15280,22 @@ callvirt m ## Remarks The following table lists the instruction's hexadecimal and Microsoft Intermediate Language (MSIL) assembly format, along with a brief reference summary: -|Format|Assembly Format|Description| -|------------|---------------------|-----------------| -|DA|sub.ovf|Subtracts one integer value from another with an overflow check.| +| Format | Assembly Format | Description | +|--------|-----------------|------------------------------------------------------------------| +| DA | sub.ovf | Subtracts one integer value from another with an overflow check. | The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. - -2. `value2` is pushed onto the stack. - -3. `value2` and `value1` are popped from the stack; `value2` is subtracted from `value1` with a check for overflow. - -4. The result is pushed onto the stack. +1. `value1` is pushed onto the stack. +2. `value2` is pushed onto the stack. +3. `value2` and `value1` are popped from the stack; `value2` is subtracted from `value1` with a check for overflow. +4. The result is pushed onto the stack. is thrown if the result can not be represented in the result type. This operation is performed on signed integers; for floating-point values, use . - The following method overload can use the `sub.ovf` opcode: - -- +The method uses the `sub.ovf` opcode. ]]> @@ -15369,27 +15346,22 @@ callvirt m ## Remarks The following table lists the instruction's hexadecimal and Microsoft Intermediate Language (MSIL) assembly format, along with a brief reference summary: -|Format|Assembly Format|Description| -|------------|---------------------|-----------------| -|DB|sub.ovf.un|Subtracts one unsigned integer value from another with an overflow check.| +| Format | Assembly Format | Description | +|--------|-----------------|---------------------------------------------------------------------------| +| DB | sub.ovf.un | Subtracts one unsigned integer value from another with an overflow check. | The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. - -2. `value2` is pushed onto the stack. - -3. `value2` and `value1` are popped from the stack; `value2` is subtracted from `value1` with a check for overflow. - -4. The result is pushed onto the stack. +1. `value1` is pushed onto the stack. +2. `value2` is pushed onto the stack. +3. `value2` and `value1` are popped from the stack; `value2` is subtracted from `value1` with a check for overflow. +4. The result is pushed onto the stack. is thrown if the result can not be represented in the result type. This operation is performed on signed integers; for floating-point values, use . - The following method overload can use the `sub.ovf.un` opcode: - -- +The method uses the `sub.ovf.un` opcode. ]]> @@ -15446,9 +15418,8 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. A value is pushed onto the stack. - -2. The value is popped off the stack and execution is transferred to the instruction at the offset indexed by the value, where the value is less than `N`. +1. A value is pushed onto the stack. +2. The value is popped off the stack and execution is transferred to the instruction at the offset indexed by the value, where the value is less than `N`. The `switch` instruction implements a jump table. The format of the instruction is an `unsigned int32` representing the number of targets `N`, followed by `N` int32 values specifying jump targets. These targets are represented as offsets (positive or negative) from the beginning of the instruction following this `switch` instruction. @@ -15458,11 +15429,7 @@ callvirt m Control transfers into and out of `try`, `catch`, `filter`, and `finally` blocks cannot be performed by this instruction. (Such transfers are severely restricted and must use the leave instruction instead). - The following method overload can use the `switch` opcode. The `Label[]` argument is an array of Labels representing 32-bit offsets. - -- - - + The method uses the `switch` opcode. The `Label[]` argument is an array of Labels representing 32-bit offsets. ## Examples The following code sample illustrates the use of the `Switch` opcode to generate a jump table using an array of . @@ -15519,9 +15486,9 @@ callvirt m ## Remarks The following table lists the instruction's hexadecimal and Microsoft Intermediate Language (MSIL) assembly format, along with a brief reference summary: -|Format|Assembly Format|Description| -|------------|---------------------|-----------------| -|FE 14|tail.|Subsequent call terminates current methods| +| Format | Assembly Format | Description | +|--------|-----------------|--------------------------------------------| +| FE 14 | tail. | Subsequent call terminates current methods | There is no stack transition behavior defined for this instruction. @@ -15529,11 +15496,9 @@ callvirt m The stack must be empty except for the arguments being transferred by the following call. The instruction following the call instruction must be a ret. Thus the only valid code sequence is `tail. call` (or `calli` or `callvirt`). Correct Microsoft Intermediate Language (MSIL) instructions must not branch to the `call` instruction, but they may branch to the subsequent . - The current frame cannot be discarded when control is transferred from untrusted code to trusted code, since this would jeopardize code identity security. The .NET Framework security checks can therefore cause the `tail` to be ignored, leaving a standard instruction. Similarly, in order to allow the exit of a synchronized region to occur after the call returns, the `tail` prefix is ignored when used to exit a method that is marked synchronized. + The current frame cannot be discarded when control is transferred from untrusted code to trusted code, since this would jeopardize code identity security. The .NET security checks can therefore cause the `tail` to be ignored, leaving a standard instruction. Similarly, in order to allow the exit of a synchronized region to occur after the call returns, the `tail` prefix is ignored when used to exit a method that is marked synchronized. - The following method overload can use the `tail` opcode: - -- + The method uses the `tail` opcode. ]]> @@ -15660,9 +15625,9 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An object reference (to an exception) is pushed onto the stack. +1. An object reference (to an exception) is pushed onto the stack. -2. The object reference is popped from the stack and the exception thrown. +2. The object reference is popped from the stack and the exception thrown. The `throw` instruction throws the exception object (type `O`) currently on the stack. @@ -15670,7 +15635,7 @@ callvirt m The following method overload can use the `throw` opcode: -- +- ]]> @@ -15727,7 +15692,7 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. `Unaligned` specifies that the address (an unmanaged pointer, `native int`) on the stack might not be aligned to the natural size of the immediately following `ldind`, `stind`, `ldfld`, `stfld`, `ldobj`, `stobj`, `initblk`, or `cpblk` instruction. That is, for a instruction the alignment of the address may not be to a 4-byte boundary. For `initblk` and `cpblk` the default alignment is architecture dependent (4-byte on 32-bit CPUs, 8-byte on 64-bit CPUs). Code generators that do not restrict their output to a 32-bit word size must use `unaligned` if the alignment is not known at compile time to be 8-byte. @@ -15739,9 +15704,9 @@ callvirt m The following method overloads can use the `unaligned` opcode: -- +- -- +- ]]> @@ -15798,11 +15763,11 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An object reference is pushed onto the stack. +1. An object reference is pushed onto the stack. -2. The object reference is popped from the stack and unboxed to a value type pointer. +2. The object reference is popped from the stack and unboxed to a value type pointer. -3. The value type pointer is pushed onto the stack. +3. The value type pointer is pushed onto the stack. A value type has two separate representations within the Common Language Infrastructure (CLI): @@ -15822,7 +15787,7 @@ callvirt m The following method overload can use the `unbox` opcode: -- +- ]]> @@ -15878,11 +15843,11 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An object reference `obj` is pushed onto the stack. +1. An object reference `obj` is pushed onto the stack. -2. The object reference is popped from the stack and unboxed to the type specified in the instruction. +2. The object reference is popped from the stack and unboxed to the type specified in the instruction. -3. The resulting object reference or value type is pushed onto the stack. +3. The resulting object reference or value type is pushed onto the stack. When applied to the boxed form of a value type, the `unbox.any` instruction extracts the value contained within `obj` (of type `O`), and is therefore equivalent to `unbox` followed by `ldobj`. @@ -15896,7 +15861,7 @@ callvirt m The following method overload can use the `unbox.any` opcode: -- +- ]]> @@ -15953,7 +15918,7 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. An address is pushed onto the stack. +1. An address is pushed onto the stack. `volatile`. specifies that the address is a volatile address (that is, it can be referenced externally to the current thread of execution) and the results of reading that location cannot be cached or that multiple stores to that location cannot be suppressed. Marking an access as `volatile` affects only that single access; other accesses to the same location must be marked separately. Access to volatile locations need not be performed atomically. @@ -15961,7 +15926,7 @@ callvirt m The following method overload can use the `volatile` opcode: -- +- ]]> @@ -16018,13 +15983,13 @@ callvirt m The stack transitional behavior, in sequential order, is: -1. `value1` is pushed onto the stack. +1. `value1` is pushed onto the stack. -2. `value2` is pushed onto the stack. +2. `value2` is pushed onto the stack. -3. `value2` and `value1` are popped from the stack and their bitwise XOR computed. +3. `value2` and `value1` are popped from the stack and their bitwise XOR computed. -4. The bitwise XOR of `value2` and `value1` is pushed onto the stack. +4. The bitwise XOR of `value2` and `value1` is pushed onto the stack. The `xor` instruction computes the bitwise XOR of the top two values on the stack and leaves the result on the stack. @@ -16032,7 +15997,7 @@ callvirt m The following method overload can use the `xor` opcode: -- +- ]]> diff --git a/xml/System.Reflection.Emit/ParameterBuilder.xml b/xml/System.Reflection.Emit/ParameterBuilder.xml index bb5cd36d91a..a42b6fdc75f 100644 --- a/xml/System.Reflection.Emit/ParameterBuilder.xml +++ b/xml/System.Reflection.Emit/ParameterBuilder.xml @@ -419,7 +419,7 @@ . This is not CLS-compliant, but it can be useful in interop scenarios. + `defaultValue` is restricted to the following types: `Boolean`, `SByte`, `Int16`, `Int32`, `Int64`, `Byte`, `UInt16`, `UInt32`, `UInt64`, `Single`, `Double`, `DateTime`, `Char`, `String`, and `Enum`. If the parameter type is a reference type, CLS compliance requires `defaultValue` to be `null`. However, `defaultValue` can be non-null for a reference type as long as the value can be assigned to that reference type. For example, an `Int32` value can be assigned to a parameter of type . This is not CLS-compliant, but it can be useful in interop scenarios. ]]> diff --git a/xml/System.Reflection.Emit/PropertyBuilder.xml b/xml/System.Reflection.Emit/PropertyBuilder.xml index 10f1de05cc8..c33549d4f18 100644 --- a/xml/System.Reflection.Emit/PropertyBuilder.xml +++ b/xml/System.Reflection.Emit/PropertyBuilder.xml @@ -1141,7 +1141,7 @@ . This is not CLS-compliant, but it can be useful in interop scenarios. + `defaultValue` is restricted to the following types: `Boolean`, `SByte`, `Int16`, `Int32`, `Int64`, `Byte`, `UInt16`, `UInt32`, `UInt64`, `Single`, `Double`, `DateTime`, `Char`, `String`, and `Enum`. If the property type is a reference type, CLS compliance requires `defaultValue` to be `null`. However, `defaultValue` can be non-null for reference types as long as the value can be assigned to that reference type. For example, an `Int32` value can be assigned to a property of type . This is not CLS-compliant, but it can be useful in interop scenarios. ]]> diff --git a/xml/System.Reflection.Emit/SignatureHelper.xml b/xml/System.Reflection.Emit/SignatureHelper.xml index e23bff6edaf..5ddf41cf392 100644 --- a/xml/System.Reflection.Emit/SignatureHelper.xml +++ b/xml/System.Reflection.Emit/SignatureHelper.xml @@ -1234,9 +1234,6 @@ For more information, see [ECMA 335 Common Language Infrastructure (CLI)](https: If a property has no custom modifiers, use the method overload. -> [!NOTE] -> This method overload is introduced in the .NET Framework 3.5 or later. - ]]> diff --git a/xml/System.Reflection.Emit/TypeBuilder.xml b/xml/System.Reflection.Emit/TypeBuilder.xml index d403d7e77ea..2facb93c378 100644 --- a/xml/System.Reflection.Emit/TypeBuilder.xml +++ b/xml/System.Reflection.Emit/TypeBuilder.xml @@ -3846,8 +3846,6 @@ See for a description of the format of the > [!NOTE] > For more information on custom modifiers, see [ECMA C# and Common Language Infrastructure Standards](/dotnet/standard/components#applicable-standards) and [Standard ECMA-335 - Common Language Infrastructure (CLI)](https://www.ecma-international.org/publications-and-standards/standards/ecma-335/). - This method overload is introduced in the .NET Framework 3.5 or later. - ]]> The length of is zero. @@ -7148,18 +7146,11 @@ See for a description of the format of the > [!NOTE] > Default inheritance is limited to the runtime's evaluation of transparency. No attributes are applied to the dynamic assembly. If you want to add security attributes, you must apply them yourself. - For more information about reflection emit and transparency, see [Security Issues in Reflection Emit](/dotnet/framework/reflection-and-codedom/security-issues-in-reflection-emit). For information about transparency, see [Security Changes](/dotnet/framework/security/security-changes). + For more information about reflection emit and transparency, see [Security Issues in Reflection Emit](/dotnet/framework/reflection-and-codedom/security-issues-in-reflection-emit). ]]> The current dynamic type has not been created by calling the method. - - - Security Issues in Reflection Emit - Security Considerations for Reflection - Security Changes in the .NET Framework Version 4.0 - Security-Transparent Code, Level 1 - Security-Transparent Code, Level 2 @@ -7219,18 +7210,11 @@ See for a description of the format of the > [!NOTE] > Default inheritance is limited to the runtime's evaluation of transparency. No attributes are applied to the dynamic assembly. If you want to add security attributes, you must apply them yourself. - For more information about reflection emit and transparency, see [Security Issues in Reflection Emit](/dotnet/framework/reflection-and-codedom/security-issues-in-reflection-emit). For information about transparency, see [Security Changes](/dotnet/framework/security/security-changes). + For more information about reflection emit and transparency, see [Security Issues in Reflection Emit](/dotnet/framework/reflection-and-codedom/security-issues-in-reflection-emit). ]]> The current dynamic type has not been created by calling the method. - - - Security Issues in Reflection Emit - Security Considerations for Reflection - Security Changes in the .NET Framework Version 4.0 - Security-Transparent Code, Level 1 - Security-Transparent Code, Level 2 @@ -7290,18 +7274,11 @@ See for a description of the format of the > [!NOTE] > Default inheritance is limited to the runtime's evaluation of transparency. No attributes are applied to the dynamic assembly. If you want to add security attributes, you must apply them yourself. - For more information about reflection emit and transparency, see [Security Issues in Reflection Emit](/dotnet/framework/reflection-and-codedom/security-issues-in-reflection-emit). For information about transparency, see [Security Changes](/dotnet/framework/security/security-changes). + For more information about reflection emit and transparency, see [Security Issues in Reflection Emit](/dotnet/framework/reflection-and-codedom/security-issues-in-reflection-emit). ]]> The current dynamic type has not been created by calling the method. - - - Security Issues in Reflection Emit - Security Considerations for Reflection - Security Changes in the .NET Framework Version 4.0 - Security-Transparent Code, Level 1 - Security-Transparent Code, Level 2 @@ -8331,8 +8308,6 @@ For more information on how to format `binaryAttribute`, see [ECMA C# and Common ## Remarks If `parent` is `null`, is used as the base type. - In the .NET Framework versions 1.0 and 1.1, no exception is thrown if `parent` is an interface type, but a is thrown when the method is called. - The method does not check for most invalid parent types. For example, it does not reject a parent type that has no parameterless constructor when the current type has a parameterless constructor, it does not reject sealed types, and it does not reject the type. In all these cases, exceptions are thrown by the method. ]]> @@ -8347,7 +8322,7 @@ For more information on how to format `binaryAttribute`, see [ECMA C# and Common For the current dynamic type, the property is , but the property is . - is an interface. This exception condition is new in the .NET Framework version 2.0. + is an interface. diff --git a/xml/System.Reflection.Metadata.Ecma335/MetadataBuilder.xml b/xml/System.Reflection.Metadata.Ecma335/MetadataBuilder.xml index 9fb7be572f4..bc56d1b4e74 100644 --- a/xml/System.Reflection.Metadata.Ecma335/MetadataBuilder.xml +++ b/xml/System.Reflection.Metadata.Ecma335/MetadataBuilder.xml @@ -39,7 +39,7 @@ ## Remarks -The class enables you to programmatically generate assemblies. These assemblies can be saved to a file, unlike dynamic assemblies generated by class, which does not support saving assemblies to a file on .NET 5+ and .NET Core. +The class enables you to programmatically generate assemblies that can be saved to a file. The `MetadataBuilder` API operates low-level metadata constructs, such as tables or blobs. For a simpler way to generate assemblies dynamically using C#, see in Roslyn API. diff --git a/xml/System.Reflection/Assembly.xml b/xml/System.Reflection/Assembly.xml index ca46d10cecf..f102a23b35d 100644 --- a/xml/System.Reflection/Assembly.xml +++ b/xml/System.Reflection/Assembly.xml @@ -85,34 +85,25 @@ ## Remarks Use the class to load assemblies, to explore the metadata and constituent parts of assemblies, to discover the types contained in assemblies, and to create instances of those types. - To get an array of objects representing the assemblies currently loaded into an application domain (for example, the default application domain of a simple project), use the method. + To get an array of objects representing the assemblies that are currently loaded, use the method. - To load assemblies dynamically, the class provides the following static methods (`Shared` methods in Visual Basic). Assemblies are loaded into the application domain where the load operation occurs. + To load assemblies dynamically, the class provides the following static methods. - The recommended way to load assemblies is to use the method, which identifies the assembly to be loaded by its display name (for example, "System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"). The search for the assembly follows the rules described in [How the Runtime Locates Assemblies](/dotnet/framework/deployment/how-the-runtime-locates-assemblies). - - The and methods enable you to load an assembly for reflection, but not for execution. For example, an assembly that targets a 64-bit platform can be examined by code that is running on a 32-bit platform. - - The and methods are provided for rare scenarios in which an assembly must be identified by path. - To get an object for the currently executing assembly, use the method. +To get an object for the currently executing assembly, use the method. - Many members of the class provide information about an assembly. For example: +Many members of the class provide information about an assembly. For example: - The method returns an object that provides access to the parts of the assembly display name. - - The method lists the attributes applied to the assembly. - - The method provides access to the files in the assembly manifest. - - The method provides the names of the resources in the assembly manifest. The method lists all the types in the assembly. The method lists the types that are visible to callers outside the assembly. The method can be used to search for a particular type in the assembly. The method can be used to search for and create instances of types in the assembly. - For more information on assemblies, see the "Application Domains and Assemblies" section in the [Application Domains](/dotnet/framework/app-domains/application-domains) topic. - - - ## Examples The following code example shows how to obtain the currently executing assembly, create an instance of a type contained in that assembly, and invoke one of the type's methods with late binding. For this purpose, the code example defines a class named `Example`, with a method named `SampleMethod`. The constructor of the class accepts an integer, which is used to compute the return value of the method. @@ -126,7 +117,6 @@ This type is thread safe. - Application Domains @@ -255,7 +245,7 @@ In .NET 5 and later versions, for bundled assemblies, this property throws an ex ]]> - .NET Core and .NET 5+ only: In all cases. + In all cases. @@ -1055,10 +1045,6 @@ In .NET 5 and later versions, for bundled assemblies, this property throws an ex > [!NOTE] > Writing your own code to parse display names is not recommended. Instead, pass the display name to the constructor, which parses it and populates the appropriate fields of the new . - In the .NET Framework version 2.0, processor architecture is added to assembly identity, and can be specified as part of assembly name strings. However, it is not included in the string returned by the property, for compatibility reasons. See . - - - ## Examples The following example retrieves the display name of the currently executing assembly, and the display name of the assembly that contains the type (`int` in C#, `Integer` in Visual Basic). @@ -1491,8 +1477,6 @@ In .NET 5 and later versions, for bundled assemblies, this property throws an ex ## Remarks - **.NET Framework only:** In the default application domain, this method returns the process executable. In other application domains, this method returns the first executable that was executed by . - The method can return `null` when a managed assembly has been loaded from an unmanaged application. For example, if an unmanaged application creates an instance of a COM component written in C#, a call to the method from the C# component returns null, because the entry point for the process was unmanaged code rather than a managed assembly. ]]> @@ -3043,7 +3027,7 @@ In .NET 5 and later versions, for bundled assemblies, this method throws an exce ## Remarks This method only searches the current assembly instance. The `name` parameter includes the namespace but not the assembly. To search other assemblies for a type, use the method overload, which can optionally include an assembly display name as part of the type name. - In .NET Core/.NET 5+, if there are assembly-qualified generic type parameters in the type name string, those assembly references will be loaded by the of the method that called Assembly.GetType, or by the context if it's set. +If there are assembly-qualified generic type parameters in the type name string, those assembly references will be loaded by the of the method that called Assembly.GetType, or by the context if it's set. > [!NOTE] > If the type has been forwarded to another assembly, it is still returned by this method. For information on type forwarding, see [Type Forwarding in the Common Language Runtime](/dotnet/standard/assembly/type-forwarding). @@ -3147,7 +3131,7 @@ In .NET 5 and later versions, for bundled assemblies, this method throws an exce ## Remarks This method only searches the current assembly instance. The `name` parameter includes the namespace but not the assembly. To search other assemblies for a type, use the method overload, which can optionally include an assembly display name as part of the type name. - In .NET Core/.NET 5+, if there are assembly-qualified generic type parameters in the type name string, those assembly references will be loaded by the of the method that called Assembly.GetType, or by the context if it's set. +If there are assembly-qualified generic type parameters in the type name string, those assembly references will be loaded by the of the method that called Assembly.GetType, or by the context if it's set. > [!NOTE] > If the type has been forwarded to another assembly, it is still returned by this method. For information on type forwarding, see [Type Forwarding in the Common Language Runtime](/dotnet/standard/assembly/type-forwarding). @@ -3256,7 +3240,7 @@ In .NET 5 and later versions, for bundled assemblies, this method throws an exce ## Remarks This method only searches the current assembly instance. The `name` parameter includes the namespace but not the assembly. To search other assemblies for a type, use the method overload, which can optionally include an assembly display name as part of the type name. - In .NET Core/.NET 5+, if there are assembly-qualified generic type parameters in the type name string, those assembly references will be loaded by the of the method that called Assembly.GetType, or by the context if it's set. +If there are assembly-qualified generic type parameters in the type name string, those assembly references will be loaded by the of the method that called Assembly.GetType, or by the context if it's set. > [!NOTE] > If the type has been forwarded to another assembly, it is still returned by this method. For information on type forwarding, see [Type Forwarding in the Common Language Runtime](/dotnet/standard/assembly/type-forwarding). @@ -3408,19 +3392,8 @@ In .NET 5 and later versions, for bundled assemblies, this method throws an exce Gets a value indicating whether the assembly was loaded from the global assembly cache (.NET Framework only). - - .NET Framework only: if the assembly was loaded from the global assembly cache; otherwise, . - - .NET Core and .NET 5 and later: in all cases. - - - + in all cases. + This property is marked obsolete starting in .NET 5, and generates a compile-time warning. @@ -3514,9 +3487,8 @@ This property is marked obsolete starting in .NET 5, and generates a compile-tim is set to the version of the CLR used to build the assembly. However, it might have been set to another value at compile time. +By default, is set to the version of the CLR used to build the assembly. However, it might have been set to another value at compile time. ]]> @@ -3555,14 +3527,8 @@ This property is marked obsolete starting in .NET 5, and generates a compile-tim Gets a value that indicates whether this assembly is held in a collectible . if this assembly is held in a collectible ; otherwise, . - - - + To be added. + @@ -3684,7 +3650,7 @@ This property is marked obsolete starting in .NET 5, and generates a compile-tim ## Remarks Dynamic assemblies are represented by the derived class . - When a dynamic assembly is saved to disk, the saved assembly is not dynamic. If the saved assembly is loaded into another application domain or process, the property returns `false`. + When a dynamic assembly is saved to disk, the saved assembly is not dynamic. If the saved assembly is loaded into another process, the property returns `false`. ]]> @@ -3729,11 +3695,7 @@ This property is marked obsolete starting in .NET 5, and generates a compile-tim Gets a value that indicates whether the current assembly is loaded with full trust. - - .NET Framework only: if the current assembly is loaded with full trust; otherwise, . - - .NET Core and .NET 5+: in all cases. - + in all cases. To be added. @@ -3806,8 +3768,6 @@ This property is marked obsolete starting in .NET 5, and generates a compile-tim This method overload always creates a new object in its own isolated load context. - **.NET Framework only:** The trust level of an assembly that is loaded by using this method is the same as the trust level of the calling assembly. To load an assembly from a byte array with the trust level of the application domain, use the method overload. For more information about the use of evidence with overloads of the method that take byte arrays, see the method overload. - ]]> @@ -3871,16 +3831,7 @@ This property is marked obsolete starting in .NET 5, and generates a compile-tim ## Remarks - In .NET Core/.NET 5+, the target assembly will be loaded into the current or into the context if it's set. For more information on assembly loading, see [Managed assembly loading algorithm](/dotnet/core/dependency-loading/loading-managed#algorithm). - -> [!NOTE] -> **.NET Framework only:** For information about loading assemblies from remote locations, see [``](/dotnet/framework/configure-apps/file-schema/runtime/loadfromremotesources-element). - -> [!NOTE] -> **.NET Framework only:** Do not use an with only the property set. The property does not supply any elements of the assembly identity (such as name or version), so loading does not occur according to load-by-identity rules, as you would expect from the method. Instead, the assembly is loaded using load-from rules. For information about the disadvantages of using the load-from context, see the method overload or [Best Practices for Assembly Loading](/dotnet/framework/deployment/best-practices-for-assembly-loading). - -> [!NOTE] -> **.NET Framework only:** If both the property and the property are set, the first attempt to load the assembly uses the display name (including version, culture, and so on, as returned by the property). If the file is not found, is used to search for the assembly. If the assembly is found using , the display name is matched against the assembly. If the match fails, a is thrown. +The target assembly will be loaded into the current or into the context if it's set. For more information on assembly loading, see [Managed assembly loading algorithm](/dotnet/core/dependency-loading/loading-managed#algorithm). ## Examples The following example instantiates an object and uses it to load the `sysglobal.dll` assembly. The example then displays the full name of the assembly's public types. @@ -3894,12 +3845,7 @@ This property is marked obsolete starting in .NET 5, and generates a compile-tim is . is not found. - A file that was found could not be loaded. - --or- - -.NET Framework only: specifies a location that is disabled based on <loadFromRemoteSources>. - + A file that was found could not be loaded. is not a valid assembly for the currently loaded runtime. @@ -3958,19 +3904,12 @@ This property is marked obsolete starting in .NET 5, and generates a compile-tim ## Remarks - In .NET Core/.NET 5+, the target assembly will be loaded into the current or into the context if it's set. For more information on assembly loading, see [Managed assembly loading algorithm](/dotnet/core/dependency-loading/loading-managed#algorithm). - -To load the correct assembly, it's recommended to call the `Load` method by passing the long form of the assembly name. The long form of an assembly name consists of its simple name (such as "System" for the System.dll assembly) along with its version, culture, public key token, and optionally its processor architecture. It corresponds to the assembly's property. The following example illustrates the use of a long name to load the System.dll assembly for .NET Framework 4: +The target assembly will be loaded into the current or into the context if it's set. For more information on assembly loading, see [Managed assembly loading algorithm](/dotnet/core/dependency-loading/loading-managed#algorithm). - :::code language="csharp" source="~/snippets/csharp/System.Reflection/Assembly/Load/load11.cs" id="Snippet1"::: - :::code language="vb" source="~/snippets/visualbasic/System.Reflection/Assembly/Load/load11.vb" id="Snippet1"::: +To load the correct assembly, it's recommended to call the `Load` method by passing the long form of the assembly name. The long form of an assembly name consists of its simple name (such as "System" for the System.dll assembly) along with its version, culture, public key token, and optionally its processor architecture. It corresponds to the assembly's property. is thrown if `assemblyString` specifies the full assembly name, and the first assembly that matches the simple name has a different version, culture, or public key token. The loader does not continue probing for other assemblies that match the simple name. - In the .NET Framework version 2.0, processor architecture is added to assembly identity, and can be specified as part of assembly name strings. For example, "ProcessorArchitecture=msil". However, the recommended way to specify an assembly name is to create an object and pass it to an appropriate overload of the method. See . - - - ## Examples The following example loads an assembly given its fully qualified name, and lists all the types contained in the specified assembly. For information about how to obtain the fully qualified assembly name, see [Assembly Names](/dotnet/standard/assembly/names). @@ -4061,12 +4000,10 @@ To load the correct assembly, it's recommended to call the `Load` method by pass ## Remarks -In .NET Core/5+, the target assembly is loaded into the current . For more information on assembly loading, see [Managed assembly loading algorithm](/dotnet/core/dependency-loading/loading-managed#algorithm"). +The target assembly is loaded into the current . For more information on assembly loading, see [Managed assembly loading algorithm](/dotnet/core/dependency-loading/loading-managed#algorithm). This method overload always creates a new object in its own isolated load context. - **.NET Framework only:** The trust level of an assembly that is loaded by using this method is the same as the trust level of the calling assembly. To load an assembly from a byte array with the trust level of the application domain, use the method overload. For more information about the use of evidence with overloads of the method that take byte arrays, see the method overload. - ]]> @@ -4143,23 +4080,13 @@ In .NET Core/5+, the target assembly is loaded into the current overloads instead. - -The assembly is loaded into a new AssemblyLoadContext created for this purpose. For more information on assembly loading, see [Managed assembly loading algorithm](/dotnet/core/dependency-loading/loading-managed#algorithm"). - - Use the method to load and examine assemblies that have the same identity, but are located in different paths. does not load files into the load-from context, and does not resolve dependencies using the load path, as the method does. is useful in this limited scenario because cannot be used to load assemblies that have the same identities but different paths; it will load only the first such assembly. - - **.NET Framework only:** See [``](/dotnet/framework/configure-apps/file-schema/runtime/loadfromremotesources-element) for loading assemblies from remote locations. +This API is present in .NET for compatibility, but it's recommended to use overloads instead. ]]> The argument is not an absolute path. The parameter is . - A file that was found could not be loaded. - --or- - -.NET Framework only: specifies a location that is disabled based on <loadFromRemoteSources>. + A file that was found could not be loaded. The parameter is an empty string ("") or does not exist. is not a valid assembly for the currently loaded runtime. @@ -4174,15 +4101,7 @@ The assembly is loaded into a new AssemblyLoadContext created for this purpose. Loads an assembly. - - `](/dotnet/framework/configure-apps/file-schema/runtime/loadfromremotesources-element) for loading assemblies from remote locations. - - ]]> - + To be added. @@ -4242,50 +4161,7 @@ The assembly is loaded into a new AssemblyLoadContext created for this purpose. ## Remarks - This API is present in .NET Core for compatibility, but it is recommended to use overloads instead. - -The assembly is loaded into the default AssemblyLoadContext. For more information on assembly loading, see [Managed assembly loading algorithm](/dotnet/core/dependency-loading/loading-managed#algorithm"). - - The `assemblyFile` parameter must refer to a URI without escape characters. This method supplies escape characters for all invalid characters in the URI. - -> [!NOTE] -> .NET Framework only: File transfer protocol (FTP) is not supported. If the URI supplied for `assemblyFile` is an FTP address, the assembly is not loaded. No exception is thrown. - - `assemblyFile` may be absolute or relative to the current directory. - - **.NET Framework only:** Assemblies can be loaded into one of three contexts, or can be loaded without context: - -- The load context contains assemblies found by probing: in the GAC, in a host assembly store if the runtime is hosted, or in the and of the application domain. Most overloads of the method load assemblies into this context. - -- The load-from context contains assemblies for which the user provided a path not included in the directories searched by probing. It also allows dependencies on that path to be found and loaded because the path information is maintained by the context. , , and are examples of methods that load by path. - - See [``](/dotnet/framework/configure-apps/file-schema/runtime/loadfromremotesources-element) for loading assemblies from remote locations. - -- The reflection-only context contains assemblies loaded with the and methods; code in these contexts cannot be executed. - -- If the user generated or found the assembly, it is not in any context. This applies to assemblies loaded using overloads of the method that specify a byte array containing an assembly, and to transient dynamic assemblies created with reflection emit and not saved to disk. - - The method has the following disadvantages. Consider using instead. - -- If an assembly with the same identity is already loaded in the load-from context, returns the loaded assembly even if a different path was specified. - -- An assembly can be loaded in the load-from context even though an assembly with the same identity exists in the load context. Interoperability between the two assemblies will not work, leading to errors such as , , or other unexpected behavior. - -- Calling with a location that's in the probing path will load the assembly in the load context and not in the load-from context. - -- If an assembly file whose identity is goverened by a binding redirect policy is passed to , the policy will be applied and the assembly will be loaded from the probing path in the load context. - -- If an assembly is loaded in the load-from context, and later an assembly in the load context attempts to load the same assembly by display name, the load attempt fails. This can occur when an assembly is deserialized. - -- demands and , or , on the specified path. - -- If a native image exists for `assemblyFile`, it is not used. The assembly cannot be loaded as domain neutral. - -## Examples - The following example loads an assembly given its file name or path. - - :::code language="csharp" source="~/snippets/csharp/System.Reflection/Assembly/CodeBase/assembly.cs" id="Snippet11"::: - :::code language="vb" source="~/snippets/visualbasic/System.Reflection/Assembly/CodeBase/assembly.vb" id="Snippet11"::: +This API is present in .NET for compatibility, but it is recommended to use overloads instead. ]]> @@ -4293,11 +4169,7 @@ The assembly is loaded into the default AssemblyLoadContext. For more informatio is . is not found, or the module you are trying to load does not specify a filename extension. - A file that was found could not be loaded. - --or- - -.NET Framework only: specifies a location that is disabled based on <loadFromRemoteSources>. + A file that was found could not be loaded. is not a valid assembly for the currently loaded runtime; for example, a 32-bit assembly in a 64-bit process. @@ -4377,61 +4249,11 @@ The assembly is loaded into the default AssemblyLoadContext. For more informatio ## Remarks - This API is not supported in .NET Core/.NET 5+. This method throws when called. Use instead. - - The `assemblyFile` parameter must refer to a URI without escape characters. This method supplies escape characters for all invalid characters in the URI. - -> [!NOTE] -> File transfer protocol (FTP) is not supported. If the URI supplied for `assemblyFile` is an FTP address, the assembly is not loaded. No exception is thrown. - - `assemblyFile` can be absolute or relative to the current directory. - - Assemblies can be loaded into one of three contexts, or can be loaded without context: - -- The load context contains assemblies found by probing: in the global assembly cache, in a host assembly store if the runtime is hosted, or in the and of the application domain. Most overloads of the method load assemblies into this context. - -- The load-from context contains assemblies for which the user provided a path that is not included in probing. , , and are examples of methods that load by path. - - See [``](/dotnet/framework/configure-apps/file-schema/runtime/loadfromremotesources-element) for loading assemblies from remote locations. - -- The reflection-only context contains assemblies loaded with the and methods; code in these contexts cannot be executed. - -- If the user generated or found the assembly, it is not in any context. This applies to assemblies loaded using overloads of the method that specify a byte array containing an assembly, and to transient dynamic assemblies created with reflection emit and not saved to disk. - - The load-from context allows an assembly to be loaded from a path that is not included in probing, and yet allows dependencies on that path to be found and loaded because the path information is maintained by the context. - - The method has the following disadvantages. Consider using instead. - -- If an assembly with the same identity is already loaded, returns the loaded assembly even if a different path was specified. - -- If an assembly is loaded with , and later an assembly in the load context attempts to load the same assembly by display name, the load attempt fails. This can occur when an assembly is deserialized. - -- If an assembly is loaded with , and the probing path includes an assembly with the same identity but a different location, an , , or other unexpected behavior can occur. - -- demands and , or , on the specified path. - -- If a native image exists for `assemblyFile`, it is not used. The assembly cannot be loaded as domain-neutral. - - The assembly is loaded with the evidence that the loader supplies. +This API is not supported. This method throws when called. Use instead. ]]> - .NET Core and .NET 5+ only: In all cases. - - is . - - is not found, or the module you are trying to load does not specify a file name extension. - A file that was found could not be loaded. - --or- - - specifies a location that is disabled based on <loadFromRemoteSources>. - - is not a valid assembly for the currently loaded runtime; for example, a 32-bit assembly in a 64-bit process. - - A codebase that does not start with "file://" was specified without the required . - The parameter is an empty string (""). - The assembly name exceeds the system-defined maximum length. + In all cases. @@ -4684,22 +4506,7 @@ The assembly is loaded into the default AssemblyLoadContext. For more informatio The display name of the assembly. Loads an assembly from the application directory or from the global assembly cache using a partial name. The loaded assembly. If is not found, this method returns . - - [!IMPORTANT] -> The method is obsolete and has been retained for backward compatibility. The non-obsolete alternative is . - - Applications that load assemblies with this method will be affected by upgrades of those assemblies. Therefore, do not use this method; redesign the application to use the method overload or the method overload. - - In .NET Core/5+, the target assembly is loaded into the current or the if it's set. - - This method first calls . If the assembly is not found, this method returns the assembly from the global assembly cache that has the same simple name, and the highest version number. - - ]]> - + To be added. The parameter is . The assembly is not a valid assembly for the currently loaded runtime. @@ -4756,9 +4563,7 @@ The assembly is loaded into the default AssemblyLoadContext. For more informatio ## Remarks -In .NET 5 and later versions, for bundled assemblies, the value returned is an empty string. - -.NET Framework only: If the loaded file was [shadow-copied](/dotnet/framework/app-domains/shadow-copy-assemblies), the location is that of the file after being shadow-copied. To get the location before the file has been shadow-copied, use the property. +For bundled assemblies, the value returned is an empty string. ## Examples The following example displays the location of the loaded file that contains the manifest. @@ -5143,26 +4948,10 @@ In .NET 5 and later versions, for bundled assemblies, the value returned is an e A byte array that is a COFF-based image containing an emitted assembly. - Loads the assembly from a common object file format (COFF)-based image containing an emitted assembly. The assembly is loaded into the reflection-only context of the caller's application domain. + Loads the assembly from a common object file format (COFF)-based image containing an emitted assembly. The assembly is loaded into the reflection-only context of the application domain. The loaded assembly. - - method. - - The reflection-only context is no different from other contexts. Assemblies that are loaded into the context can be unloaded only by unloading the application domain. - - ]]> - - - is . - - is not a valid assembly for the currently loaded runtime. - - - cannot be loaded. - .NET Core and .NET 5+ only: In all cases. + To be added. + In all cases. @@ -5220,30 +5009,8 @@ In .NET 5 and later versions, for bundled assemblies, the value returned is an e The display name of the assembly, as returned by the property. Loads an assembly into the reflection-only context, given its display name. The loaded assembly. - - method. - - The reflection-only context is no different from other contexts. Assemblies that are loaded into the context can be unloaded only by unloading the application domain. - - ]]> - - - is . - - is an empty string (""). - - is not found. - - is found, but cannot be loaded. - - is not a valid assembly for the currently loaded runtime. - - .NET Core and .NET 5+ only: In all cases. + To be added. + In all cases. @@ -5301,36 +5068,8 @@ In .NET 5 and later versions, for bundled assemblies, the value returned is an e The path of the file that contains the manifest of the assembly. Loads an assembly into the reflection-only context, given its path. The loaded assembly. - - event and load the dependency in the event handler. - - You cannot execute code from an assembly that has been loaded into the reflection-only context. To execute the code, load the assembly with the method. - - The `assemblyFile` parameter must refer to a URI without escape characters. This method supplies escape characters for all invalid characters in the URI. - - The path specified for `assemblyFile` is relative to the current directory. - - The reflection-only context is no different from other contexts. Assemblies that are loaded into the context can be unloaded only by unloading the application domain. - - ]]> - - - is . - - is not found, or the module you are trying to load does not specify a file name extension. - - is found, but could not be loaded. - - is not a valid assembly for the currently loaded runtime. - - A codebase that does not start with "file://" was specified without the required . - The assembly name exceeds the system-defined maximum length. - - is an empty string (""). - .NET Core and .NET 5+ only: In all cases. + To be added. + In all cases. @@ -5373,16 +5112,7 @@ In .NET 5 and later versions, for bundled assemblies, the value returned is an e Gets a value that indicates which set of security rules the common language runtime (CLR) enforces for this assembly. The security rule set that the CLR enforces for this assembly. - - - - Security-Transparent Code - Security Changes in the .NET Framework 4 + To be added. @@ -5638,15 +5368,7 @@ In .NET 5 and later versions, for bundled assemblies, the value returned is an e [!CAUTION] -> If you use either of these solutions, you must be certain that it is safe to load `assemblyFile` with full trust. - - For a discussion of load contexts, including the load-from context, see the method overload. +Use this method to load a local assembly that the operating system has flagged as having been loaded from the Web (for example, a temporary file that was downloaded from the Internet or intranet). ]]> diff --git a/xml/System.Reflection/AssemblyName.xml b/xml/System.Reflection/AssemblyName.xml index 22b1b5fae2f..5850153c0e6 100644 --- a/xml/System.Reflection/AssemblyName.xml +++ b/xml/System.Reflection/AssemblyName.xml @@ -1098,9 +1098,7 @@ mylib, Version=1.2.1900.0, Culture=neutral, PublicKeyToken=a14f3033def15840 ## Remarks > [!IMPORTANT] -> Starting with the .NET Framework 4, the property of an object that is returned by the method is if there is no hash algorithm for the referenced assembly, or if the hash algorithm of the referenced assembly is not identified by the enumeration. In previous versions of the .NET Framework, the property returned in this situation. - - +> The property of an object that is returned by the method is if there is no hash algorithm for the referenced assembly, or if the hash algorithm of the referenced assembly is not identified by the enumeration. ## Examples The following example emits a dynamic assembly and saves it to the current directory. When the assembly is created, the property is used to set the hash algorithm for the assembly manifest. @@ -1161,21 +1159,8 @@ mylib, Version=1.2.1900.0, Culture=neutral, PublicKeyToken=a14f3033def15840 Gets or sets the public and private cryptographic key pair that is used to create a strong name signature for the assembly. The public and private cryptographic key pair to be used to create a strong name for the assembly. - - property. The getter for the property is only useful if the user set the property before using the object to create a dynamic assembly, and subsequently wants to retrieve the key pair. - -## Examples - The following example emits a dynamic assembly and saves it to the current directory. When the assembly is created, the property is used to set the assembly's public and private cryptographic keys. - - :::code language="csharp" source="~/snippets/csharp/System.Reflection/AssemblyName/Flags/assemblyname_keypair.cs" id="Snippet1"::: - :::code language="vb" source="~/snippets/visualbasic/System.Reflection/AssemblyName/Flags/assemblyname_keypair.vb" id="Snippet1"::: - - ]]> - - .NET 6+ only: In all cases. + To be added. + In all cases. @@ -1351,8 +1336,7 @@ mylib, Version=1.2.1900.0, Culture=neutral, PublicKeyToken=a14f3033def15840 for reference assemblies. +This property always returns for reference assemblies. ]]> diff --git a/xml/System.Reflection/AssemblyNameFlags.xml b/xml/System.Reflection/AssemblyNameFlags.xml index 72d70294c70..4c50be5b6b0 100644 --- a/xml/System.Reflection/AssemblyNameFlags.xml +++ b/xml/System.Reflection/AssemblyNameFlags.xml @@ -260,7 +260,7 @@ 256 - Specifies that the assembly can be retargeted at runtime to an assembly from a different publisher. This value supports the .NET Framework infrastructure and is not intended to be used directly from your code. + Specifies that the assembly can be retargeted at runtime to an assembly from a different publisher. This value supports the .NET infrastructure and is not intended to be used directly from your code. diff --git a/xml/System.Reflection/AssemblySignatureKeyAttribute.xml b/xml/System.Reflection/AssemblySignatureKeyAttribute.xml index bd3a1ed864e..0359265deaa 100644 --- a/xml/System.Reflection/AssemblySignatureKeyAttribute.xml +++ b/xml/System.Reflection/AssemblySignatureKeyAttribute.xml @@ -58,17 +58,17 @@ Provides migration from an older, simpler strong name key to a larger key with a stronger hashing algorithm. - attribute allows the assembly metadata to continue to have the old public key token and binary large object (BLOB) so that existing assembly references continue to work. It also ensures that the mapping comes from an owner of the identity key. - - The presence of the attribute does not necessarily mean that strong name validation takes place. In common full-trust scenarios, the attribute is never considered, because strong name signatures are never validated. However, when the strong name signature does have to be validated, both the strong name signature and the countersignature must be validated. The assembly's identity key does not have to be identical to the signature key (the key used to do the actual signing and validation). The identity key can be mapped to a different (more robust) signing key. This lets you set the identity of an assembly, and update the signing keys and algorithms to more secure versions. - - The countersignature addresses security concerns when a malicious assembly claims some other identity. For example, a malicious System.Core.dll assembly could contain the Microsoft public key in its metadata, and use the attribute to tell strong name validation to use the attacker's signature key if no countersignature is present. Thus, it could masquerade as a strong name-validated Microsoft assembly. - - For information about how to sign assemblies for use with this new attribute, see [Enhanced Strong Naming](/dotnet/standard/assembly/enhanced-strong-naming). - + attribute allows the assembly metadata to have the older public key token and binary large object (BLOB) so that existing assembly references continue to work. It also ensures that the mapping comes from an owner of the identity key. + + The presence of the attribute does not necessarily mean that strong name validation takes place. In common full-trust scenarios, the attribute is never considered, because strong name signatures are never validated. However, when the strong name signature does have to be validated, both the strong name signature and the countersignature must be validated. The assembly's identity key does not have to be identical to the signature key (the key used to do the actual signing and validation). The identity key can be mapped to a different (more robust) signing key. This lets you set the identity of an assembly, and update the signing keys and algorithms to more secure versions. + + The countersignature addresses security concerns when a malicious assembly claims some other identity. For example, a malicious System.Core.dll assembly could contain the Microsoft public key in its metadata, and use the attribute to tell strong name validation to use the attacker's signature key if no countersignature is present. Thus, it could masquerade as a strong name-validated Microsoft assembly. + + For information about how to sign assemblies for use with this new attribute, see [Enhanced Strong Naming](/dotnet/standard/assembly/enhanced-strong-naming). + ]]> @@ -114,15 +114,15 @@ The countersignature, which is the signature key portion of the strong-name key. Creates a new instance of the class by using the specified public key and countersignature. - @@ -166,11 +166,11 @@ sn -a IdentityPubKey.snk IdentityKey.snk SignaturePubKey.snk Gets the countersignature for the strong name for this assembly. The countersignature for this signature key. - diff --git a/xml/System.Reflection/ConstructorInfo.xml b/xml/System.Reflection/ConstructorInfo.xml index 3297382b499..b22dcfb2eb7 100644 --- a/xml/System.Reflection/ConstructorInfo.xml +++ b/xml/System.Reflection/ConstructorInfo.xml @@ -74,11 +74,6 @@ ## Remarks `ConstructorInfo` is used to discover the attributes of a constructor as well as to invoke a constructor. Objects are created by calling on a `ConstructorInfo` returned by either the or method of a object. -> [!NOTE] -> inherits from several members, such as , that can be used to examine generic methods. In the .NET Framework version 2.0 constructors cannot be generic, so these members return `false` or `null`. - - - ## Examples The following example uses `ConstructorInfo` with and to find the constructors that match the specified search criteria. @@ -367,12 +362,9 @@ Access restrictions are ignored for fully trusted code. That is, private constructors, methods, fields, and properties can be accessed and invoked using reflection whenever the code is fully trusted. > [!NOTE] -> To create an instance of a value type that has no instance constructors, use the method. - - This method is a convenience method for the following overloaded version, using default values. This method cannot be overridden. +> To create an instance of a value type that has no instance constructors, use the method. -> [!NOTE] -> This method can be used to access non-public members if the caller has been granted with the flag and if the grant set of the non-public members is restricted to the caller's grant set, or a subset thereof. (See [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection).) +This method is a convenience method for using default values. This method cannot be overridden. ]]> @@ -456,13 +448,8 @@ Before calling the constructor, `Invoke` ensures that the caller has access permission and that the parameters are of the correct number, order and type. - Access restrictions are ignored for fully trusted code. That is, private constructors, methods, fields, and properties can be accessed and invoked using reflection whenever the code is fully trusted. - -> [!NOTE] -> To create an instance of a value type that has no instance constructors, use the method. - > [!NOTE] -> This method can be used to access non-public members if the caller has been granted with the flag and if the grant set of the non-public members is restricted to the caller's grant set, or a subset thereof. (See [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection).) To use this functionality, your application should target .NET Framework 3.5 or later. +> To create an instance of a value type that has no instance constructors, use the method. ]]> diff --git a/xml/System.Reflection/FieldInfo.xml b/xml/System.Reflection/FieldInfo.xml index 3d0bc2884f2..e19dce1f4da 100644 --- a/xml/System.Reflection/FieldInfo.xml +++ b/xml/System.Reflection/FieldInfo.xml @@ -443,11 +443,6 @@ method to get objects for the fields of a type, gets a structure for each field, and then retrieves the objects from the handles using this overload of the method. @@ -514,16 +509,13 @@ ` (`MyType(Of Integer)` in Visual Basic), `declaringType` is the runtime type handle for `MyType`. Do not use the runtime type handle of the generic type definition, unless the runtime field handle represents a field on the generic type definition. +The recommended practice is that `declaringType` should always be the runtime type handle of the constructed type that `handle` belongs to. That is, if `handle` is a runtime field handle for a field that belongs to `MyType` (`MyType(Of Integer)` in Visual Basic), `declaringType` is the runtime type handle for `MyType`. Do not use the runtime type handle of the generic type definition, unless the runtime field handle represents a field on the generic type definition. Implementations are compatible in some cases. For example, a single implementation is shared by all types that are constructed from a particular generic type definition by using reference types for the generic type arguments. For example, `MyType`, `MyType`, and `MyType` all share the same implementation. In this situation, the object that is returned represents a field on the type that `declaringType` specifies, regardless of the original source of `handle`. This practice is not recommended, because it works only if the generic type arguments of the constructed type are reference types. If a generic argument is a value type, the runtime type handle of the constructed type is not compatible with runtime field handles from constructions that have a reference type in the same generic parameter position, or that have a different value type in that position. In that case, the only way to use the overload is to ensure that `declaringType` is the runtime type handle for the constructed type that `handle` belongs to. - - ## Examples The following example shows how to retrieve objects for fields on constructed generic classes. The example defines the generic type `Test` (`Test(Of T)` in Visual Basic) with a single field named `TestField`, of type `T`. The example gets the and for the case where `T` is , and demonstrates the following: @@ -871,9 +863,6 @@ > Access restrictions are ignored for fully trusted code. That is, private constructors, methods, fields, and properties can be accessed and invoked through reflection whenever the code is fully trusted. > [!NOTE] -> This method can be used to access non-public members if the caller has been granted with the flag and if the grant set of the non-public members is restricted to the caller's grant set, or a subset thereof. (See [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection).) -> -> To use this functionality, your application should target .NET Framework 3.5 or later. ## Examples The following example uses the method to retrieve the value of a static field. Note that the value of the `obj` argument is `null`. @@ -1684,10 +1673,7 @@ Myfieldb - B readonly field, IsInitOnly = True Using these properties is much simpler than examining the security annotations of an assembly and its types and members, checking the current trust level, and attempting to duplicate the runtime's rules. -> [!IMPORTANT] -> For partial-trust assemblies, the value of this property depends on the current trust level of the assembly. If the assembly is loaded into a partially trusted application domain (for example, into a sandboxed application domain), then the runtime ignores the security annotations of the assembly. The assembly and all its types are treated as transparent. The runtime pays attention to the security annotations of a partial-trust assembly only when that assembly is loaded into a fully trusted application domain (for example, into the default application domain of a desktop application). By contrast, a trusted assembly (that is, a strong-named assembly that is installed in the global assembly cache) is always loaded with full trust regardless of the trust level of the application domain, so its current trust level is always fully trusted. You can determine the current trust levels of assemblies and application domains by using the and properties. - - For more information about reflection and transparency, see [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection). For information about transparency, see [Security Changes](/dotnet/framework/security/security-changes). + For more information about reflection and transparency, see [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection). ]]> @@ -1742,18 +1728,15 @@ Myfieldb - B readonly field, IsInitOnly = True ## Remarks The , , and properties report the transparency level of the field at its current trust level, as determined by the common language runtime (CLR). The combinations of these properties are shown in the following table: -|Security level|IsSecurityCritical|IsSecuritySafeCritical|IsSecurityTransparent| -|--------------------|------------------------|----------------------------|---------------------------| -|Critical|`true`|`false`|`false`| -|Safe critical|`true`|`true`|`false`| -|Transparent|`false`|`false`|`true`| +| Security level | IsSecurityCritical | IsSecuritySafeCritical | IsSecurityTransparent | +|----------------|--------------------|------------------------|-----------------------| +| Critical | `true` | `false` | `false` | +| Safe critical | `true` | `true` | `false` | +| Transparent | `false` | `false` | `true` | Using these properties is much simpler than examining the security annotations of an assembly and its types and members, checking the current trust level, and attempting to duplicate the runtime's rules. -> [!IMPORTANT] -> For partial-trust assemblies, the value of this property depends on the current trust level of the assembly. If the assembly is loaded into a partially trusted application domain (for example, into a sandboxed application domain), then the runtime ignores the security annotations of the assembly. The assembly and all its types are treated as transparent. The runtime pays attention to the security annotations of a partial-trust assembly only when that assembly is loaded into a fully trusted application domain (for example, into the default application domain of a desktop application). By contrast, a trusted assembly (that is, a strong-named assembly that is installed in the global assembly cache) is always loaded with full trust regardless of the trust level of the application domain, so its current trust level is always fully trusted. You can determine the current trust levels of assemblies and application domains by using the and properties. - - For more information about reflection and transparency, see [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection). For information about transparency, see [Security Changes](/dotnet/framework/security/security-changes). + For more information about reflection and transparency, see [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection). ]]> @@ -1808,18 +1791,15 @@ Myfieldb - B readonly field, IsInitOnly = True ## Remarks The , , and properties report the transparency level of the field at its current trust level, as determined by the common language runtime (CLR). The combinations of these properties are shown in the following table: -|Security level|IsSecurityCritical|IsSecuritySafeCritical|IsSecurityTransparent| -|--------------------|------------------------|----------------------------|---------------------------| -|Critical|`true`|`false`|`false`| -|Safe critical|`true`|`true`|`false`| -|Transparent|`false`|`false`|`true`| +| Security level | IsSecurityCritical | IsSecuritySafeCritical | IsSecurityTransparent | +|----------------|--------------------|------------------------|-----------------------| +| Critical | `true` | `false` | `false` | +| Safe critical | `true` | `true` | `false` | +| Transparent | `false` | `false` | `true` | Using these properties is much simpler than examining the security annotations of an assembly and its types and members, checking the current trust level, and attempting to duplicate the runtime's rules. -> [!IMPORTANT] -> For partial-trust assemblies, the value of this property depends on the current trust level of the assembly. If the assembly is loaded into a partially trusted application domain (for example, into a sandboxed application domain), then the runtime ignores the security annotations of the assembly. The assembly and all its types are treated as transparent. The runtime pays attention to the security annotations of a partial-trust assembly only when that assembly is loaded into a fully trusted application domain (for example, into the default application domain of a desktop application). By contrast, a trusted assembly (that is, a strong-named assembly that is installed in the global assembly cache) is always loaded with full trust regardless of the trust level of the application domain, so its current trust level is always fully trusted. You can determine the current trust levels of assemblies and application domains by using the and properties. - - For more information about reflection and transparency, see [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection). For information about transparency, see [Security Changes](/dotnet/framework/security/security-changes). + For more information about reflection and transparency, see [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection). ]]> @@ -2226,8 +2206,6 @@ This method cannot be used to set values of static, init-only (`readonly` in C#) > [!NOTE] > This method can be used to access non-public members if the caller has been granted with the flag and if the grant set of the non-public members is restricted to the caller's grant set, or a subset thereof. (See [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection).) -> -> To use this functionality, your application should target .NET Framework 3.5 or later. ## Examples The following example sets the value of a field, gets and displays the value, modifies the field, and displays the result. @@ -2385,8 +2363,6 @@ This method cannot be used to set values of static, init-only (`readonly` in C#) > [!NOTE] > This method can be used to access non-public members if the caller has been granted with the flag and if the grant set of the non-public members is restricted to the caller's grant set, or a subset thereof. (See [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection).) -> -> To use this functionality, your application should target .NET Framework 3.5 or later. ]]> diff --git a/xml/System.Reflection/IReflect.xml b/xml/System.Reflection/IReflect.xml index cea6c4fce30..89273d0b3e5 100644 --- a/xml/System.Reflection/IReflect.xml +++ b/xml/System.Reflection/IReflect.xml @@ -52,8 +52,6 @@ In .NET 10 and later versions, no COM object casts successfully to this interfac In .NET 5 through .NET 9, COM objects that implement `IDispatchEx` can be cast to this interface, but all methods throw `TypeLoadException`. -On .NET Framework, the interface is used to interoperate with the [IDispatch interface](/windows/win32/api/oaidl/nn-oaidl-idispatch). defines a subset of the reflection methods. Implementing this interface enables a type to customize its behavior when the object is being accessed from COM as an `IDispatch` object. The class can be used to marshal an object that implements or as a COM `IDispatch` object, and vice versa. - ]]> @@ -842,8 +840,6 @@ On .NET Framework, the interface is used to in Access restrictions are ignored for fully trusted code. That is, private constructors, methods, fields, and properties can be accessed and invoked through reflection whenever the code is fully trusted. - - ## Examples The following example obtains the value of the property. diff --git a/xml/System.Reflection/MemberInfo.xml b/xml/System.Reflection/MemberInfo.xml index 51e35e18bf1..9394760f5a9 100644 --- a/xml/System.Reflection/MemberInfo.xml +++ b/xml/System.Reflection/MemberInfo.xml @@ -644,14 +644,8 @@ Gets a value that indicates whether this object references one or more assemblies held in a collectible . if the references one or more assemblies held in a collectible assembly load context; otherwise, . - - - + To be added. + diff --git a/xml/System.Reflection/MethodBase.xml b/xml/System.Reflection/MethodBase.xml index 51e087e6f4d..6b64b33417f 100644 --- a/xml/System.Reflection/MethodBase.xml +++ b/xml/System.Reflection/MethodBase.xml @@ -501,11 +501,8 @@ The elements of the returned array are in the order in which they appear in the list of type parameters for the generic method. - If the current method is a closed constructed method (that is, the property returns `false`), the array returned by the method contains the types that have been assigned to the generic type parameters of the generic method definition. - - If the current method is a generic method definition, the array contains the type parameters. - - If the current method is an open constructed method (that is, the property returns `true`) in which specific types have been assigned to some type parameters and type parameters of enclosing generic types have been assigned to other type parameters, the array contains both types and type parameters. Use the property to tell them apart. For a demonstration of this scenario, see the code example provided for the property. - - If the current method is a constructor, the returned array is an empty array in .NET 11 and later. In .NET 10 and earlier versions, the method throws . For a list of the invariant conditions for terms specific to generic methods, see the property. For a list of the invariant conditions for other terms used in generic reflection, see the property. @@ -633,7 +630,7 @@ The property is used to obtain a list of objects and display their types and index order. The property is used to obtain a list of exception-handling clauses. > [!NOTE] -> Not all computer languages can generate clauses. The Visual Basic example shows a filter clause, using a Visual Basic `When` expression, which is omitted from the examples for other languages. +> Not all computer languages can generate clauses. The Visual Basic example shows a filter clause, using a Visual Basic `When` expression, which is omitted from the examples for other languages. :::code language="csharp" source="~/snippets/csharp/System.Reflection/ExceptionHandlingClause/Overview/source.cs" id="Snippet1"::: :::code language="vb" source="~/snippets/visualbasic/System.Reflection/ExceptionHandlingClause/Overview/source.vb" id="Snippet1"::: @@ -704,14 +701,7 @@ The method's handle. Gets method information by using the method's internal metadata representation (handle). A containing information about the method. - - - + To be added. is invalid. @@ -771,9 +761,8 @@ structure for a constructor or method of a generic type can represent different objects, depending on the types specified for the type parameters of the generic type. For example, if `class G` (`class G(Of T)` in Visual Basic) has a method that returns type `T`, the object for that method in a constructed class such as `G` is different from the object for that method in the generic type definition. +A structure for a constructor or method of a generic type can represent different objects, depending on the types specified for the type parameters of the generic type. For example, if `class G` (`class G(Of T)` in Visual Basic) has a method that returns type `T`, the object for that method in a constructed class such as `G` is different from the object for that method in the generic type definition. ]]> @@ -982,15 +971,10 @@ To invoke a static method using its object, pass `null` for `obj`. > [!NOTE] -> If this method overload is used to invoke an instance constructor, the object supplied for `obj` is reinitialized; that is, all instance initializers are executed. The return value is `null`. If a class constructor is invoked, the class is reinitialized; that is, all class initializers are executed. The return value is `null`. - -> [!NOTE] -> This method can be used to access non-public members if the caller has been granted with the flag and if the grant set of the non-public members is restricted to the caller's grant set, or a subset thereof. (See [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection).) To use this functionality, your application should target .NET Framework 3.5 or later. +> If this method overload is used to invoke an instance constructor, the object supplied for `obj` is reinitialized; that is, all instance initializers are executed. The return value is `null`. If a class constructor is invoked, the class is reinitialized; that is, all class initializers are executed. The return value is `null`. If a parameter of the reflected method is a value type, and the corresponding argument in `parameters` is `null`, the runtime passes a zero-initialized instance of the value type. - - ## Examples The following code example demonstrates dynamic method lookup using reflection. Note that you cannot use the object from the base class to invoke the overridden method in the derived class, because late binding cannot resolve overrides. @@ -1091,7 +1075,7 @@ This method dynamically invokes the method reflected by this instance on `obj`, You may not omit optional parameters in calls to `Invoke`. To invoke a method and omit optional parameters, call `Type.InvokeMember` instead. > [!NOTE] -> If this method overload is used to invoke an instance constructor, the object supplied for `obj` is reinitialized; that is, all instance initializers are executed. The return value is `null`. If a class constructor is invoked, the class is reinitialized; that is, all class initializers are executed. The return value is `null`. +> If this method overload is used to invoke an instance constructor, the object supplied for `obj` is reinitialized; that is, all instance initializers are executed. The return value is `null`. If a class constructor is invoked, the class is reinitialized; that is, all class initializers are executed. The return value is `null`. For pass-by-value primitive parameters, normal widening is performed (Int16 -> Int32, for example). For pass-by-value reference parameters, normal reference widening is allowed (derived class to base class, and base class to interface type). However, for pass-by-reference primitive parameters, the types must match exactly. For pass-by-reference reference parameters, the normal widening still applies. @@ -1103,15 +1087,8 @@ This method dynamically invokes the method reflected by this instance on `obj`, On the other hand, if the method is non-virtual, then reflection will use the implementation given by the type from which the `MethodInfo` was obtained, regardless of the type of the object passed as the target. - Access restrictions are ignored for fully trusted code. That is, private constructors, methods, fields, and properties can be accessed and invoked via reflection whenever the code is fully trusted. - If the invoked method throws an exception, the method returns the originating exception. -> [!NOTE] -> This method can be used to access non-public members if the caller has been granted with the flag and if the grant set of the non-public members is restricted to the caller's grant set, or a subset thereof. (See [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection).) To use this functionality, your application should target .NET Framework 3.5 or later. - - - ## Examples The following example demonstrates all members of the class using an overload of . The private method `CanConvertFrom` finds compatible types for a given type. For another example of invoking members in a custom binding scenario, see [Dynamically Loading and Using Types](/dotnet/framework/reflection-and-codedom/dynamically-loading-and-using-types). @@ -1362,7 +1339,7 @@ This method dynamically invokes the method reflected by this instance on `obj`, ## Remarks > [!NOTE] -> The property returns `false` for a object in a dynamic type, unless the flag was included in the `attributes` parameter when the constructor was defined. Omitting the flag does not affect the correctness of the emitted constructor. +> The property returns `false` for a object in a dynamic type, unless the flag was included in the `attributes` parameter when the constructor was defined. Omitting the flag does not affect the correctness of the emitted constructor. ]]> @@ -1699,7 +1676,7 @@ If `IsVirtual` is `false` or `IsFinal` is `true`, then the method cannot be over Use the property to determine whether the current object represents a generic method. Use the property to determine whether the current object represents an open constructed method or a closed constructed method. > [!NOTE] -> Generics are not supported by default; this property returns `false` if not overridden in a derived class. Generic constructors are not supported in the .NET Framework version 2.0, so this property returns `false` if the current instance is of type . +> Generics are not supported by default; this property returns `false` if not overridden in a derived class. The following table summarizes the invariant conditions for terms specific to generic methods. For other terms used in generic reflection, such as *generic type parameter* and *generic type*, see the property. @@ -1773,14 +1750,12 @@ The following table summarizes the invariant conditions for terms specific to ge - For each object in the array returned by the method: - - The property is `true`. - - - The property returns the current instance. - - - The property is the same as the position of the object in the array. + - The property is `true`. + - The property returns the current instance. + - The property is the same as the position of the object in the array. > [!NOTE] -> Generics are not supported by default; this property returns `false` if not overridden in a derived class. Generic constructors are not supported in the .NET Framework version 2.0, so this property returns `false` if the current instance is of type . +> Generics are not supported by default; this property returns `false` if not overridden in a derived class. For a list of the invariant conditions for terms specific to generic methods, see the property. For a list of the invariant conditions for other terms used in generic reflection, see the property. @@ -1842,7 +1817,7 @@ The following table summarizes the invariant conditions for terms specific to ge When a member in a derived class is declared with the C# `new` modifier or the Visual Basic `Shadows` modifier, it can hide a member of the same name in the base class. C# hides base class members by signature. That is, if the base class member has multiple overloads, the only one that is hidden is the one that has the identical signature. By contrast, Visual Basic hides all the base class overloads. Thus, returns `false` on a member declared with the Visual Basic `Shadows` modifier, and `true` on a member declared with the C# `new` modifier. > [!WARNING] -> This property does not determine whether a method has the attribute. A method that is declared with either the `new` or the `Shadows` modifier will have the attribute, but only methods declared with `new` (that is, only C# methods) will have the property set to `true`. To determine whether a method has the attribute, use code similar to the following: `if ((myMethodInfo.Attributes & MethodAttributes.VtableLayoutMask) == MethodAttributes.NewSlot)` in C# or `If (myMethodInfo.Attributes And MethodAttributes.VtableLayoutMask) = MethodAttributes.NewSlot` in Visual Basic. Note, however, that although all methods declared with `new` or `Shadows` have the attribute, not all methods that have the attribute are declared with `new` or `Shadows`. +> This property does not determine whether a method has the attribute. A method that is declared with either the `new` or the `Shadows` modifier will have the attribute, but only methods declared with `new` (that is, only C# methods) will have the property set to `true`. To determine whether a method has the attribute, use code similar to the following: `if ((myMethodInfo.Attributes & MethodAttributes.VtableLayoutMask) == MethodAttributes.NewSlot)` in C# or `If (myMethodInfo.Attributes And MethodAttributes.VtableLayoutMask) = MethodAttributes.NewSlot` in Visual Basic. Note, however, that although all methods declared with `new` or `Shadows` have the attribute, not all methods that have the attribute are declared with `new` or `Shadows`. @@ -2026,25 +2001,21 @@ The following table summarizes the invariant conditions for terms specific to ge ## Remarks The , , and properties report the transparency level of the method or constructor at its current trust level, as determined by the common language runtime (CLR). The combinations of these properties are shown in the following table: -|Security level|IsSecurityCritical|IsSecuritySafeCritical|IsSecurityTransparent| -|--------------------|------------------------|----------------------------|---------------------------| -|Critical|`true`|`false`|`false`| -|Safe critical|`true`|`true`|`false`| -|Transparent|`false`|`false`|`true`| +| Security level | IsSecurityCritical | IsSecuritySafeCritical | IsSecurityTransparent | +|----------------|--------------------|------------------------|-----------------------| +| Critical | `true` | `false` | `false` | +| Safe critical | `true` | `true` | `false` | +| Transparent | `false` | `false` | `true` | Using these properties is much simpler than examining the security annotations of an assembly and its types and members, checking the current trust level, and attempting to duplicate the runtime's rules. -> [!IMPORTANT] -> For partial-trust assemblies, the value of this property depends on the current trust level of the assembly. If the assembly is loaded into a partially trusted application domain (for example, into a sandboxed application domain), the runtime ignores the security annotations of the assembly. The assembly and all its types are treated as transparent. The runtime pays attention to the security annotations of a partial-trust assembly only when that assembly is loaded into a fully trusted application domain (for example, into the default application domain of a desktop application). By contrast, a trusted assembly (that is, a strong-named assembly that is installed in the global assembly cache) is always loaded with full trust regardless of the trust level of the application domain, so its current trust level is always fully trusted. You can determine the current trust levels of assemblies and application domains by using the and properties. - - For more information about reflection and transparency, see [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection). For information about transparency, see [Security Changes](/dotnet/framework/security/security-changes). + For more information about reflection and transparency, see [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection). ]]> Security Considerations for Reflection - Security Changes in the .NET Framework Version 4.0 @@ -2094,25 +2065,21 @@ The following table summarizes the invariant conditions for terms specific to ge ## Remarks The , , and properties report the transparency level of the method or constructor at its current trust level, as determined by the common language runtime (CLR). The combinations of these properties are shown in the following table: -|Security level|IsSecurityCritical|IsSecuritySafeCritical|IsSecurityTransparent| -|--------------------|------------------------|----------------------------|---------------------------| -|Critical|`true`|`false`|`false`| -|Safe critical|`true`|`true`|`false`| -|Transparent|`false`|`false`|`true`| +| Security level | IsSecurityCritical | IsSecuritySafeCritical | IsSecurityTransparent | +|----------------|--------------------|------------------------|-----------------------| +| Critical | `true` | `false` | `false` | +| Safe critical | `true` | `true` | `false` | +| Transparent | `false` | `false` | `true` | Using these properties is much simpler than examining the security annotations of an assembly and its types and members, checking the current trust level, and attempting to duplicate the runtime's rules. -> [!IMPORTANT] -> For partial-trust assemblies, the value of this property depends on the current trust level of the assembly. If the assembly is loaded into a partially trusted application domain (for example, into a sandboxed application domain), the runtime ignores the security annotations of the assembly. The assembly and all its types are treated as transparent. The runtime pays attention to the security annotations of a partial-trust assembly only when that assembly is loaded into a fully trusted application domain (for example, into the default application domain of a desktop application). By contrast, a trusted assembly (that is, a strong-named assembly that is installed in the global assembly cache) is always loaded with full trust regardless of the trust level of the application domain, so its current trust level is always fully trusted. You can determine the current trust levels of assemblies and application domains by using the and properties. - - For more information about reflection and transparency, see [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection). For information about transparency, see [Security Changes](/dotnet/framework/security/security-changes). + For more information about reflection and transparency, see [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection). ]]> Security Considerations for Reflection - Security Changes in the .NET Framework Version 4.0 @@ -2164,17 +2131,13 @@ The following table summarizes the invariant conditions for terms specific to ge The , , and properties report the transparency level of the method or constructor at its current trust level, as determined by the common language runtime (CLR). Using these properties is much simpler than examining the security annotations of an assembly and its types and members, checking the current trust level, and attempting to duplicate the runtime's rules. -> [!IMPORTANT] -> For partial-trust assemblies, the value of this property depends on the current trust level of the assembly. If the assembly is loaded into a partially trusted application domain (for example, into a sandboxed application domain), the runtime ignores the security annotations of the assembly. The assembly and all its types are treated as transparent. The runtime pays attention to the security annotations of a partial-trust assembly only when that assembly is loaded into a fully trusted application domain (for example, into the default application domain of a desktop application). By contrast, a trusted assembly (that is, a strong-named assembly that is installed in the global assembly cache) is always loaded with full trust regardless of the trust level of the application domain, so its current trust level is always fully trusted. You can determine the current trust levels of assemblies and application domains by using the and properties. - - For more information about reflection and transparency, see [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection). For information about transparency, see [Security Changes](/dotnet/framework/security/security-changes). + For more information about reflection and transparency, see [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection). ]]> Security Considerations for Reflection - Security Changes in the .NET Framework Version 4.0 @@ -2426,14 +2389,7 @@ If MethodInfo.IsVirtual AndAlso Not MethodInfo.IsFinal Then Gets a handle to the internal metadata representation of a method. A object. - - - + To be added. diff --git a/xml/System.Reflection/MethodImplAttributes.xml b/xml/System.Reflection/MethodImplAttributes.xml index e6cae5a1b9c..b9b5f8668a0 100644 --- a/xml/System.Reflection/MethodImplAttributes.xml +++ b/xml/System.Reflection/MethodImplAttributes.xml @@ -59,52 +59,39 @@ Specifies flags for the attributes of a method implementation. - [!NOTE] -> Locking on the instance or on the type, as with the `Synchronized` flag, is not recommended for public types, because code other than your own can take locks on public types and instances. This might cause deadlocks or other synchronization problems. - +> Locking on the instance or on the type, as with the `Synchronized` flag, is not recommended for public types, because code other than your own can take locks on public types and instances. This might cause deadlocks or other synchronization problems. + ]]> diff --git a/xml/System.Reflection/Module.xml b/xml/System.Reflection/Module.xml index f94bee92e77..c2b56fbd5b3 100644 --- a/xml/System.Reflection/Module.xml +++ b/xml/System.Reflection/Module.xml @@ -87,10 +87,6 @@ One or more modules deployed as a unit compose an assembly. For information about creating an assembly with more than one module, see [Multifile Assemblies](/dotnet/framework/app-domains/multifile-assemblies). - Note that a .NET Framework module is not the same as a module in Visual Basic, which is used by a programmers to organize functions and subroutines in an application. - - - ## Examples The following code examples show how to use reflection to get information about modules: diff --git a/xml/System.Reflection/PropertyInfo.xml b/xml/System.Reflection/PropertyInfo.xml index dd017c2547f..a73a3a11c1e 100644 --- a/xml/System.Reflection/PropertyInfo.xml +++ b/xml/System.Reflection/PropertyInfo.xml @@ -196,18 +196,16 @@ property returns the attributes associated with the property represented by this object. The attributes are primarily modifiers applied by a compiler when creating a property; they indicate whether a property is the default property, a `SpecialName` property, and so on. Note that, for almost all properties found in types in the .NET Framework class library, the value of the property is . + The property returns the attributes associated with the property represented by this object. The attributes are primarily modifiers applied by a compiler when creating a property; they indicate whether a property is the default property, a `SpecialName` property, and so on. Note that, for almost all properties found in types in the .NET class library, the value of the property is . > [!TIP] > In most cases, you probably want to retrieve the custom attributes associated with a property. To do this, retrieve the value of the property, or call one of the overloads of the method. To get the property: -1. Get a object that represents the type to which the property belongs. - -2. Get the object by calling an overload of the method. - -3. Retrieve the property's attributes from the property. +1. Get a object that represents the type to which the property belongs. +2. Get the object by calling an overload of the method. +3. Retrieve the property's attributes from the property. You can define the attributes of a property for a type created dynamically using reflection emit by calling an overload of the method and supplying a value for the `attributes` argument. @@ -333,15 +331,15 @@ returns `true` if the property has a `set` accessor, even if the accessor is `private`, `internal` (or `Friend` in Visual Basic), or `protected`. If the property does not have a `set` accessor, the method returns `false`. + returns `true` if the property has a `set` accessor, even if the accessor is `private`, `internal` (or `Friend` in Visual Basic), or `protected`. If the property does not have a `set` accessor, the method returns `false`. To get the value of the property: -1. Get the object of the type that includes the property. +1. Get the object of the type that includes the property. -2. Call the to get the object that represents the property. +2. Call the to get the object that represents the property. -3. Retrieve the value of the property. +3. Retrieve the value of the property. @@ -1419,9 +1417,6 @@ Console.WriteLine("CurrCult: " + To use the `GetValue` method, first get the class `Type`. From the `Type`, get the `PropertyInfo`. From the `PropertyInfo`, use the `GetValue` method. -> [!NOTE] -> This method can be used to access non-public members if the caller has been granted with the flag and if the grant set of the non-public members is restricted to the caller's grant set, or a subset thereof. (See [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection).) To use this functionality, your application should target .NET Framework 3.5 or later. - ## Examples The following example shows how to get the value of an indexed property. The property is the default property (the indexer in C#) of the class. @@ -1513,9 +1508,6 @@ Console.WriteLine("CurrCult: " + To use the `GetValue` method, first get the class `Type`. From the `Type`, get the `PropertyInfo`. From the `PropertyInfo`, use the `GetValue` method. -> [!NOTE] -> This method can be used to access non-public members if the caller has been granted with the flag and if the grant set of the non-public members is restricted to the caller's grant set, or a subset thereof. (See [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection).) To use this functionality, your application should target .NET Framework 3.5 or later. - ]]> The array does not contain the type of arguments needed. @@ -1814,11 +1806,11 @@ Console.WriteLine("CurrCult: " + ## Remarks To determine the type of a particular property, do the following: -1. Get a object that represents the type (the class or structure) that contains the property. If you are working with an object (an instance of a type), you can call its method. Otherwise, you can use the C# operator or the Visual Basic [GetType](/dotnet/visual-basic/language-reference/operators/gettype-operator) operator, as the example illustrates. +1. Get a object that represents the type (the class or structure) that contains the property. If you are working with an object (an instance of a type), you can call its method. Otherwise, you can use the C# operator or the Visual Basic [GetType](/dotnet/visual-basic/language-reference/operators/gettype-operator) operator, as the example illustrates. -2. Get a object that represents the property in which you're interested. You can do this by getting an array of all properties from the method and then iterating the elements in the array, or you can retrieve the object that represents the property directly by calling the method and specifying the property name. +2. Get a object that represents the property in which you're interested. You can do this by getting an array of all properties from the method and then iterating the elements in the array, or you can retrieve the object that represents the property directly by calling the method and specifying the property name. -3. Retrieve the value of the property from the object. +3. Retrieve the value of the property from the object. @@ -1960,9 +1952,6 @@ Console.WriteLine("CurrCult: " + To use the method, first get a object that represents the class. From the , get the object. From the object, call the method. -> [!NOTE] -> This method can be used to access non-public members if the caller has been granted with the flag and if the grant set of the non-public members is restricted to the caller's grant set, or a subset thereof. (See [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection).) To use this functionality, your application should target .NET Framework 3.5 or later. - ## Examples The following example declares a class named `Example` with one `static` (`Shared` in Visual Basic) and one instance property. The example uses the method to change the original property values and displays the original and final values. @@ -2046,9 +2035,6 @@ Console.WriteLine("CurrCult: " + To use the method, first get a object that represents the class. From the , get the . From the , use the method. -> [!NOTE] -> In .NET Framework, this method can be used to access non-public members if the caller has been granted with the flag and if the grant set of the non-public members is restricted to the caller's grant set, or a subset thereof. (See [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection).) To use this functionality, your application should target .NET Framework 3.5 or later. - ## Examples The following example defines a class named `TestClass` that has a read-write property named `Caption`. It displays the default value of the `Caption` property, calls the method to change the property value, and displays the result. @@ -2153,9 +2139,6 @@ Console.WriteLine("CurrCult: " + To use the `SetValue` method, first get the class `Type`. From the `Type`, get the `PropertyInfo`. From the `PropertyInfo`, use the `SetValue` method. -> [!NOTE] -> This method can be used to access non-public members if the caller has been granted with the flag and if the grant set of the non-public members is restricted to the caller's grant set, or a subset thereof. (See [Security Considerations for Reflection](/dotnet/framework/reflection-and-codedom/security-considerations-for-reflection).) To use this functionality, your application should target .NET Framework 3.5 or later. - ]]> The array does not contain the type of arguments needed. diff --git a/xml/System.Reflection/StrongNameKeyPair.xml b/xml/System.Reflection/StrongNameKeyPair.xml index eefd44f8ab5..b2b48aac4b0 100644 --- a/xml/System.Reflection/StrongNameKeyPair.xml +++ b/xml/System.Reflection/StrongNameKeyPair.xml @@ -67,7 +67,7 @@ ## Examples The following code example shows how to open a Company.keys file (produced by running the [Sn.exe (Strong Name Tool)](/dotnet/framework/tools/sn-exe-strong-name-tool) with the **-k** switch), read the public key from the file, and display the key in the console window. - + :::code language="csharp" source="~/snippets/csharp/System.Reflection/StrongNameKeyPair/Overview/strongnamekeypairx.cs" id="Snippet1"::: :::code language="vb" source="~/snippets/visualbasic/System.Reflection/StrongNameKeyPair/Overview/StrongNameKeyPairX.vb" id="Snippet1"::: @@ -127,10 +127,7 @@ An array of type containing the key pair. Initializes a new instance of the class, building the key pair from a array. To be added. - - is . - The caller does not have the required permission. - .NET 6+ only: In all cases. + In all cases. @@ -174,10 +171,7 @@ A containing the key pair. Initializes a new instance of the class, building the key pair from a . To be added. - - is . - The caller does not have the required permission. - .NET 6+ only: In all cases. + In all cases. @@ -220,18 +214,8 @@ A string containing the key pair. Initializes a new instance of the class, building the key pair from a . - - - - - is . - The caller does not have the required permission. - .NET Core and .NET 5+ only: In all cases. + To be added. + In all cases. @@ -285,16 +269,8 @@ A object that holds the serialized object data. A object that contains contextual information about the source or destination. Initializes a new instance of the class, building the key pair from serialized data. - - - - .NET Core and .NET 5+ only: In all cases. - XML and SOAP Serialization + To be added. + In all cases. @@ -343,9 +319,7 @@ Gets the public part of the public key or public key token of the key pair. An array of type containing the public key or public key token of the key pair. To be added. - .NET Core and .NET 5+ only: In all cases. - - + In all cases. @@ -393,7 +367,7 @@ The object that initiated the callback. Runs when the entire object graph has been deserialized. To be added. - .NET Core and .NET 5+ only: In all cases. + In all cases. @@ -443,9 +417,7 @@ The destination context of the serialization. Sets the object with all the data required to reinstantiate the current object. To be added. - - is . - .NET Core and .NET 5+ only: In all cases. + In all cases. diff --git a/xml/System.Reflection/TypeAttributes.xml b/xml/System.Reflection/TypeAttributes.xml index bd7716da7cb..03eb8644d51 100644 --- a/xml/System.Reflection/TypeAttributes.xml +++ b/xml/System.Reflection/TypeAttributes.xml @@ -448,7 +448,7 @@ 196608 - LPSTR is interpreted by some implementation-specific means, which includes the possibility of throwing a . Not used in the Microsoft implementation of the .NET Framework. + LPSTR is interpreted by some implementation-specific means, which includes the possibility of throwing a . Not used in the Microsoft implementation of .NET. @@ -492,7 +492,7 @@ 12582912 - Used to retrieve non-standard encoding information for native interop. The meaning of the values of these 2 bits is unspecified. Not used in the Microsoft implementation of the .NET Framework. + Used to retrieve non-standard encoding information for native interop. The meaning of the values of these 2 bits is unspecified. Not used in the Microsoft implementation of .NET. diff --git a/xml/System.Reflection/TypeDelegator.xml b/xml/System.Reflection/TypeDelegator.xml index 7fbe1f24853..e3c5307fd61 100644 --- a/xml/System.Reflection/TypeDelegator.xml +++ b/xml/System.Reflection/TypeDelegator.xml @@ -1920,7 +1920,7 @@ This method can be used to find a constructed generic member given a member from @@ -2060,8 +2060,7 @@ This method can be used to find a constructed generic member given a member from A method will be invoked if both the following conditions are true: - The number of parameters in the method declaration equals the number of arguments in the specified argument list (unless default arguments are defined on the member). - -- The type of each arguments can be converted by the binder to the type of the parameter. +- The type of each argument can be converted by the binder to the type of the parameter. The binder will find all the matching methods. These methods are found based upon the type of binding requested (`BindingFlags.MethodInvoke`, `BindingFlags.GetProperties`, and so on). The set of methods is filtered by the name, number of arguments, and a set of search modifiers defined in the binder. @@ -2070,7 +2069,7 @@ This method can be used to find a constructed generic member given a member from > [!NOTE] > Access restrictions are ignored for fully trusted code. That is, private constructors, methods, fields, and properties can be accessed and invoked using reflection whenever the code is fully trusted. - Currently, `InvokeMember` performs the Microsoft .NET Framework reflection semantics for every type of object. + Currently, `InvokeMember` performs the .NET reflection semantics for every type of object. If the member specified by name is an array and the `BindingFlags.GetField` flag is set on `invokeAttr`, the `args` array specifies the elements whose values are to be returned. For example, the following call through `Type` object `t` returns the value of the first element of the string array MyArray, which is a member of the calling object: diff --git a/xml/System.Reflection/TypeInfo.xml b/xml/System.Reflection/TypeInfo.xml index bb17756b9a8..34f1f3e3e5a 100644 --- a/xml/System.Reflection/TypeInfo.xml +++ b/xml/System.Reflection/TypeInfo.xml @@ -79,13 +79,12 @@ class is included in the .NET for Windows 8.x Store apps subset for use in creating Windows Store apps. is available in the full .NET Framework as well. For more information about reflection for Windows Store apps, see [System.Reflection namespaces](/dotnet/api/?term=system.reflection) and [Reflection in the .NET Framework for Windows Store Apps](/dotnet/framework/reflection-and-codedom/reflection-for-windows-store-apps). - contains many of the members available in the class, and many of the reflection properties in the .NET for Windows 8.x Store apps return collections of objects. To get a object from a object, use the extension method. + contains many of the members available in the class. To get a object from a object, use the extension method. A object represents the type definition itself, whereas a object represents a reference to the type definition. Getting a object forces the assembly that contains that type to load. In comparison, you can manipulate objects without necessarily requiring the runtime to load the assembly they reference. - In the .NET for Windows 8.x Store apps, you use the reflection properties of that return collections instead of methods that return arrays. For example, use the property to get all declared members, or the property to get all declared properties. Reflection contexts can implement lazy traversal of these collections for large assemblies or types. To get specific members, use methods such as and , and pass the name of the method or property you would like to retrieve. +You can use the property to get all declared members, or the property to get all declared properties. Reflection contexts can implement lazy traversal of these collections for large assemblies or types. To get specific members, use methods such as and , and pass the name of the method or property you would like to retrieve. To filter the results of properties, use LINQ queries. For reflection objects that originate with the runtime (for example, as the result of `typeof(Object)`), you can traverse the inheritance tree by using the methods in the class. Consumers of objects from customized reflection contexts cannot use these methods and must traverse the inheritance tree themselves.