Miscellaneous - Effective C# - page 301

Finally, watch out for non-CLS types sneaking into an interface when you
use polymorphic arguments. It's easy to do with event arguments. You can
create a type that is not compliant with CLS and use it where a base type
that is CLS-compliant is expected.
Suppose that you created this class derived from EventArgs:
public class BadEventArgs : EventArgs
{
public UInt32 ErrorCode;
}
The BadEventArgs type is not CLS compliant; you should not use it with
event handlers written in other languages. But polymorphism makes this
easy to do. You can declare the event type to use the base class, EventArgs:
// Hiding the non-compliant event argument:
public delegate void MyEventHandler (
object sender, EventArgs args );
public event MyEventHandler OnStuffHappens;
// Code to raise Event:
BadEventArgs arg = new BadEventArgs ();
arg.ErrorCode = 24 ;
// Interface is legal, runtime type is not:
OnStuffHappens( this , arg);
The interface declaration, which uses an EventArgs argument, is CLS com-
pliant. However, the actual type you substituted in the event arguments
was not. The end result is a type that some languages cannot use. Devel-
opers trying to use those types will not be able to call the methods in your
assembly. Their language may even hide the visibility of those APIs. Or,
they may show that the APIs exist but not provide a way to access them.
This discussion of CLS compliance ends with how CLS-compliant classes
implement compliant or noncompliant interfaces. It can get complicated,
but we'll simplify it. Understanding CLS compliance with interfaces also
will help you fully understand what it means to be CLS compliant and
how the environment views compliance.