views:

137

answers:

3

Is there a way to make reflector disassemble back to the new c# constructs?

Auto-Implemented properties are coming out like this:

[CompilerGenerated]
private string <TypeName>k__BackingField;
 public string TypeName
 {
     [CompilerGenerated]
     get
      {
         return this.<TypeName>k__BackingField;
      }
      [CompilerGenerated]
      private set
      {
          this.<TypeName>k__BackingField = value;
      }
 }

Generic Types with Strings ints or objects come out wrong:

Tuple<User,String><User,string>

Not to mention the confusing enumerators that are generated in response to some lambda based code.

Any Ideas? Getting back to the original form would be great, but getting to an equivalent compilable state would be a huge step forward. The above examples aren't valid C# code.

A: 

Well, obviously, Reflector just doesn’t have that feature yet. It hasn’t even caught up with C# 3.0 yet, much less C# 4.0. Just wait for the next version (if there will be one).

Timwi
Auto properties are C# 3.0
Jason Williams
@Jason Williams: Answer updated.
Timwi
+3  A: 

Not everything is a two-way translation. Things like lambda expressions, iterators and auto-implemented properties are syntactic sugar in C# that get compiled into real code for us. It isn't always possibly to take this compiled code and determine what the original code looked like.

If Reflector made assumptions about the code in order to detect the results of these syntactic abstractions and then Microsoft changed the compiler, it would be broken again. Reflector instead appears to choose to base its decompilation on the CLR and language specifications that are less subject to change without prior notice.

Jeff Yates
Bad answer: In the case of lambda expressions, iterators and auto-implemented properties, it is obviously possible. Reflector just can’t do it yet.
Timwi
@Timwi: I don't believe that it is obviously possible, nor do I agree that it should do it. To do so would be making assumptions about the code that cannot be guaranteed.
Jeff Yates
I don’t think RedGate care what you think it should *not* do. Besides, it already makes heaps of assumptions and it is still a useful tool. Support for autoprops and all those other features would make it a better tool than it is now because right now it is generating C# code that doesn’t even parse.
Timwi
@Timwi: Code that doesn't parse and invalid code are different things. The code that is generated is valid under given specifications for the CLR.
Jeff Yates
The problem is it generates code the can't be compiled. Getting back to the original form would be great, but getting to an equivalent compilable state would be a huge step forward. I'm going to add this above.
Adam
I agree, it would be nice if Reflector produced code that could be compiled. It's not always possible though, for code that didn't originate in C#.
Gabe
But Gabe, it doesn't do it for code that did originate in C#. Make some assumptions and create working code, I say.
Adam
+4  A: 

As regards auto-implemented properties, they come out fine (i.e. as get; set; without the compiler-generated backing-field) in the latest version. Just make sure you set Optimization to .NET 3.5 or .NET 4.0 in View -> Options -> Disassembler.

Ani
Some or all (not sure) static auto props still come out wrong with .net 4.0 settings.
Adam