Errata

After going to press, the Visual Studio team made a change to new project defaults. When you create a new EXE project, the default platform is x86 (not anycpu). This change was made for many reasons: support for edit & continue, support for IntelliTrace debugging, and allows 32-bit COM components to work correctly when interoperating with them. And, since most applications do not need a 64-bit address space, making the default x86 seems like a reasonable solution (for now). New DLL projects default to a platform of anycpu.

Microsoft moved the location of the .NET 4.0 GAC. The GAC is in the C:\Windows\Assembly directory for .NET 3.5 and earlier. For .NET 4.0, the directory is C:\Windows\Microsoft.NET\Assembly.

Manifest table which identifying files in the assembly is "FileDef" table, not "FileRef" table.

The below excerpt seems to be inconistent with regard to the explanation of how the System.Runtime.CompilerServices.DynamicAttribute applies to dynamic local variables - see the *** markings in the text below.

"
When the type of a field, method parameter, method return type, or ***local variable***, is specifed as dynamic, the compiler converts this type to the System. Object type and applies an
instance of System.Runtime.CompilerServices.DynamicAttribute to the field, parameter, or return type in metadata.

If a ***local variable*** is specifed as dynamic, then the variable's
type will also be of type Object, but the DynamicAttribute is not applied to the local variable since its usage is self-contained within the method.
"

The first sentence says that System.Runtime.CompilerServices.DynamicAttribute will be applied to dynamic local variable but the second sentence says something different.

Note from the Author or Editor:
Yes, you are correct - local variables cannot have attributes assigned to them.

If the M method invoked at runtime has a return type of void, an exception is thrown.

Note from the Author or Editor:
Yes, you are right. A RuntimeBinderException is thrown with the following message: "Cannot implicitly convert type 'void' to 'object'"

StrongNameIdentityPermission does not work because
1) After .NET 2.0, StrongNameIdentityPermission is not checked for fully trusted assembly, so applications which installed locally or executed from network file sharing can use features which are marked with StrongNameIdentityPermissionAttribute.
2) LinkDemand is no longer supported in .NET 4 Code Access Security model. So this mechanism has not been work at all.

"A property may be read-only or write-only; field access is always readable and writeable."

A field that is marked `readonly` is only writeable within a constructor.

EventHandler<EventArgs> temp = ...

should read (as on following page 264):

EventHandler<NewMailEventArgs> temp = ...

protected void OnNewMail(NewMailEventArgs e) {

should be:

protected virtual void OnNewMail(NewMailEventArgs e) {

I agree that it is not subject for this book, but Java's generics actually does not require that source code is available from its user.

var dtl = List<DateTime>();

should read

var dtl = new List<DateTime>();

It Says:

Like delegates, an interface with generic type parameters can have its type parameters be contravariant or covariant. Here is an example of an interface with a contravariant generic type parameter:

public interface IEnumerator<out T> : IEnumerator {
Boolean MoveNext();
T Current { get; }
}

Since T is contravariant, it is possible to have the following code compile and run >successfully:

// This method accepts an IEnumerable of any reference type
Int32 Count(IEnumerable<Object> collection) { ... }
...
// The call below passes an IEnumerable<String> to Count
Int32 c = Count(new[] { "Grant" });


It Should Be:

Either the wording of contravariant needs to change to covariance or the IEnumerator<out T> needs to change to "in" and the example adjusted.

Note from the Author or Editor:
Yes, in the book, I have reversed the terms occasionally by mistake. For the record, out=covariant and in=contravariant.

According to ECMA-335, defining static members on interface is not compliant with CLS (Common Language Specification), but it is part of CLI (Common Language Infrastructure). So "Common Language Infrastructure (CLI)-compliant interface" should be "Common Language Specification (CLS)-compliant interface."

non-generic IComparable's Compare

should be:

non-generic IComparer's Compare

(1)
ConvertFromUtf32 actually produces a string consisting of ONE OR TWO UTF-16 characters from a single UTF-32 character since some UTF-32 code point is represented ideally with UTF-16 (e.x. ASCII characters). Please refer <http://msdn.microsoft.com/library/en-us/System.Char.ConvertFromUtf32>.
(2)
ConvertToUtf32 produces a 'UTF-32' character from a UTF-16 surrogate pair, not UTF-16.

number of characters or number of bytes
should be:
number of bytes or number of characters

To convert an array of bytes to an array of characters,
should be:
To convert an array of bytes to an array of characters or to a string,

the first line said, "... is about as fast as the safe two-dimensional array access technique..."

actually, it should say ".. is about as fast as the safe jagged array access technique ...", actually the result on my machine are as follows,


00:00:13.5779201: Safe2DimArrayAccess
00:00:07.5597660: SafeJaggedArrayAccess
00:00:06.3206468: Unsafe2DimArrayAccess

"To understand how they work, we first need to look at the System.Nullable<T> class, which is
defined in the FCL."

System.Nullable<T> is actually defined as a struct not a class.

Not actually an error in the text, but a bug in the code. The Equals method defined in Exception<TExceptionArgs> might throw a System.NullReferenceException if obj happens not to be of type Exception<TExceptionArgs>. (Line 3 in the method body: "other.m_args" will raise the exception.)

The author probably meant to write "if (other == null) return false;" instead of "if (obj == null) return false;" (line 2 in the method body), which would prevent the NullReferenceException from occurring.

Regards
Andreas

Btw. The bug is also present in the downloadable source files:
Ch20-1-ExceptionHandling.cs, line 172/173.

should be:

public abstract Boolean IsInvalid {
get; // A derived class overrides this property...
)

You say that "... the GCNotification class raises an event whenever a generation 0 or generation 2 collection occurs."
Your code sample for GCNotification class uses a destructor to invoke event delegates. In destructor you check whether desired generation (variable m_generation:int) is less or equal to generation of current object and if it is - you invoke the delegates:

if (GC.GetGeneration(this) >= m_generation) {
Action<Int32> temp = Interlocked.CompareExchange(ref s_gcDone, null, null);
if (temp != null) temp(m_generation);
}

However, that GC.GetGeneration(this) will return 2 not only after 2nd generation collection occured, but also after the 1st generation collection occured (during which object is promoted to 2nd generation and put to freachable queue, because it's registered for finalization) - after that finalizer is called and GetGeneration() returns 2 which is not the same as 2nd generation collection occured.

Note from the Author or Editor:
Yes, you are correct about this. A simple fix would be to save the generation to a field within the Finalize method and compare this to m_generation instead of calling GC.GetGeneration. Of course,. the error only occurs once and so I don't think it is a big deal either way.

"When I ran this code, it took 134,174 milliseconds to access the instance field of a NonMBRO class that is derived from Object, and it took 1,533,886 milliseconds to..."

To get the milliseconds value, I must change the following code:

Console.WriteLine("{0:N0}", Stopwatch.GetTimestamp() - time); // 134,174
...
Console.WriteLine("{0:N0}", Stopwatch.GetTimestamp() - time); // 1,533,886

To:

Console.WriteLine("{0:N0}", (Stopwatch.GetTimestamp() - time)
/(Stopwatch.Frequency / 1000)); // 30 on my machine
...
Console.WriteLine("{0:N0}",(Stopwatch.GetTimestamp() - time)
/(Stopwatch.Frequency / 1000)); // 818 on my machine

"In the case of a nested type, Name returns the concatenation of the name of the containing type...", but when I debug it, the Name only returns the nested type's name, while the MemberInfo.ToString() method shows the concatenation.

Note from the Author or Editor:
OK, I fix this in the next edition.

Type's static GetTypeHandle method returns the runtime handle of the type of specified object, not of the specified type object. For example:

// Pass the type
var h = Type.GetTypeHandle(typeof(Int32));
Console.WriteLine( Type.GetFromHandle(t) ); // Displays 'System.RuntimeType'

// Pass the instance
h = Type.GetTypeHandle(123);
Console.WriteLine( Type.GetFromHandle(t) ); // Displays 'System.Int32'

To convert a Type object to a RuntimeTypeHandle, just query Type's instance read-only TypeHandle property like the case of field and method.

Note from the Author or Editor:
This refers to the first bullet on the page.

"If the type's fields don't exactly match the names of the fields..., then a SerializationException exception is thrown...". Actually when I tried if the deserialization implies an string "Name" property of an specific class, while the assembly provided an Int32 "Name" property, an ArgumentException will be thrown. Furthermore, if, the deserialization can imply an class possess more properties than the one applied by the actual assembly, the new properties will be set to their default value when initializes.

I experimented both the following 2 scenario,
1. Serialize an instance of TypeA which TypeA has one Name field,
Deserialize using another TypeA while TypeA has 2 fields, Name and ID, The deserializing can go successfully, the Id column will be set its default value.
2. Serialize an instance Of TypeA, TypeA has 2 fields, Name and ID,
Deserialize using Another TypeA, TypeA has 1 fields, Name. The deserializeing can go successfully, Name value is set correctly.

for my assembly is not strong named.

Minor inconsistency:

On page 735 you state that "the easiest way to determine if a Task completed successfully is to use code like this: if (task.Status == TaskStatus.RanToCompletion) ..." (this is as opposed to !task.IsFaulted && !task.IsCancelled, presumably?)

However in the code listing on page 736 you use t => !t.IsFaulted && !t.IsCancelled as a way to select tasks that ran to completion.

On page 737, at the "Note" section, you have written : "Note When calling TaskFactory?s or TaskFactory<TResult>?s static ContinueWhenAll and ContinueWhenAny methods, ...".
But as far as I know, neither "Task Factory" class nor "Task Factory<TResult>" class contains any static members.

Note from the Author or Editor:
Correct, these methods are not static. I'll fix in next edition.

[quote]
When I run this on my machine, I get a result of 15,856,074 milliseconds.[/quote].

A millisecond (from milli- and second; abbreviation: ms) is a thousandth (1/1000) of a second. [wiki]

When I change the following code:

Console.WriteLine("Access time: {0:N0}", Stopwatch.GetTimestamp() - s_startTime)

to:

Console.WriteLine("Access time: {0:N0} ", (Stopwatch.GetTimestamp() - s_startTime) / (Stopwatch.Frequency / 1000));

I got the correct milliseconds result.

the comment in LastTransaction.get says "has shared access", while it should say "exclusive"

ReaderWriterLockSlim was introduced in .NET Framework version 3.5 not 2.0. Please refer Version Information section of following: http://msdn.microsoft.com/en-us/library/system.threading.readerwriterlockslim.aspx

Page 838 Paragraph 2 outlines why you don't think upgrading a ReaderWriterLockSlim is a useful thing, and ends with "This is the same as having the reader thread exit the lock and then immediately acquire it for writing."

This is not entirely accurate. If you exit the lock and re-acquire for writing there is a possibility of state being modified by another writer in the interim. This means that you will have to re-verify any conclusions drawn from inspecting state within the initial read-lock section after your re-acquire your write lock.

Also, you don't mention that the read lock must be explicitly acquired in "upgradeable mode" with EnterUpgradeableReadLock(), and only one thread can hold a read lock in upgradeable mode at any time (which ensures that you can upgrade without first releasing the read lock, and also without risk of deadlock).

Upgradeable mode becomes a problem if all your accesses acquire an upgradeable read lock, in which case you've effectively degraded to the equivalent of a single exclusive lock. If, however, you have multiple ways of accessing the protected data, and most of these require read-only access, then what's the problem with using an upgradeable lock in a location where you might need write access?

Note from the Author or Editor:
I could mention these methods in the next editon. I still belive they have very little value however in a real-life program.

// true if AddingComplete is called
should be
// true if CompleteAdding is called

// true if IsAddingComplete and Count==0
should be
// true if IsAddingCompleted is true and Count==0