.Net

Dot Net Questions - Part 1

2014-12-20T03:24:00.000-08:00

How you can build Robust, Scalable and Fault Tolerant application?
What is a smart Client?
How to handle a situation where Service data contract is changing very frequently?
How GC works.
What if dispose function is not implemented then how you will release unmanaged resources?
What if your application is loading lots of data at startup? Your application will be unresponsive until all the data is not loaded. What are the different ways to handle this situation?
What is Covariance and Contravariance
IEnumerable vs IQueryable
How finalize method will impact GC?
SQL - Lets say there are millions of records in a table, provide the options to optimize its performance.
SQL - What are the different ways to optimize SQL server's performance?

IXmlSerializable – Control XML Serialization

2013-08-24T10:50:00.001-07:00

Sometimes we are in hard need to control the xml serialization. One of these needs could be to reduce the serialized data, so that less data will travel over wire and hence we will get the improved data transfer speed.

To control it, we can use the IXmlSerializable interface. This interface contains three functions

XmlSchema GetSchema()
void ReadXml(XmlReader reader)
void WriteXml(XmlWriter writer)

In these functions, we can control the serialization with the help of XMLReader and XMLWriter. IXmlSerializable interface is recognized by the both XmlSerializer and Data Contract Serializer; and hence it can be used used by WCF and ASMX Web Services.

Lets have a look into the code -

Code

using System;
using System.Xml;
using System.Xml.Linq;
using System.Xml.Schema;
using System.Xml.Serialization;

namespace XMLSerialization
{
    internal class Program
    {
        private static void Main(string[] args)
        {
            Person[] p = new Person[3];
            p[0] = new Person() { Name = "Sanjay", Age = 30 };
            p[1] = new Person() { Name = "Sanjay Legha", Age = 0 };
            p[2] = new Person() { Age = 30 };

            //Person p = new Person() { Name = "Sanjay", Age = 50 };

            string filePath = @"D:\Sanjay\TempCode\XMLSerialization\XMLSerialization\bin\Debug\Serialized.xml";
            using (System.IO.FileStream fs = new System.IO.FileStream(filePath, System.IO.FileMode.Create))
            {
                System.Xml.Serialization.XmlSerializer x = new System.Xml.Serialization.XmlSerializer(p.GetType());
                x.Serialize(fs, p);
            }

            using (System.IO.FileStream fs = new System.IO.FileStream(filePath, System.IO.FileMode.Open))
            {
                System.Xml.Serialization.XmlSerializer x = new System.Xml.Serialization.XmlSerializer(p.GetType());
                object obj = x.Deserialize(fs);
            }

            Console.Write("Done");
            Console.Read();
        }
    }

    public class Person : IXmlSerializable
    {
        public Person()
        {
            this.Name = string.Empty;
            this.Age = 0;
        }

        [XmlElement(IsNullable = false)]
        public string Name { get; set; }

        [XmlElement()]
        public int Age { get; set; }

        public XmlSchema GetSchema()
        {
            return null;
        }

        public void ReadXml(XmlReader reader)
        {
            if (reader.NodeType == XmlNodeType.Element)
            {
                XElement el = XNode.ReadFrom(reader) as XElement;

                foreach (var item in el.Nodes())
                {
                    if (item is XElement)
                    {
                        XElement node = item as XElement;
                        switch (node.Name.LocalName)
                        {
                            case "Name":
                                this.Name = node.Value;
                                break;

                            case "Age":
                                this.Age = Convert.ToInt32(node.Value);
                                break;
                        }
                    }
                }
            }
        }

        public void WriteXml(XmlWriter writer)
        {
            if (!string.IsNullOrWhiteSpace(Name))
                writer.WriteElementString("Name", Name);

            if (Age != 0)
                writer.WriteElementString("Age", Age.ToString());
        }
    }
}

Output

<?xml version="1.0"?>
<ArrayOfPerson xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Person>
    <Name>Sanjay</Name>
    <Age>30</Age>
  </Person>
  <Person>
    <Name>Sanjay Legha</Name>
  </Person>
  <Person>
    <Age>30</Age>
  </Person>
</ArrayOfPerson>

Generic Serialize Deserialize - XmlSerializer

2013-08-24T06:52:00.001-07:00

A generic Xml Serializer De-Serializer code snap

public class SerializeDeserialize
{
    public static void SerializeData<T>(string filePath, T data)
    {
        using (System.IO.FileStream fs = new System.IO.FileStream(filePath, System.IO.FileMode.CreateNew))
        {
            System.Xml.Serialization.XmlSerializer x = new System.Xml.Serialization.XmlSerializer(data.GetType());
            x.Serialize(fs, data);
        }
    }
    public static T DeSerializeData<T>(string filePath)
    {
        T data;
        using (System.IO.FileStream fs = new System.IO.FileStream(filePath, System.IO.FileMode.Open, System.IO.FileAccess.Read))
        {
            System.Xml.Serialization.XmlSerializer x = new System.Xml.Serialization.XmlSerializer(typeof(T));
            object obj = x.Deserialize(fs);
            data = (T)obj;
        }
        return data;
    }
}

Programmatically Compile And Use Code Using C#

2012-02-25T05:46:00.001-08:00

Introduction

It is always better if you could create all your required classes in your project. But, sometimes it becomes very crucial if you could create a class for the specific situation at runtime or if you could change the existing one.

To overcome this situation, .Net Framework exposes some class that allow us to programmatically access the C# language compiler.

In this post I am demonstrating how to create an entity class and its collection class through a windows application, and passing the collection class object to the DataGridView as DataSource.

Note: I am assuming you have the basic knowledge of reflection.

How To

Setup the project and form

In this example I am using the basic windows forms application. You can follow the following steps to setup this application -

Create a Windows Forms Application. It will create a form with name Form1.
Add a button on Form1 and name it btnCompile.
Add a DataGridView. Here I am using its default name dataGridView1.
Double click on the btnCompile to generate the event handler.

Implement the compiler

After adding code in event handler, your code should look like -

private void btnCompile_Click(object sender, EventArgs e)
{
    // code string to compile
    string code =
@"class EntityCollection : System.Collections.Generic.List<Entity> {}

class Entity
{
    public string Name { get; set; }

    public int Age { get; set; }
}";

    // RETRIEVING COMPILER INTERFACE
    CSharpCodeProvider codeProvider = new CSharpCodeProvider();
    ICodeCompiler codeCompiler = codeProvider.CreateCompiler();

    // PREPARING COMPILER PARAMETERS
    CompilerParameters compilerParameters = new CompilerParameters();
    compilerParameters.GenerateInMemory = true;
    compilerParameters.TreatWarningsAsErrors = false;
    compilerParameters.WarningLevel = 4;
    compilerParameters.ReferencedAssemblies.Add("System.dll");

    // COMPILING CODE
    CompilerResults results = codeCompiler.CompileAssemblyFromSource(compilerParameters, code);

    if (results.Errors.Count > 0)
    {
        StringBuilder sbExceptions = new StringBuilder();

        foreach (CompilerError CompErr in results.Errors)
        {
            sbExceptions.AppendLine(
                            "Line number " + CompErr.Line +
                            ", Error Number: " + CompErr.ErrorNumber +
                            ", '" + CompErr.ErrorText + ";" +
                            Environment.NewLine + Environment.NewLine);
        }

        MessageBox.Show("Exception raised while compiling your code: \n\n" + sbExceptions.ToString());
    }
    else
    {
        // GETTING COMPILED ASSEMBLY
        Assembly assembly = results.CompiledAssembly;

        // RETRIEVING COLLECTION CLASS FROM COMPILED ASSEMBLY.
        Type type = assembly.GetType("EntityCollection");

        // CREATING INSTANCE OF COLLECTION CLASS
        IList list = (IList)Activator.CreateInstance(type);

        // RETRIEVING ENTITY CLASS FROM COMPILED ASSEMBLY.
        Type eType = assembly.GetType("Entity");
        object obj = Activator.CreateInstance(eType);

        // ASSIGNING VALUES TO THE ENTITY CLASS OBJECT.
        eType.GetProperty("Name").SetValue(obj, "Sanjay", null);
        eType.GetProperty("Age").SetValue(obj, 30, null);

        // ADDING CLASS TO COLLECTION OBJECT
        list.Add(obj);

        // ASSIGNED LIST TO GRID VIEW AS DATA SOURCE
        dataGridView1.DataSource = list;
    }
}

About code

.NET Framework provides the ICodeCompiler compiler execution interface.The CSharpCodeProvider class implements this interface and provides access to the C# code compiler. The following code creates an instance of CSharpCodeProvider and initializes ICodeCompiler interface object.

CSharpCodeProvider codeProvider = new CSharpCodeProvider();
ICodeCompiler codeCompiler = codeProvider.CreateCompiler();

Now you have the compiler interface which can be used to compile your source code. You need to pass parameters to the compiler by using the CompilerParameters class.

CompilerParameters compilerParameters = new CompilerParameters();
compilerParameters.GenerateInMemory = true;
compilerParameters.TreatWarningsAsErrors = false;
compilerParameters.WarningLevel = 4;
compilerParameters.ReferencedAssemblies.Add("System.dll");

CompilerResults results = codeCompiler.CompileAssemblyFromSource(compilerParameters, code);

CompilerParameters object is used to pass parameters to tell the compiler that you want to generate a class library in memory which can be used further in the code. To compile code you will use function CompileAssemblyFromSource. CompileAssemblyFromSource method takes the compilerParameters object and the source code, which is a string.

Once the code is compiled, you can check to see if there were any compilation errors. You can use the return value from CompileAssemblyFromSource method, which is a CompilerResults object. This object contains an errors collection, which contains any errors that occurred during the compilation process.

Below code collects all the errors in the string builder class which is for demonstration only which you can user for your purpose -

if (results.Errors.Count > 0)
{
    StringBuilder sbExceptions = new StringBuilder();

    foreach (CompilerError CompErr in results.Errors)
    {
        sbExceptions.AppendLine(
                        "Line number " + CompErr.Line +
                        ", Error Number: " + CompErr.ErrorNumber +
                        ", '" + CompErr.ErrorText + ";" +
                        Environment.NewLine + Environment.NewLine);
    }

    MessageBox.Show("Exception raised while compiling your code: \n\n" + sbExceptions.ToString());
}

Once the assembly is generated without any error you can use it in your code. I have used it to generate a list of items and binded this list to the grid view as its data source -

else
    {
        // GETTING COMPILED ASSEMBLY
        Assembly assembly = results.CompiledAssembly;

        // RETRIEVING COLLECTION CLASS FROM COMPILED ASSEMBLY.
        Type type = assembly.GetType("EntityCollection");

        // CREATING INSTANCE OF COLLECTION CLASS
        IList list = (IList)Activator.CreateInstance(type);

        // RETRIEVING ENTITY CLASS FROM COMPILED ASSEMBLY.
        Type eType = assembly.GetType("Entity");
        object obj = Activator.CreateInstance(eType);

        // ASSIGNING VALUES TO THE ENTITY CLASS OBJECT.
        eType.GetProperty("Name").SetValue(obj, "Sanjay", null);
        eType.GetProperty("Age").SetValue(obj, 30, null);

        // ADDING CLASS TO COLLECTION OBJECT
        list.Add(obj);

        // ASSIGNED LIST TO GRID VIEW AS DATA SOURCE
        dataGridView1.DataSource = list;
    }

Once the compilation successes, build assembly can be retrieved from CompileAssemblyFromSource method’s return value which contains CompiledAssembly property.

Now you have the compiled assembly. You can play with it as you wish.

Extension Methods In Dot Net, C#

2012-02-12T07:15:00.001-08:00

Sometimes we are in need to extend any class but often it is just not possible to use inheritance if you are working with a value type, a sealed class, or an interface. C# 3 introduces the idea of extension methods.

Extension methods allows an existing type to be extended with new methods without altering the definition of the original type.

SYNTAX

You cannot use any method as the extension method – it has to have the following characteristics:

It has to be in a non-nested, non-generic static class and therefore has to be a static method.
It has to have at least one parameter where the type of the first parameter will be the type that is extends.
The first parameter has to be prefixed with this keyword.

In final words, an extension method is a static method of a static class, where the this modifier is applied to the first parameter. The type of the first parameter will be the type that is extended.

For example:

namespace ExtensionMethods
{
    public static class MyExtensions
    {
        public static int WordCount(this String str)
        {
            return str.Split(new char[] { ' ', '.', '?' },
               StringSplitOptions.RemoveEmptyEntries).Length;
        }
    }
}

Syntax Explanation

MyExtensions class is a static class and WordCount is a static method of static class. this keyword tells that this is an extension method. Type of first parameter tells it is extending string class.

Usage

The WordCounts extension method can be called as it was an instance method of a string class, as follows:

Console.WriteLine ("Hello Extension Methods".WordCount());

string s = "Hello Extension Methods";
int i = s.WordCount();

Note: Extension methods are only in scope when you explicitly import the namespace into your source code with a using directive.

In your code you invoke the extension method with instance method syntax. However, the intermediate language (IL) generated by the compiler translates your code into a call on the static method. Therefore, the principle of encapsulation is not really being violated. In fact, extension methods cannot access private variables in the type they are extending.

The above function’s translation will be as follows:

Console.WriteLine (MyExtensions.WordCount("Hello Extension Methods"));

Extending Interfaces

LINQ has already extended lots of interfaces like, IEnumerable, IEnumerable<T>, IList, IList<T> etc.

A simple syntax of how to extend the interface is:

public static T First<T> (this IEnumerable<T> sequence)
{
foreach (T element in sequence)
return element;

throw new InvalidOperationException ("No elements found!");
}
...
Console.WriteLine ((new int[]{23,453,345}).First());

Extension Method Chaining

Extension methods, like instance methods, provide a tidy way to chain functions. Consider the following two functions:

IList<string> strings = new List<string>();
strings.Add("Hello");
strings.Add("Extension");
strings.Add("Methods");

strings.First().WordCount();

Ambiguity and Resolution

As mentioned above, Extension Methods are only in scope when you explicitly import the namespace into your source code with a using directive. Consider the extension method WordCount, the following application must import ExtensionMethods, in order to avoid a compile-time error:

namespace TestApp
{
    using ExtensionMethods; // importing namespace
    class Test
    {
        static void Main()
        {
            Console.WriteLine ("Hello Extension Methods".WordCount());
        }
    }
}

Extension methods v.s. instance methods

As per the standard preference rule, any compatible instance method will always take precedence over the extension method. In the following example, Test’s Foo method will always take precedence even when called with an argument x of type int:

class Test
{
public void Foo (object x) { } // This method always wins
}
static class Extensions
{
public static void Foo (this Test t, int x) { }
}

The only way to call the extension method in this case is via normal static syntax-

Extensions.Foo(...).

Extension methods versus extension methods

If two extension methods have the same signature then the method must be called as an ordinary static method to resolve ambiguity.

If one extension method has more specific arguments, then the more specific method takes precedence. To illustrate, consider the following two classes:

static class StringExtensions
{
public static int WordCount (this string s) {...}
}
static class ObjectExtensions
{
public static int WordCount (this object s) {...}
}

The following code calls StringExtensions’s WordCount method:

int wordCount = "Hello Extension Methods".WordCount();

To call ObjectExtensions’s WordCount method, we must specify it explicitly:

int wordCount = (ObjectExtensions.WordCount ("Hello Extension Methods"));

Delegates VS Interfaces

2012-02-12T00:40:00.001-08:00

Delegates and interfaces are similar in that they enable the separation of specification and implementation. Multiple independent authors can produce implementations that are compatible with an interface specification. Similarly, a delegate specifies the signature of a method, and authors can write methods that are compatible with the delegate specification. When should you use interfaces, and when should you use delegates?

Delegates are useful when:

A single method is being called.
A class may want to have multiple implementations of the method specification.
It is desirable to allow using a static method to implement the specification.
An event-like design pattern is desired (for more information, see the Introduction To Events post).
The caller has no need to know or obtain the object that the method is defined on.
The provider of the implementation wants to "hand out" the implementation of the
specification to only a few select components.
Easy composition is desired.

Interfaces are useful when:

The specification defines a set of related methods that will be called.
A class typically implements the specification only once.
The caller of the interface wants to cast to or from the interface type to obtain other interfaces or classes.

Introduction to C# Events

2012-02-11T23:43:00.001-08:00

An event is a member that enables an object or class to provide notifications. Clients can attach executable code for events by supplying event handlers. Events work on broadcaster / subscriber model where one object is broadcasting events and other attached objects are subscribing with those events.

Events are declared using event-declarations:

event-declaration:
      event-modifier event type variable-declaration;

event-modifiers:
    new
    public
    protected
    internal
    private
    static
    virtual
    sealed
    override
    abstract
    extern

An event-declaration may include a set of attributes and access modifiers, the new, static, virtual, override, sealed, abstract, and extern modifiers.

Event declarations are subject to the same rules as method declarations with regard to valid combinations of modifiers.

The type of an event declaration must be a delegate-type, and that delegate-type must be at least as accessible as the event itself.

An event declaration may include event-accessor-declarations. However, if it does not, for non-extern, non-abstract events, the compiler supplies them automatically; for extern events, the accessors are provided externally.

An event declaration that omits event-accessor-declarations defines one or more events—one for each of the variable-declarators. The attributes and modifiers apply to all of the members declared by such an event-declaration.

It is a compile-time error for an event-declaration to include both the abstract modifier and brace-delimited event-accessor-declarations.

When an event declaration includes an extern modifier, the event is said to be an external event. Because an external event declaration provides no actual implementation, it is an error for it to include both the extern modifier and event-accessor-declarations.

An event can be used as the left-hand operand of the += and -= operators. These operators are used, respectively, to attach event handlers to or to remove event handlers from an event, and the access modifiers of the event control the contexts in which such operations are permitted.

Since += and -= are the only operations that are permitted on an event outside the type that declares the event, external code can add and remove handlers for an event, but cannot in any other way obtain or modify the underlying list of event handlers.

In an operation of the form x += y or x -= y, when x is an event and the reference takes place outside the type that contains the declaration of x, the result of the operation has type void (as opposed to having the type of x, with the value of x after the assignment). This rule prohibits external code from indirectly examining the underlying delegate of an event.

The following example shows how event handlers are attached to instances of the Button class:

public delegate void EventHandler(object sender, EventArgs e);
public class Button: Control
{
    public event EventHandler Click;
}
public class LoginDialog: Form
{
    Button OkButton;
    Button CancelButton;
    public LoginDialog()
    {
        OkButton = new Button(...);
        OkButton.Click += new EventHandler(OkButtonClick);
        CancelButton = new Button(...);
        CancelButton.Click += new EventHandler(CancelButtonClick);
    }
    void OkButtonClick(object sender, EventArgs e)
    {
        // Handle OkButton.Click event
    }
    void CancelButtonClick(object sender, EventArgs e)
    {
        // Handle CancelButton.Click event
    }
}

Here, the LoginDialog instance constructor creates two Button instances and attaches event handlers to the Click events.

Field-like events

Within the program text of the class or struct that contains the declaration of an event, certain events can be used like fields. To be used in this way, an event must not be abstract or extern, and must not explicitly include event-accessor-declarations. Such an event can be used in any context that permits a field. The field contains a delegate which refers to the list of event handlers that have been added to the event. If no event handlers have been added, the field contains null.

In the example

public delegate void EventHandler(object sender, EventArgs e);
public class Button: Control
{
    public event EventHandler Click;
    protected void OnClick(EventArgs e)
    {
        if (Click != null) Click(this, e);
    }
    public void Reset()
    {
        Click = null;
    }
}

Click is used as a field within the Button class. As the example demonstrates, the field can be examined, modified, and used in delegate invocation expressions. The OnClick method in the Button class “raises” the Click event. The notion of raising an event is precisely equivalent to invoking the delegate represented by the event—thus, there are no special language constructs for raising events. Note that the delegate invocation is preceded by a check that ensures the delegate is non-null.

Outside the declaration of the Button class, the Click member can only be used on the left-hand side of the += and –= operators, as in

b.Click += new EventHandler(…);

which appends a delegate to the invocation list of the Click event, and

b.Click –= new EventHandler(…);

which removes a delegate from the invocation list of the Click event.

When compiling a field-like event, the compiler automatically creates storage to hold the delegate, and creates accessors for the event that add or remove event handlers to the delegate field. In order to be thread-safe, the addition or removal operations are done while holding the lock on the containing object for an instance event, or the type object for a static event.

Thus, an instance event declaration of the form:

class X
{
public event D Ev;
}

could be compiled to something equivalent to:

class X
{
    private D __Ev; // field to hold the delegate
    public event D Ev {
        add {
            lock(this) { __Ev = __Ev + value; }
        }
        remove {
            lock(this) { __Ev = __Ev - value; }
        }
    }
}

Within the class X, references to Ev are compiled to reference the hidden field __Ev instead. The name “__Ev” is arbitrary; the hidden field could have any name or no name at all.

Similarly, a static event declaration of the form:

class X
{
public static event D Ev;
}

could be compiled to something equivalent to:

class X
{
    private static D __Ev; // field to hold the delegate
    public static event D Ev {
        add {
            lock(typeof(X)) { __Ev = __Ev + value; }
        }
        remove {
            lock(typeof(X)) { __Ev = __Ev - value; }
        }
    }
}

Event accessors

Event declarations typically omit event-accessor-declarations, as in the Button example above. One situation for doing so involves the case in which the storage cost of one field per event is not acceptable. In such cases, a class can include event-accessor-declarations and use a private mechanism for storing the list of event handlers.

The event-accessor-declarations of an event specify the executable statements associated with adding and removing event handlers.

The accessor declarations consist of an add-accessor-declaration and a remove-accessor-declaration. Each accessor declaration consists of the token add or remove followed by a block. The block associated with an add-accessor-declaration specifies the statements to execute when an event handler is added, and the block associated with a remove-accessor-declaration specifies the statements to execute when an event handler is removed.

Each add-accessor-declaration and remove-accessor-declaration corresponds to a method with a single value parameter of the event type and a void return type. The implicit parameter of an event accessor is named value. When an event is used in an event assignment, the appropriate event accessor is used. Specifically, if the assignment operator is += then the add accessor is used, and if the assignment operator is -= then the remove accessor is used. In either case, the right-hand operand of the assignment operator is used as the argument to the event accessor. The block of an add-accessor-declaration or a remove-accessor-declaration must conform to the rules for void methods. In particular, return statements in such a block are not permitted to specify an expression.

Since an event accessor implicitly has a parameter named value, it is a compile-time error for a local variable or constant declared in an event accessor to have that name.

In the example

class Control: Component
{
    // Unique keys for events
    static readonly object mouseDownEventKey = new object();
    static readonly object mouseUpEventKey = new object();
    // Return event handler associated with key
    protected Delegate GetEventHandler(object key) {...}
    // Add event handler associated with key
    protected void AddEventHandler(object key, Delegate handler) {...}
    // Remove event handler associated with key
    protected void RemoveEventHandler(object key, Delegate handler) {...}
    // MouseDown event
    public event MouseEventHandler MouseDown {
        add { AddEventHandler(mouseDownEventKey, value); }
        remove { RemoveEventHandler(mouseDownEventKey, value); }
    }
    // MouseUp event
    public event MouseEventHandler MouseUp {
        add { AddEventHandler(mouseUpEventKey, value); }
        remove { RemoveEventHandler(mouseUpEventKey, value); }
    }
    // Invoke the MouseUp event
    protected void OnMouseUp(MouseEventArgs args) {
        MouseEventHandler handler;
        handler = (MouseEventHandler)GetEventHandler(mouseUpEventKey);
        if (handler != null)
            handler(this, args);
    }
}

the Control class implements an internal storage mechanism for events. The AddEventHandler method associates a delegate value with a key, the GetEventHandler method returns the delegate currently associated with a key, and the RemoveEventHandler method removes a delegate as an event handler for the specified event. Presumably, the underlying storage mechanism is designed such that there is no cost for associating a null delegate value with a key, and thus unhandled events consume no storage.

Static and instance events

When an event declaration includes a static modifier, the event is said to be a static event. When no static modifier is present, the event is said to be an instance event.

A static event is not associated with a specific instance, and it is a compile-time error to refer to this in the accessors of a static event.

An instance event is associated with a given instance of a class, and this instance can be accessed as this in the accessors of that event.

When an event is referenced in a member-access of the form E.M, if M is a static event, E must denote a type containing M, and if M is an instance event, E must denote an instance of a type containing M.

Virtual, sealed, override, and abstract accessors

A virtual event declaration specifies that the accessors of that event are virtual. The virtual modifier applies to both accessors of an event.

An abstract event declaration specifies that the accessors of the event are virtual, but does not provide an actual implementation of the accessors. Instead, non-abstract derived classes are required to provide their own implementation for the accessors by overriding the event. Because an abstract event declaration provides no actual implementation, it cannot provide brace-delimited event-accessor-declarations.

An event declaration that includes both the abstract and override modifiers specifies that the event is abstract and overrides a base event. The accessors of such an event are also abstract.

Abstract event declarations are only permitted in abstract classes.

The accessors of an inherited virtual event can be overridden in a derived class by including an event declaration that specifies an override modifier. This is known as an overriding event declaration. An overriding event declaration does not declare a new event. Instead, it simply specializes the implementations of the accessors of an existing virtual event.

An overriding event declaration must specify the exact same accessibility modifiers, type, and name as the overridden event.

An overriding event declaration may include the sealed modifier. Use of this modifier prevents a derived class from further overriding the event. The accessors of a sealed event are also sealed.

It is a compile-time error for an overriding event declaration to include a new modifier.

Introduction to C# Delegates

2012-02-11T04:32:00.001-08:00

Delegates enable scenarios that other languages such as C++, Pascal, and Modula have addressed with function pointers. Unlike C++ function pointers, however, delegates are fully object oriented, and unlike C++ pointers to member functions, delegates encapsulate both an object instance and a method.

A delegate declaration defines a class that is derived from the class System.Delegate. A delegate instance encapsulates an invocation list, which is a list of one or more methods, each of which is referred to as a callable entity. For instance methods, a callable entity consists of an instance and a method on that instance. For static methods, a callable entity consists of just a method. Invoking a delegate instance with an appropriate set of arguments causes each of the delegate’s callable entities to be invoked with the given set of arguments.

An interesting and useful property of a delegate instance is that it does not know or care about the classes of the methods it encapsulates; all that matters is that those methods be compatible with the delegate’s type. This makes delegates perfectly suited for “anonymous” invocation.

Delegate declarations

A delegate-declaration is a type-declaration that declares a new delegate type.

delegate-declaration:
attributes delegate return-type(formal-parameter-list);

delegate-modifier:
new
public
protected
internal
private

It is a compile-time error for the same modifier to appear multiple times in a delegate declaration.

The new modifier is only permitted on delegates declared within another type, in which case it specifies that such a delegate hides an inherited member by the same name.

The optional formal-parameter-list specifies the parameters of the delegate, and return-type indicates the return type of the delegate.

The return type of a delegate type must be either void, or output-safe.

All the formal parameter types of a delegate type must be input-safe. Additionally, any out or ref parameter types must also be output-safe. Note that even out parameters are required to be input-safe, due to a limitation of the underlying execution platform.

Delegate types in C# are name equivalent, not structurally equivalent. Specifically, two different delegate types that have the same parameter lists and return type are considered different delegate types. However, instances of two distinct but structurally equivalent delegate types may compare as equal.

For example:

delegate int D1(int i, double d);

class A
{
      public static int M1(int a, double b) {...}
}

class B
{
      delegate int D2(int c, double d);
      public static int M1(int f, double g) {...}
      public static void M2(int k, double l) {...}
      public static int M3(int g) {...}
      public static void M4(int g) {...}
}

The delegate types D1 and D2 are both compatible with the methods A.M1 and B.M1, since they have the same return type and parameter list; however, these delegate types are two different types, so they are not interchangeable. The delegate types D1 and D2 are incompatible with the methods B.M2, B.M3, and B.M4, since they have different return types or parameter lists.

Like other generic type declarations, type arguments must be given to create a constructed delegate type. The parameter types and return type of a constructed delegate type are created by substituting, for each type parameter in the delegate declaration, the corresponding type argument of the constructed delegate type. The resulting return type and parameter types are used in determining what methods are compatible with a constructed delegate type. For example:

delegate bool Predicate(T value);

class X
{
      static bool F(int i) {...}
      static bool G(string s) {...}
}

The delegate type Predicate<int> is compatible with the method X.F and the delegate type Predicate<string> is compatible with the method X.G.

The only way to declare a delegate type is via a delegate-declaration. A delegate type is a class type that is derived from System.Delegate. Delegate types are implicitly sealed, so it is not permissible to derive any type from a delegate type. It is also not permissible to derive a non-delegate class type from System.Delegate. Note that System.Delegate is not itself a delegate type; it is a class type from which all delegate types are derived.

C# provides special syntax for delegate instantiation and invocation. Except for instantiation, any operation that can be applied to a class or class instance can also be applied to a delegate class or instance, respectively. In particular, it is possible to access members of the System.Delegate type via the usual member access syntax.

The set of methods encapsulated by a delegate instance is called an invocation list. When a delegate instance is created from a single method, it encapsulates that method, and its invocation list contains only one entry. However, when two non-null delegate instances are combined, their invocation lists are concatenated—in the order left operand then right operand—to form a new invocation list, which contains two or more entries.

Delegates are combined using the binary + and += operators. A delegate can be removed from a combination of delegates, using the binary - and -= operators. Delegates can be compared for equality.

The following example shows the instantiation of a number of delegates, and their corresponding invocation lists:

delegate void D(int x);

class C
{
    public static void M1(int i) {...}
    public static void M2(int i) {...}
}

class Test
{
    static void Main () 
    {
        D cd1 = new D(C.M1);          // M1
        D cd2 = new D(C.M2);          // M2
        D cd3 = cd1 + cd2;            // M1 + M2
        D cd4 = cd3 + cd1;            // M1 + M2 + M1
        D cd5 = cd4 + cd3;            // M1 + M2 + M1 + M1 + M2
    }
}

When cd1 and cd2 are instantiated, they each encapsulate one method. When cd3 is instantiated, it has an invocation list of two methods, M1 and M2, in that order. cd4’s invocation list contains M1, M2, and M1, in that order. Finally, cd5’s invocation list contains M1, M2, M1, M1, and M2, in that order. For more examples of combining (as well as removing) delegates.

Delegate compatibility

A method or delegate M is compatible with a delegate type D if all of the following are true:

D and M have the same number of parameters, and each parameter in D has the same ref or out modifiers as the corresponding parameter in M.
For each value parameter (a parameter with no ref or out modifier), an identity conversion or implicit reference conversion exists from the parameter type in D to the corresponding parameter type in M.
For each ref or out parameter, the parameter type in D is the same as the parameter type in M.
An identity or implicit reference conversion exists from the return type of M to the return type of D.

Delegate instantiation

An instance of a delegate is created by a delegate-creation-expression or a conversion to a delegate type. The newly created delegate instance then refers to either:

The static method referenced in the delegate-creation-expression, or
The target object (which cannot be null) and instance method referenced in the delegate-creation-expression, or
Another delegate.

For example:

delegate void D(int x);

class C
{
    public static void M1(int i) {...}
    public void M2(int i) {...}
}

class Test
{
    static void Main () 
    { 
        D cd1 = new D(C.M1);          // static method
        C t = new C();
        D cd2 = new D(t.M2);          // instance method
        D cd3 = new D(cd2);           // another delegate
    }
}

Once instantiated, delegate instances always refer to the same target object and method. Remember, when two delegates are combined, or one is removed from another, a new delegate results with its own invocation list; the invocation lists of the delegates combined or removed remain unchanged.

Delegate invocation

C# provides special syntax for invoking a delegate. When a non-null delegate instance whose invocation list contains one entry is invoked, it invokes the one method with the same arguments it was given, and returns the same value as the referred to method. If an exception occurs during the invocation of such a delegate, and that exception is not caught within the method that was invoked, the search for an exception catch clause continues in the method that called the delegate, as if that method had directly called the method to which that delegate referred.

Invocation of a delegate instance whose invocation list contains multiple entries proceeds by invoking each of the methods in the invocation list, synchronously, in order. Each method so called is passed the same set of arguments as was given to the delegate instance. If such a delegate invocation includes reference parameters, each method invocation will occur with a reference to the same variable; changes to that variable by one method in the invocation list will be visible to methods further down the invocation list. If the delegate invocation includes output parameters or a return value, their final value will come from the invocation of the last delegate in the list.

If an exception occurs during processing of the invocation of such a delegate, and that exception is not caught within the method that was invoked, the search for an exception catch clause continues in the method that called the delegate, and any methods further down the invocation list are not invoked.

Attempting to invoke a delegate instance whose value is null results in an exception of type System.NullReferenceException.

The following example shows how to instantiate, combine, remove, and invoke delegates:

using System;

delegate void D(int x);

class C
{
    public static void M1(int i)
    {
        Console.WriteLine("C.M1: " + i);
    }
    
    public static void M2(int i) 
    {
        Console.WriteLine("C.M2: " + i);
    }

    public void M3(int i) 
    {
        Console.WriteLine("C.M3: " + i);
    }
}

class Test
{
    static void Main () 
    { 
        D cd1 = new D(C.M1);
        cd1(-1);                  // call M1

        D cd2 = new D(C.M2);
        cd2(-2);                  // call M2

        D cd3 = cd1 + cd2;
        cd3(10);                  // call M1 then M2

        cd3 += cd1;
        cd3(20);                  // call M1, M2, then M1

        C c = new C();
        D cd4 = new D(c.M3);
        cd3 += cd4;
        cd3(30);                  // call M1, M2, M1, then M3

        cd3 -= cd1;         // remove last M1
        cd3(40);                  // call M1, M2, then M3

        cd3 -= cd4;
        cd3(50);                  // call M1 then M2

        cd3 -= cd2;
        cd3(60);                  // call M1

        cd3 -= cd2;         // impossible removal is benign
        cd3(60);                  // call M1

        cd3 -= cd1;         // invocation list is empty so cd3 is null
        //          cd3(70);          // System.NullReferenceException thrown

        cd3 -= cd1;         // impossible removal is benign
      }
}

As shown in the statement cd3 += cd1;, a delegate can be present in an invocation list multiple times. In this case, it is simply invoked once per occurrence. In an invocation list such as this, when that delegate is removed, the last occurrence in the invocation list is the one actually removed.

Immediately prior to the execution of the final statement, cd3 -= cd1;, the delegate cd3 refers to an empty invocation list. Attempting to remove a delegate from an empty list (or to remove a non-existent delegate from a non-empty list) is not an error.

The output produced is:

C.M1: -1
C.M2: -2
C.M1: 10
C.M2: 10
C.M1: 20
C.M2: 20
C.M1: 20
C.M1: 30
C.M2: 30
C.M1: 30
C.M3: 30
C.M1: 40
C.M2: 40
C.M3: 40
C.M1: 50
C.M2: 50
C.M1: 60
C.M1: 60

Introduction to C# Generics (MSDN)

2012-02-11T01:05:00.000-08:00

Summary: This article discusses the problem space generics address, how they are implemented, the benefits of the programming model, and unique innovations, such as constrains, generic methods and delegates, and generic inheritance. In addition it discusses how the .NET Framework utilizes generics (45 pages)

Introduction
Generics Problem Statement
What Are Generics
Applying Generics
Generic Constraints
Generics and Casting
Inheritance and Generics
Generic Methods
Generic Delegates
Generics and Reflection
Generics and the .NET Framework
Conclusion

Introduction

Generics are the most powerful feature of C# 2.0. Generics allow you to define type-safe data structures, without committing to actual data types. This results in a significant performance boost and higher quality code, because you get to reuse data processing algorithms without duplicating type-specific code. In concept, generics are similar to C++ templates, but are drastically different in implementation and capabilities. This article discusses the problem space generics address, how they are implemented, the benefits of the programming model, and unique innovations, such as constrains, generic methods and delegates, and generic inheritance. You will also see how generics are utilized in other areas of the .NET Framework such as reflection, arrays, collections, serialization, and remoting, and how to improve on the basic offering.

Generics Problem Statement

Consider an everyday data structure such as a stack, providing the classic Push() and Pop() methods. When developing a general-purpose stack, you would like to use it to store instances of various types. Under C# 1.1, you have to use an Object-based stack, meaning that the internal data type used in the stack is an amorphous Object, and the stack methods interact with Objects:

public class Stack
{
   object[] m_Items; 
   public void Push(object item)
   {...}
   public object Pop()
   {...}
}

Code block 1 shows the full implementation of the Object-based stack. Because Object is the canonical .NET base type, you can use the Object-based stack to hold any type of items, such as integers:

Stack stack = new Stack();
stack.Push(1);
stack.Push(2);
int number = (int)stack.Pop();

Code block 1. An Object-based stack

public class Stack
{
   readonly int m_Size; 
   int m_StackPointer = 0;
   object[] m_Items; 
   public Stack():this(100)
   {}   
   public Stack(int size)
   {
      m_Size = size;
      m_Items = new object[m_Size];
   }
   public void Push(object item)
   {
      if(m_StackPointer >= m_Size) 
         throw new StackOverflowException();       
      m_Items[m_StackPointer] = item;
      m_StackPointer++;
   }
   public object Pop()
   {
      m_StackPointer--;
      if(m_StackPointer >= 0)
      {
         return m_Items[m_StackPointer];
      }
      else
      {
         m_StackPointer = 0;
         throw new InvalidOperationException("Cannot pop an empty stack");
      }
   }
}

However, there are two problems with Object-based solutions. The first issue is performance. When using value types, you have to box them in order to push and store them, and unbox the value types when popping them off the stack. Boxing and unboxing incurs a significant performance penalty in their own right, but it also increases the pressure on the managed heap, resulting in more garbage collections, which is not great for performance either. Even when using reference types instead of value types, there is still a performance penalty because you have to cast from an Object to the actual type you interact with and incur the casting cost:

Stack stack = new Stack();
stack.Push("1");
string number = (string)stack.Pop();

The second (and often more severe) problem with the Object-based solution is type safety. Because the compiler lets you cast anything to and from Object, you lose compile-time type safety. For example, the following code compiles fine, but raises an invalid cast exception at run time:

Stack stack = new Stack();
stack.Push(1);
//This compiles, but is not type safe, and will throw an exception: 
string number = (string)stack.Pop();

You can overcome these two problems by providing a type-specific (and hence, type-safe) performant stack. For integers you can implement and use the IntStack:

public class IntStack
{
   int[] m_Items; 
   public void Push(int item){...}
   public int Pop(){...}
} 
IntStack stack = new IntStack();
stack.Push(1);
int number = stack.Pop();

For strings you would implement the StringStack:

public class StringStack
{
   string[] m_Items; 
   public void Push(string item){...}
   public string Pop(){...}
}
StringStack stack = new StringStack();
stack.Push("1");
string number = stack.Pop();

And so on. Unfortunately, solving the performance and type-safety problems this way introduces a third, and just as serious problem—productivity impact. Writing type-specific data structures is a tedious, repetitive, and error-prone task. When fixing a defect in the data structure, you have to fix it not just in one place, but in as many places as there are type-specific duplicates of what is essentially the same data structure. In addition, there is no way to foresee the use of unknown or yet-undefined future types, so you have to keep an Object-based data structure as well. As a result, most C# 1.1 developers found type-specific data structures to be impractical and opt for using Object-based data structures, in spite of their deficiencies.

What Are Generics

Generics allow you to define type-safe classes without compromising type safety, performance, or productivity. You implement the server only once as a generic server, while at the same time you can declare and use it with any type. To do that, use the < and > brackets, enclosing a generic type parameter. For example, here is how you define and use a generic stack:

public class Stack<T>
{
   T[] m_Items; 
   public void Push(T item)
   {...}
   public T Pop()
   {...}
}
Stack<int> stack = new Stack<int>();
stack.Push(1);
stack.Push(2);
int number = stack.Pop();

Code block 2 shows the full implementation of the generic stack. Compare Code block 1 to Code block 2 and see that it is as if every use of object in Code block 1 is replaced with T in Code block 2, except that the Stack is defined using the generic type parameter T:

public class Stack<T>
{...}

When using a generic stack, you have to instruct the compiler which type to use instead of the generic type parameter T, both when declaring the variable and when instantiating it:

Stack<int> stack = new Stack<int>();

The compiler and the runtime do the rest. All the methods (or properties) that accept or return a T will instead use the specified type, an integer in the example above.

Code block 2. The generic stack

public class Stack<T>
{
   readonly int m_Size; 
   int m_StackPointer = 0;
   T[] m_Items;
   public Stack():this(100)
   {}
   public Stack(int size)
   {
      m_Size = size;
      m_Items = new T[m_Size];
   }
   public void Push(T item)
   {
      if(m_StackPointer >= m_Size) 
         throw new StackOverflowException();
      m_Items[m_StackPointer] = item;
      m_StackPointer++;
   }
   public T Pop()
   {
      m_StackPointer--;
      if(m_StackPointer >= 0)
      {
         return m_Items[m_StackPointer];
      }
      else
      {
         m_StackPointer = 0;
         throw new InvalidOperationException("Cannot pop an empty stack");
      }
   }
}

Note T is the generic type parameter (or type parameter) while the generic type is the Stack<T>. The int in Stack<int> is the type argument.

The advantage of this programming model is that the internal algorithms and data manipulation remain the same while the actual data type can change based on the way the client uses your server code.

Generics Implementation

On the surface C# generics look syntactically similar to C++ templates, but there are important differences in the way they are implemented and supported by the compiler. As you will see later in this article, this has significant implications on the manner in which you use generics.

Note In the context of this article, when referring to C++ it means classic C++, not Microsoft C++ with the managed extensions.

Compared to C++ templates, C# generics can provide enhanced safety but are also somewhat limited in capabilities.

In some C++ compilers, until you use a template class with a specific type, the compiler does not even compile the template code. When you do specify a type, the compiler inserts the code inline, replacing every occurrence of the generic type parameter with the specified type. In addition, every time you use a specific type, the compiler inserts the type-specific code, regardless of whether you have already specified that type for the template class somewhere else in the application. It is up to the C++ linker to resolve this, and it is not always possible to do. This may results in code bloating, increasing both the load time and the memory footprint.

In .NET 2.0, generics have native support in IL (intermediate language) and the CLR itself. When you compile generic C# server-side code, the compiler compiles it into IL, just like any other type. However, the IL only contains parameters or place holders for the actual specific types. In addition, the metadata of the generic server contains generic information.

The client-side compiler uses that generic metadata to support type safety. When the client provides a specific type instead of a generic type parameter, the client's compiler substitutes the generic type parameter in the server metadata with the specified type argument. This provides the client's compiler with type-specific definition of the server, as if generics were never involved. This way the client compiler can enforce correct method parameters, type-safety checks, and even type-specific IntelliSense.

The interesting question is how does .NET compile the generic IL of the server to machine code. It turns out that the actual machine code produced depends on whether the specified types are value or reference type. If the client specifies a value type, then the JIT compiler replaces the generic type parameters in the IL with the specific value type, and compiles it to native code. However, the JIT compiler keeps track of type-specific server code it already generated. If the JIT compiler is asked to compile the generic server with a value type it has already compiled to machine code, it simply returns a reference to that server code. Because the JIT compiler uses the same value-type-specific server code in all further encounters, there is no code bloating.

If the client specifies a reference type, then the JIT compiler replaces the generic parameters in the server IL with Object, and compiles it into native code. That code will be used in any further request for a reference type instead of a generic type parameter. Note that this way the JIT compiler only reuses actual code. Instances are still allocated according to their size off the managed heap, and there is no casting.

Generics Benefits

Generics in .NET let you reuse code and the effort you put into implementing it. The types and internal data can change without causing code bloat, regardless of whether you are using value or reference types. You can develop, test, and deploy your code once, reuse it with any type, including future types, all with full compiler support and type safety. Because the generic code does not force the boxing and unboxing of value types, or the down casting of reference types, performance is greatly improved. With value types there is typically a 200 percent performance gain, and with reference types you can expect up to a 100 percent performance gain in accessing the type (of course, the application as a whole may or may not experience any performance improvements). The source code available with this article includes a micro-benchmark application, which executes a stack in a tight loop. The application lets you experiment with value and reference types on an Object-based stack and a generic stack, as well as changing the number of loop iterations to see the effect generics have on performance.

Applying Generics

Because of the native support for generics in the IL and the CLR, most CLR-compliant language can take advantage of generic types. For example, here is some Visual Basic .NET code that uses the generic stack of Code block 2:

Dim stack As Stack(Of Integer)
stack = new Stack(Of Integer)
stack.Push(3)
Dim number As Integer
number = stack.Pop()

You can use generics in classes and in structs. Here is a useful generic point struct:

public struct Point<T>
{
   
   public T X;
   
   public T Y;
}

You can use the generic point for integer coordinates, for example:

Point<int> point;
point.X = 1;
point.Y = 2;

Or for charting coordinates that require floating point precision:

Point<double> point;
point.X = 1.2;
point.Y = 3.4;

Besides the basic generics syntax presented so far, C# 2.0 has some generics-specific syntax. For example, consider the Pop() method of Code block 2. Suppose instead of throwing an exception when the stack is empty, you would like to return the default value of the type stored in the stack. If you were using an Object-based stack, you would simply return null, but a generic stack could be used with value types as well. To address this issue, you can use the default() operator, which returns the default value of a type.

Here is how you can use default in the implementation of the Pop() method:

public T Pop()
{
   m_StackPointer--;
   if(m_StackPointer >= 0)
   {
      return m_Items[m_StackPointer];
   }
   else
   {
      m_StackPointer = 0;
      return default(T);
   }
}

The default value for reference types is null, and the default value for value types (such as integers, enum, and structures) is a zero whitewash (filling the structure with zeros). Consequently, if the stack is constructed with strings, the Pop() methods return null when the stack is empty, and when the stack is constructed with integers, the Pop() methods return zero when the stack is empty.

Multiple Generic Types

A single type can define multiple generic-type parameters. For example, consider the generic linked list shown in Code block 3.

Code block 3. Generic linked list

class Node<K,T>
{
   public K Key;
   public T Item;
   public Node<K,T> NextNode;
   public Node()
   {
      Key      = default(K);
      Item     = defualt(T);
      NextNode = null;
   }
   public Node(K key,T item,Node<K,T> nextNode)
   {
      Key      = key;
      Item     = item;
      NextNode = nextNode;
   }
}

public class LinkedList<K,T>
{
   Node<K,T> m_Head;
   public LinkedList()
   {
      m_Head = new Node<K,T>();
   }
   public void AddHead(K key,T item)
   {
      Node<K,T> newNode = new Node<K,T>(key,item,m_Head.NextNode);
      m_Head.NextNode = newNode;
   }
}

The linked list stores nodes:

class Node<K,T>
{...}

Each node contains a key (of the generic type parameter K) and a value (of the generic type parameter T). Each node also has a reference to the next node in the list. The linked list itself is defined in terms of the generic type parameters K and T:

public class LinkedList<K,T>
{...}

This allows the list to expose generic methods like AddHead():

public void AddHead(K key,T item);

Whenever you declare a variable of a type that uses generics, you must specify the types to use. However, the specified type arguments can themselves be generic type parameters. For example, the linked list has a member variable called m_Head of type Node, used for referencing the first item in the list. m_Head is declared using the list's own generic type parameters K and T

Node<K,T> m_Head;

You need to provide type arguments when instantiating a node, and again, you can use the linked list's own generic type parameters:

public void AddHead(K key,T item)
{
   Node<K,T> newNode = new Node<K,T>(key,item,m_Head.NextNode);
   m_Head.NextNode = newNode;
}

Note that the fact the list uses the same names as the node for the generic type parameters is purely for readability purposes, and it could have used other names, such as:

public class LinkedList<U,V>
{...}

Or:

public class LinkedList<KeyType,DataType>
{...}

In which case, m_Head would have been declared as:

Node<KeyType,DataType> m_Head;

When the client is using the linked list, the client has to provide type arguments. The client can choose integers as keys and strings as data items:

LinkedList<int,string> list = new LinkedList<int,string>();
list.AddHead(123,"AAA");

But the client can choose any other combination, such as a time stamp for keys:

LinkedList<DateTime,string> list = new LinkedList<DateTime,string>();
list.AddHead(DateTime.Now,"AAA");

Sometimes is it useful to alias a particular combination of specific types. You can do that through the using statement, as shown in Code block 4. Note that the scope of aliasing is the scope of the file, so you have to repeat aliasing across the project files in the same way you would with using namespaces.

Code block 4. Generic type aliasing

using List = LinkedList<int,string>;

class ListClient
{
   static void Main(string[] args)
   {
      List list = new List();
      list.AddHead(123,"AAA");
   }
}

Generic Constraints

With C# generics, the compiler compiles the generic code into IL independent of any type arguments that the clients will use. As a result, the generic code could try to use methods, properties, or members of the generic type parameters that are incompatible with the specific type arguments the client uses. This is unacceptable because it amounts to lack of type safety. In C# you need to instruct the compiler which constraints the client-specified types must obey in order for them to be used instead of the generic type parameters. There are three types of constraints. A derivation constraint indicates to the compiler that the generic type parameter derives from a base type such an interface or a particular base class. A default constructor constraint indicates to the compiler that the generic type parameter exposes a default public constructor (a public constructor with no parameters). A reference/value type constraint constrains the generic type parameter to be a reference or a value type. A generic type can employ multiple constraints, and you even get IntelliSense reflecting the constraints when using the generic type parameter, such as suggesting methods or members from the base type.

It is important to note that although constraints are optional, they are often essential when developing a generic type. Without them, the compiler takes the more conservative, type-safe approach and only allows access to Object-level functionality in your generic type parameters. Constraints are part of the generic type metadata so that the client-side compiler can take advantage of them as well. The client-side compiler only allows the client developer to use types that comply with the constraints, thus enforcing type safety.

An example will go a long way to explain the need and use of constraints. Suppose you would like to add indexing ability or searching by key to the linked list of Code block 3:

public class LinkedList<K,T>
{
   T Find(K key)
   {...}
   public T this[K key]
   {
      get{return Find(key);}
   }
}

This allows the client to write the following code:

LinkedList<int,string> list = new LinkedList<int,string>();

list.AddHead(123,"AAA");
list.AddHead(456,"BBB");
string item = list[456];
Debug.Assert(item == "BBB");

To implement the search, you need to scan the list, compare each node's key with the key you're looking for, and return the item of the node whose key matches. The problem is that the following implementation of Find() does not compile:

T Find(K key)
{
   Node<K,T> current = m_Head;
   while(current.NextNode != null)
   {
      if(current.Key == key) //Will not compile
         break;
      else
         
         current = current.NextNode;
   }
   return current.Item; 
}

The reason is that the compiler will refuse to compile this line:

if(current.Key == key)

The line above will not compile because the compiler does not know whether K (or the actual type supplied by the client) supports the == operator. For example, structs by default do not provide such an implementation. You could try to overcome the == operator limitation by using the IComparable interface:

public interface IComparable 
{
   int CompareTo(object obj);
}

CompareTo() returns 0 if the object you compare to is equal to the object implementing the interface, so the Find() method could use it as follows:

if(current.Key.CompareTo(key) == 0)

Unfortunately, this does not compile either because the compiler has no way of knowing whether K (or the actual type supplied by the client) is derived from IComparable.

You could explicitly cast to IComparable to force the compiler to compile the comparing line, except doing so is at the expense of type safety:

if(((IComparable)(current.Key)).CompareTo(key) == 0)

If the type the client uses does not derive from IComparable, it results in a run-time exception. In addition, when the key type used is a value type instead of the key type parameter, you force a boxing of the key, and that may have some performance implications.

Derivation Constraints

In C# 2.0 you use the where reserved keyword to define a constraint. Use the where keyword on the generic type parameter followed by a derivation colon to indicate to the compiler that the generic type parameter implements a particular interface. For example, here is the derivation constraint required to implement the Find() method of LinkedList:

public class LinkedList<K,T> where K : IComparable
{
   T Find(K key)
   {
      Node<K,T> current = m_Head;
      while(current.NextNode != null)
      {
         if(current.Key.CompareTo(key) == 0)
            
            break;
         else      
            
            current = current.NextNode;
      }
      return current.Item; 
   }
   //Rest of the implementation 
}

You will also get IntelliSense support on the methods of interfaces you constrain.

When the client declares a variable of type LinkedList providing a type argument for the list's key, the client-side compiler will insist that the key type is derived from IComparable and will refuse to build the client code otherwise.

Note that even though the constraint allows you to use IComparable, it does not eliminate the boxing penalty when the key used is a value type, such as an integer. To overcome this, the System.Collections.Generic namespace defines the generic interface IComparable<T>:

public interface IComparable<T> 
{
   int CompareTo(T other);
   bool Equals(T other);
}

You can constrain the key type parameter to support IComparable<T> with the key's type as the type parameter, and by doing so you gain not only type safety but also eliminate the boxing of value types when used as keys:

public class LinkedList<K,T> where K : IComparable<K>
{...}

In fact, all the types that supported IComparable in .NET 1.1 support IComparable<T> in .NET 2.0. This enables the use for keys of common types such as int, string, Guid, DateTime, and so on.

In C# 2.0, all constraints must appear after the actual derivation list of the generic class. For example, if LinkedList derives from the IEnumerable<T> interface (for iterator support), you would put the where keyword immediately after it:

public class LinkedList<K,T> : IEnumerable<T> where K : IComparable<K>
{...}

In general, only define a constraint at the level where you require it. In the linked list example, it is pointless to define the IComparable<T> derivation constraint at the node level, because the node itself does not compare keys. If you do so, you will have to place the constraint at the LinkedList level as well, even if the list does not compare keys. This is because the list contains a node as a member variable, causing the compiler to insist that the key type defined at the list level complies with the constraint placed by the node on the generic key type.

In other words, if you define the node as so:

class Node<K,T> where K : IComparable<K>
{...}

Then you would have to repeat the constraint at the list level, even if you do not provide the Find() method, or any other method for that matter:

public class LinkedList<KeyType,DataType> where KeyType : IComparable<KeyType>
{
   Node<KeyType,DataType> m_Head;
}

You can constrain multiple interfaces on the same generic type parameter, separated by a comma. For example:

public class LinkedList<K,T> where K : IComparable<K>,IConvertible
{...}

You can provide constraints for every generic type parameter your class uses, for example:

public class LinkedList<K,T> where K : IComparable<K>
                             where T : ICloneable 
{...}

You can have a base class constraint, meaning, stipulating that the generic type parameter is derived from a particular base class:

public class MyBaseClass
{...}
public class LinkedList<K,T> where K : MyBaseClass
{...}

However, at most one base class can be used in a constraint because C# does not support multiple inheritance of implementation. Obviously, the base class you constrain cannot be a sealed class or a static class, and the compiler enforces that. In addition, you cannot constrain System.Delegate or System.Array as a base class.

You can constrain both a base class and one or more interfaces, but the base class must appear first in the derivation constraint list:

public class LinkedList<K,T> where K : MyBaseClass, IComparable<K>
{...}

C# does allow you to specify another generic type parameter as a constraint:

public class MyClass<T,U> where T : U 
{...}

When dealing with a derivation constraint, you can satisfy the constraint using the base type itself, not necessarily a strict sub class of it. For example:

public interface IMyInterface
{...}
public class MyClass<T> where T : IMyInterface
{...}
MyClass<IMyInterface> obj = new MyClass<IMyInterface>();

Or even:

public class MyOtherClass
{...}

public class MyClass<T> where T : MyOtherClass 
{...}

MyClass<MyOtherClass> obj = new MyClass<MyOtherClass>();

Finally, note that when providing a derivation constraint, the base type (interface or base class) you constrain must have consistent visibility with that of the generic type parameter you define. For instance, the following constraint is valid, because internal types can use public types:

public class MyBaseClass
{}
internal class MySubClass<T> where T : MyBaseClass
{}

However, if the visibility of the two classes were reversed, such as:

internal class MyBaseClass
{}
public class MySubClass<T> where T : MyBaseClass
{}

Then the compiler would issue an error, because no client from outside the assembly will ever be able to use the generic type MySubClass, rendering MySubClass in effect as an internal rather than a public type. The reason outside clients cannot use MySubClass is that to declare a variable of type MySubClass, they require to make use of a type that derives from the internal type MyBaseClass.

Constructor Constraint

Suppose you want to instantiate a new generic object inside a generic class. The problem is the C# compiler does not know whether the type argument the client will use has a matching constructor, and it will refuse to compile the instantiation line.

To address this problem, C# allows you to constrain a generic type parameter such that it must support a public default constructor. This is done using the new() constraint. For example, here is a different way of implementing the default constructor of the generic Node <K,T> from Code block 3.

class Node<K,T> where T : new() 
{
   public K Key;
   public T Item;
   public Node<K,T> NextNode;
   public Node()
   {
      Key      = default(K);
      Item     = new T();
      NextNode = null;
   }
}

You can combine the constructor constraint with derivation constraint, provided the constructor constraint appears last in the constraint list:

public class LinkedList<K,T> where K : IComparable<K>,new() 
{...}

Reference/Value Type Constraint

You can constrain a generic type parameter to be a value type (such as an int, a bool, and enum) or any custom structure using the struct constraint:

public class MyClass<T> where T : struct 

{...}

Similarly, you can constrain a generic type parameter to be a reference type (a class) using the class constraint:

public class MyClass<T> where T : class 

{...}

The reference/value type constraint cannot be used with base class constraint, because a base class constraint implies a class. Similarly, you cannot use the struct and the default constructor constraint, because a default constructor constraint too implies as class. Though you can use the class and the default constructor constraint, it adds no value. You can combine the reference/value type constraint with an interface constraint, as long as the reference/value type constraint appears first in the constraint list.

Generics and Casting

The C# compiler only lets you implicitly cast generic type parameters to Object, or to constraint-specified types, as shown in Code block 5. Such implicit casting is type safe because any incompatibility is discovered at compile-time.

Code block 5. Implicit casting of generic type parameters

interface ISomeInterface
{...}
class BaseClass
{...}
class MyClass<T> where T : BaseClass,ISomeInterface
{
   void SomeMethod(T t)
   {
      ISomeInterface obj1 = t;
      BaseClass      obj2 = t;
      object         obj3 = t;
   }
}

The compiler lets you explicitly cast generic type parameters to any other interface, but not to a class:

interface ISomeInterface
{...}
class SomeClass
{...}
class MyClass<T> 
{
   void SomeMethod(T t)
   {
      ISomeInterface obj1 = (ISomeInterface)t;//Compiles
      SomeClass      obj2 = (SomeClass)t;     //Does not compile
   }
}

However, you can force a cast from a generic type parameter to any other type using a temporary Object variable:

class SomeClass
{...}

class MyClass<T> 
{
   
   void SomeMethod(T t)
   
   {
      object temp = t;
      SomeClass obj = (SomeClass)temp;
   
   }
}

Needless to say, such explicit casting is dangerous because it may throw an exception at run time if the type argument used instead of the generic type parameter does not derive from the type to which you explicitly cast. Instead of risking a casting exception, a better approach is to use the is and as operators, as shown in Code block 6. The is operator returns true if the generic type parameter is of the queried type, and as will perform a cast if the types are compatible, and will return null otherwise. You can use is and as on both generic type parameters and on generic classes with specific type arguments.

Code block 6. Using 'is' and 'as' operators on generic type parameters

public class MyClass<T> 
{
   public void SomeMethod(T t)
   {
      if(t is int)
      {...} 

      if(t is LinkedList<int,string>)
      {...}

      string str = t as string;
      if(str != null)
      {...}

      LinkedList<int,string> list = t as LinkedList<int,string>;
      if(list != null)
      {...}
   }
}

Inheritance and Generics

When deriving from a generic base class, you must provide a type argument instead of the base-class's generic type parameter:

public class BaseClass<T>
{...}
public class SubClass : BaseClass<int>
{...}

If the subclass is generic, instead of a concrete type argument, you can use the subclass generic type parameter as the specified type for the generic base class:

public class SubClass<T> : BaseClass<T> 
{...}

When using the subclass generic type parameters, you must repeat any constraints stipulated at the base class level at the subclass level. For example, derivation constraint:

public class BaseClass<T>  where T : ISomeInterface 
{...}
public class SubClass<T> : BaseClass<T> where T : ISomeInterface
{...}

Or constructor constraint:

public class BaseClass<T>  where T : new()
{   
   public T SomeMethod()
   {
      return new T();
   }
}
public class SubClass<T> : BaseClass<T> where T : new() 
{...}

A base class can define virtual methods whose signatures use generic type parameters. When overriding them, the subclass must provide the corresponding types in the method signatures:

public class BaseClass<T>
{ 
   public virtual T SomeMethod()
   {...}
}
public class SubClass: BaseClass<int>
{ 
   public override int SomeMethod()
   {...}
}

If the subclass is generic it can also use its own generic type parameters for the override:

public class SubClass<T>: BaseClass<T>
{ 
   public override T SomeMethod()
   {...}
}

You can define generic interfaces, generic abstract classes, and even generic abstract methods. These types behave like any other generic base type:

public interface ISomeInterface<T>
{
   T SomeMethod(T t);
}
public abstract class BaseClass<T>
{
   public abstract T SomeMethod(T t);
}

public class SubClass<T> : BaseClass<T>
{
   public override T SomeMethod(T t) 
   {...)
}

There is an interesting use for generic abstract methods and generic interfaces. In C# 2.0, it is impossible to use operators such as + or += on generic type parameters. For example, the following code does not compile because C# 2.0 does not have operator constraints:

public class Calculator<T>
{
   public T Add(T arg1,T arg2)
   {
      return arg1 + arg2;//Does not compile 
   }
   //Rest of the methods 
}

Nonetheless, you can compensate using abstract methods (or preferably interfaces) by defining generic operations. Since an abstract method cannot have any code in it, you can specify the generic operations at the base class level, and provide a concrete type and implementation at the subclass level:

public abstract class BaseCalculator<T>
{
   public abstract T Add(T arg1,T arg2);
   public abstract T Subtract(T arg1,T arg2);
   public abstract T Divide(T arg1,T arg2);
   public abstract T Multiply(T arg1,T arg2);
}
public class MyCalculator : BaseCalculator<int>
{
   public override int Add(int arg1, int arg2)
   {
      return arg1 + arg2;
   }
   //Rest of the methods 
}

A generic interface will yield a somewhat cleaner solution as well:

public interface ICalculator<T>
{
   T Add(T arg1,T arg2);
   //Rest of the methods 
}
public class MyCalculator : ICalculator<int>
{
   public int Add(int arg1, int arg2)
   {
      return arg1 + arg2;
   }
   //Rest of the methods 
}

Generic Methods

In C# 2.0, a method can define generic type parameters, specific to its execution scope:

public class MyClass<T>
{
   public void MyMethod<X>(X x)
   {...}
}

This is an important capability because it allows you to call the method with a different type every time, which is very handy for utility classes.

You can define method-specific generic type parameters even if the containing class does not use generics at all:

public class MyClass
{
   public void MyMethod<T>(T t)
   {...}
}

This ability is for methods only. Properties or indexers can only use generic type parameters defined at the scope of the class.

When calling a method that defines generic type parameters, you can provide the type to use at the call site:

MyClass obj = new MyClass();
obj.MyMethod<int>(3);

That said, when the method is invoked the C# compiler is smart enough to infer the correct type based on the type of parameter passed in, and it allows omitting the type specification altogether:

MyClass obj = new MyClass();
obj.MyMethod(3);

This ability is called generic type inference. Note that the compiler cannot infer the type based on the type of the returned value alone:

public class MyClass
{
   public T MyMethod<T>()
   {}
}
MyClass obj = new MyClass();
int number = obj.MyMethod();//Does not compile

When a method defines its own generic type parameters, it can also define constraints for these types:

public class MyClass
{
   public void SomeMethod<T>(T t) where T : IComparable<T> 
   {...}
}

However, you cannot provide method-level constraints for class-level generic type parameters. All constraints for class-level generic type parameters must be defined at the class scope.

When overriding a virtual method that defines generic type parameters, the subclass method must redefine the method-specific generic type parameter:

public class BaseClass
{
   public virtual void SomeMethod<T>(T t)
   {...}
}
public class SubClass : BaseClass
{
   public override void SomeMethod<T>(T t)
   {...}
}

The subclass implementation must repeat all constraints that appeared at the base method level:

public class BaseClass
{
   public virtual void SomeMethod<T>(T t) where T : new()
   {...}
}
public class SubClass : BaseClass
{
   public override void SomeMethod<T>(T t) where T : new()
   {...}
}

Note that the method override cannot define new constraints that did not appear at the base method.

In addition, if the subclass method calls the base class implementation of the virtual method, it must specify the type argument to use instead of the generic base method type parameter. You can either explicitly specify it yourself or rely on type inference if it is available:

public class BaseClass
{ 
   public virtual void SomeMethod<T>(T t)
   {...}
}
public class SubClass : BaseClass
{
   public override void SomeMethod<T>(T t)
   {
      base.SomeMethod<T>(t);
      base.SomeMethod(t);
   }
}

Generic Static Method

C# allows you to define static methods that use generic type parameters. However, when invoking such a static method, you need to provide the concrete type for the containing class at the call site, such as in this example:

public class MyClass<T>
{
   
   public static T SomeMethod(T t)
   
   {...}
}
int number = MyClass<int>.SomeMethod(3);

Static methods can define method-specific generic type parameters and constraints, similar to instance methods. When calling such methods, you need to provide the method-specific types at the call site, either explicitly:

public class MyClass<T>
{
   public static T SomeMethod<X>(T t,X x)
   {..}
}
int number = MyClass<int>.SomeMethod<string>(3,"AAA");

Or rely on type inference when possible:

int number = MyClass<int>.SomeMethod(3,"AAA");

Generic static methods are subjected to all constraints imposed on the generic type parameter they use at the class level. As with instance method, you can provide constraints for generic type parameters defined by the static method:

public class MyClass
{
   public static T SomeMethod<T>(T t) where T : IComparable<T> 
   {...}
}

Operators in C# are nothing more than static methods and C# allows you to overload operators for your generic types. Imagine that the generic LinkedList of Code block 3 provided the + operator for concatenating linked lists. The + operator enables you to write the following elegant code:

LinkedList<int,string> list1 = new LinkedList<int,string>();
LinkedList<int,string> list2 = new LinkedList<int,string>();
 ...
LinkedList<int,string> list3 = list1+list2;

Code block 7 shows the implementation of the generic + operator on the LinkedList class. Note that operators cannot define new generic type parameters.

Code block 7. Implementing a generic operator

public class LinkedList<K,T>
{
   public static LinkedList<K,T> operator+(LinkedList<K,T> lhs,
                                           LinkedList<K,T> rhs)
   {
      return concatenate(lhs,rhs);
   }
   static LinkedList<K,T> concatenate(LinkedList<K,T> list1,
                                      LinkedList<K,T> list2)
   {
      LinkedList<K,T> newList = new LinkedList<K,T>(); 
      Node<K,T> current;
      current = list1.m_Head;
      while(current != null)
      {
         newList.AddHead(current.Key,current.Item);
         current = current.NextNode;
      }
      current = list2.m_Head;
      while(current != null)
      {
         newList.AddHead(current.Key,current.Item);
         current = current.NextNode;
      }
      return newList;
   }
   //Rest of LinkedList
}

Generic Delegates

A delegate defined in a class can take advantage of the generic type parameter of that class. For example:

public class MyClass<T>
{
   public delegate void GenericDelegate(T t);
   public void SomeMethod(T t)
   {...} 
}

When specifying a type for the containing class, it affects the delegate as well:

MyClass<int> obj = new MyClass<int>();
MyClass<int>.GenericDelegate del;

del = new MyClass<int>.GenericDelegate(obj.SomeMethod);
del(3);

C# 2.0 allows you to make a direct assignment of a method reference into a delegate variable:

MyClass<int> obj = new MyClass<int>();
MyClass<int>.GenericDelegate del;

del = obj.SomeMethod;

I am calling this feature delegate inference. The compiler is capable of inferring the type of the delegate you assign into, finding if the target object has a method by the name you specify, and verifying that the method's signature matches. Then, the compiler creates a new delegate of the inferred argument type (including the correct type instead of the generic type parameter), and assigns the new delegate into the inferred delegate.

Like classes, structs, and methods, delegates can define generic type parameters too:

public class MyClass<T>
{
   public delegate void GenericDelegate<X>(T t,X x);
}

Delegates defined outside the scope of a class can use generic type parameters. In that case, you have to provide the type arguments for the delegate when declaring and instantiating it:

public delegate void GenericDelegate<T>(T t);

public class MyClass
{
   public void SomeMethod(int number)
   {...}
}

MyClass obj = new MyClass();
GenericDelegate<int> del; 

del = new GenericDelegate<int>(obj.SomeMethod);
del(3);

Alternatively, you can use delegate inference when assigning the delegate:

MyClass obj = new MyClass();
GenericDelegate<int> del; 

del = obj.SomeMethod;

And naturally, a delegate can define constraints to accompany its generic type parameters:

public delegate void MyDelegate<T>(T t) where T : IComparable<T>;

The delegate-level constraints are enforced only on the using side, when declaring a delegate variable and instantiating a delegate object, similar to any other constraint at the scope of types or methods.

Generic delegates are especially useful when it comes to events. You can literally define a limited set of generic delegates, distinguished only by the number of the generic type parameters they require, and use these delegates for all of your event handling needs. Code block 8 demonstrates the use of a generic delegate and a generic event-handling method.

Code block 8. Generic event handling

public delegate void GenericEventHandler<S,A>(S sender,A args);
public class MyPublisher
{
   public event GenericEventHandler<MyPublisher,EventArgs> MyEvent;
   public void FireEvent()
   {
      MyEvent(this,EventArgs.Empty);
   }
}
public class MySubscriber<A> //Optional: can be a specific type
{
   public void SomeMethod(MyPublisher sender,A args)
   {...}
}
MyPublisher publisher = new MyPublisher();
MySubscriber<EventArgs> subscriber = new MySubscriber<EventArgs>();
publisher.MyEvent += subscriber.SomeMethod;

Code block 8 uses a generic delegate called GenericEventHandler, which accepts a generic sender type and a generic type parameter. Obviously, if you need more parameters, you can simply add more generic type parameters, but I wanted to model GenericEventHandler after the non-generic .NET EventHandler, defined as:

public void delegate EventHandler(object sender,EventArgs args);

Unlike EventHandler, GenericEventHandler is type safe, as shown in Code block 8 because it accepts only objects of the type MyPublisher as senders, rather than mere Object. In fact, .NET already defines a generic flavor of EventHandler in the System namespace:

public void delegate EventHandler(object sender,A args) where A : EventArgs;

Generics and Reflection

In .NET 2.0, reflection is extended to support generic type parameters. The type Type can now represent generic types with specific type arguments (called bounded types), or unspecified (unbounded) types. As in C# 1.1, you can obtain the Type of any type by using the typeof operator or by calling the GetType() method that every type supports. Regardless of the way you choose, both yield the same Type. For example, in the following code sample, type1 is identical to type2.

LinkedList<int,string> list = new LinkedList<int,string>();

Type type1 = typeof(LinkedList<int,string>);
Type type2 = list.GetType();
Debug.Assert(type1 == type2);

Both typeof and GetType() can operate on generic type parameters:

public class MyClass<T> 
{
   public void SomeMethod(T t)
   {
      Type type = typeof(T);
      Debug.Assert(type == t.GetType());
   }
}

In addition, the typeof operator can operate on unbounded generic types. For example:

public class MyClass<T> 
{}
Type unboundedType = typeof(MyClass<>);
Trace.WriteLine(unboundedType.ToString());
//Writes: MyClass`1[T]

The number 1 being traced is the number of generic type parameters of the generic type used. Note the use of the empty <>. To operate on an unbounded generic type with multiple type parameters, use a "," in the <>:

public class LinkedList<K,T> 
{...}
Type unboundedList = typeof(LinkedList<,>);
Trace.WriteLine(unboundedList.ToString());
//Writes: LinkedList`2[K,T]

Type has new methods and properties designed to provide reflection information about the generic aspect of the type. Code block 9 shows the new methods.

Code block 9. Type's generic reflection members

public abstract class Type : //Base types
{
   public virtual bool ContainsGenericParameters{get;}
   public virtual int GenericParameterPosition{get;}
   public virtual bool HasGenericArguments{get;}
   public virtual bool IsGenericParameter{get;}
   public virtual bool IsGenericTypeDefinition{get;}
   public virtual Type BindGenericParameters(Type[] typeArgs);
   public virtual Type[] GetGenericArguments();
   public virtual Type GetGenericTypeDefinition();
   //Rest of the members
}

The most useful of these new members are the HasGenericArguments property and the GetGenericArguments () and GetGenericTypeDefinition() methods. The rest of Type's new members are for advanced and somewhat esoteric scenarios beyond the scope of this article.

As its name indicates, HasGenericArguments is set to true if the type represented by the Type object uses generic type parameters. GetGenericArguments() returns an array of Types corresponding to the type arguments used. GetGenericTypeDefinition() returns a Type representing the generic form of the underlying type. Code block 10 demonstrates using these generic-handling Type members to obtain generic reflection information on the LinkedList from Code block 3.

Code block 10. Using Type for generic reflection

LinkedList<int,string> list = new LinkedList<int,string>();

Type boundedType = list.GetType();
Trace.WriteLine(boundedType.ToString());
//Writes: LinkedList`2[System.Int32,System.String]

Debug.Assert(boundedType.HasGenericArguments);

Type[] parameters = boundedType.GetGenericArguments();

Debug.Assert(parameters.Length == 2);
Debug.Assert(parameters[0] == typeof(int));
Debug.Assert(parameters[1] == typeof(string));

Type unboundedType = boundedType.GetGenericTypeDefinition();
Debug.Assert(unboundedType == typeof(LinkedList<,>));
Trace.WriteLine(unboundedType.ToString());
//Writes: LinkedList`2[K,T]

Similar to Type, MethodInfo and its base class MethodBase have new members that reflect generic method information.

As in C# 1.1, you can use MethodInfo (as well as a number of other options) for late binding invocation. However, the type of the parameters you pass for the late binding must match the bounded types used instead of the generic type parameters (if any):

LinkedList<int,string> list = new LinkedList<int,string>();
Type type = list.GetType();
MethodInfo methodInfo = type.GetMethod("AddHead");
object[] args = {1,"AAA"};
methodInfo.Invoke(list,args);

Attributes and Generics

When defining an attribute, you can instruct the compiler that the attribute should target generic type parameters, using the new GenericParameter value of the enum AttributeTargets:

[AttributeUsage(AttributeTargets.GenericParameter)] 
public class SomeAttribute : Attribute
{...}

Note that C# 2.0 does not allow you to define generic attributes.

//Does not compile:
public class SomeAttribute<T> : Attribute 
{...}

Yet internally, an attribute class can take advantage of generics by using generic types or define helper generic methods, like any other type:

public class SomeAttribute : Attribute
{
   void SomeMethod<T>(T t)
   {...}
   LinkedList<int,string> m_List = new LinkedList<int,string>();
}

Generics and the .NET Framework

To conclude this article, here are how some other areas in .NET besides C# itself are taking advantage of or interacting with generics.

System.Array and Generics

The System.Array type is extended with many generic static methods. The generic static methods are designed to automate and streamline common tasks of working with arrays, such as iterating over the array and performing an action on each element, scanning the array looking for a value that matches a certain criteria (a predicate), converting and sorting the array, and so on. Code Block 11 is a partial listing of these static methods.

Code block 11. The generic methods of System.Array

public abstract class Array
{
   //Partial listing of the static methods:  
   public static IList<T> AsReadOnly<T>(T[] array);
   public static int BinarySearch<T>(T[] array, T value);
   public static int BinarySearch<T>(T[] array, T value,
                                     IComparer<T> comparer);
   public static U[] ConvertAll<T,U>(T[] array, 
                                Converter<T,U> converter);
   public static bool Exists<T>(T[] array,Predicate<T> match);
   public static T Find<T>(T[] array,Predicate<T> match);
   public static T[] FindAll<T>(T[] array, Predicate<T> match);
   public static int FindIndex<T>(T[] array, Predicate<T> match);
   public static void ForEach<T>(T[] array, Action<T> action);
   public static int  IndexOf<T>(T[] array, T value);
   public static void Sort<K,V>(K[] keys, V[] items,
                                IComparer<K> comparer);
   public static void Sort<T>(T[] array,Comparison<T> comparison) 
}

System.Array's static generic methods all work with the following four generic delegates defined in the System namespace:

public delegate void Action<T>(T t);
public delegate int Comparison<T>(T x, T y);
public delegate U Converter<T, U>(T from);
public delegate bool Predicate<T>(T t);

Code block 12 demonstrates using these generic methods and delegates. It initializes an array with all the integers from 1 to 20. Then, using an anonymous method and the Action<T> delegate, the code traces these numbers using the Array.ForEach() method. Using a second anonymous method and the Predicate<T> delegate, the code finds all the prime numbers in the array by calling the Array.FindAll() method, which returns another array of the same generic type. Finally, the prime numbers are traced using the same Action<T> delegate and anonymous method. Note the use of type parameter inference in Code block 12. You can use the static methods without specifying the type parameters.

Code block 12. Using the generic methods of System.Array

int[] numbers = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20};
Action<int> trace =  delegate(int number)
                     {
                        Trace.WriteLine(number);
                     };
Predicate<int> isPrime =   delegate(int number)
                           {
                              switch(number)
                              {
                                case 1:case 2:case 3:case 5:case 7:                                 
                                case 11:case 13:case 17:case 19:
                                    return true;
                                 default:
                                    return false;
                              }
                           };
Array.ForEach(numbers,trace);
int[] primes = Array.FindAll(numbers,isPrime);
Array.ForEach(primes,trace);

Similar generic methods are also available on the class List<T> defined in the System.Collections.Generic namespace. These methods use the same four generic delegates. In fact, you can take advantage of those delegates in your code too, as shown in the following section.

The Static Collection Class

While both System.Array and List<T> offer handy utility methods that greatly simplify working with them, .NET does not offer such support for other collections. To compensate, the source code available with this article includes the static helper class Collection, defined as:

public static class Collection
{
   public static IList<T> AsReadOnly<T>(IEnumerable<T> collection);
   public static U[] ConvertAll<T,U>(IEnumerable<T> collection,
                                     Converter<T,U> converter);
   public static bool Contains<T>(IEnumerable<T> collection,T item) 
                                               where T : IComparable<T>;
   public static bool Exists<T>(IEnumerable<T> collection,Predicate<T>); 
   public static T Find<T>(IEnumerable<T> collection,Predicate<T> match);
   public static T[] FindAll<T>(IEnumerable<T> collection,
                                Predicate<T> match);
   public static int FindIndex<T>(IEnumerable<T> collection,T value) 
                                                where T : IComparable<T>;
   public static T FindLast<T>(IEnumerable<T> collection,
                               Predicate<T> match);
   public static int FindLastIndex<T>(IEnumerable<T> collection,T value) 
                                                where T : IComparable<T>;
   public static void ForEach<T>(IEnumerable<T> collection,Action<T> action);
   public static T[] Reverse<T>(IEnumerable<T> collection);
   public static T[] Sort<T>(IEnumerable<T> collection);
   public static T[] ToArray<T>(IEnumerable<T> collection);
   public static bool TrueForAll<T>(IEnumerable<T> collection,
                                    Predicate<T> match);
   //Overloaded versions for IEnumerator<T> 
}

The implementation of Collection is straightforward. For example, here is the ForEach<T>() method:

public static void ForEach<T>(IEnumerator<T> iterator,Action<T> action)
{
   /* Some parameter checking here, then: */
   while(iterator.MoveNext())
   {
      action(iterator.Current);
   }
}

The Collection static class is used very similar to both Array and List<T>, utilizing the same generic delegates. You can use Collection with any collection, as long as that collection supports either IEnumerable or IEnumerator:

Queue<int> queue = new Queue<int>();
//Some code to initialize queue
Action<int> trace =  delegate(int number)
                     {
                        Trace.WriteLine(number);
                     };
Collection.ForEach(queue,trace);

Generic Collections

The data structures in System.Collections are all Object-based, and thus inheriting the two problems described at the beginning of this article, namely, inferior performance and lack of type safety. .NET 2.0 introduces a set of generic collections in the System.Collections.Generic namespace. For example, there are generic Stack<T> and a generic Queue<T> classes. The Dictionary<K,T> data structure is equivalent to the non-generic HashTable, and there is also a SortedDictionary<K,T> class somewhat like SortedList. The class List<T> is analogous to the non-generic ArrayList. Table 1 maps the main types of System.Collections.Generic to those of System.Collections.

Table 1. Mapping System.Collections.Generic to System.Collections

System.Collections.Generic	System.Collections
Comparer<T>	Comparer
Dictionary<K,T>	HashTable
LinkedList<T>	-
List<T>	ArrayList
Queue<T>	Queue
SortedDictionary<K,T>	SortedList
Stack<T>	Stack
ICollection<T>	ICollection
IComparable<T>	System.IComparable
IDictionary<K,T>	IDictionary
IEnumerable<T>	IEnumerable
IEnumerator<T>	IEnumerator
IList<T>	IList

All the generic collections in System.Collections.Generic also implement the generic IEnumerable<T> interface, defined as:

public interface IEnumerable<T>
{
   IEnumerator<T> GetEnumerator();
} 
public interface IEnumerator<T> : IDisposable
{
   T Current{get;}
   bool MoveNext();
}

Briefly, IEnumerable<T> provides access to the IEnumerator<T> iterator interface, used for abstracted iterations over the collection. All the collections implement IEnumerable<T> on a nested struct, where the generic type parameter T is the type the collection stores.

Of particular interest is the way the dictionary collections define their iterators. A dictionary is actually a collection of not one but two types of generic parameter—the key and the value. System.Collection.Generic provides a generic struct called KeyValuePair<K,V> defined as:

struct KeyValuePair<K,V>
{
   public KeyValuePair(K key,V value);
   public K Key(get;set;)
   public V Value(get;set;)
}

KeyValuePair<K,V> simply stores a pair of a generic key and a generic value. This struct is what the dictionary manages as a collection, and what it uses for its implementation of IEnumerable<T>. The Dictionary class specifies the generic KeyValuePair<K,V> structure as the item argument for IEnumerable<T> and ICollection<T>:

public class Dictionary<K,T> : IEnumerable<KeyValuePair<K,T>>, 
                               ICollection<KeyValuePair<K,T>>, 
                               //More interfaces
{...}

The key and value type parameters used in KeyValuePair<K,V> are of course the dictionary's own generic key and value type parameters. You can certainly do the same in your own generic data structures that use pairs of keys and values. For example:

public class LinkedList<K,T> : IEnumerable<KeyValuePair<K,T>> where K : IComparable<K>
{...}

Serialization and Generics

.NET allows you to have serializable generic types:

[Serializable]
public class MyClass<T>
{...}

When serializing a type, besides the state of the object members, .NET persists metadata about the object and its type. If the serializable type is generic and it contains bounded types, the metadata about the generic type contains type information about the bounded types as well. Consequently, each permutation of a generic type with a specific argument type is considered a unique type. For example, you cannot serialize an object type MyClass<int> but deserialize it into an object of type MyClass<string>. Serializing an instance of a generic type is no different from serializing a non-generic type. However, when deserializing that type, you need to declare a variable with matching specific types, and specify these types again when down casting the Object returned from Deserialize. Code block 13 shows serialization and deserialization of a generic type.

Code block 13. Client-side serialization of a generic type

[Serializable]
public class MyClass<T>
{...}
MyClass<int> obj1 = new MyClass<int>();

IFormatter formatter = new BinaryFormatter(); 
Stream stream = new FileStream("obj.bin",FileMode.Create,FileAccess.ReadWrite); 
using(stream)
{
   formatter.Serialize(stream,obj1);
   stream.Seek(0,SeekOrigin.Begin);

   MyClass<int> obj2; 
   obj2 = (MyClass<int>)formatter.Deserialize(stream);
}

Note that IFormatter is object-based. You can compensate by defining a generic version of IFormatter:

public interface IGenericFormatter
{
   T Deserialize<T>(Stream serializationStream);
   void Serialize<T>(Stream serializationStream,T graph);
}

You can implement IGenericFormatter by containing an-object based formatter:

public class GenericFormatter<F> : IGenericFormatter 
                                   where F : IFormatter,new()
{
   IFormatter m_Formatter = new F();
   public T Deserialize<T>(Stream serializationStream)
   {
      return (T)m_Formatter.Deserialize(serializationStream);
   }
   public void Serialize<T>(Stream serializationStream,T graph)
   {
      m_Formatter.Serialize(serializationStream,graph);
   }
}

Note the use of the two constraints on the generic type parameter F. While it is possible to use GenericFormatter<F> as-is:

   
using GenericBinaryFormatter = GenericFormatter<BinaryFormatter>;
using GenericSoapFormatter2  = GenericFormatter<SoapFormatter>;

You can also strongly-type the formatter to use:

public sealed class GenericBinaryFormatter : GenericFormatter<BinaryFormatter>
{}
public sealed class GenericSoapFormatter : GenericFormatter<SoapFormatter>
{}

The advantage of a strongly-typed definition is that you can share it across files and assemblies, as opposed to the using alias.

Code block 14 is the same as Code block 13 expect it uses the generic formatter:

Code block 14. Using IGenericFormatter

[Serializable]
public class MyClass<T>
{...}
MyClass<int> obj1 = new MyClass<int>();

IGenericFormatter formatter = new GenericBinaryFormatter(); 
Stream stream = new FileStream("obj.bin",FileMode.Create,FileAccess.ReadWrite); 
using(stream)
{
   formatter.Serialize(stream,obj1);
   stream.Seek(0,SeekOrigin.Begin);
   MyClass<int> obj2; 
   obj2 = formatter.Deserialize(stream);
}

Generics and Remoting

You can define and deploy remote classes that utilize generics, and you can use programmatic or administrative configuration. Consider the class MyServer<T> that uses generics and is derived from MarshalByRefObject:

public class MyServer<T> : MarshalByRefObject
{...}

You can only access this class over remoting when the type parameter T is a marshalable object. This implies that T is either a serializable type or is derived from MarshalByRefObject. You can enforce that by constraining T to derive from MarshalByRefObject:

public class MyServer<T> : MarshalByRefObject 
                           where T : MarshalByRefObject
{...}

When using administrative type registration, you need to specify the exact type arguments to use instead of the generic type parameters. You must name the types in a language-neutral manner, and provide fully qualified namespaces. For example, suppose the class MyServer<T> is defined in the namespace RemoteServer in the assembly ServerAssembly, and you want to use it with integer instead of the generic type parameter T, in client activated mode. In that case, the required client-side type registration entry in the configuration file would be:

<client url="...some url goes here..."> 
   <activated type="RemoteServer.MyServer[[System.Int32]],ServerAssembly"/>
</client>

The matching host-side type registration entry in the configuration file is:

<service> 
   <activated type="RemoteServer.MyServer[[System.Int32]],ServerAssembly"/> 
</service>

The double square brackets are used to specify multiple types. For example:

LinkedList[[System.Int32],[System.String]]

When using programmatic configuration, you configure activation modes and type registration similar to C# 1.1, except when defining the type of the remote object you have to provide type arguments instead of the generic type parameters. For example, for host-side activation mode and type registration you would write:

Type serverType = typeof(MyServer<int>);
RemotingConfiguration.RegisterActivatedServiceType(serverType);

For client-side type activation mode and location registration, you have the following:

Type serverType = typeof(MyServer<int>);      
string url = ...; //some url initialization 
RemotingConfiguration.RegisterWellKnownClientType(serverType,url);

When instantiating the remote server, simply provide the type arguments, just as if you where using a local generic type:

MyServer<int> obj;
obj = new MyServer<int>();
//Use obj

Instead of using new, the client can optionally use the methods of the Activator class to connect to remote objects. When using Activator.GetObject() you need to provide the type arguments to use, and provide the argument types when explicitly casting the returned Object:

string url = ...; //some url initialization 
Type serverType = typeof(MyServer<int>);
MyServer<int> obj;
obj = (MyServer<int>)Activator.GetObject(serverType,url);
//Use obj

You can also use Activator.CreateInstance() with generic types:

Type serverType = typeof(MyServer<int>);
MyServer<int> obj;
obj = (MyServer<int>)Activator.CreateInstance(serverType);
//Use obj

In fact, Activator also offers a generic version of CreateInstance(), defined as:

T CreateInstance<T>();

CreateInstance<T>() is used similar to the non-generic flavor, only with the added benefit of type safety:

Type serverType = typeof(MyServer<int>);
MyServer<int> obj;
obj = Activator.CreateInstance(serverType);
//Use obj

What Generics Cannot Do

Under .NET 2.0, you cannot define generic Web services. That is, Web methods that use generic type parameters. The reason is that none of the Web service standards support generic services.

You also cannot use generic types on a serviced component. The reason is that generics do not meet COM visibility requirements, which are required for serviced components (just like you could not use C++ templates in COM or COM+).

Conclusion

C# generics are an invaluable part of your development arsenal. They improve performance, type safety and quality, reduce repetitive programming tasks, simplify the overall programming model, and do so with elegant, readable syntax. While the roots of C# generics are C++ templates, C# takes generics to a new level by providing compile-time safety and support. C# utilizes two-phase compilation, metadata, and innovative concepts such as constraints and generic methods. No doubt future versions of C# will continue to evolve generics, adding new capabilities and extending generics to other areas of .NET Framework such as data access or localization.

.Net

Dot Net Questions - Part 1

IXmlSerializable – Control XML Serialization

Code

Output

Generic Serialize Deserialize - XmlSerializer

Programmatically Compile And Use Code Using C#

Introduction

How To

Extension Methods In Dot Net, C#

SYNTAX

Syntax Explanation

Usage

Extending Interfaces

Extension Method Chaining

Ambiguity and Resolution

Extension methods v.s. instance methods

Extension methods versus extension methods

Delegates VS Interfaces

Introduction to C# Events

Field-like events

Event accessors

Static and instance events

Virtual, sealed, override, and abstract accessors

Introduction to C# Delegates

Delegate declarations

Delegate compatibility

Delegate instantiation

Delegate invocation

Introduction to C# Generics (MSDN)

Contents

Introduction

Generics Problem Statement

What Are Generics

Generics Implementation

Generics Benefits

Applying Generics

Multiple Generic Types

Generic Constraints

Derivation Constraints

Constructor Constraint

Reference/Value Type Constraint

Generics and Casting

Inheritance and Generics

Generic Methods

Generic Static Method

Generic Delegates

Generics and Reflection

Attributes and Generics

Generics and the .NET Framework

System.Array and Generics

The Static Collection Class

Generic Collections

Serialization and Generics

Generics and Remoting

What Generics Cannot Do

Conclusion