Comments
1 comment
-
We output it because historically Reflector was unable to recreate the original source constructs. However this has obviously changed over the past few years, for example, with the support for lambda expressions, F# (obviously still alpha), and now iterator blocks, and so there's increasingly less need to output the compiler generated code.
However, I think it's not as simple as merely turning off its output, as it can provide useful information where Reflector was unable to recreate the original source construct. A better solution would, I think, be to keep track of which blocks we have (and have not) been able to recreate source for, and then remove only those for which source constructs have been successfully generated.
Unfortunately I can't give you a timescale for when this might happen because we have other priorities for the v7 release. Obviously we do intend to improve this but I can't say more than that at the moment.
Thanks,
Bart
Add comment
Please sign in to leave a comment.
as Clive Tong pointed out:
"I've added a bug report (RP-809) suggesting that we allow users to turn off the output of the CompilerGenerated types (or perhaps even do this automatically). Since these have usually been hidden in regenerated C# constructs, there is really no need to have them in the output files, and at the moment they cause these compilation errors."
If release 7 is capable of generating correct code with all the functionality that was in the originally compiled code I would prefer if one could switch off output of any CompilerGenerated sections so generated code has no errors.
I still don't understand why you output CompilerGenerated code? Is it in any way essential? What speaks against removing it?
Could you please let me know if there is a version of Reflector out with this feature so I can test it?
Thanks,
sb