s the first new commercial language Microsoft has introduced since Visual Basic 1.0 in 1991 (FoxPro was acquired in June 1992), C# is quickly garnering heavy attention from interested spectators and hardcore developers alike. Beta 2 (released on June 18) incorporates a number of changes as Microsoft polishes the language for a projected Release-To-Manufacturing date near the end of 2001.

In this second article of a two-part series, I introduce another ten important changes found in C# Beta 2. If you haven’t read Part I of the Top 10 Changes in C# Beta 2 series yet, don’t worry; you can read the articles in any order. Developers already familiar with Beta 1 should be aware of the changes detailed in both articles.

#1?Use of Backtick and $ for Identifying Verbatim Strings No Longer Supported
Although Beta 1 C# (?2.5.3.5) and Beta 2 (?2.4.4.5) documentation for string literals both correctly specify a verbatim string literal as consisting of a @ character followed by zero or more characters enclosed in double-quotes, Beta 1 supported the use of the backtick (`) in place of the @ character. Beta 1 also supported the use of the $ character for verbatim string literals as a substitute for the double-quote, when used in conjunction with the backtick. Beta 2 no longer supports the use of the backtick or the $ character when specifying a verbatim string literal.

Sample Code Snippet:	string s1 = `$hello	world$; 	// Unsuppported in Beta 2	string s2 = `"hello	world";	// Unsuppported in Beta 2	string s3 = @"hello	world";	// Beta 1 and 2 support	string s4 = @$hello	world$;	// Neither beta 1 or 2

#2?Arrays with Unknown Ranks Are Not Supported by the Compiler
In Beta 1, use of the feature ‘array of unknown rank’ generated a compiler warning regarding deprecation, but it compiled and functioned. In Beta 2, this feature has been eliminated.

Sample Code Snippet:	int[] arr1 = {1,2};	int[,] arr2 = {{1,1},{2,3}};	int[?] arrTemp; // Array of unknown rank not allowed	arrTemp = arr1;	MessageBox.Show(arrTemp.Rank.ToString());	arrTemp = arr2; // Implicit convert error if known rank used	MessageBox.Show(arrTemp.Rank.ToString());

#3?Assemblies Now Assumed to Be CLS Non-Compliant
Prior to Beta 2, the C# compiler assumed that all assemblies not explicitly marked with the [CLSCompliant(false)] attribute were compliant with the Common Language Specification (CLS). The C# language specification indicates that a library without an explicit CLSCompliant attribute setting of True should be assumed non-compliant. This C# compiler behavior has been corrected in Beta 2. To mark an assembly as being CLS-compliant now requires an explicit use of the attribute.

#4?Syntax for Event Accessors Now Consists of Add and Remove Accessor Declarations
Previously, explicit event accessor declarations followed the same syntax as property declarations. A Get and Set accessor was used to obtain and set the delegate value with an object key. Beta 2 modified the behavior of event accessor declarations in C# to map more intuitively to the behavior of adding and removing delegates to the event sink list.

Sample Code Snippet 1 (old code):	public event MouseEventHandler MouseUp { get {return (MouseEventHandler)GetEventHandler(mouseUpKey);}	 set {SetEventHandler(mouseUpKey, value);}	}Sample Code Snippet 2 (new code):	public event MouseEventHandler MouseUp { add {AddEventHandler(mouseUpEventKey,value); }	 remove {RemoveEventHandler(mouseUpEventKey,value); }	}

#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 beta1Sample 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.