The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

P.Brian.Mackey (3) [Avatar] Offline
Sorry, this is probably my own ignorance. However, I do not follow the "Do try this at home" on pg's 48-49. I chose dotPeek, but I've used other decompilers in the past. The decompilers tend to show me something close to the original code in C# (usually exactly in fact). Or IL which is of course very different. I know Jon said he simplified some things, but I'm not clear on what that means. Did he convert the IL to C# and that's how he came up with 6.2?

Because when I decompile the async method in 6.1 it looks exactly the same. Of course if I look at the IL I see the state machine, but it's not at all like the code in 6.2. I mean wayyy off. I could use some hand holding on how we get from 6.1 > 6.2. And if you want to get even more super powered points you can add a reference/footnote to the book telling me where I can learn how to read IL.
jon.skeet (483) [Avatar] Offline
I don't use dotPeek normally, but I've just downloaded it. If you open up the options, under Decompiler there's an option for "Show compiler generated code". Turn that on, and you'll see the generated state machine, but in C#, as close as dotPeek can represent it.

I normally use Reflector (with "optimizations" reduced to before C# 5), but I do sometimes drop down to the IL.

For all of the listings I've renamed identifiers to be valid C# identifiers and reasonably friendly names. Sometimes I've refactored the decompiled switch statement to try to handle things in a more uniform way, but it's logically the same code.