I guess I should explain why
this base class is so evil. The problem comes from it providing the
element of surprise to classes that derive from it. Let's take the example a
bit further.
In one assembly, say Evil.dll, let's put
the EvilBaseClass - although we'll make it
benign to start off with (its evilness will only become apparent later).
class EvilBaseClass
{
}
Now, in another assembly, let's put a derived class (and the app thats going to
drive this).
class App
{
static void Main()
{
object o = new InnocentBystander();
System.Console.WriteLine(o);
}
}
class InnocentBystander : EvilBaseClass
{
public override string ToString()
{
return "Hooray!";
}
}
If we run this it prints out
Hooray!
OK, now lets make EvilBaseClass really evil.
class EvilBaseClass
{
public new virtual string ToString()
{
return string.Empty;
}
}
We rebuild Evil.dll and redeploy it. Now run the
Application and it prints out
InnocentBystander
Ahh, so even though we haven't rebuilt the application assembly, the
InnocentBystander is no longer overriding System.Object.ToString,
magically it is now overriding EvilBaseClass.ToString
which as far is the CLR is concerned is a completely unlated method to
System.Object.ToString and it didn't even exist when we built the
application.
All of this goes to show just how dangerous a keyword combination
new virtual really is.