Type Summary

KC When we teach API design, we often use this enum as an example of a bad enum design. The problem is that this enum is actually combining several different concepts: visibility selection, member selection, binding algorithm, and so on, yet it claims to be Flags enum, which would imply the values can be used independently or together, using the binary OR operator. This is not the case. Just look at the documentation for this enum. It spells out several rules for the usage of the enum. It's probably the most complicated enum documentation in the whole framework.

BG This enum has two different axes, and both must be specified when using the enum. The first is the type of method—static or instance. The second is visibility—public or non–public. You must specify one or both of those values when using the BindingFlags enum, and it's remarkably easy to forget to specify one of these. It's a surprisingly common problem for users of Reflection.

JP I probably get the most questions about this particular enum, which is a result of bad design choice. So, first off, in all cases where you end up utilizing the BindingFlags overload, you must specify BindingFlags.Instance or BindingFlags.Static and also specify the visibility choice of BindingFlags.Public or BindingFlags.NonPublic to actually get anything to return.

I certainly wish we would have done something a little more explicit here.

JP A funny thing about the BindingFlags enum: we originally had a lot more binding flag options (aren't there already enough?!), which we ripped out just before RTM ship. These included things like predefined BindingFlags combinations (BindingFlags.Private, etc.) and more granular binding flags.

JP BindingFlags.IgnoreCase has some performance and working set implications associated with it (we double the Reflection string cache and lowercase all strings passed in). If your scenario doesn't need it, try to avoid it.