SharpDevelop Community

Get your problems solved!
Welcome to SharpDevelop Community Sign in | Join | Help
in Search

New decomplier branch

Last post 01-27-2017 10:04 PM by DanielGrunwald. 3 replies.
Page 1 of 1 (4 items)
Sort Posts: Previous Next
  • 08-28-2016 3:57 PM

    • Cairn
    • Not Ranked
    • Joined on 08-15-2016
    • Posts 2

    New decomplier branch

    I have been looking at the various branches and noted a new decomplier version.

    What's the difference between the current and the new branch?

    When and if is the new verson expected on the main branch

    Other than the 2 blog postings, are thaere any docs on ILSpy?






  • 12-03-2016 10:33 PM In reply to

    Re: New decomplier branch

    We now have the main points of the new branch documented in the wiki:

    The branch will be merged to master when roughly has the same features as the old decompiler engine (~after step 2 on the roadmap).

    Documentation: There's only the blog posts and the source code comments. (OK, there were almost no comments in the old decompiler engine; but the new one is a tiny bit better in this regard). There's also David's old dissertation in the doc/ folder in the repository, but that is of practically no relevance to the current state of the decompiler.

    newdecompiler also has the "Show steps" button in the ILAst view, where the decompiler tells you which transforms were applied (and allows debugging each step individually). This is quite helpful for tracking down mis-decompilations.

  • 01-25-2017 6:43 PM In reply to

    Re: New decomplier branch

    How far along is the newdecompiler branch? Is the code structure reasonably stable?

    More specifically, I have a fork ( ) that supports Mono compiled iterators. If I were to try to port that to the new decompiler engine, would I be facing a lot of extra work keeping up with a constantly changing API? Decompiling a .NET 3.5 assembly, would I be likely to get better or worse results than with trunk? Would you be interested in reports of things that don't decompile incorrectly or would it just be 'we know that part isn't finished yet'?

  • 01-27-2017 10:04 PM In reply to

    Re: New decomplier branch

    "yield return" support is still incomplete in the new engine, so don't try porting that yet.

    We haven't tested .NET 3.5 yet; but I generally I would expect that newdecompiler produces code that is less pretty but more correct. If you find code that is decompiled incorrectly (generated C# function has different semantics than original IL function), please report a bug.

    But we're not yet interested in "the decompiler did not detect this C# construct" if the decompiler generates verbose code that's equivalent to the C# construct.

Page 1 of 1 (4 items)
Powered by Community Server (Commercial Edition), by Telligent Systems
Don't contact us via this ( email address.