(The Other) Top 10 Changes in C# Beta 2 : Page 2

#5–Behavior When Using the Unsafe Modifier Has Changed
In Beta 1, use of the unsafe keyword to specify an unsafe statement did not require an explicit unsafe block to be defined.

Sample Code Snippet 1 (old code):
	public static void Main() 
	{ int i = 5;
	  unsafe SquarePtrParam (&i);
} // no error in beta1

Sample Code Snippet 2 (new code):
	public static void Main() 
	{ int i = 5;
	  unsafe {SquarePtrParam (&i);}
} // Compiles, but unsupported according to beta 2 documentation 

Sample Code Snippet 3 (preferred new code):
	unsafe public static void Main() 
	{	int i = 5;
		SquarePtrParam (&i);
	} // unsafe modifier moved to method declaration 

#6–Use of /Unsafe Compiler Option Now Enforced
Until Beta 2, the inclusion of unsafe code (through use of the unsafe modifier) within an assembly did not properly require the use of the /unsafe C# compiler command-line parameter. Within the IDE, the use of the /unsafe compiler option was configured through a Project property called "Allow unsafe code blocks." In Beta 1, even when the default setting was False, a project using unsafe code would compile without generating the appropriate error. Beta 2 now enforces /unsafe compiler option usage.

#7–Compiler Reference Search Algorithm Has Been Modified
In Beta 2, the C# compiler has been given an expanded search algorithm for finding non-fully qualified assembly references used by the application being compiled. The modified search mechanism is:

1. Examine the current working directory from which the compiler is being executed.
   
2. Examine the COM+ system directory.
   
3. Examine the path from the /LIB command-line parameter, if provided.
   
4. Examine any paths contained in the LIB environment variable.

#8–C# Compiler Command-Line Options Have Been Expanded
Numerous changes been made in the available command-line parameters used by the C# compiler. A behavioral change in the compiler involves the automatic reading of a CSC.rsp, if it exists. The compiler (CSC.exe) will look both in the directory containing the command-line compiler, and in the directory currently in use. Employment of a CSC.rsp response file is most convenient when you need to list out multiple assembly references to be used when compiling.

#9–The Compiler Checks for Members of System.Object That Should Be Overridden, But Are Not
In Beta 2, additional intelligence has been added to the compiler regarding overriding members of the base class System.Object. This ensures that all functionally linked methods of the base System.Object class are overridden as a group. For example, this code snippet compiles fine in Beta 1, but in Beta 2 generates a compile error:

"…overrides Object.Equals(object o) but does not override Object.GetHashCode()"

Sample Code Snippet:
	public override bool Equals(object obj)
      { 
	return true;
	}

#10–Attribute Target Specifiers Are Now Supported
In Beta 1, the target of an attribute assignment was not always unambiguous because the location of the code for assigning an attribute did not also precisely identify the target. Attributes assigned to a method could refer to the method, the return value, or even the type of the method return value. To resolve the occasional ambiguity, Beta 2 supports attribute target specifiers, including:

• Assembly
  
• Module
  
• Type
  
• Method
  
• Property
  
• Field
  
• Param
  
• Event
  
• Return

For example, assigning the marshalling type for the return value of a method to the unmanaged (and unsafe) BStr data type, the attribute would be assigned using the return attribute target identifier.

Sample Code Snippet:	
[return:MarshalAs(UnmanagedType.BStr)]public string Method1()
	{…}

Be sure to read the first Top Ten Changes in C# Beta 2 article for a complete overview of the most important Beta 2 changes.

Previous Page