Stuff in Reflection that’s not in Metadata

Previously, I mentioned some things in Metadata that aren’t exposed in Reflection.  Here’s an opposite case. While metadata represents static bits on disk, Reflection operates in a live process with access to the CLR’s loader. So reflection can represent things the CLR loader and type system may do that aren’t captured in the metadata.  …


Codegen for On Error Resume Next

VB has a “On Error Resume Next”, which tells each line to swallow exceptions and just keep executing to the next line. It’s kind of like a try-catch around every single line. It may be tempting for C++ developers to make fun of VB for this, but this is a lot like programming with HRESULT…

3

Things in Metadata that are missing in Reflection

System.Reflection is a high-level way of describing Types in .NET targetted at managed code consumers. The API is easy to use, but does not expose all the information that’s actually present and affecting decisions. For example, Reflection does not expose TypeRef, MemberRef, AssemblyRef, or other Ref tokens.  These tokens are references to things in other…

1

Return vs. Finally (2)

The Return statement and finally have competition. Both can are the “last” thing to execute when a function exits, so which of them is really last? I blogged about this before regarding C#’s semantics setting data. Now I’ll compare some interesting differences between C# and Python. Who wins if you set them up in direct…

4

Quiz: What runs before Main()?

Quiz: What managed code runs before managed Main() in your program startup path?     Answers: I note “managed code”, because obviously the CLR startup code gets executed, as does other native startup code. 1) The common answer is static constructors referenced from Main(). 2) The less common answer would be managed code in the…

5

Why debugging breaks in optimized (production) builds.

You may have noticed that debugging optimized builds (eg, what you commonly get when you attach to a end-user instance of your app that wasn’t launched from your debugging environment) is usually a degraded experience. At an architectural level, there’s a fundamental tension between being debuggable and optimizing. The debugger generally requires the code to…

7

Techniques for Debugging IL

I mentioned in the recent dev lab that you can debug at the IL level. I demoed two ways to do this, and here I wanted to compare them more thoroughly. The big thing that’s missing is that while you can do IL level stepping, you can’t view the IL evaluation stack.   1) Rewriting…

4

TypeDef vs. TypeRef

Many of the .NET docs use the phrase “TypeDef or TypeRef”. What’s the difference? Both refer to metadata tokens.  Each token has a scope for resolving the token, which basically corresponds to a module (a .dll or .exe). IMetaDataImport is the interface for reading metadata from a module. A TypeDef refers to a type definition…

2

Measuring language complexity: Do you need a debugger?

When people are asking for a debugger for language X, practically it means that the usage of language X has gotten sufficiently complicated that mere inspection is insufficient for diagnosing problems. I alluded to this when I said that XML is code.  People want to be able to debug their XML: debug the XSLT transform…

2

Using Foo<T>(…) instead of Foo(System.Type, …)

Whenever you’re passing in a parameter of System.Type that is usually determined at compile-time, consider having a version with a generic parameter.  This converts runtime checks into compile time checks, may let you have more efficient code, and likely lets you get rid of ugly casts. For example, a method like: static object Enum.Parse(Type enumType,…

8