Methods are the third and last leg of the tripod supporting the entire concept of managed programming, the first two being types and fields. When it comes down to execution, types, fields, and methods are the central players, with the rest of the metadata simply providing additional information about this triad.

Method items can appear in three contexts: a method definition, a method reference (for example, when a method is called), and a method implementation (when a method provides the implementation of another method).

Method Metadata

Similar to field-related metadata, method-related metadata involves definition-specific and reference-specific metadata. In addition, method-related metadata includes the method implementation, discussed later in this chapter, as well as method semantics, method interoperability, and security metadata. (Chapter 15 describes method semantics, Chapter 18 examines method interoperability, and Chapter 17 includes method security.) Figure 10-1 shows the metadata tables involved in the method definition and referencing implementation, and their mutual dependencies. To avoid cluttering the illustration, I have not included metadata tables involved in the other three method-related aspects: method semantics, method interoperability, and security metadata. The MethodSpec table, introduced in version 2.0 of the CLR, is used to define the generic method instantiations. This table will be discussed in Chapter 12.

<method_def> ::=
.method<flags> <call_conv> <ret_type> <name>(<arg_list>) < impl> {
   <method_body> }

. method public instance void set_X(int32value) cil managed
{
  ldarg.0
  ldarg.1
  stfldint32 .this::x
  ret
}

.method public static int32Diff(int32,int32) cil managed
{
   ...
}
.method publicvoid .ctor( ) runtime internalcall{}

<method_def> ::=
.method<flags> <call_conv> <ret_type> <name>(<arg_list>) < impl> {
   <method_body> }

<ret_type> ::=  <type> [ marshal(<native_type>)];
<arg_list> ::= [ <arg> [,<arg>*] ];
<arg> ::= [ [<in_out_flag>]* ] <type> [ marshal(<native_type>)]
          [<p_name>];
<in_out_flag> ::= in| out| opt

.method public static int32 marshal(int) Diff(
[ in] int32 marshal(int) First,
[ in] int32 marshal(int) Second)
{
   ...
}

<param_const_def> ::= .param[<sequence>] = <const_type> [  (<value>) ]

 .method public static int32 marshal(int) Diff(
[ in] int32 marshal(int) First,
[ opt] int32 marshal(int) Second)
{
   .param[2] = int32(0)
   ...
}

<method_ref> ::=
[ method] <call_conv> <ret_type> <class_ref>::<name>(<arg_list>)

call instance void Foo::Bar(int32,int32)
ldtoken method instance void Foo::Bar(int32,int32)

call instance void Foo::Bar(int32,int32)               // TypeDef
call instance void[OtherAssembly]Foo::Bar(int32, int32)// TypeRef
call instance void class Foo[]::Bar(int32,int32)       // TypeSpec
call void[ .moduleOther.dll]::Bar(int32, int32)        // ModuleRef

Static, Instance, Virtual Methods

We can classify methods in many ways: global methods vs. member methods, variable argument lists vs. fixed argument lists, and so on. Global and vararg methods are discussed in later sections. In this section, I’ll focus on static vs. instance methods. Take a look at Figure 10-2.

Static methods are shared by all instances of a type. They don’t require an instance reference (this) and cannot access instance members unless the instance reference is provided explicitly. When a type is loaded, static methods are placed in a separate typewide table.

The signature of a static method is exactly as it is specified, with the first specified argument being number 0.

 .method public static void Bar(int32 i, float32 r)
{
   ldarg.0// Load int32 i on stack
   ...
}

Instance methods are instance specific and have the this instance reference as an unlisted first (number 0) argument of the signature.

.method public instance void Bar(int32 i, float32 r)
{
   ldarg.0// Load instance pointer on stack
   ldarg.1// Load int32 i on stack
   ...
}

Instance methods are divided into virtual and nonvirtual methods, identified by the presence or absence of the virtual flag. The virtual methods of a class can be called through the virtual method table (v-table) of this class, which adds a level of indirection to implement so-called late binding. Method calling through the v-table (virtual dispatch) is performed by a special virtual call instruction (callvirt). Virtual methods can be overridden in derived classes by these classes’ own virtual methods of the same signature and name—and even of a different name, although such overriding requires an explicit declaration, as described later in this chapter. Virtual methods can be abstract or might offer some implementation.

If you have a nonvirtual method declared in a class, it does not mean you can’t declare another nonvirtual method with the same name and signature in a class derived from the first one. You can, but it will be a different method, having nothing to do with the method declared in the base class. Such a method in the derived class hides the respective method in the base class, but the hidden method can still be called if you explicitly specify the owning class.

If you do the same with virtual methods, however, the method declared in the derived class actually overrides (replaces in the v-table) the method declared in the base class. This is true unless, of course, you specify the newslot flag on the overriding method, in which case the overriding method will occupy a new entry of the v-table and hence will not really be overriding anything.

To illustrate this point, take a look at the following code from the sample file Virt_not.il on the Apress web site:

 .class public A
{
   .method public specialname void .ctor()
   {
      ldarg.0
      call instance void[mscorlib]System.Object:: .ctor()
      ret
   }
   .method public void Foo()
   {
      ldstr"A::Foo"
      call void[mscorlib]System.Console::WriteLine(string)
      ret
   }
   .method publicvirtual void Bar()
   {
      ldstr"A::Bar"
      call void[mscorlib]System.Console::WriteLine(string)
      ret
   }
   .method public virtual void Baz()
   {
      ldstr"A::Baz"
      call void[mscorlib]System.Console::WriteLine(string)
      ret
   }
 
}
 
.class public B extends A
{
   .method public specialname void .ctor()
   {
      ldarg.0
      call instance void A:: .ctor()
      ret
   }
   .method public void Foo()
   {
      ldstr"B::Foo"
      call void[mscorlib]System.Console::WriteLine(string)
      ret
   }
   .method public virtual void Bar()
   {
      ldstr"B::Bar"
      call void[mscorlib]System.Console::WriteLine(string)
      ret
   }
   .method publicvirtual newslot void Baz()
   {
      ldstr"B::Baz"
      call void[mscorlib]System.Console::WriteLine(string)
      ret
   }
}
 
.method public static void Exec()
{
   .entrypoint
   newobj instance void B::.ctor() // Create instance of derived class
   castclass class A               // Cast it to base class
 
   dup                             // We need 3 instance pointers
   dup                             // On stack for 3 calls
 
   call instance void A::Foo()
   callvirt instance void A::Bar()
   callvirt instance void A::Baz()
   ret
}

If you compile and run the sample, you’ll receive this output:

A:Foo

B:Bar

A:Baz

The method A::Foo is nonvirtual; hence, declaring B::Foo does not affect A::Foo in any way. So when you cast B to A and call A::Foo, B::Foo does not enter the picture; it’s a different method.

The A::Bar method is virtual, as is B::Bar, so when you create an instance of B, B::Bar replaces A::Bar in the v-table. Casting B to A after that does not change anything: B::Bar is sitting in the v-table of the class instance, and A::Bar is gone. Hence, when you call A::Bar using virtual dispatch, the “usurper” B::Bar is called instead.

Both the A::Baz and B::Baz methods are virtual, but B::Baz is marked newslot. Thus, instead of replacing A::Baz in the v-table, B::Baz takes a new entry and peacefully coexists with A::Baz. Since A::Baz is still present in the v-table of the instance, the situation is practically (oops, almost wrote “virtually”; I should watch it; we can’t have puns in such a serious book) identical to the situation with A::Foo and B::Foo, except that the calls are done through the v-table. The Visual Basic .NET compiler likes this concept and uses it rather extensively.

If you don’t want a virtual method to be overridden in the class descendants, you can mark it with the final flag. If you try to override a final method, the loader fails and throws a TypeLoad exception.

Instances of unboxed value types don’t have pointers to v-tables. It is perfectly legal to declare the virtual methods as members of a value type, but these methods can be virtually called only from a boxed instance of the value type:

   .class public value XXX
{
   .method public void YYY( )
   {
      ...
   }
   .method public virtual void ZZZ( )
   {
      ...
   }
}
.method public static void Exec( )
{
   .entrypoint
   .locals init(valuetype XXX xxx)   // Variable xxx is an
                                      // Instance of XXX
 
   ldloca xxx                        // Load managed ptr to xxx
   call instance void XXX::YYY( )    // Legal: access to value
                                      // type member
                                      // by managed ptr
   ldloca xxx
   callvirt instance void XXX::ZZZ( )// Illegal: virtual call of
                                      //  methods possible only
                                      //  by object reference.
   ldloca xxx
   call instance void XXX::ZZZ( )    // Legal: nonvirtual call,
                                      //  access to value type member
                                      //  by managed ptr.
 
   ldloc xxx                         //  Load instance of XXX.
   box valuetype XXX                 //  Convert it to object reference.
   callvirt instancevoid XXX::ZZZ( )// Legal
   ...
}

Explicit Method Overriding

Thus far, I’ve discussed implicit virtual method overriding—that is, a virtual method defined in a class overriding another virtual method of the same name and signature, defined in the class’s ancestor or an interface the class implements. But implicit overriding covers only the simplest cases.

Consider the following problem: class A implements interfaces IX and IY, and each of these interfaces defines its own virtual method called int32 Foo(int32). It is known that these methods are different and must be implemented separately. Implicit overriding can’t help in this situation. It’s time to use the MethodImpl metadata table.

The MethodImpl metadata table contains descriptors of explicit method overrides. An explicit override states which method overrides which other method. To define an explicit override in ILAsm, the following directive is used within the scope of the overriding method:

.override<class_ref>::<method_name>

The signature of the method need not be specified because the signature of the overriding method must match the signature of the overridden method, and the signature of the overriding method is known: it’s the signature of the current method. For example,

.class public interface IX {
   .method public abstract virtual int32Foo(int32) { }
}
.class public interface IY {
   .method public abstract virtual int32Foo(int32) { }
 }
.class public A implements IX,IY {
   .method public virtual int32XFoo(int32) {
      .override IX::Foo
      ...
    }
   .method public virtual int32YFoo(int32) {
      .override IY::Foo
      ...
    }
}

Not surprisingly, you can’t override the same method with two different methods within the same class: there is only one slot in the v-table to be overridden. However, you can use the same method to override several virtual methods. Let’s have a look at the following code from the sample file Override.il on the Apress web site:

.class public A
{
   .method public specialname void .ctor()
   {
      ldarg.0
      call instance void[mscorlib]System.Object:: .ctor()
      ret
   }
   .method public void Foo()
   {
      ldstr"A::Foo"
      call void[mscorlib]System.Console::WriteLine(string)
      ret
   }
   .method publicvirtual void Bar()
   {
      ldstr"A::Bar"
      call void[mscorlib]System.Console::WriteLine(string)
      ret
   }
   .method public virtual void Baz()
   {
      ldstr"A::Baz"
      call void[mscorlib]System.Console::WriteLine(string)
      ret
   }
}
.class public B extends A
{
   .method publicspecialname void .ctor()
   {
      ldarg.0
      call instance void A:: .ctor()
      ret
   }
   .method public void Foo()
   {
      ldstr"B::Foo"
      call void[mscorlib]System.Console::WriteLine(string)
      ret
   }
   .method public virtual void BarBaz()
   {
      .override A::Bar
      .override A::Baz
      ldstr"B::BarBaz"
      call void[mscorlib]System.Console::WriteLine(string)
      ret
   }
}
...
.method publicstatic void Exec()
{
   .entrypoint
   newobj instance void B:: .ctor()//  Create instance of derived class
   castclass class A               // Cast it to base class
 
   dup                             // We need 3 instance pointers
   dup                             // On stack for 3 calls
 
   call instance void A::Foo()
   callvirt instance void A::Bar()
   callvirt instance void A::Baz()
   ...
   ret
}

The output of this code demonstrates that the method B::BarBaz overrides both A::Bar and A::Baz:

A::Foo

B::BarBaz

B::BarBaz

Virtual method overriding, both implicit and explicit, is propagated to the descendants of the overriding class, unless the descendants themselves override those methods. The second half of the sample file Override.il demonstrates this:

...
.class public C extends B
{
   .method publicspecialname void .ctor()
   {
      ldarg.0
      call instance void B:: .ctor()
      ret
   }
   // No overrides; let's inherit everything from B
}
.method public static void Exec()
{
   .entrypoint
   ...
   newobj instance void C:: .ctor()//  Create instance of derived class
   castclass class A              // Cast it to "grandparent"
 
   dup                             // We need 3 instance pointers
   dup                             // On stack for 3 calls
 
   call instance void A::Foo()
   callvirt instance void A::Bar()
   callvirt instance void A::Baz()
   ret
}

The output is the same, which proves that class C has inherited the overridden methods from class B:

A::Foo

B::BarBaz

B::BarBaz

ILAsm supports an extended form of the explicit override directive, placed within the class scope:

.override<class_ref>::<method_name> with<method_ref>

For example, the overriding effect would be the same in the preceding code if you defined class B like so:

.class public B extends A
{
   .method public specialname void .ctor()
   {
      ldarg.0
      call instance void A ::.ctor()
      ret
   }
   .methodpublic void Foo()
   {
      ldstr"B::Foo"
      call void[mscorlib]System.Console::WriteLine(string)
      ret
   }
   .method public virtual void BarBaz()
   {
      ldstr"B::BarBaz"
      call void[mscorlib]System.Console::WriteLine(string)
      ret
   }
   .override A::Bar withinstance void B::BarBaz()
   .override A::Baz with instance void B::BarBaz()
}

In the extended form of the .override directive, the overriding method must be fully specified because the extended form is used within the overriding class scope, not within the overriding method scope.

To tell the truth, the extended form of the .override directive is not very useful in the existing versions of the common language runtime because the overriding methods are restricted to those of the overriding class. Under these circumstances, the short form of the directive is sufficient, and I doubt that anyone would want to use the more cumbersome extended form. But I’ve noticed that in this industry the circumstances tend to change.

One more note: you probably have noticed that the sample Override.il looks tedious and repetitive: similar constructors of the classes and multiple calls to [mscorlib]System.Console::WriteLine(string). As was discussed in Chapter 3, version 2.0 or later of the ILAsm allows you to streamline the programming by means of defines, typedefs, and the special keywords .this, .base, and .nester. Have a look at the sample Override_v2.il on the Apress web site:

#define DEFLT_CTOR
" .method public specialname void .ctor()
   { ldarg.0; call instance void .base:: .ctor(); ret}"
 
.typedef methodvoid[mscorlib]System.Console::WriteLine(string) as PrintString
 
.class public A
{
   DEFLT_CTOR
   .method public void Foo()
   {
      ldstr"A::Foo"
      call PrintString
      ret
   }
   .method public virtual void Bar()
   {
      ldstr"A::Bar"
      call PrintString
      ret
   }
   .method publicvirtual void Baz()
   {
      ldstr"A::Baz"
      call PrintString
      ret
   }
}
 
.class public B extends A
{
   DEFLT_CTOR
   .methodpublic void Foo()
   {
      ldstr"B::Foo"
      call PrintString
      ret
   }
   .method public virtual void BarBaz()
   {
      .override .base::Bar
      .override .base::Baz
      ldstr"B::BarBaz"
      call PrintString
      ret
   }
}
...
.class public C extends B
{
   DEFLT_CTOR
   // No overrides; let's inherit everything from B
}
.method publicstatic void Exec()
{
   .entrypoint
   ...
   newobj instance void C:: .ctor()//  Create instance of derived class
   castclass class A              // Cast it to "grandparent"
 
   dup                             // We need 3 instance pointers
   dup                             // On stack for 3 calls
 
   call instance void A::Foo()
   callvirt instance void A::Bar()
   callvirt instance void A::Baz()
   ret
}

Not only is sample Override_v2.il easier to read and to type, it is compiled faster (only marginally; you will not notice any effect compiling such small sample). I will leave it to you to modify the Virt_not.il sample in the same way. Just don’t forget that these syntax enhancements are specific to version 2.0 or later and are not supported in versions 1.0 and 1.1.

Method Overriding and Accessibility

Can I override an inaccessible virtual method? For example, if class A has private virtual method Foo, can I derive class B from A and override Foo? I know I cannot call A::Foo, but I don’t want to call it; I want to override it so A calls my own B::Foo. Can I?

“Yes you can,” says C++, “exactly because you are not calling the private method Foo of A.”

“No you cannot,” says C#, “because you have no access whatsoever to the private method Foo of A.”

“Eh?” says Visual Basic.... No, no, I’m just kidding, of course. Actually, VB sides with C#.

So what should the common language runtime say in this regard? As usual, it finds some common ground that is acceptable to all languages.

There is the special flag strict (0x0200) that controls the “overridability” of a virtual method. If the method is declared strict virtual, then it can be overridden only by classes that have access to it. A private strict virtual method, for example, cannot be overridden in principle, so it just as well might have been marked final.

If the flag strict is not specified, then the method can be overridden without any regard to its accessibility.

So C# and VB declare their methods strict virtual, C++ declares its methods virtual, and everyone is happy. (Note that C# and VB put the flag strict only on virtual methods with limited accessibility, such as “internal”; this flag is meaningless on public and protected methods, and private virtual methods are forbidden in these languages.)

An interesting thing about this situation is that the explicit overrides are always bound to the accessibility, as if all virtual methods were strict virtual. This creates a regrettable asymmetry between implicit and explicit overriding.

One more note about overriding and accessibility: you cannot override a virtual method with a method that has more restricted accessibility. For example, you cannot override a public method with a family method, but you can override a family method with a public method. This rule works for both implicit and explicit overrides. I leave it to you to figure out the reasoning behind this rule.

Method Header Attributes

The RVA value (if it is nonzero) of a Method record points to the method body. The managed method body consists of a method header, IL code, and an optional managed exception handling (EH) table, as shown in Figure 10-3.

Two types of method headers—fat and tiny—are defined in CorHdr.h. The first two bits of the header indicate its type: bit 10 stands for the tiny format, and bit 11 stands for the fat format. Why do we need two bits for a simple dichotomy? Speaking hypothetically, the day might come when more method header types are introduced.

A tiny method header is only 1 byte in size, with the first two (least significant) bits holding the type—10—and the six remaining bits holding the method IL code size in bytes. A method is given a tiny header if it has neither local variables nor managed exception handling, if it works fine with the default evaluation stack depth of 8 slots, and if its code size is less than 64 bytes. A fat header is 12 bytes in size and has the structure described in Table 10-1. The fat headers must begin at 4-byte boundaries. Figure 10-4 shows the structures of both tiny and fat method headers.

Local Variables

Local variables are the typed data items that are declared within the method scope and exist from the moment the method is called until it returns. ILAsm allows us to assign names to local variables and reference them by name, but IL instructions address the local variables by their zero-based ordinals.

When the source code is compiled in debug mode, the local variable names are stored in the PDB file accompanying the module, and in this case the local variable names might survive round-tripping. In general, however, these names are not preserved because they, unlike the names of fields and method parameters, are not part of the metadata.

All the local variables, no matter when they are declared within the method scope, form a single signature, kept in the StandAloneSig metadata table (token type 0x11000000). The token referencing respective signature is part of the method header.

Local variables are declared in ILAsm as follows:

.method public void Foo(int32 ii, int32 jj)
{
   .locals init(float32 ff, float64 dd, object oo, string ss)
   ...
}

The init keyword sets the flag 0x4 in the method header, indicating that the JIT compiler must inject the code initializing all local variables before commencing the method execution. Initialization means that for all variables of value types, which are allocated upon declaration, the corresponding memory is zeroed, and all variables of object reference types are set to null. Code that contains methods without a local variable initialization flag set is deemed unverifiable and can be run only with verification disabled.

ILAsm does not require that all local variables be declared in one place; the following is perfectly legal:

.method public void Foo(int32ii, int32jj)
{
   .locals init(float32ff, float64dd, object oo, string ss)
   ...
   {
      .locals(int32kk, bool bb)
      ...
   }
   ...
   {
      .locals(int32mm, float32f)
      ...
   }
   ...
 
}

In this case, the summary local variables signature will contain the types float32, float64, object, string, int32, bool, int32, and float32. Repeating init in subsequent local variable declarations of the same method is not necessary because any one of the .locals init directives sets the local variable initialization flag.

It’s obvious enough that there is a redundant local variable slot in the composite signature: by the time you need mm, you don’t need kk anymore, so you could reuse the slot and reduce the composite signature. In ILAsm, you can do that by explicitly specifying the zero-based slot numbers for local variables.

.method public void Foo(int32ii, int32jj)
{
   .locals init([0] float32ff, [1] float64dd,
                 [2] object oo, [3] string ss)
   ...
   {
      .locals([4] int32kk, [5] bool bb)
      ...
   }
   ...
   {
      .locals([4] int32mm, [6] float32f)
      ...
   }
   ...
 
}

Could you also reuse slot 5 for variable f? No, because the type of slot 5 is bool, and you need a slot of type float32 for f. Only the slots holding local variables of the same type and used within nonoverlapping scopes can be reused.

Class Constructors and the beforefieldinit Flag

The class constructors are executed before any members (static or instance) of the classes are accessed. Normally, it means that a .cctor is executed right before first access to a static member of the class or before the first class instantiation, whichever comes first.

However, if the class has the beforefieldinit flag set (see Chapter 7), the invocation of .cctor happens on a “relaxed” (as it is called in the Ecma International/ISO standard) schedule—the .cctor is supposed to be called any time, at CLR discretion, prior to the first access to a static field of the class.

In fact, the .cctor invocation schedule in presence of the beforefieldinit flag is anything but “relaxed:” the .cctor is invoked right when the class is referenced, even if no members of the class are ever accessed.

Take a look at the following code (sample Cctors.il on the Apress web site):

.assembly extern mscorlib{ auto}
.assembly cctors {}
.module cctors.exe
 
.typedef[mscorlib]System.Console as TTY
 
#define DEFLT_CTOR
 " .method public specialname void .ctor()
  { ldarg.0; call instance void .base:: .ctor(); ret;}"
 
.class public Base
{
    DEFLT_CTOR
    .method publicvoid DoSomething()
    {
        ldarg.0
        pop
        ldstr"Base::DoSomething()"
        call void TTY::WriteLine(string)
        ret
    }
}
.class public/*beforefieldinit*/ A extends Base
{
    DEFLT_CTOR
    .method public static specialname void .cctor()
    {
        ldstr"A::.cctor()"
        call void TTY::WriteLine(string)
        ret
    }
}
.class public/*beforefieldinit*/ B extends Base
{
    DEFLT_CTOR
    .method public static specialname void .cctor()
    {
        ldstr"B::.cctor()"
        call void TTY::WriteLine(string)
        ret
    }
}
 
.method publicstatic void Exec()
{
    .entrypoint
    .locals init(class Base b1)
 
    ldstr"Enter string"
    call void TTY::WriteLine(string)
    call string TTY::ReadLine()
    call bool string::IsNullOrEmpty(string)
    brtrue L1// use result of IsNullOrEmpty
 
    // Instantiate class A with .cctor
    newobj instance void A:: .ctor()
    stloc.s b1
    br L2
L1:
    // Instantiate class B with .cctor
    newobj instancevoid B:: .ctor()
    stloc.s b1
L2:
    // Use the instance
    ldloc.s b1
    call instance void Base::DoSomething()
 
    ret
}

This code instantiates either class A or class B, depending on whether you input a nonempty or empty string. The output shows that the class constructor of respective class is executed right before the instantiation of the class:

>cctors.exe

Enter string

B::.cctor()

Base::DoSomething()

or

>cctors.exe

Enter string

aaa
A::.cctor()

Base::DoSomething()

But if you uncomment the beforefieldinit flags on declarations of classes A and B and reassemble the code, the output changes:

>cctors.exe

A::.cctor()

B::.cctor()
Enter string

Base::DoSomething()

As you see, the class constructors of both A and B are executed even before the program requests the input string, let alone before either class is accessed. It’s a good thing your class constructors are so harmless; imagine what would happen if the class constructors of A and B were mutually exclusive in some respect. However, without the beforefieldinit flag, the runtime has to check if the .cctor has run every time a member of this class is accessed, and this, of course, means a performance penalty.

The moral of the story is this: avoid using the beforefieldinit flag if you want to run only relevant class constructors, i.e., if you have reasons to suspect your class constructors can step on each other’s toes. To do so in C#, always explicitly specify static constructors for classes that have initialized static fields.

Module Constructors

What happens if you declare a type initializer (.cctor) outside any type scope? What type will it initialize and when?

The answer is simple: as you already know, the global static methods and fields belong to special type (always the first record in the TypeDef table), usually named <Module> and representing current managed module (PE file). Thus, the globally declared type initializer is the module initializer, or module constructor. It is executed upon module load, before any contents of this module are accessed. In this regard, a module constructor is functionally similar to DllMain, called, with reason, DLL_PROCESS_ATTACH. The most common use of the module constructors is the initialization of global fields, but far be it from me to stifle your imagination.

Method Table Validity Rules

• The Flags entry can have only those bits set that are defined in the enumeration CorMethodAttr in CorHdr.h (validity mask 0xFDF7).
• [run time] The accessibility flag (mask 0x0007) must be one of the following: privatescope, private, famandassem, assembly, family, famorassem, or public.
• The static flag must not be combined with any of the following flags: final, virtual, newslot, or abstract.
• The pinvokeimpl flag must be paired with the static flag (but not vice versa).
• Methods having privatescope accessibility must not have the virtual, final, newslot, specialname, or rtspecialname flag set.
• The abstract, newslot, and final flags must be paired with the virtual flag.
• The abstract flag and the implementation flag forwardref are mutually exclusive.
• [run time] If the flag 0x4000 is set, the method must either have an associated DeclSecurity metadata record that holds security information concerning access to the method or have the associated custom attribute System.Security.SuppressUnmanagedCodeSecurityAttribute. The inverse is true as well.
• [run time] Methods belonging to interfaces must have either the static flag set or the virtual flag set.
• [run time] Global methods must have the static flag set.
• If the rtspecialname flag is set, the specialname flag must also be set.
• The ImplFlags entry must have only those bits set that are defined in the enumeration CorMethodImplAttr in CorHdr.h (validity mask 0x10BF).
• The implementation flag forwardref is used only during in-memory edit-and-continue scenarios and in object files (generated by the MC++ compiler) and must not be set for any method in a managed PE file.
• [run time] The implementation flags cil and unmanaged are mutually exclusive.
• [run time] The implementation flags native and managed are mutually exclusive.
• The implementation flag native must be paired with the unmanaged flag.
• [run time] The implementation flag synchronized must not be set for methods belonging to value types.
• [run time] The implementation flags runtime and internalcall are for internal use only and must not be set for methods defined outside .NET Framework system assemblies.
• [run time] The Name entry must hold a valid reference to the #Strings stream, indexing a nonempty string no more than 1,023 bytes long in UTF-8 encoding.
• [run time] If the method name is .ctor, .cctor, _VtblGap*, or _Deleted*, the rtspecialname flag must be set, and vice versa.
• [run time] A method named .ctor—an instance constructor—must not have the static flag or the virtual flag set.
• [run time] A method named .cctor—a class constructor—must have the static flag set.
• [run time] The Signature entry must hold a valid reference to the #Blob stream, indexing a valid method signature. Chapter 8 discusses validity rules for method signatures.
• [run time] A method named .ctor—an instance constructor—must return void and must have the default calling convention.
• [run time] A method named .cctor—a class constructor—must return void, can take no parameters, and must have the default calling convention.
• No duplicate records—attributed to the same TypeDef and having the same name and signature—should exist unless the accessibility flag is privatescope.

• [run time] The RVA entry must hold 0 or a valid relative virtual address pointing to a read-only section of the PE file.
  • [run time] The RVA entry holds 0 if and only if
  • the abstract flag is set, or
  • the implementation flag runtime is set, or
  • the implementation flag internalcall is set, or
  • the class owning the method has the import flag set, or
  • the pinvokeimpl flag is set, the implementation flags native and unmanaged are not set, and the ImplMap table contains a record referencing the current Method record, and this record contains valid ModuleRef reference.

Param Table Validity Rules

• The Flags entry can have only those bits set that are defined in the enumeration CorParamAttr in CorHdr.h (validity mask 0x3013).
• [run time] If the flag 0x2000 (pdHasFieldMarshal) is set, the FieldMarshal table must contain a record referencing this Param record, and vice versa.
• [run time] If the flag 0x1000 (pdHasDefault) is set, the Constant table must contain a record referencing this Param record, and vice versa.
• [run time] The Sequence entry must hold a value no larger than the number of mandatory parameters of the method owning the Param record.
• If the method owning the Param record returns void, the Sequence entry must not hold 0.
• The Name entry must hold 0 or a valid reference to the #Strings stream, indexing a nonempty string no more than 1,023 bytes long in UTF-8 encoding.

MethodImpl Table Validity Rules

• [run time] The Class entry must hold a valid index to the TypeDef table.
• [run time] The MethodDecl entry must index a record in the Method or MemberRef table.
• [run time] The method indexed by MethodDecl must be virtual.
• [run time] The method indexed by MethodDecl must not be final.
• [run time] If the parent of the method indexed by MethodDecl is not the TypeDef indexed by Class, the method indexed by MethodDecl must not be private.
• [run time] The parent of the method indexed by MethodDecl must not be sealed.
• [run time] The signatures of the methods indexed by MethodDecl and MethodBody must match.
• [run time] The MethodBody entry must index a record in the Method table.
• [run time] The method indexed by MethodBody must be virtual.
• [run time] The parent of the method indexed by MethodBody must be the TypeDef indexed by Class.