Errata

Print Print Icon

Submit your own errata for this product.


The errata list is a list of errors and their corrections that were found after the product was released.

The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.

Color Key: Serious Technical Mistake Minor Technical Mistake Language or formatting error Typo Question



Version Location Description Submitted By
Safari Books Online 15
3rd paragraphs from the bottom

Executable assembly
...but the types defined in the assembly cannot be used by other...


It looks like this should be removed, as one can use types from executable console app as well as from GUI app.

 Andriy 
Printed Page 22
3rd paragraph

Example on displaying public key from the key pair does not work. An additional step is needed to extract the public key to a file before the display step. Problem occurs with Visual Studio 2008.
Replace:
sn -tp MyKeyPair.snk
With:
sn -p MyKeyPair.snk MyKeyPair.bin
sn -tp MyKeyPair.bin

 David Ellison 
Printed Page 115
middle of page

<FileIOPermission(SecurityAction.Demand, Write = "C:SomeFile.txt">
should read:
<FileIOPermission(SecurityAction.Demand, Write:="C:SomeFile.txt")>

I also happened to notice that there is a similar problem on page 129 with
the colon missing in a VB attribute.

 Anonymous 
Printed Page 131
first and second code example

The text describes the way to optionally request full access to the hard drive is to
use:

[assembly: FileIOPermission(PermissionState.Unrestricted)]

and the way to refuse any access to the hard drive is to use:

[assembly: FileIOPermission(PermissionState.Unrestricted)]

The same line of code can't do nearly opposite things

I believe the code should look as follows:

[assembly: FileIOPermission(SecurityAction.RequestOptional, Unrestricted = true)]

and

[assembly: FileIOPermission(SecurityAction.RequestRefuse, Unrestricted = true)]

respectively.

 Anonymous 
Printed Page 145
2nd paragraph in "Defining the RadioPerminssion class" section

"RadioPerminssion implements the IUnrestricted interface".
should be:
"...IUnrestrictedPermission interface."

 Anonymous 
Printed Page 147
Code Listing

the second constructor looks as follows:

if (actions & (~RadioAction.All)) != 0)
{
// exception throw here
}
else
{
RadioActions = actions
}

this.RadioActions = actions;

I think this is easier to read as follows;

if (actions & (~RadioAction.All)) != 0)
{
// exception throw here
}

this.RadioActions = actions;

 Anonymous 
Printed Page 166
2nd paragraph (the "Exclusive" attribute)

The following statement is made for the "Exclusive" attribute;

"Because the final permission set of an assembly or application domain is the union
of the sets of permissions granted..."

I believe that the word "union" should actually be "intersection".

Case in point, page 170, last paragraph where the following statement appears;

"The runtime uses this process to determine the permissions granted by each policy
level and then intersects them to calculate the final code-access permission set for
the assembly."

Also note that Figure 8-7 on page 171 illustrates an intersection as the final grant
set.

 Anonymous 
Printed Page 330
C# example at bottom of page

At the bottom of page 329 and top of page 330, it is recommended that an abstract
class Adler32 be defined, but in the following examples (bottom of page 330, middle
of page 331) the abstract class is not used (as it is for the VB example). For
instance, on page 330, the line:

public class Adler32Managed : HashAlgorithm {

should be:

public class Adler32Managed : Adler32 {

or else the 'Defining the Abstract Class' section makes no sense.

Making this change makes the C# sample match the VB sample. All remaining
Adler32Managed samples need to be changed (e.g. page 331, 333).

 Anonymous