Haibo Luo's weblog : Reflection

SignatureResolver (unfinished)

Haibo_Luo — Sun, 09 Mar 2008 01:44:00 GMT

While writing the ILVisualizer for dynamic method late 2005, I'd like to show the local variable information as well; so I started working on the managed signature parser, at least to parse LocalVarSig (Ecma-335 23.2.6). It was 2+ years ago, and never got to a finished state. Now perhaps I will never spend more time on it, so I refreshed the code a bit and you may find it useful for some scenarios.

Here is an example of how to use SignatureResolver to get LocalVarSig in IronPython. The static method SignatureResolver.GetLocalVarSig takes the byte array (the signature blob) and the enclosing method, and returns an array of LocalVar (which includes mainly the runtime type) inside that method.

# show local variables for every Array.CreateInstance overload methods
import clr
import System
clr.AddReference("ClrTest.Reflection.SignatureResolver")
from ClrTest.Reflection import *

for method in clr.GetClrType(System.Array).GetMember("CreateInstance"):
    body = method.GetMethodBody()   # C# won't allow this
    tok = body.LocalSignatureMetadataToken
    sig = method.DeclaringType.Module.ResolveSignature(tok)
    print "> %s, 0x%x" % (method, tok)
    for lv in SignatureResolver.GetLocalVarSig(sig, method):
        print lv

Next is part of the output showing one Array.CreateInstance method's local variable types. The result is, of course, same as what Reflector tells us in the below picture. "(p)" means the local variable is pinned.

> System.Array CreateInstance(System.Type, Int32[], Int32[]), 0x11000009
System.RuntimeType 
System.Int32 
System.Int32& (p)
System.Int32& (p)
System.Array 
System.Int32[] 
System.Int32[] 
System.RuntimeTypeHandle

Yes, I understand the MethodBody.LocalVariables property gives us the similar information; but the dynamic method can not. That was why I wanted to decode the bytes, and to use DynamicScopeTokenResolver to get a meaningful type string. I admit this version of code diverts from its original goal: it only works for RuntimeMethodInfo/RuntimeConstructorInfo, and won't work for dynamic method; but if one day, you are in need of parsing blob, the functions like GetToken/GetInt32Uncompressed could be handy. GetToken basically is the reverse of TypeDefOrRefEncoded (ecma-335: 23.2.8)

int GetToken() {
    int token = GetInt32Uncompressed();
    return s_mapForTokenType[token & 0x03] | (token >> 2);
}

int GetInt32Uncompressed() {
    byte first = _sig[_pos];

    if (first <= 0x7F) {
        return _sig[_pos++];
    } else if (first <= 0xBF) {
        byte[] bytes = new byte[2];
        bytes[1] = (byte)(_sig[_pos++] - 0x80);
        bytes[0] = _sig[_pos++];
        return BitConverter.ToInt16(bytes, 0);
    } else {
        byte[] bytes = new byte[4];
        bytes[3] = (byte)(_sig[_pos++] - 0xC0);
        bytes[2] = _sig[_pos++];
        bytes[1] = _sig[_pos++]; ;
        bytes[0] = _sig[_pos++];
        return BitConverter.ToInt32(bytes, 0);
    }
}

My SignatureResolver also provide another static method GetMethodRefSig to get MethodRefSig (Ecma-335 22.25 and 23.2.2).

If you are interested in this topic, you may download the attached file, unzip it, and take a look at the source. Also try to use VS2008 to build it.

If you are an IronPython user, you may try the accompanying tests (in IronPython). I compare the SignatureResolver.GetLocalVarSig result with the official reflection API MethodBody.LocalVariables: they are same for all method/constructors from all simple-LoadFrom-successful framework assemblies. If you have ClrTest.Reflection.ILReader.dll (or know how to get one), you can try test_methodrefsig.py, which tests GetMethodRefSig.

As stated in the title, this is *unfinished* and could be buggy.

Disclaimer: THE CODE IS PROVIDED "AS IS", WITH NO WARRANTIES INTENDED OR IMPLIED. USE AT YOUR OWN RISK.

Name of Array Type

Haibo_Luo — Wed, 29 Nov 2006 09:36:00 GMT

Two things related to array type name came to my mind while writing the previous post.

Given an one-dimensional non-zero based double array x, x.GetType().ToString() returns "System.Double[*]"; we can use Type.GetType("System.Double[*]") to get hold of such type easily. To get an instance of such type, instead of calling Array.CreateInstance, we can find ConstructorInfo first, and call ConstructorInfo.Invoke. Believe it or not, this type has 2 constructors, one is to create zero-based array, the other one for non-zero-based array.

Type t1 = Type.GetType("System.Double[*]");
ConstructorInfo[] ctors = t1.GetConstructors();
foreach (ConstructorInfo ci in ctors)
Console.WriteLine(ci); // print "Void .ctor(Int32)" and "Void .ctor(Int32, Int32)"

Array a1 = (Array)ctors[0].Invoke(new object[] { 10 });
Console.WriteLine(a1.GetType()); // print "System.Double[]"

Array a2 = (Array)ctors[1].Invoke(new object[] { -5, 10 }); // lowerbound: -5
Console.WriteLine(a2.GetType()); // print "System.Double[*]"

Type.GetType("System.Int32[,][]") returns a jagged array, more precisely, a one-dimensional array whose elements are two-dimensional arrays, This is different from the type "int[,][]" declared in C#, which is a two-dimensional array of one-dimensional arrays. The type name grammar used in Type.GetType is more close to how IL describes such array: you can see a3's type as "int32[0...,0...][]" in ildasm.

Type t2 = Type.GetType("System.Int32[,][]");
int[][,] a3 = new int[2][,] { new int[,] { { 1, 2 } }, new int[,] { { 3, 4, 5 }, { 6, 7, 8 } } };
int[,][] a4 = new int[1, 2][] { { new int[] { 1, 2 }, new int[] { 3, 4, 5 } } };
Console.WriteLine(a3.GetType() == t2); // True
Console.WriteLine(a4.GetType() == t2); // False

.locals init (
[6] int32[0...,0...][] a3,
[7] int32[][0...,0...] a4,

Late-bound Array SetValue

Haibo_Luo — Mon, 27 Nov 2006 08:04:00 GMT

The type "System.Array" provides us a set of API for the late-bound array operations, including array creation (Array.CreateInstance), read/write access to array element (Array.SetValue/Array.GetValue). They are convenient to use. Let me start with some code to create an one-dimensional integer array, and set the first 2 elements using early-bind assignment and Array.SetValue, respectively. To simplify my code, this post will only touch the late-bound set value on array (the similar discussion can be applied to get value).

// creation: new int[5]
Array x = Array.CreateInstance(typeof(int), 5);

// 0. early-bind set: explicit cast to int[]
int[] y = (int[])x;
y[0] = 100;

// 1. late-bound set via Array.SetValue
x.SetValue(200, 1);

From the signature of Array.SetValue(object, int), we know that the integer "200" has to be boxed first before passing into this API, which is a performance hit (among others). However, we can take a look at what kind of IL sequence C# compiler generates for the early-bound assignment, and build an equivalent dynamic method to avoid the boxing: C# compiler emits Stelem.I4 to store the 32-bit integer value.

// 2. late-bound set via DynamicMethod/Delegate/OpCodes.Stelem
DynamicMethod dm = new DynamicMethod("SetValueByStelem", typeof(void),
new Type[] { typeof(Array), typeof(int), typeof(int) }, typeof(Test));
ILGenerator ilgen = dm.GetILGenerator();
ilgen.Emit(OpCodes.Ldarg_0);
ilgen.Emit(OpCodes.Castclass, x.GetType());
ilgen.Emit(OpCodes.Ldarg_1); // index
ilgen.Emit(OpCodes.Ldarg_2); // value
ilgen.Emit(OpCodes.Stelem_I4);
ilgen.Emit(OpCodes.Ret);
MySetValue sv = (MySetValue)dm.CreateDelegate(typeof(MySetValue));

sv(x, 2, 300);

delegate void MySetValue(Array array, int index, int value);

The runtime (so is System.Array) supports non-zero lowerbound array (C# does not). The code snippet below creates a length-of-5 integer array with -3 as its' lower-bound, and then tries to set value for some elements.

We can no longer cast such array to int[].
Array.SetValue works. Note we need use the lowerbound value to access the first element.
The instructions "stelem/stelem.<type>" are for one dimensional array with zero-based index only. So the dynamic method approach with stelem instruction won't work.
For each concrete array type, runtime adds three special methods: Get/Set/Address. With reflection we can hold those MethodInfo, so you can call MethodInfo.Invoke or create another dynamic method wrapper around it. This works for zero-based array too.

// creation: new int[-3..1]
Array x = Array.CreateInstance(typeof(int), new int[] { 5 }, new int[] { -3 });

// 1. late-bound set via Array.SetValue
x.SetValue(200, 1 - 3);

// 3. late-bound set via MethodInfo.Invoke of "Set"
MethodInfo mi = x.GetType().GetMethod("Set");
mi.Invoke(x, new object[] { 3 - 3, 400 });

// 4. late-bound set via DynamicMethod/Delegate/"Set"
DynamicMethod dm = new DynamicMethod("SetValueBySet", typeof(void),
new Type[] { typeof(Array), typeof(int), typeof(int) }, typeof(Test));

ILGenerator ilgen = dm.GetILGenerator();
ilgen.Emit(OpCodes.Ldarg_0);
ilgen.Emit(OpCodes.Castclass, x.GetType());
ilgen.Emit(OpCodes.Ldarg_1);
ilgen.Emit(OpCodes.Ldarg_2);
ilgen.Emit(OpCodes.Call, mi);
ilgen.Emit(OpCodes.Ret);

MySetValue sv = (MySetValue)dm.CreateDelegate(typeof(MySetValue));
sv(x, 4 - 3, 500);

Using Vance's CodeTimers class, I measured these 5 approaches' performance on my Vista machine. My scenario is to set value on 1-dimensional zero-based integer array, the action loop contains 10 lines of set-value code (those dynamic method and delegate creation are prepared ahead). The fastest late-bound set approach is DynamicMethod with Stelem, about 90-times slower than the early-bound assignment; but it is 3-times faster than Array.SetValue. Here is the raw output:

Data units of msec resolution = 0.279365 usec
Early-bound assignment : count: 1000000 4.525 +- 1% msec
Late-bound set via Array.SetValue : count: 1000000 1138.182 +- 2% msec
Late-bound set via DynamicMethod/Stelem : count: 1000000 397.005 +- 0% msec
Late-bound set via Set MethodInfo.Invoke: count: 1000000 36352.360 +- 0% msec
Late-bound set via DynamicMethod/Set : count: 1000000 453.956 +- 7% msec

What about multi-dimensional array? Array.SetValue still works; for better performance, we might want use the special "Set" method. By the way, the following ildasm output shows what C# compiler generates for "array[0, 1] = 1000;", which uses "Set". Note "int32[0..., 0...]" is TypeSpec(0x1B).

IL_0009: ldloc.0
IL_000a: ldc.i4.0
IL_000b: ldc.i4.1
IL_000c: ldc.i4 0x3e8
IL_0011: call instance void int32[0...,0...]/* 1B000003 */::Set(int32, int32, int32) /* 0A000020 */

Take Two: IL Visualizer

Haibo_Luo — Fri, 17 Nov 2006 03:55:00 GMT

I was glad to hear many positive feedbacks about the DebuggerVisualizer for DynamicMethod; on the sad side, it shows our lack of good LCG debugging support (on which, Mike Stall is seeking your opinion).

Recently along with the ILReader update, I made a few changes on the visualizer:

Add support to show IL of RuntimeMethodInfo and RuntimeConstructorInfo (besides DynamicMethod). Actually Roy already had a version providing such functionality. Last year, I wanted to enable viewing IL on all MethodBase-derived types. Well, my daily duty and interests changed; I am afraid I won't ever meet that goal.
Add support to show IL of Delegate.MethodInfo, where the delegate might be created from DynamicMethod.
Simplify IL Visualizer UI. When the DynamicMethod IL code is incomplete, those branch instructions' label shown inside the visualizer could be incorrect. However it is easy to identify this fixup failure: they always branch to the next instruction. I removed the label-fix-succeed-failed information as well as the font ComboBox at the bottom of the dialog. Now changing the font is done by the RichTextBox's context menu.
Add another way to view IL: "Send to IL Monitor". DebuggerVisualizer dialog is a modal dialog, which means we have to dismiss it first to continue anything with Visual Studio. I found this is inconvenient when trying to track the whole code-gen process. You can now choose "Send to IL Monitor". Before clicking it, a separate application "ilmonitor.exe" need to be started first. Those IL information is sent to this application with TCP socket (and the listening port number is hard-coded as 22017). For one dynamic method, if we click the magnifying glass "Send to IL Monitor" button a couple of times at different code-gen stages, the same window will show the growing IL with different background colors. As you see from the pictures below, it can also track many dynamic methods' IL.

You may download the attachment and try to build the solutions in your VS. The images below were captured in my Vista box.

Disclaimer: THE CODE IS PROVIDED "AS IS", WITH NO WARRANTIES INTENDED OR IMPLIED. USE AT YOUR OWN RISK.

update (3/7/2008): VS2008 solution can be found at http://blogs.msdn.com/haibo_luo/archive/2008/03/07/8107924.aspx.

System.Reflection-based ILReader

Haibo_Luo — Mon, 06 Nov 2006 23:02:00 GMT

Compared to what I posted previously here (or what was used in the DynamicMethod visualizer), this new version introduced the Visitor pattern.

A do-nothing visitor ILInstructionVisitor is included; the users can focus on their domain-specific logic by simply inheriting from it and overriding few methods.

public abstract class ILInstructionVisitor {
    public virtual void VisitInlineBrTargetInstruction(InlineBrTargetInstruction inlineBrTargetInstruction) { }
    public virtual void VisitInlineFieldInstruction(InlineFieldInstruction inlineFieldInstruction) { }
    ...
}

The abstract class ILInstruction now has an abstract method "Accept"; each derived ILInstruction class provides the override "Accept" method, which dispatches the call to ILInstructionVisitor's corresponding visit method. It saves a long switch statement when an ILInstruction is about to be processed.
The class ILReader has a shortcut to traverse all IL instructions: the instance method "Accept".

Class ILReader has 2 overload constructors. There are many mscorlib types derived from MethodBase (see the picture at the right side, from Reflector); only RuntimeMethodInfo or RuntimeConstructorInfo instance is supposed to pass into the first constructor. Internally it uses MethodBase.GetMethodBody and token resolution APIs from System.Reflection.Module. DynamicMethod does not provide public APIs to access the method body, nor the token resolution APIs. IILProvider and ITokenResolver are designed for easy plug-in of other IL Streams. If you are familar with the DynamicMethod visualizer source code, you already know, for tool authoring purpose, we could use Reflection to reflect some private members (which so depends on the implementation details, and could be likely broken in the future runtime version), and then come up dynamic method related classes (which implement both interfaces). We could figure out how Reflection.Emit manages those tokens at the bake time, but I have not gotten enough time on solving it.

public ILReader(MethodBase method);
public ILReader(IILProvider ilProvider, ITokenResolver tokenResolver);

Let us check out how we can build something "useful" with the ILReader. Instead of demo'ing with C# code, I'd like to write some Python code here (well, to promote IronPython ...).

The first IronPython code examines which System.String's public methods could throw ArgumentOutOfRangeException directly. For that, I can write a ILInstructionVisitor-derived class ThrowExceptionHunter, having one override method VisitInlineMethodInstruction, which checks whether the instructions's operand "Method" belongs to one of ArgumentOutOfRangeException's constructors. In order to stop hunting after hitting the ArgumentOutOfRangeException constructor, I need write a tailored loop, instead of using ILReader.Accept. From the output, we see 11 methods could throw ArgumentOutOfRangeException "directly", and they always call the constructor which requires 2 string arguments (i.e., paramName, message);

class ThrowExceptionHunter(ILInstructionVisitor):
    def __init__(self, method, exceptionType):
        self.method = method
        self.ctors = exceptionType.GetConstructors()
        self.found = False
    def VisitInlineMethodInstruction(self, instruction):
        if instruction.Method in self.ctors:
            print instruction.Method, '|', self.method
            self.found = True

clrStringType = clr.GetClrType(System.String)
exceptionType = clr.GetClrType(System.ArgumentOutOfRangeException)
for method in clrStringType.GetMethods():
    h = ThrowExceptionHunter(method, exceptionType)
    for il in ILReader(method):
        il.Accept(h)
        if h.found: break

Output:
Void .ctor(System.String, System.String) | System.String Join(System.String, System.String[], Int32, Int32)
...
Void .ctor(System.String, System.String) | System.String Remove(Int32)

Next visitor is to find callees (methods called by the current method). Early-bind method calls happen with either InlineMethodInstruction or InlineSigInstruction. Suppose you unlikely write code using "calli", only one ILInstructionVisitor method need to be overridden: to put the called method together into a python set (therefore there is no duplicate). The results shows String.StartsWith(String, StringComparison) internally used 10 different methods (including constructor call, property access).

class CalleeFinderNoDup(ILInstructionVisitor):
    def __init__(self):
        self.callees = set()
    def VisitInlineMethodInstruction(self, instruction):
        self.callees.add(instruction.Method)

method = clrStringType.GetMethod('StartsWith', System.Array[System.Type]([str, System.StringComparison]))
reader = ILReader(method)

v = CalleeFinderNoDup()
reader.Accept(v)
print 'How many:', len(v.callees)
for x in v.callees:
    print x, '/', x.DeclaringType

Output:
How many: 10
Void .ctor(System.String) / System.ArgumentNullException
...
Int32 CompareOrdinalIgnoreCaseEx(System.String, Int32, System.String, Int32, Int32) / System.Globalization.TextInfo

We can think of many scenarios related to IL code disassembly; the attached ILReader library provides 2 visitors for that purpose: ReadableILStringVisitor and RawILStringVisitor. Along the visit, we pass in IILStringCollector. ReadableILStringToTextWriter, which implements IILStringCollector, can be used to dump the readable IL string to the specified TextWriter (shown below). We can write customized ILStringCollectors to collect those IL strings in other manners.

v = ReadableILStringVisitor(ReadableILStringToTextWriter(System.Console.Out))
reader.Accept(v)

Output:
IL_0000: ldarg.1
IL_0001: brtrue.s IL_000e
IL_0003: ldstr "value"
IL_0008: newobj Void .ctor(System.String)/System.ArgumentNullException
IL_000d: throw
...
IL_00f7: call System.String GetResourceString(System.String)/System.Environment
IL_00fc: ldstr "comparisonType"
IL_0101: newobj Void .ctor(System.String, System.String)/System.ArgumentException
IL_0106: throw

By the way, you may think those method names inside the ILInstructionVisitor class are way too long - they all can simply be named "Visit". I agree, actually that was my first try; however to be dynamic language friendly, I renamed them by adding the matching instruction class name. When all methods are named "Visit", static language compiler (like C#) can still decide which method to bind based on the parameter type, while IronPython has to surrender itself to classes derived from such visitor: If we wrote one customized "Visit" method for ThrowExceptionHunter, which base "Visit" method is supposed to override? If you need to override several "Visit" methods from ILInstructionVisitor, there is no way to implement it in Python - defining any amount of "Visit" methods only keeps the last one alive.

TryILReader.py can be viewed here.

More tools (and discussion) related to this ILReader coming soon. Hope one day this could become System.Reflection.ILReader ...

Disclaimer: THE CODE IS PROVIDED "AS IS", WITH NO WARRANTIES INTENDED OR IMPLIED. USE AT YOUR OWN RISK

Member Order Returned by GetFields, GetMethods ...

Haibo_Luo — Mon, 10 Jul 2006 09:04:00 GMT

As John mentioned in his post, every Reflection user should keep this in mind: our code should not count on the member order returned by GetFields, GetMethods and other similar GetXXXs calls.

Given two fields (F1, F2) in one type, I think the compiler is free to emit F1 before F2, or vice versa. Also reflection does not guarantee to return fields in the order of how they present in the metadata; GetXXXs could be returning the members in different order at different running moments, which is illustrated by the following code. (Of course, they should have the same set of members)

using System;
using System.Reflection;

public class C {
public int F1;
public int F2;

static void Main() {
typeof(C).GetField("F2"); // Line 9

PrintFields(); // Line 11
PrintFields(); // Line 12

GC.Collect();
GC.WaitForPendingFinalizers(); // Line 15

PrintFields(); // Line 17
PrintFields(); // Line 18
}

static void PrintFields() {
foreach (FieldInfo fi in typeof(C).GetFields())
Console.Write("{0} ", fi.Name);
Console.WriteLine();
}
}

Below is mostly like what you will get when running under .NET 2.0 (50727.42). You may download the attached C# file, and get it a try. (By the way, the PE file generated by C# compiler has F1 before F2 in the metadata).

> FieldOrder.exe
F1 F2
F2 F1
F1 F2
F1 F2

Behind the scenes is reflection 2.0's MemberInfo caching mechanism. Joel Pobar’s MSDN article has a nice overview about it. Here are some basic facts before diving into each important line.

Each type has its own MemberInfo caches. Reflection creates different caches for different member types, one for each (if necessary): FieldInfo, MethodInfo, ConstructorInfo...
The caches are created and populated lazily. If ConstructorInfos are never asked, the ConstructorInfo cache will not be created. If only one method is requested for MethodInfo, only that method’s MethodInfo will be populated into the MethodInfo cache, not with all other methods.
The type keeps a weak reference to its MemberInfo caches, so, for example, when there is no reference to this type’s FieldInfos, the runtime could reclaim the memory used by the FieldInfo cache.

Line 9: we are asking for FieldInfo of "F2". At that time, the type C’s FieldInfo cache is null, Reflection will create the cache, look for the field with name "F2", create an object RuntimeFieldInfo, and put it into the cache. Imagining the cache looks like an ArrayList, the first element of the cache now contains FieldInfo "F2".

Line 11: typeof(C).GetFields() asks for type C's all fields (with default binding flags). It goes through all fields, and returns an array of FieldInfo (in order of F1/F2). Before returning this array back to the user, it updates the cache: appending "F1" after "F2" ("F2" already exists as the result of line 9). It also marks this cache "complete".

Line 12: the 2nd GetFields notices that the cache was built completely, immediately scans the cache, and returns an array of FieldInfo F2/F1 in that order.

Line 17: the 3rd GetFields occurs after GC, where the FieldInfo cache was reclaimed; GetFields has to re-create the cache. It goes through all fields again, and the cache is filled with FieldInfos in the order of F1/F2.

Line 18: same reason as the 2nd GetFields call, it returns F1/F2 quickly.

The picture at right shows the appearance/changes of the FieldInfo cache. Note the cache after line 11 has F2 in front of F1, GetFields at that line still returns F1/F2.

My Attribute Disappears

Haibo_Luo — Wed, 22 Feb 2006 02:55:00 GMT

The GetCustomAttributes scenario (ICustomAttributeProvider.GetCustomAttributes or Attribute.GetCustomAttributes, referred to as GetCA in this post) involves 3 pieces:

a custom attribute type
an entity which is decorated with the custom attribute
a code snippet calling GetCA on the decorated entity.

These pieces could be residing together in one assembly; or separately in 3 different assemblies. The following C# code shows each piece in separate files, and I will compile them into 3 assemblies: the attribute type assembly (attribute.dll), the decorated entity assembly (decorated.dll) and the querying assembly (getca.exe):

// file: attribute.cs
public class MyAttribute : System.Attribute { }

// file: decorated.cs
[My]
public class MyClass { }

// file: getca.cs
using System;
using System.Reflection;
class Demo {
static void Main(string[] args) {
Assembly asm = Assembly.LoadFrom(args[0]);
object[] attrs = asm.GetType("MyClass").GetCustomAttributes(true);
Console.WriteLine(attrs.Length);
}
}

D:\> sn.exe -k sn.key
D:\> csc /t:library /keyfile:sn.key attribute.cs
D:\> csc /t:library /r:attribute.dll decorated.cs
D:\> gacutil -i attribute.dll
D:\> del attribute.dll
D:\> csc getca.cs
D:\> getca.exe decorated.dll
1
D:\> getca.exe \\machine\d$\decorated.dll
0

attribute.dll is installed in GAC (no local copy, to avoid confusion); getca.exe checks whether the loaded type MyClass has MyAttribute. As you see from the output, MyAttribute disappeared when the decorated entity was loaded from a share (or as a partially trusted assembly, to be precise).

GetCA is supposed to return an array of attribute objects. In order to do so, it parses the custom attribute metadata, finds the right custom attribute constructor, and then invokes that .ctor with some parameters (if any). It is a late-bound call, reflection decides whether the querying assembly should invoke the attribute .ctor, or avoid calling it for security reasons.

Let me quote something from ShawnFa's security blog: "by default, strongly named, fully trusted assemblies are given an implicit LinkDemand for FullTrust on every public and protected method of every publicly visible class". This means, in a scenario where a library is strongly named and fully trusted, partial trusted assemblies are unable to call into such library.

The GetCA scenario is not exactly the same, but similar. The .ctor to be invoked is in attribute.dll (in GAC, strongly named and fully trusted). The querying assembly (runs locally, fully trusted too) is the code that makes the invocation (if that were to happen). But to make this .ctor invocation, we need pass in the parameters, which are provided by the decorated entity assembly. GetCA will take the decorated entity as the caller to the attribute type constructor. Based on what I just quoted, if the decorated entity assembly is partially trusted, we will filter out such attribute object creation, unless the attribute assembly is decorated with AllowPartiallyTrustedCallersAttribute. Note please read Shawn's blog entry carefully about this attribute and its' security implications before taking this approach.

What if the attribute and decorated entity are in the same assembly? In this case, it does not matter whether the assembly is loaded from a share or locally. GetCA will try to create and return the attribute object. If the loaded assembly is partially trusted, the runtime gives it a smaller set of permissions and running the .ctor code is not going to do something terrible.

To close, GetCA will try to create the custom attribute object if any of the following 3 conditions is true:

the decorated entity and the custom attribute type are in one assembly,
the decorated entity is fully trusted,
the assembly which defines the custom attribute type is decorated with APTCA.

By the way, the new class CustomAttributeData in .NET 2.0 is designed to access custom attribute in the reflection-only context, where no code will be executed (only metadata checking). If we use CustomAttributeData.GetCustomAttributes instead in the above example, it prints 1; one CustomAttributeData object, not one MyAttribute object.

Type.FullName returns null when ...

Haibo_Luo — Sat, 18 Feb 2006 02:22:00 GMT

Type.FullName returns null when the type is not generic type definition but contains generic paramters.

The rational behind this design is to ensure Type.FullName (if not null) can uniquely identify a type in an assembly; or given the string returned by Type.FullName, Type.GetType(string typeName) can return the original type back. It is hard to keep this invariant if
!type.IsGenericTypeDefinition && type.ContainsGenericParameters.

For instance, suppose we have an assembly compiled with the following C# code:

class G<T> {
public void M<S>() { }
}

typeof(G<>).FullName is "G`1", and we can round trip this type from Type.GetType("G`1"). But we can build more complicated generic types, such as G<S> (type G<> bound with the generic parameter from the method M<>); in order to identify such type with a string, a lot of extra information is need.

Below are some examples where Type.FullName returns null.

class G<T> {
public class C { }
public void M(C arg) { }
}
class G2<T> : G<T> { }

string s1 = typeof(G<>).GetGenericArguments()[0].FullName;
// T in G<T>: generic parameter
string s2 = typeof(G<>).GetMethod("M").GetParameters()[0].ParameterType.FullName;
// check out the IL, it is G`1/C<!T> (not generic type definition)
// Related topic, see this
string s3 = typeof(G2<>).BaseType.FullName;
// base type of G2<>, which is not generic type definition either
// it equals to typeof(G<>).MakeGenericType(typeof(G2<>).GetGenericArguments()[0])

Use IronPython to Experiment .NET Libraries

Haibo_Luo — Thu, 19 Jan 2006 02:43:00 GMT

When working on .NET projects, we often need to find the right API or the proper parameters to pass in to a particular method. Usually we search MSDN or turn to other search engines to solve such issue. Some people, however, prefer first-hand experience over search; they perfer experimenting or playing with a small piece of C# or VB.Net code. These people probably should consider using IronPython, which I found can save a lot of edit-save-compile-run cycles.

For example, suppose I want to make sure I understand the functionality of Path.GetTempFileName and Path.GetRandomName before using either API in my code. This is how I would do in IronPython:

D:\IronPython > IronPythonConsole.exe
>>> import System
>>> from System.IO import *
>>> Path.GetTempFileName()
'C:\\Documents and Settings\\username\\Local Settings\\Temp\\tmpEE7.tmp'
>>> Path.GetRandomFileName()
'fbrhamew.f13'

We see the instant functionality result with 4 lines of python code. No Ctrl+S, No csc.exe or vbc.exe... Another example: the tricky method String.Format(string, object). Sometimes we need to tweak the formatting string, rebuild the entire solution several times to get the expected string. Let us try to format a long number to 8-char hex. After trying a few different things based on my vague memory, finally I get what I want.

>>> from System import *
>>> String.Format("{0,8:X}", 12345678)
' BC614E'
>>> String.Format("{0,X8}", 12345678)
Traceback (most recent call last):
File , line 0, in input##37
File , line 0, in Format
File , line 0, in AppendFormat
File , line 0, in FormatError
SystemError: Input string was not in a correct format.
>>> String.Format("{0:X8}", 12345678)
'00BC614E'

Don't like typing? IronPythonConsole keeps the history, so we can use up/down key to get our previous codes back, and then do a little more editing. Or we can save the method object first, and easily have more String.Format fun (yeah...next time you want to play with code snippets when reading blogs, try doing so with IronPython...)

>>> f = String.Format
>>> f("{0:X8}", 12345678)
'00BC614E'
>>> f("{{0:X8}}", 12345678)
'{0:X8}'
>>> f("{{{0:X8}}}", 12345678)
'{X8}'

Just another FYI: 1.0 Beta1 also shipped a winform version console: IronPythonWindowConsole.exe, which provides similar typing experience like VS IDE intellisense.

Let me finish this post with an experiment with System.Reflection.BindingFlags (seems this is really confusing). I will try with the type of System.Random; Reflector shows this type as follows (I will only focus on these 8 methods):

[Serializable, ComVisible(true)]
public class Random
{
      // Methods
      public Random();
      public Random(int Seed);
      private double GetSampleForLargeRange();
      private int InternalSample();
      public virtual int Next();
      public virtual int Next(int maxValue);
      public virtual int Next(int minValue, int maxValue);
      public virtual void NextBytes(byte[] buffer);
      public virtual double NextDouble();
      protected virtual double Sample();

      // Fields
      ......
}

>>> import System
>>> from System import *
>>> from System.Reflection import *
>>> r = Random()
>>> t = r.GetType()
>>> gm = t.GetMethods
>>> gm()
System.Reflection.MethodInfo[](Int32 Next(), Int32 Next(Int32, Int32), Int32 Next(Int32), Double NextDouble(), Void NextBytes(Byte[]), System.Type GetType(), System.String ToString(), Boolean Equals(System.Object), Int32 GetHashCode())
>>> _.Length
9
It also includes 4 public methods defined in System.Object; and no private/protected methods
>>> bf = BindingFlags
>>> gm(bf.Public)
System.Reflection.MethodInfo[]()
Nothing returned if only specifying Public, need another flag?
>>> gm(bf.Public | bf.Static)
System.Reflection.MethodInfo[]()
This can not tell much, since Random does not have static methods.
>>> gm(bf.Public | bf.Instance)
System.Reflection.MethodInfo[](Int32 Next(), Int32 Next(Int32, Int32), Int32 Next(Int32), Double NextDouble(), Void NextBytes(Byte[]), System.Type GetType(), System.String ToString(), Boolean Equals(System.Object), Int32 GetHashCode())
Looks same as gm() returned? Actually gm() returns static methods too, but for this example, Random does not have any.
>>> gm(bf.Public | bf.Instance | bf.DeclaredOnly)
System.Reflection.MethodInfo[](Int32 Next(), Int32 Next(Int32, Int32), Int32 Next(Int32), Double NextDouble(), Void NextBytes(Byte[]))
DeclaredOnly will not return the 4 methods defined in System.Object
>>> gm(bf.NonPublic | bf.Instance)
System.Reflection.MethodInfo[](Double Sample(), Int32 InternalSample(), Double GetSampleForLargeRange(), System.Object MemberwiseClone(), Void Finalize())
>>> _.Length
5
Get back protected method Sample() here, and another 2 private methods defined in Sample; also 2 methods from System.Object
>>> gm(bf.Public | bf.NonPublic | bf.Instance)
System.Reflection.MethodInfo[](Double Sample(), Int32 InternalSample(), Int32 Next(), Double GetSampleForLargeRange(), Int32 Next(Int32, Int32), Int32 Next(Int32), Double NextDouble(), Void NextBytes(Byte[]), System.Type GetType(), System.Object MemberwiseClone(), System.String ToString(), Boolean Equals(System.Object), Int32 GetHashCode(), Void Finalize())
>>> _.Length
14
We got back all 14(5+9) instance methods from type Object and Random, public, protected or private
>>> ...

Activator.CreateInstance and beyond

Haibo_Luo — Thu, 17 Nov 2005 21:55:00 GMT

Q: Assume we have 2000 unknown types; (however) we know each type has a constructor with integer as its' only parameter type. How to create objects 10000 times for each type (and make such late-new fast)?

Activator.CreateInstance comes to my fingers first. It is just so convenient to use: calling Activator.CreateInstance(type, new object[] {100}) in a loop. Done... I already heard somebody is yelling "this API is slow" ;) Yeah, each time it need figure out the right ConstructorInfo (by calling GetConstructors to get all ctors, parsing the constructor method signature/comparing, and binding to the most matched one). If you happen to have Visual Studio Team System installed, you can use this code to do a sample profiling and see what is going on there.

Activator.CreateInstance(type, 100);

Reflection Emit can optimize this scenario a bit: we create an in-memory module and a helper class "ClassFactory", then define one helper method for each type with the early-bind call (strong typed new, see OpCodes.Newobj below); the emitted method is equivalent to "public static Type TypeName(int arg1){ return new Type(arg1); }" in C#.

AssemblyBuilder asmBldr = AppDomain.CurrentDomain.DefineDynamicAssembly(new AssemblyName("InMemory"), AssemblyBuilderAccess.Run);
ModuleBuilder modBldr = asmBldr.DefineDynamicModule("helper");
TypeBuilder typeBldr = modBldr.DefineType("ClassFactory");

MethodBuilder methBldr = typeBldr.DefineMethod(type.Name, MethodAttributes.Public | MethodAttributes.Static, type, new Type[] { typeof(int) });
ILGenerator ilgen = methBldr.GetILGenerator();
ilgen.Emit(OpCodes.Nop);
ilgen.Emit(OpCodes.Ldarg_1);
ilgen.Emit(OpCodes.Newobj, type.GetConstructor(new Type[] { typeof(int) }));
ilgen.Emit(OpCodes.Ret);

Type baked = typeBldr.CreateType();

MethodInfo mi = baked.GetMethod(type.Name);

mi.Invoke(null, new object[] { 100 });

The code in italic need be put in a loop to repeat on 2000 types. We cache the MethodInfo (after baked) to a Dictionary<Type, MethodInfo> so that we can quickly retrieve the MethodInfo for massive consequent Invoke calls.

With DynamicMethod in CLR 2.0, we can avoid that lengthy preparation and bake steps (yes, light-weight codegen). For each type, simply create one dynamic method with the early-bind newobj, and cache it for future use.

DynamicMethod dm = new DynamicMethod("MyCtor", type, new Type[] { typeof(int) }, typeof(LateNew).Module);
ILGenerator ilgen = dm.GetILGenerator();
ilgen.Emit(OpCodes.Ldarg_1);
ilgen.Emit(OpCodes.Newobj, type.GetConstructor(new Type[] { typeof(int) }));
ilgen.Emit(OpCodes.Ret);

dm.Invoke(null, new object[] { 100 });

Do not forget ConstructorInfo.Invoke. This approach caches the RuntimeConstructorInfo of the exact constructor which we can then invoke on directly; on the other hand, previous Emit/DynamicMethod approaches seemly add one more layer late-invocation.

ConstructorInfo ci = t.GetConstructor(new Type[] { typeof(int) });

ci.Invoke(new object[] { 100 });

If you subsribe Joel Pobar's blog , you may already notice "delegate call in whidbey is close to callvirt in term of performance". Instead of caching the baked MethodInfo (or DynamicMethod), we should spend a bit more time on the preparation stage: to create the delegate (function pointer) for those on-the-fly methods and cache them . Assume I already defined such helper delegate type as follows:

public delegate object CtorInt32Delegate(int arg);

Let's call next approach as Reflection.Emit+Delegate, we can leverage those codes for the Reflection Emit approach above, and add one line of code to create the delegate:

...
Type baked = typeBldr.CreateType();
MethodInfo mi = baked.GetMethod(type.Name);

CtorInt32Delegate d = (CtorInt32Delegate)Delegate.CreateDelegate(typeof(CtorInt32Delegate), mi);

d(100); // C# syntax shortcut to d.Invoke(100);

We do the similar thing for the DynamicMethod + Delegate approach :

DynamicMethod dm = new DynamicMethod("MyCtor", type, new Type[] { typeof(int) }, typeof(LateNew).Module);
// get ILGenerator, and Emit call squences

CtorInt32Delegate d = (CtorInt32Delegate)dm.CreateDelegate(typeof(CtorInt32Delegate));

d(100);

The following table lists the result of these 6 approaches (no doubt there are other good solutions to the original question) when running the test code at my machine: the 2nd column shows the preparation time (code in the first box of each pair); the 3rd column is the object creation time cost (the second box). Among them, the last 2 approaches show the best performance. If you are wondering the early-bind cost for the same task, it is roughly 1 second at my machine.

Approach	Preparation Time(sec)	Object Creation Time (sec)
Activator.CreateInstance	--	00:09:28.4796646
Reflection.Emit	00:00:01.5781553	00:02:28.7684813
DynamicMethod.Invoke	00:00:00.0781265	00:02:04.3930133
ConstructorInfo.Invoke	00:00:00.0468759	00:00:56.0167005
Reflection.Emit+Delegate	00:00:01.4218750	00:00:04.2968750
DynamicMethod+Delegate	00:00:00.1093771	00:00:05.7031250

What if the constructor is parameterless? Here is the result (side by side with previous scenario, the object creation cost listed):

Approach	Parameterless	Parameter
Activator.CreateInstance	00:00:54.1729151	00:09:28.4796646
Reflection.Emit	00:02:10.3775032	00:02:28.7684813
DynamicMethod.Invoke	00:01:37.6581250	00:02:04.3930133
ConstructorInfo.Invoke	00:00:44.1883484	00:00:56.0167005
Reflection.Emit+Delegate	00:00:04.3125000	00:00:04.2968750
DynamicMethod+Delegate	00:00:05.5313562	00:00:05.7031250

We noticed:

Activator.CreateInstance approach is actually not that bad here: this API has different path to handle parameterless scenarios.
No significant differences between these 2 scenarios for other 5 approaches.

Furthermore, if only less than 16 types are frequently used, Activator.CreateInstance is "fast" API: internally it creates some sort of delegate directly on the type's parameterless constructor (no dynamic generated methods involved), and cache them. However, the cache size is 16, and 'Least Recently Used'-like cache algorithm is applied. The table below shows the time cost for creating objects of 16 or 17 different types sequentially 2000000 times.

# types used	Call Activator.CreateInstance(Type type)	Reflection.Emit+Delegate
16	00:00:10.8439582	00:00:01.5156541 + 00:00:04.2344563
17	00:01:27.6110571	00:00:01.5312794 + 00:00:04.4844611

Read IL from MethodBody

Haibo_Luo — Tue, 04 Oct 2005 21:40:00 GMT

Reflection in .NET 2.0 ships with a new class MethodBody, which "provides access to information about the local variables and exception-handling clauses in a method body, and to the Microsoft intermediate language (MSIL) that makes up the method body". (Thanks to Glenn, who wrote this in the MSDN doc; I simply copy & paste it). The only one method inside this class (others are properties) is:

public byte[] GetILAsByteArray()

which returns us a byte array containing IL content for this method body.

Recently we got some questions related to reflecting IL stream: users want to check where a specific method was used; or try to build a call graph inside an assembly;... Reflection currently does not support this directly. Lutz Roeder's awesome tool - .NET Reflector can indeed show the call/callee graph for each method. I used to have the source code for his ILReader, and noticed it did not use Reflection APIs (so for sure we can read IL without reflection APIs)

A code sketch below shows how we can use classes in the Reflection/Emit namespace (and other useful APIs provided in .NET 2.0) to read IL instructions. Standard ECMA-335 is the authoritative resource to understand IL, MethodBody format and other CLI topics if you want to know more of them.

public class ILReader : IEnumerable<ILInstruction>
{
   Byte[] m_byteArray;
   Int32 m_position;
   MethodBase m_enclosingMethod;

   static OpCode[] s_OneByteOpCodes = new OpCode[0x100];
   static OpCode[] s_TwoByteOpCodes = new OpCode[0x100];
   static ILReader()
   {
   foreach (FieldInfo fi in typeof(OpCodes).GetFields(BindingFlags.Public | BindingFlags.Static))
   {
   OpCode opCode = (OpCode)fi.GetValue(null);
   UInt16 value = (UInt16)opCode.Value;
if (value < 0x100)
   s_OneByteOpCodes[value] = opCode;
   else if ((value & 0xff00) == 0xfe00)
   s_TwoByteOpCodes[value & 0xff] = opCode;
   }
   }

   public ILReader(MethodBase enclosingMethod)
   {
   this.m_enclosingMethod = enclosingMethod;
   MethodBody methodBody = m_enclosingMethod.GetMethodBody();
   this.m_byteArray = (methodBody == null) ? new Byte[0] : methodBody.GetILAsByteArray();
   this.m_position = 0;
   }

   public IEnumerator<ILInstruction>GetEnumerator()
   {
   while (m_position < m_byteArray.Length)
   yield return Next();

   m_position = 0;
   yield break;
   }
   System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator() { return this.GetEnumerator(); }

   ILInstruction Next()
   {
   Int32 offset = m_position;
   OpCode opCode = OpCodes.Nop;
   Int32 token = 0;

   // read first 1 or 2 bytes as opCode
   Byte code = ReadByte();
   if (code != 0xFE)
   opCode = s_OneByteOpCodes[code];
   else
   {
   code = ReadByte();
   opCode = s_TwoByteOpCodes[code];
   }

   switch (opCode.OperandType)
   {
   case OperandType.InlineNone:
   return new InlineNoneInstruction(m_enclosingMethod, offset, opCode);

   case OperandType.ShortInlineBrTarget:
   SByte shortDelta = ReadSByte();
   return new ShortInlineBrTargetInstruction(m_enclosingMethod, offset, opCode, shortDelta);

   case OperandType.InlineBrTarget: Int32 delta = ReadInt32(); return new ...;
   case OperandType.ShortInlineI: Byte int8 = ReadByte();    return new ...;
   case OperandType.InlineI:    Int32 int32 = ReadInt32(); return new ...;
   case OperandType.InlineI8: Int64 int64 = ReadInt64(); return new ...;
   case OperandType.ShortInlineR: Single float32 = ReadSingle(); return new ...;
   case OperandType.InlineR:    Double float64 = ReadDouble(); return new ...;
   case OperandType.ShortInlineVar: Byte index8 = ReadByte();    return new ...;
   case OperandType.InlineVar:    UInt16 index16 = ReadUInt16(); return new ...;
   case OperandType.InlineString: token = ReadInt32(); return new ...;
   case OperandType.InlineSig:    token = ReadInt32(); return new ...;
   case OperandType.InlineField:    token = ReadInt32(); return new ...;
   case OperandType.InlineType: token = ReadInt32(); return new ...;
   case OperandType.InlineTok:    token = ReadInt32(); return new ...;

   case OperandType.InlineMethod:
   token = ReadInt32();
   return new InlineMethodInstruction(m_enclosingMethod, offset, opCode, token);

   case OperandType.InlineSwitch:
   Int32 cases = ReadInt32();
   Int32[] deltas = new Int32[cases];
   for (Int32 i = 0; i < cases; i++) deltas[i] = ReadInt32();
   return new InlineSwitchInstruction(m_enclosingMethod, offset, opCode, deltas);

   default:
   throw new BadImageFormatException("unexpected OperandType " + opCode.OperandType);
   }
   }

   Byte ReadByte() { return (Byte)m_byteArray[m_position++]; }
   SByte ReadSByte() { return (SByte)ReadByte(); }

   UInt16 ReadUInt16() { m_position += 2; return BitConverter.ToUInt16(m_byteArray, m_position - 2); }
   UInt32 ReadUInt32() { m_position += 4; return BitConverter.ToUInt32(m_byteArray, m_position - 4); }
   UInt64 ReadUInt64() { m_position += 8; return BitConverter.ToUInt64(m_byteArray, m_position - 8); }

   Int32 ReadInt32() { m_position += 4; return BitConverter.ToInt32(m_byteArray, m_position - 4); }
   Int64 ReadInt64() { m_position += 8; return BitConverter.ToInt64(m_byteArray, m_position - 8); }

   Single ReadSingle() { m_position += 4; return BitConverter.ToSingle(m_byteArray, m_position - 4); }
   Double ReadDouble() { m_position += 8; return BitConverter.ToDouble(m_byteArray, m_position - 8); }
}

Few comments here:

Definitions for ILInstruction and others derived XXXInstructions are not included here. Imagine ILInstruction (need) knows Offset, OpCode, ...; and the derived ILInstructions may contain other information. If only OpCode.Call or OpCode.CallVirt (which belong to OperandType.InlineMethod case) was interesting to me, I'd like to define special CallInstruction or CallVirtInstruction class, and create them explicitly. Module.ResolveMethod can then help to get MethodBase from the operand (token). Yiru's blog has some posts related to this topic.
The static constructor of ILReader uses Reflection to initialize 2 static OpCode arrays from the enum type OpCodes. As I mentioned here, we may use Enum.GetValues to achieve this too.
The public constructor accepts a MethodInfo, gets its MethodBody, and then calls GetILAsByteArray() to set m_byteArray. Note calling GetMethodBody on the interface method and others could return null.
The Next() method takes advantage of OpCode.OperandType to decide what kind of operand is expected, how many bytes should be read.
BitConverter.ToXXX can read a number of bytes and convert them to primitive values in-place. Very handy!

Then I can consume the ILInstruction sequence in C# as follows:

foreach (ILInstruction il in new ILReader(method)) { /* do something with il */ }

Nested Types in Generic Classes

Haibo_Luo — Wed, 28 Sep 2005 21:22:00 GMT

In C#, nested types can be defined in generic classes just like they would be in non-generic classes. For example:

class G<T> {
public class NestedC { }
public enum NestedEnum { A, B }
}

Inside the nested type NestedC, we can still use type parameter T, which was "declared" with class G<T>. Actually this is a misconception (the C# compiler does some magic behind the scenes). If we were to use ildasm to view the node of NestedC, we would find "NestedC" is a generic type with type parameter "T". As far as the runtime is concerned, this "T" is not the same as the "T" with G<T>; they just happen to have the same name.

.class private auto ansi beforefieldinit G`1<T>
extends [mscorlib]System.Object
{
.class auto ansi nested public beforefieldinit NestedC<T>
extends [mscorlib]System.Object
{ ...

When we use T inside NestedC, we are in fact referring to NestedC's own T, the type parameter "T" declared with NestedC<T>. With that in mind, let us think about what the following code will print:

class Test {
static void Main() {
Type type1 = typeof(G<int>.NestedC);
Console.WriteLine(type1);
Console.WriteLine(type1.IsGenericTypeDefinition);

Type type2 = typeof(G<int>).GetNestedType("NestedC");
Console.WriteLine(type2);
Console.WriteLine(type2.IsGenericTypeDefinition);
}
}

1. typeof(G<int>.NestedC) is translated by C# compiler to

IL_0001: ldtoken class G`1/NestedC<int32>
IL_0006: call class [mscorlib]System.Type [mscorlib]System.Type::GetTypeFromHandle(valuetype [mscorlib]System.RuntimeTypeHandle)

The generic argument "int32" is bound to NestedC<>, not G<>;

2. You might already have noticed that although both are generic types, "NestedC" does not have `(grave accent), but "G`1" does. So typeof(G<int>).GetNestedType("NestedC") will get back the open generic type "NestedC<>".

Here is the result, is it as you expected?

   G`1+NestedC[System.Int32]
   False
   G`1+NestedC[T]
   True

In summary, when written in C#, every type defined under a generic type will be a generic type (including enum; C# does not allow us to explicitly define a generic enum). To define a truly non-generic nested type inside a generic type, IL can help:

.class private auto ansi beforefieldinit G`1<T>
extends [mscorlib]System.Object
{
.class auto ansi nested public beforefieldinit NestedNonGenericC
extends [mscorlib]System.Object
{ ...

No LocalVariableInfo.Name?

Haibo_Luo — Sat, 03 Sep 2005 05:35:00 GMT

This was one ladybug in MSDN product feedback center. First of all, thanks to those who filed bugs or suggestions through it, which really help improve our product quality.

No Name property in the LocalVariableInfo class is "by design" (possibly forever). Inside a .Net assembly, there is no metadata (or table) keeping this information. However, sometimes when using ildasm to view the method, we do see those local variable names, such as

.locals init ([0] int32 m_int32,
[1] object m_object,
[2] int32[] m_array,
[3] int32[] CS$0$0000)

Those names are from the pdb file, not embedded in the exe or dll. If we move the pdb to other directory, and open the ildasm again, we will see those variable names become to V_0, V_1...

.locals init (int32 V_0,
object V_1,
int32[] V_2,
int32[] V_3)

If you *really* need those names in your managed application, you may want to take a look at Mdbg source codes; but here are the general steps to get it:

Get IMetaDataImport, say import (I found examples here or here);
Call Marshal.GetComInterfaceForObject(import, typeof(IMetaDataImport)) to get the raw interface IntPtr;
Call new SymBinder().GetReader() with that IntPtr to get ISymbolReader
Call ISymbolReader.GetMethod() on the SymbolToken, which is constructed based on the MetadataToken of the method you want to get local variable names, and get back ISymMethod
Then play with ISymMethod.RootScope, ISymbolScope.GetChildren(), ISymbolScope.GetLocals();

Yes, there is ISymbolVariable.Name.

Get Names and Values of Enum Members

Haibo_Luo — Sun, 28 Aug 2005 21:00:00 GMT

Yes, reflection can get this done. Assume we have an Enum type - Colors, the following code will print the name and value for each member of it.

foreach (FieldInfo fi in typeof(Colors).GetFields(BindingFlags.Public | BindingFlags.Static))
{
Console.WriteLine(fi.Name);
Console.WriteLine(fi.GetValue(null));
}

Note we need to specify BindingFlags.Static explicitly here; Otherwise, both static and instance fields will get returned, including the special instance field "value__".

In fact, BCL provides more neat (and maybe faster) APIs to achieve this:

string[] names = Enum.GetNames(typeof(Colors));
Colors[] values = (Colors[])Enum.GetValues(typeof(Colors));

If the enum type we are exploring is loaded in the ReflectionOnly context, calling FieldInfo.GetValue will throw "InvalidOperationException: Code execution is prohibited in an assembly loaded as ReflectionOnly", since GetValue tries to create an object of the enum type and return it. Same for Enum.GetValues.

The new API in FieldInfo:

public virtual object GetRawConstantValue();

could be what you need in such scenarios. It will return the value of enum's underlying integer type. For example, if the underlying type of enum "Colors" is byte, fi.GetRawConstandValue() will return a boxed byte.

Reflection and Nullable

Haibo_Luo — Tue, 23 Aug 2005 10:25:00 GMT

You might have already read this: VS2005 made the last-minute DCR related to boxed Nullable<T>. Runtime now treats Nullable<T> differently from other generic value types when boxing:

Int32? x = null;
object y = x;
// y is simply null, not a truly boxed "nullable<int> struct" (which then tells it has no value)

And

Int32 ? x = 100;
object y = x;
// y is boxed Int32 100 (same as "object y = 100"), no longer a boxed "nullable<int> struct" with a field of value 100.

Reflection late-bind invocation always deals with "object"; value type instances are always getting boxed first before invocation. One of such APIs: PropertyInfo.SetValue(Object obj, Object value, Object[] index). There was one question in Microsoft Technical Forums: Exception is thrown when setting DateTime value to a property with type Nullable<DateTime>. With this DCR change, such late-bind calls can be written in a more natural way.

class C
{
   Int32? m_field;
   public Int32? Property
   {
get { return m_field; }
set { m_field = value; }
   }
}

PropertyInfo pi = typeof(C).GetProperty("Property");
C c = new C();
pi.SetValue(c, 100, null);         // works
pi.SetValue(c, (Int32?)100, null); // no longer have to write like this

After boxing, 100 and (Int32?)100 are the same thing: boxed Int32 object. There is no more boxed object with type "Int32?"; late-invocation has to accept it and set to Int32? property. Or think it this way, runtime can not tell where a boxed Int32 object was originally from: either just Int32 instance or Int32? instance; it is reasonable to allow setting a boxed Int32 object to field/property of either Int32 or Int32? type (same for argument pass-in when doing method invocation)

pi.SetValue(c, null, null); // works

This actually worked before the DCR. And ,

Object ret = pi.GetValue(c, null);

ret will be either boxed Int32 object or simply null. There is no problem in casting the result to Int32? type.

Here are some reflection behavior changes as a result of this DCR:

Probably the most important one is "typeof(T?).IsAssignableFrom(typeof(T)) == true". PropertyInfo.SetValue/GetValue use this first to ensure the pass-in value is assignable to Nullable<T> property.
Object.GetType() will never get back any type of Nullable<T>. Joe had an interesting post on this.
Activator.CreateInstance could never be expected to return null before; with this DCR, it will return null when creating instance of type Nullable<T> but not providing non-null T value. For example, Activator.CreateInstance(typeof(Int32?)) returns null.