How can we help you today? How can we help you today?

return new GetEnumerator>d__0(0) { <>4__this = this };

Is it known problem?
Reflector (5.1.3.0) exposes syntactically incorrect C# code. For instance: System.Web.dll (.Net 3.5 SP1 installed), XmlDataSourceView class 
IEnumerator IEnumerable.GetEnumerator()
{
    return new GetEnumerator>d__0(0) { <>4__this = this };
}
Noblebug
0

Comments

1 comment

Sort by
  • odalet
    That is not a "problem", maybe a yet missing functionality... and it exists for years.

    In fact, from .NET 2.0, some language constructs are just syntactic sugar and lead to IL generation when compiled. These constructs include the yield statement among others (anonymous delegates and lambdas, anonymous types, linq, ...)

    I think the code you've seen is the generated code for a yield. Each time you build a quick IEnumerable implementation by writing a yield return..., behind the scene (at compile time) a complete enumerator class is built. Because it is directly generated in IL (well, I suppose so), the variable and method names don't have to respect C# naming restrictions.

    Starting this post, I said it may be a "missing" functionality. It would be great if we could turn on an option asking Reflector to check for the C# correctness of the statements, and if not correct, to generate C# compliant (or VB compliant) names (should not be too difficult: usually these variables and methods are private or internal, and any obfuscator knows how to do this...).

    In the same area, some problems can arise with non C# keywords or constructs. Usually switch statements don't compile back correctly (because if some goto that jump too far away for the C# compiler. And we can find some strange blocks in try/catch/finally: a faultblock can appear... This is valid in IL, but not in C#

    Quoting http://gregbeech.com/blogs/tech/archive ... lters.aspx
    fault - This block is similar to a finally block in that is observes error state but does not modify it, however the fault block is only run when an exception occurs so can allow clean-up which would only be valid under error conditions. This cannot be implemented in either C# or VB.NET.

    PS: you may encounter other weird things if you decompile VB.NET code or worst (very worst) Managed C++. The latter is the most probable (with obfuscated code) cause of crashes for Reflector.
    odalet
    0

Add comment

Please sign in to leave a comment.