开发者

How to make Reflector not Choke on new syntax

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
 {
     [CompilerGen开发者_StackOverflow中文版erated]
     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.


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.


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.


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

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜