It's very easy to detect a call to Enum.ToString(). What exactly is the bad pattern you need to protect against, though? I don't think I understand, exactly, since in most cases, a rename wouldn't be relevant in IL for an enum member (since the underlying literal itself is usually emitted to IL, not the named enum member).
using System; public enum Test { value = 1} public class TestClass |
The code above didn't cause a possible issue that I could see. Can you provide the pattern that does? Or otherwise clear up my confusion?
Michael Fanning
VSTS Development: Code Analysis
This of course broke the parsing done by the C++ program.
It was quite clear that was happening, because the unobfuscated version output the correct value and the obfuscated version - with no other changes - output "a", which was the name of the renamed enum value.
Here's a little test program that demonstrates the problem:
internal class Class1 { enum TestEnum { TestEnumValue } [STAThread] |
The IL for the unobfuscated Main() looks like this, and prints "TestEnumValue":
| .method private hidebysig static void Main(string[] args) cil managed { .custom instance void [mscorlib]System.STAThreadAttribute::.ctor() .entrypoint // Code Size: 27 byte(s) .maxstack 2 L_0000: ldstr "Enum = " L_0005: ldc.i4.0 L_0006: box ObfuscatedEnum.Class1/TestEnum L_000b: call instance string [mscorlib]System.Enum::ToString() L_0010: call string string::Concat(string, string) L_0015: call void [mscorlib]System.Console::WriteLine(string) L_001a: ret } |
| .method private hidebysig static void a(string[] A_0) cil managed { .custom instance void [mscorlib]System.STAThreadAttribute::.ctor() .entrypoint // Code Size: 27 byte(s) .maxstack 2 L_0000: ldstr "Enum = " L_0005: ldc.i4.0 L_0006: box a/a L_000b: call instance string [mscorlib]System.Enum::ToString() L_0010: call string string::Concat(string, string) L_0015: call void [mscorlib]System.Console::WriteLine(string) L_001a: ret } |
Where:
1. The enum value was displayed in the user interface
2. An external process outside of the Framework parsed the enum (such as above)
The first situation should be avoided by using localized versions of the enum. The second situation I would class as rare and I'm wondering if it really quantifies a rule to be written for it. Especially considering that in most situations if the developeer uses Framework methods to parse the string (ie Enum.Parse) then no problems would be encountered.
Let us know here if you have further questions.
Michael
