What’s new in System.Reflection (and friends)


Figured I’d take the opportunity to capitalize on the increased link traffic Brad sent my way, by giving a quick and dirty overview of “What’s new in Reflection”. Illustrated are features I believe are worth their weight in gold – it’s a subset of the overall change list. I wrote some of this a little while back to be included in the Whidbey docs, not sure if they’ve made it there yet. As always, things can and normally do change, and taking dependencies on Beta bits is generally a “bad thing(tm)”. Nevertheless, here goes:


 


Lightweight code gen (LCG)


 


LCG is probably one of the most interesting features in the late-bound space. I’ve spoken briefly about it here and here. Provides enhanced runtime code generation facilities for emitting static methods at runtime. Less overhead (no need to generate assemblies, modules and types at runtime). GC collection of generated methods which means better resource utilization in long running applications. LCG also has the ability to skip JIT-time visibility checks.


 


ReflectionOnly context


 


A new feature in Whidbey that allows the user to load an assembly in the “ReflectionOnly” loader context, where no code will be executed. This allows for some loader restrictions to be relaxed, such as the applying of policy. It also allows for reflection over architecture specific assemblies (Reflection over 64bit generated assemblies from a 32bit environment). A example subset of the API:


 


Assembly asm = Assembly.ReflectionOnlyLoad(“assembly.dll”);


// …


Type t = Type.ReflectionOnlyGetType(“MyType”, false, false);


 


Reflection over MethodBody


 


This new Whidbey feature allows a user to reflect over a given methods IL stream, its locals, and its exceptions. This is a preliminary API for the power users of reflection. It basically gives the user the ability to parse an IL byte stream. A user is able to reflect on underlying method metadata, and make rational decisions about methods based on their functionality, code paths, exception handling and usage. It also allows a user to realize more than just the method contract and signature. An example subset of the API:


 


MethodInfo mi = typeof(Foo).GetMethod(“Bar”);


MethodBody mb = mi.GetMethodBody();


 


Console.WriteLine(“MaxStackSize: ” + mb.MaxStackSize);


Console.WriteLine(“Local Signature metadata token: ” + mb.LocalSignatureMetadataToken);


Console.WriteLine(“Byte array length: ” + mb.GetILAsByteArray().Length);


Console.WriteLine(“Byte array: ” + System.Text.Encoding.ASCII.GetString(mb.GetILAsByteArray()));


// …


 


Token Handle Resolution API’s


 


My favorite. We’ve got some work to do here, but more on that later. New API’s added to move from Info to metadata token and RuntimeHandle. New API’s added to move from metadata token to RuntimeHandle. User is able to burn in type identity using the Module and metadata token. This has some fairly complex performance and working set benefits that I hope to blog about some other day. There’s also the general sense of a better late-bound experience with runtime identity. Also has some interesting “if you were to build a compiler” implications. Example subset of the API:


 


int fooToken = typeof(Foo).MetadataToken;


RuntimeTypeHandle typeHandle = typeof(Foo).Module.ModuleHandle.ResolveTypeHandle(fooToken);


// …


 


Reflection and Reflection.Emit support for Generic types


 


I think this has been well blogged about. We support full reflection and code generation on and of generics types. Various API’s have been added to the XXXInfo range of API’s, along with added Reflection.Emit API’s. I don’t believe the latest community drop supports full Reflection.Emit generics support, but expect that for Beta 2.


 


Improved Reflection support for Custom Attributes


 


We can now return a class that has information about a custom attribute, but yet does not execute its constructor! This is part of the whole “ReflectionOnly” story, and generally gives some important semantic benefits.


 


Improved Performance


 


Touchy subject. I’ll move on before I get in trouble… 😉


 


 


Writing a tool (using Reflection of course) to do a diff over Everett vs Whidbey API’s is generally how I work out what we’ve added in other namespaces. It’s pretty simple to do, so I’ll leave it as an exercise to the reader.


 


Enjoy.


Comments (43)

  1. Wesner Moise says:

    Could you comment on the new Introspection engine, that FXCop uses, and whether it is available in Whidbey? I refer you to this link http://wesnerm.blogs.com/net_undocumented/2004/05/introspection.html.

  2. Joel Pobar says:

    I don’t know all that much about the FxCop "introspection" engine, however I know that it is designed to serve FxCop’s static analysis scenario. This is somewhat different to where Reflection currently is, a runtime datastructure and metadata abstraction, which adheres to the rules of the runtime. Just think Reflection over virtual members for a good sense of what I mean.

    Having said that, we have put thought into a managed metadata API. I’d be interested in feedback from the community about how compelling a feature like that would be.

  3. Jim Arnold says:

    Awesome. I am very happy.

    Jim

  4. Eric Wilson says:

    Why is the performance information a touchy subject? Is it really getting better?

  5. Doug McClean says:

    Regarding Token handle resolution APIs, I don’t quite know what that means, but I have a guess (and a suggestion that if this isn’t what this does, should be done somewhere else).

    Will this allow me to take the Method{Def/Ref}Token I can get by reading the byte[] from a MethodBody and convert it into a RuntimeMethodHandle and from there into a MethodInfo to disassemble Call and CallVirt opcodes?

  6. Kevin Downs says:

    Sounds Wonderful!

    A few questions:

    1. Does the ‘reflection-only’ context have a mechanism which allows assemblies to be unloaded? I appreciate the rational for not allowing unloading in normal contexts, but it would be *really* useful here – even if it only flushed the entire context, rather than individual assemblies

    2. Is it possible to reflect over an assembly that has a StrongNameIdentityPermissionAttribute?

    3. Is it possible to load an assembly from a network share?

    4. Is it possible to reflect over CF assemblies?

  7. Addy Santo says:

    A missing link in the code. You write:

    Assembly asm = Assembly.ReflectionOnlyLoad("assembly.dll");

    // …

    Type t = Type.ReflectionOnlyGetType("MyType", false, false);

    what exactly needs to come in the middle in order for someone to know that a type called "MyType" exists in the assembly? The only way I knew was asm.GetTypes() but that defeats the whole purpose of ReflectionOnly….

  8. Yes, reflection can get this done. Assume we have an Enum type – Colors, the following code will print…

  9. I saw Joel’s blog about new stuff in Reflection and he mentioned ReflectionOnly context. Apart from the…

  10. I saw Joel’s blog about new stuff in Reflection and he mentioned ReflectionOnly context. Apart from the…

  11. I was reading Joel’s blog about new stuff in Reflection and he mentioned ReflectionOnly context….

  12. I was reading Joel’s blog about new stuff in Reflection and he mentioned ReflectionOnly context….

  13. I was reading Joel’s blog about new stuff in Reflection and he mentioned ReflectionOnly context….

  14. I was reading Joel’s blog about new stuff in Reflection and he mentioned ReflectionOnly context….

  15. I was reading Joel’s blog about new stuff in Reflection and he mentioned ReflectionOnly context….

  16. I was reading Joel’s blog about new stuff in Reflection and he mentioned ReflectionOnly context….

  17. I was reading Joel’s blog about new stuff in Reflection and he mentioned ReflectionOnly context….

  18. I was reading Joel’s blog about new stuff in Reflection and he mentioned ReflectionOnly context….

  19. I was reading Joel’s blog about new stuff in Reflection and he mentioned ReflectionOnly context….

  20. I was reading Joel’s blog about new stuff in Reflection and he mentioned ReflectionOnly context….

  21. I was reading Joel’s blog about new stuff in Reflection and he mentioned ReflectionOnly context….

  22. I was reading Joel’s blog about new stuff in Reflection and he mentioned ReflectionOnly context….

  23. I was reading Joel’s blog about new stuff in Reflection and he mentioned ReflectionOnly context….

  24. I was reading Joel’s blog about new stuff in Reflection and he mentioned ReflectionOnly context….

  25. My upcoming Tech-Ed Talk in Israel will be all about what’s new and Cool in .NET 2.0 Reflection. Over…

  26. The following links to .NET resources have been collated over time with the assistance of colleagues. …

  27. Here’s the next .NET Framework 2.0 performance guideline in the series from Prashant Bansode, Bhavin