You may have noticed that the analyzer doesn't show anything useful for enum values. If you analyze the enum itself you can see, for example, where it is used (see figure 1), however, if you choose one of the values, all the nodes in the analyzer will be empty (see figure 2).

Figure 1. Analyzer showing usages of the System.Data.SqlDbType enum.

Figure 2. Result of analyzing the Decimal value of the System.Data.SqlDbType enum. Note that both the "Used By" and "Assigned By" nodes are empty.

This happens because the enum values themselves don't appear in the compiled IL, only the numeric values of the underlying type, by default System.Int32, to which they map.

For example, say you have this enum:

public enum CustomColor
{
    Red = 0,
    Purple = 1,
    Orange = 2
}

And you use it in a switch statement like this:

switch ( myCustomColor )
{
    case Red:
        ...
        break;
    case Purple:
        ...
        break;
    case Orange:
        ...
        break;
    default:
        ...
        break;
}


When you compile this code the "Red", "Purple", and "Orange" values don't end up in the IL: just 0, 1, and 2. So, when you decompile with .NET Reflector you end up with:

switch ( myCustomColor )
{
    case 0:
        ...
        break;
    case 1:
        ...
        break;
    case 2:
        ...
        break;
    default:
        ...
        break;
}



It's then impossible to find all usages of, for example, "Orange", because the information is lost from the compiled code, and if we mapped to the numeric value, and then searched for uses of that. well, you can imagine how many false positives there might be.

There are a couple of things we could consider doing about this:

1. Disable the Analyze option for enum values.
2. Do some sort of inference based on the type of the value in the switch statement.

I think (1) sounds like a sensible short term, whilst (2) might be something we would consider introducing in a future version of .NET Reflector. Note though that there are circumstances where (2) might not work correctly, and so could result in spurious, or missing, results in the analyzer.

It's also worth pointing out that having the PDB files for the assembly won't make any difference since they do not store this information.