Calls the method indicated by the passed method descriptor.
Assembly: mscorlib (in mscorlib.dll)
The following table lists the instruction's hexadecimal and Microsoft Intermediate Language (MSIL) assembly format, along with a brief reference summary:
28 < T >
Call the method described by methodDesc.
The stack transitional behavior, in sequential order, is:
Method arguments arg1 through argN are pushed onto the stack.
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.
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 (Tailcall) 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 Callvirt instruction for calling virtual methods, where the destination address also depends upon the runtime type of the instance reference pushed before the Callvirt).
The arguments are placed on the stack in left-to-right order. That is, the first argument is computed and placed on the stack, then the second argument, then the third, until all necessary arguments are atop the stack in descending order. There are three important special cases:
1. Calls to an instance (or virtual) method must push that instance reference before any of the user-visible arguments. The instance reference must not be a null reference. The signature carried in the metadata does not contain an entry in the parameter list for the this pointer; instead, it uses a bit to indicate whether the method requires passing the this pointer.
2. It is valid to call a virtual method using call (rather than callvirt); this indicates that the method is to be resolved using the class specified by method rather than as specified dynamically from the object being invoked.
3. Note that a delegate's Invoke method can be called with either the call or callvirt instruction.
SecurityException may be thrown if system security does not grant the caller access to the called method. The security check may occur when the Microsoft Intermediate Language (MSIL) instructions are converted to native code rather than at run time.
When calling methods of System.Object on value types, consider using the constrained prefix with the callvirt instruction instead of emitting a call instruction. This removes the need to emit different IL depending on whether or not the value type overrides the method, avoiding a potential versioning problem. Consider using the constrained prefix when invoking interface methods on value types, since the value type method implementing the interface method can be changed using a MethodImpl. These issues are described in more detail in the Constrained opcode.
The following Emit method overloads can use the call opcode:
ILGenerator.EmitCall(OpCode, MethodInfo, Type)
Windows Phone 8.1, Windows Phone 8, Windows 8.1, Windows Server 2012 R2, Windows 8, Windows Server 2012, Windows 7, Windows Vista SP2, Windows Server 2008 (Server Core Role not supported), Windows Server 2008 R2 (Server Core Role supported with SP1 or later; Itanium not supported)
The .NET Framework does not support all versions of every platform. For a list of the supported versions, see .NET Framework System Requirements.