Errata

The text of the book states: At runtime, arithmetic operations on integral types can overflow. By default, this happens silently--no exception is thrown, and the result exhibits "wraparound" behavior, as though the computation was done on a larger integer type and the extra significant bits discarded.

The example, however, should not be expected to do that due to two's complement binary representation of integers. Depending on the specific implementation, it seems more likely that such a specific case might occur from incrementing a signed integer set at -1. Here's what I'm thinking in some rather hideous looking code. The unchecked block is just to show decrementing int.MinValue, which should get you int.MaxValue regardless of whether the value is treated as signed or unsigned. Technically overflow I guess, but not in the same way as the text of the book describes.

uint x = 0xFFFFFFFF;
System.Console.WriteLine((int)x == -1); // true
System.Console.WriteLine(x+1); // 0 or maybe 0x100000000 truncated
System.Console.WriteLine((int)x+1); // same
System.Console.WriteLine((long)x + 1); // 0x100000000
unchecked
{
int a = (int)0x80000000; // int.MinValue
System.Console.WriteLine(a == int.MinValue); // true
int b = (int)0x7FFFFFFF; // int.MaxValue
System.Console.WriteLine(b == int.MaxValue); // true
System.Console.WriteLine(--a == b); // true
}

You can switch on char too.

string[] arr = { "Atom", "atom", "Zamia" };
Array.Sort(arr, StringComparer.InvariantCulture);
foreach (var item in arr)
Console.Write(item + " ");

Output is ordered as:
//atom Atom Zamia

And not:
Atom, atom, Zamia

The Figure 7-4 shows the inner structure of a LinkedList<T>, with rectangles representing references and arrows representing to where each reference points.

Although there are nulls (correctly) placed before the first item's Previous reference and after the last item's Next reference, the arrows for all Previous and Next references seem to point to the wrong side.

The Next references should point to the right, to the *next* reference (as the name states), not the previous one (to the left). Similarly, Previous references should point to the left, to the *previous* reference, not to the next one (to the right).

There's a line of code missing which means that the the appropriate Xml will not even be printed. The WriteXml(XmlWriter w) method should have the Close() method called as follows:

public void WriteXml(XmlWriter w)
{
foreach (XCustomer c in Customers)
{
w.WriteStartElement(XCustomer.XmlName);
c.WriteXml(w);
w.WriteEndElement();
}

foreach (Supplier s in Suppliers)
{
w.WriteStartElement(Supplier.XmlName);
s.WriterXml(w);
w.WriteEndElement();
}

w.Close();
}

I do believe the answer should be 216816.

Using your code:

Task<int> primeNumberTask = Task.Run(() => Enumerable.Range(2, 3000000).Count(n => Enumerable.Range(2, (int)Math.Sqrt(n)-1).All(i => n % i > 0)));

Gives an answer of 216816

I think you accidentally used the code

Task<int> primeNumberTask = Task.Run(() => Enumerable.Range(2, 3000000).Count(n => Enumerable.Range(2, (int)Math.Sqrt(n-1)).All(i => n % i > 0)));

Which does generate 216815

Where instead of doing Math.sqrt(n) you did Math.sqrt(n-1) instead.

Quote from the book: "This manufactures a new key pair and stores it to a file called MyApp.snk."

Error: "MyApp.snk" should be "MyKeyPair.snk"