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.

Apologies - I've only just seen this message; somehow I must have become unsubscribed.

I didn't write the exercises for the liveBook edition of this book - I'll get in touch with Manning to find out more.
As it happens, I added section numbers to the appendix just about a week ago smilie

I'm not sure about the typo you reported in chapter 2 though. Dictionary<TKey, TValue> *is* the generic equivalent of the non-generic Hashtable class, just like List<T> is the generic equivalent of the non-generic ArrayList type.
Thanks, I've fixed this now.
Thanks - I've fixed that in my copy now.
Thanks - I've fixed listing 2.9.
> Did you mean value type ?

No, I meant a custom type instead of Task or Task<T>. The custom type still has to implement the awaitable pattern, but there can be types other than Task that do that - such as ValueTask<T>.
Ah, I suspect any formatting problem like that is with the manuscript -> MEAP system, probably where things cross page boundaries in the manuscript. I suspect there's nothing I can do to the manuscript for that, but obviously we'll make sure it all works out in the final version, where we have the "joy" of tweaking the spacing of every bit of it...

Page 5 typo: "easily1" isn't in my Word document. I suspect this is a
MEAP production artifact.

Page 5 justification: that shifts from "why use C#" to "why use
.NET". I'm going to leave this as it is.

Page 9: unfortunately I just don't have space or time to go into
everything that could possibly be interesting. (Bear in mind that
the C# 2-4 coverage is deliberately slimmed down from the 3rd

Page 24/25/47 "code formatting": could you say exactly what you mean
about code formatting? (I don't actually have the MEAP edition; I'm
doing everything from the master document. If you can explain what
you mean without me having to *get* the MEAP document, it'll be a
lot simpler for me to check.)

Page 25: Enum bit: done

Page 25: It also comes...: done

Page 26: I mean the "where T : struct" constraint, that *doesn't*
include nullable value types, even though they're structs. So
Nullable<int> isn't a valid type argument for a type parameter
constrained by "where T : struct". That's something the CLR
enforces, as well as the compiler.

Page 29: You can match against a non-null value, e.g.

int? x = 50;
if (x is int y)
Console.WriteLine(y); // 50

Page 34: done

Page 35: done

Page 56: done
Thanks for these; will get to them when I have a chance.
Thanks, fixed.
Thanks very much - fixed both.
Thanks - I've corrected my local copy; I don't know whether the changes will make it into the next MEAP or not, but they'll get there eventually.
Yes, Amazon is very definitely wrong! I'm still writing the book, then it needs to go through editing, production, printing etc...

If you're able to cancel your Amazon order though, you can get the early access edition from Manning directly. (I realize you may have chosen to use Amazon for hard copy, to avoid shipping costs.)
The book is nearing completion in terms of content. I will be editing chapter 15 to include what we know about C# 8 at the moment, but I expect the book to go "into production" (copy editing, layout etc) a long time before C# 8 is actually released. I'd be very surprised if C# 8 were fully released before the book were printed, even - if you look at the *potential* features that the C# team has talked about, there are a lot which are still very much up in the air. Given the magnitude of the nullable references change, I expect the team will want a pretty significant preview period, too.
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.
Yup, that was just a typo - I've fixed it locally; it should come in the next MEAP.
Thanks, I'll pass this on to my editor - I don't know anything about the production process, but hopefully they'll be able to fix this.
Hi Arno,

Looking at chapter 15, it seems I was a bit over-enthusiastic about predicting when blittable types would be available. They're not C# 7.2 - I don't know whether the plans for them are still in progress or not.

This is definitely one area I'll be either rewriting when it's actually implemented, or removing entirely.

I'm nervous about making comparisons with serialization, as there are lots of different kinds of serialization, and they handle things like references quite differently. I'll see when I get back to the topic though smilie

I expect to introduce them briefly as motivating factors in a lot of the ref-related features, but I don't expect to give massive in-depth coverage.
I'd definitely want to include "filter" in there - it *is* an exception filter, it's just that "when" is the syntax for it.
"Middle when filter" is possible - I'll have to think about that.

Hopefully with the diagram and text saying the same thing, it'll be clearer anyway.
(Not sure why I hadn't replied to this before.)

It's definitely an opinion, but it's based on experience of wanting to add behaviour myself. Will look at rewording it slightly.
(Sorry for not replying to this before - I was tracking it, but hadn't remembered to reply.)

I've actually reworded the sentence slightly differently, but hopefully you'll still like it:

"Properties allow us to differentiate between how state access and manipulation is exposed in the API, and how that state is implemented."
Now actually done smilie
Fixed for the next MEAP, thanks.
Now actually fixed, so should be in the next MEAP (although it may be in a different place).
Now genuinely fixed, so should be in the next MEAP...
Fixed, thanks.
Now addressed the issues where I agree. (I won't go into the few where I've chosen not to.)

Just as a general rule, if I've put something like "section X.XX" that refers to something where I don't know the number yet (usually in a chapter I haven't written yet, or where I know it's about to move.)
For the logging with the diagram - no, both the text and the diagram are correct:

Middle filter
Bottom filter
Top finally
Middle finally
Caught in Bottom

I'm not sure if the diagram was wrong at some point, but that's definitely the correct order. It looks like you expect the *body* of the catch block to execute before any intervening finally blocks - it doesn't, and never has.
Fixed in the next version (now chapter 5...) thanks.
Finally got round to implementing these (mostly) now the reorg is done.

For the retry questions: I don't know if "when" improves performance at all, but I wouldn't make that a reason for using it; the circuit-breaker pattern is somewhat related to this, but doesn't really address the way that retries don't compose well. (It may be a workaround for that in many cases, but it doesn't actually stop it from being an initial issue.)

I probably won't add the r/theta/x/y to the figure, but we'll see what my copy editor thinks.
Thanks for that - not sure how it happened, but I'll fix it when I go through other comments for chapter 3.

Sorry for the hyphenated parts - I found and fixed a bunch of those, but apparently not all of them smilie
It seems very unlikely to me that C# 8 will be concrete enough to be covered in detail before the book comes out. I already have a chapter including some of the features that are being discussed, and I hope to expand that coverage more in the coming months, but I don't expect that C# 8 will be covered in the 4th edition in the same way that C# 6 and C# 7 are.
Thanks John - will include these in my next round of modifications.
Thanks - I'll look through all of these when I do a next sweep through all the reported errors and suggested changes.
(And yes, one post per chapter would be useful.)

If there are any areas you'd particularly want feedback on, please indicate that. Otherwise I'll just treat each one as a suggestion that I can accept/reject/modify as my editor and I see fit - is that okay?
Whoops yes, thanks.

As for interface properties - not sure. We'll find out more over time, I'm sure smilie
Yup, that looks like a typo - will get it fixed for the next round, thanks.
Thanks for the typo fix - will get that done for the next MEAP.

As for "only integer types" - my guess is that it's to fit in with what the CLI can do efficiently for switch statements.
Thanks - will fix this in the next MEAP.
Right, the first typo is definitely okay in my master document.

Likewise, all of "with arity 9" is in a normal font in the master document. It may be a quirk of the MEAP process, which isn't the same as the final production process - don't worry, it'll definitely be sorted.
Thanks for reporting these.

I can't find the "coruse" typo, so maybe I've fixed it already. I'm sure it'll be caught in copy-editing later.

Looking at my original Word document around the long tuple types, it looks like all the parts that should be in code *are* in code, and vice versa. Can you be clearer about the way in which it's odd, or would you just want it not to be in code font at all?

Finally, the "arity-8" vs "arity 8" issue is consistent, but it varies in terms of whether I'm using a specific arity as an adjective. For example: "A tuple with arity 8 is an arity-8 tuple." Again, this might be changed in copy-edit, but it's deliberate at the moment.
Yes it should - thanks for spotting that. I've fixed it locally; I don't think it'll make it into the next MEAP release, but it should be in the one after that.
Nope, it's definitely meant to be x*x + y*y. It's "the root of x squared + y squared"... and there's no "power" operator in C#, so the easiest way of squaring something is just to multiply it by itself. (Your suggested code would multiply by 2, not take the value to the *power* of 2, which is different.)
Just a typo - I've corrected it locally, so hopefully it'll be fixed in the next drop. Thanks for bringing it to my attention!
You couldn't write that code, but you could write the equivalent:

public List<int> immutableList  { get { return new List<int>(); } }

... which would have the exact same effect. So basically, you shouldn't do that. In both cases, it makes perfect sense to be able to call the property and then call Add on the returned reference. I don't know which part of the language you'd expect to prevent at compile-time, or why you'd expect an exception to be thrown at execution time.

If you want a read-only property, use

public List<int> ReadOnlyProperty { get; } = new List<int>();

instead. That's an automatically-implemented read-only property, and it's very different in effect from the property you showed before - but from a *caller's* perspective, it's the same, in terms of just being "a read-only property of type List<int>.
This doesn't feel like it's particularly related to expression-bodied members - you have the same problem before C# 6.

*Both* of your options are broken if you're looking for immutability: your second option doesn't achieve immutability either, as you're allowing the caller to mutate the list.

It's not clear what you want your class to achieve, but if you want a property that returns a read-only list, you shouldn't be declaring that it returns `List<T>` - declare that you return something like `IList<T>`, `IReadOnlyList<T>`, `ReadOnlyCollection<T>` or `IImmutableList<T>`.

Yes, the backing fields are set by the property... and chaining to the default constructor doesn't do anything extra that's beneficial in this particular case. In other cases (e.g. if you have other fields you only want to explicitly set in some constructors) then it could still be useful to do so.
It compiles when using a C# 6 compiler. It wouldn't have compiled with a C# 5 or earlier compiler.

With the C# 5 compiler you receive these errors:

Point.cs(7,1): error CS0188: The 'this' object cannot be used before all of its fields are assigned to

Point.cs(5,8): error CS0843: Backing field for automatically implemented property 'Point.X' must be fully assigned
before control is returned to the caller. Consider calling the default constructor from a constructor
Point.cs(5,8): error CS0843: Backing field for automatically implemented property 'Point.Y' must be fully assigned
before control is returned to the caller. Consider calling the default constructor from a constructor
For simple typos that you expect to be picked up by copy editors anyway, it may be simpler just to ignore them.

Any technical issues should *definitely* be reported, of course.

Either way, while email is simpler for me, recording them here potentially avoids duplication...
The intention is that there will be a chapter going over the most important aspects of C# 2-4, which should be fine for a reminder of topics you already mostly know, but won't be in nearly as much depth as the the third edition. I don't know at what point the 3rd edition ebook will come with the 4th edition - I can certainly look into that.

The part around async will be primarily the C# 5 material, but updated with the changes to async that have come in C# 6 and C# 7.

I take your point about "volume 2" but I'd also note that it's never been "the whole of C#" in that even the first edition was "what's new in C# 2 and 3" rather than going over C# 1 in detail.
Not that I'm aware of, I'm afraid. It's possible that there will be marketing drives which include upgrades - I don't know.
But today it's on Deal of the Day so is 50% off anyway - use code dotd032417au at
My guess is that the image ones are ones where there are annotations. I'll pass this comment on, thanks.
Good question - I'm not sure about that. I'll ask my editor and get back to you.
Yup, just a typo. I'll add an erratum when I get the chance.
No, that still prints 0 - because it's the same scenario, effective.


will be resolved as Console.WriteLine(object), with a conversion from default(X) to object... which involves boxing the default value if X is a value type.
No, it will always resolve to Console.WriteLine(object) unless you have constraints on the type parameter.

In your case, it's actually resolving to Console.WriteLine(string, object) - and default(X) is being boxed to an object if necessary (or the reference is being passed along as-is, if X is a reference type). Assuming you're calling WriteDefault<int>, default(X) is 0, which is then boxed and printed out, just as if you'd called Console.WriteLine("Default of your object is: {0}", (object) 0);

Look at the IL for WriteDefault method and you'll see what I mean.
I don't know enough about what happened to say, to be honest - it's not a server I run, I just have the site on there.

I think I'm going to be moving it to Azure/AWS/GCE in the long term though.
Yes, the server went down around 12 hours ago - it's being restored, and I'm hoping it'll all be fixed later today.
Oh, sorry - must have skipped straight past that. Looking now.
Yes, it should be Monitor.Exit - it looks like that's a typo which has persisted in two different editions smilie

I've added an erratum for this:

Thanks for spotting it!
Fixed now, and thanks again - glad Manning sorted out the order issue, and I hope you enjoy the right edition of the book smilie
Eek! Thanks very much, will fix that now.
Well, it's an inherent danger in any state shared between multiple parallel tasks. I agree it's something to be aware of. It's not really specific to asynchronous functions - the same is true if you use Parallel.For etc... indeed in the common use of asynchrony (for concurrency between tasks rather than running a single task in parallel multiple times) I'd argue it's less of a concern than in other situations.

I'll add a note though.
Right - this is basically a natural impedance mismatch between a data model which is case-sensitive and the way that *some* languages are case-insensitive.
It's *like* that, yes - but depending on the source, it's also like adding an event handler. It depends on whether it's a "hot" or "cold" data source.

It's been a long time since I've used Rx myself, and I think it's come a long way since then - I suggest you look at for a lot more material
Added at - I hope that covers it sufficiently.
Good point. I'll add an erratum with an example on
I agree that it's odd that it's allowed. I only became aware of just how easy it is fairly recently.

Fortunately, I don't think there's much of a risk in real code - it's the sort of thing you do very explicitly, when you particularly want to. So while it's alarming, I don't think it hurts the type safety much as it impacts real developers.
Pretty much, yes. There have been minor fix-ups here and there, but 99% of the new content is in part 5.
By "switch into the more forensic mode" I just mean "start thinking in a more detailed way about exactly what's going on" - like a detective would.
Yes, you're absolutely right - I'm not sure what happened there. I'll add an erratum on the web site. Thanks for pointing it out!
Yes, you're absolutely right - I've added it to the errata:

I mean that even just a small amount of original code ends up with quite a long MoveNext() method, and if you add a little bit more it gets more complicated, then more complicated still etc.
That's very strange. Just like with the second edition, it's correct in the printed version but incorrect in the ebook form (see for the erratum for the second edition).

I really don't understand how that's happened - I'll send a note to the production team to find out why.
Thanks for the heads-up. The PDF is definitely fixed, so my guess is that Manning didn't regenerate the mobi file. I'll talk to Manning about it.
I honestly don't know what MSDN means in this case. It's possible that it's documenting the *intended* behaviour, but that it was never actually implemented. I can't immediately work out any other meaning...
Well spotted - I've added an erratum for this:
We wanted to keep the book to a manageable size, and my hopes about Code Contracts taking off haven't materialized in the years since the second edition.

Where I had hoped that knowing about Code Contracts would be a fundamental part of knowing C#, that hasn't happened - so it made sense to remove them from the third edition.

Thanks - well spotted. I've added an erratum for this:
Softbound just means paperback (instead of hardback).

I don't expect there to be any difference between the two - and the Amazon versions should still have the inlay allowing free access to the ebook.
Yes - on September 23rd, apparently. (I don't have anything to do with that side of things I'm afraid, but that's what I've been informed!)
No need for that - just email me and I'll include them on the Errata page:

(That has errata for the first and second editions, too.)
Hi Yaakov,

It's explained in chapter 1, when I talk about Snippy - it creates a "Snippet" class. Yes, plugging the snippet directly into LinqPad or a console app wouldn't work, but it fits in with the rest of the book.

In some places elsewhere I've reiterated that Snippet is the class generated by Snippy, but I haven't for this particular example. I think it's probably worth just adding a note on the web site rather than changing the text here - I don't want to overdo it.

Thanks for noticing though!
Yes indeed - thanks very much for spotting it!
Thanks for reporting this - I *think* it's been fixed in typesetting, but I'll double-check when I go through the proofs.
Hi Pat,

Do you mean "In C# 3, the assignment to worksheet would fail without a cast"? If so, the point is that the C# 4 code (listing 1.19) *doesn't* use a cast - because there's an implicit conversion from dynamic to (nearly) any type.

If that's not the sentence you meant, could you clarify?

Hi John,

I'm pretty sure we fixed this in the most recent round of editing, but I'll double check when we go through the proofs.

Thanks for pointing it out!

We should be able to fix that - thanks very much for spotting it!

I assume that by "diagram" you mean "listing"?

If so, yes - the italic/bold thing is a mistake which we're fixing in copy-edit. Thanks for noticing it.
Maybe this is a US/UK terminology issue. In the UK we call for a takeaway even if it's going to be delivered. I'll check this when that chapter gets to copy edit.
My aim is to align your thinking more closely with that of the C# designers. So instead of just saying, "You can use feature X to achieve goal Y" I try to explain why certain elements were designed the way they are, what the trade-offs are, a few of the "gotchas" etc. I want to encourage people to think about language at a slightly deeper level, basically.

Whether I *achieve* that or not is a different matter.
Hi Berry,

The 3rd edition includes all the C# 4 content from the 2nd edition, but it doesn't include the chapter on Code Contracts. So unless you're really interested in that specific aspect of the 2nd edition, it makes sense to just go up to the 3rd edition.

(I cut the Code Contracts chapter as it doesn't seem to have taken off as well as I'd hoped. I'd envisaged that by this point, it would be really widely used.)

Sorry for taking a while to reply.

C# in Depth covers the changes from C# 1 onwards - so yes, it includes everything post-C# 3 (which was the version in Visual Studio 200smilie.

Whether or not C# in Depth is suitable for your level is a tougher call. If you're fairly new to programming in general, it might be worth waiting a while - readers who are relatively new to C# but have experience in other languages are more likely to find it reasonable.

You might want to read a couple of the preview chapters to see if you feel out of your depth, or think you could plough through.

Hopefully it'll be right for you one day though smilie

Yes, that's right. Note that Code Contracts has a very good user manual. See for more resources.
Fixed already thanks - the "are" should be "argue".
The first quote is absolutely deliberate - the point is that because it's synchronous until the first await we know that the full stack trace of how we get to the Click event *is* available.

I may add a section saying that if you put a breakpoint in the same async method *after* an await, you will (probably, depending on the await) see something different.

The p696 quote is also deliberate, but possibly a little over-simple. Yes, it would be hard to tell what the call stack would be, in that you need to think about the original SynchronizationContext and whether any earlier awaits in the method have already had to wait, but those are exactly the things you should be thinking about when the code doesn't behave as you expect it to. I'll look at tweaking the language.

For your second point, I think that adding the "breakpoint after an await" near page 684 will sort this out too... along with your final point. I don't know how much detail I'll need to go into, but it's a topic worth pursuing at least a little bit more, thanks.
Fixed now as discussed by email. Thanks!
Fixed, thanks.
Thanks - haven't used it myself, but that sounds like it's worth mentioning, yes.