DynamicMethod Class

Defines and represents a dynamic method that can be compiled, executed, and discarded. Discarded methods are available for garbage collection.

Syntax

[System.Runtime.InteropServices.ComVisible(true)]
public sealed class DynamicMethod : System.Reflection.MethodInfo

Remarks

You can use the System.Reflection.Emit.DynamicMethod class to generate and execute a method at run time, without having to generate a dynamic assembly and a dynamic type to contain the method. The executable code created by the just-in-time (JIT) compiler is reclaimed when the System.Reflection.Emit.DynamicMethod object is reclaimed. Dynamic methods are the most efficient way to generate and execute small amounts of code.

A dynamic method can be anonymously hosted, or it can be logically associated with a module or with a type.

If the dynamic method is anonymously hosted, it is located in a system-provided assembly, and therefore is isolated from other code. By default, it does not have access to any non-public data. An anonymously hosted dynamic method can have restricted ability to skip the JIT compiler's visibility checks, if it has been granted System.Security.Permissions.ReflectionPermission with the System.Security.Permissions.ReflectionPermissionFlag.RestrictedMemberAccess flag. The trust level of the assembly whose non-public members are accessed by the dynamic method must be equal to, or a subset of, the trust level of the call stack that emitted the dynamic method. For more information about anonymously hosted dynamic methods, see Walkthrough: Emitting Code in Partial Trust Scenarios.
If the dynamic method is associated with a module that you specify, the dynamic method is effectively global to that module. It can access all types in the module and all internal (Friend in Visual Basic) members of the types. You can associate a dynamic method with any module, regardless of whether you created the module, provided that a demand for System.Security.Permissions.ReflectionPermission with the System.Security.Permissions.ReflectionPermissionFlag.RestrictedMemberAccess flag can be satisfied by the call stack that includes your code. If the System.Security.Permissions.ReflectionPermissionFlag.MemberAccess flag is included in the grant, the dynamic method can skip the JIT compiler's visibility checks and access the private data of all types declared in the module or in any other module in any assembly.
If the dynamic method is associated with a type that you specify, it has access to all members of the type, regardless of access level. In addition, JIT visibility checks can be skipped. This gives the dynamic method access to the private data of other types declared in the same module or in any other module in any assembly. You can associate a dynamic method with any type, but your code must be granted System.Security.Permissions.ReflectionPermission with both the System.Security.Permissions.ReflectionPermissionFlag.RestrictedMemberAccess and System.Security.Permissions.ReflectionPermissionFlag.MemberAccess flags.

The following table shows which types and members are accessible to an anonymously hosted dynamic method, with and without JIT visibility checks, depending on whether System.Security.Permissions.ReflectionPermission with the System.Security.Permissions.ReflectionPermissionFlag.RestrictedMemberAccess flag is granted.


	Without System.Security.Permissions.ReflectionPermissionFlag.RestrictedMemberAccess	With System.Security.Permissions.ReflectionPermissionFlag.RestrictedMemberAccess
Without skipping JIT visibility checks	Public members of public types in any assembly.	Public members of public types in any assembly.
Skipping JIT visibility checks, with restrictions	Public members of public types in any assembly.	All members of all types, only in assemblies whose trust levels are equal to or less than the trust level of the assembly that emitted the dynamic method.

Note:

Prior to the net_v20sp1_long, emitting code required System.Security.Permissions.ReflectionPermission with the System.Security.Permissions.ReflectionPermissionFlag.ReflectionEmit flag. This permission is included by default in the FullTrust and LocalIntranet named permission sets, but not in the Internet permission set. Therefore, in earlier versions of the dnprdnshort a library can be used with Internet permissions only if it has the System.Security.SecurityCriticalAttribute attribute and also executes an System.Security.PermissionSet.Assert for System.Security.Permissions.ReflectionPermissionFlag.ReflectionEmit. Such libraries require careful security review because coding errors could result in security holes. The net_v20SP1_short allows code to be emitted in partial trust scenarios without issuing any security demands, because generating code is not inherently a privileged operation. That is, the generated code has no more permissions than the assembly that emits it. This allows libraries that emit code to be security transparent and removes the need to assert System.Security.Permissions.ReflectionPermissionFlag.ReflectionEmit, which simplifies the task of writing a secure library. To use this feature, your application should target the net_v35_long or later.

The following table shows which types and members are accessible to a dynamic method that is associated with a module or with a type in a module.


	Associated with module	Associated with type
Without skipping JIT visibility checks	Public and internal members of public, internal, and private types in the module. Public members of public types in any assembly.	All members of the associated type. Public and internal members of all the other types in the module. Public members of public types in any assembly.
Skipping JIT visibility checks	All members of all types in any assembly.	All members of all types in any assembly.

Associated with module

Associated with type

Without skipping JIT visibility checks

Public and internal members of public, internal, and private types in the module.

Public members of public types in any assembly.

All members of the associated type. Public and internal members of all the other types in the module.

Public members of public types in any assembly.

Skipping JIT visibility checks

All members of all types in any assembly.

A dynamic method that is associated with a module has the permissions of that module. A dynamic method that is associated with a type has the permissions of the module containing that type.

Dynamic methods and their parameters do not have to be named, but you can specify names to assist in debugging. Custom attributes are not supported on dynamic methods or their parameters.

Although dynamic methods are static methods (Shared methods in Visual Basic), the relaxed rules for delegate binding introduced in the dnprdnlong allow a dynamic method to be bound to an object, so that it acts like an instance method when called using that delegate instance. An example that demonstrates this is provided for the DynamicMethod.CreateDelegate(Type, object) method overload.

Note:

In the dnprdnlong, dynamic methods do not support symbol information, that is, local variable names and line-number mapping. This limitation might be removed in a future version. You can use System.Reflection.Emit.AssemblyBuilder during development to simplify debugging the generated Microsoft intermediate language (MSIL), and then switch to dynamic methods during final deployment, because the System.Reflection.Emit.ILGenerator calls are the same in both cases.

Verification

The following list summarizes the conditions under which dynamic methods can contain unverifiable code. (For example, a dynamic method is unverifiable if its DynamicMethod.InitLocals property is set to false.)

A dynamic method that is associated with a security-critical assembly is also security-critical, and can skip verification. For example, an assembly without security attributes that is run as a desktop application is treated as security-critical by the runtime. If you associate a dynamic method with the assembly, the dynamic method can contain unverifiable code.
If a dynamic method that contains unverifiable code is associated with an assembly that has level 1 transparency, the just-in-time (JIT) compiler injects a security demand. The demand succeeds only if the dynamic method is executed by fully trusted code. See Security-Transparent Code, Level 1.
If a dynamic method that contains unverifiable code is associated with an assembly that has level 2 transparency (such as mscorlib.dll), it throws an exception (injected by the JIT compiler) instead of making a security demand. See Security-Transparent Code, Level 2.
An anonymously hosted dynamic method that contains unverifiable code always throws an exception. It can never skip verification, even if it is created and executed by fully trusted code.

The exception that is thrown for unverifiable code varies depending on the way the dynamic method is invoked. If you invoke a dynamic method by using a delegate returned from the DynamicMethod.CreateDelegate(Type) method, a System.Security.VerificationException is thrown. If you invoke the dynamic method by using the erload:System.Reflection.Emit.DynamicMethod.Invoke method, a System.Reflection.TargetInvocationException is thrown with an inner System.Security.VerificationException.

Requirements

Namespace: System.Reflection.Emit
Assembly: mscorlib (in mscorlib.dll)
Assembly Versions: 2.0.0.0, 4.0.0.0
Since: .NET 2.0