Continuing in the series sharing some of the information in the .NET Framework Standard Library Annotated Reference Vol 1 and .NET Framework Standard Library Annotated Reference Vol 2 with some information on BindingFlags.

 

public enum BindingFlags

{

CreateInstance = 0x200,

DeclaredOnly = 0x2,

MS Default = 0x0,

ExactBinding = 0x10000,

MS FlattenHierarchy = 0x40,

GetField = 0x400,

GetProperty = 0x1000,

IgnoreCase = 0x1,

MS IgnoreReturn = 0x1000000,

Instance = 0x4,

InvokeMethod = 0x100,

NonPublic = 0x20,

OptionalParamBinding = 0x40000,

Public = 0x10,

MS PutDispProperty = 0x4000,

MS PutRefDispProperty = 0x8000,

SetField = 0x800,

SetProperty = 0x2000,

Static = 0x8,

SuppressChangeType = 0x20000,

}

 

 

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. 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.