Frans Bouma's blog

Generator.CreateCoolTool();

Syndication

News

    Visit LLBLGen Pro's website

    Follow FransBouma on Twitter

    Add to Technorati Favorites

About me

Fun stuff I created

My work

Here's a (big, bad) difference between VB.NET and C#

Ricardo blogs about the differences between C# and VB.NET. Well, I'll give you one, which is very harmful in some areas.

Class C is a derived class from DataTable. DataTable implements ISerializable, but does this private. Class C has a new member variable which has to be serialized as well. Simply adding '[Serializable]' to Class C doesn't work, because a base class already implements ISerializable. So C has to implement ISerializable too.

Because DataTable implements ISerializable private (ISerializable.GetObjectData() is private), this can be a problem, since I have to do the complete serialization of C and the data in its base class by hand. Dino Esposito wrote an article about that, it's located here.

Using Dino's article, I can implement ISerializable and the GetObjectData() code to serialize the data and the private membervariable of C. That is... in C#. In VB.NET you can't, because the VB.NET compiler will throw an error that a base class of C already implements ISerializable. There is no way in VB.NET to re-implement ISerializable or to make the serialization formatter call a GetObjectData() method defined in C to do the serialization, simply because it will see the GetObjectData() method of DataTable as the implementation of ISerializable.GetObjectData(), which will serialize the DataTable contents, but not private member variables of derived classes.

Now, it took me some time to work around this (create a C# class with the member variable, derive the VB.NET class from that class) and it still isn't a solution which will work in all cases. In other words: VB.NET lacks re-implementation of interface members and with classes like DataTable in .NET (some winforms controls also have some interface members implemented privately, so you can't re-implement them) which have a privately implemented ISerializable, VB.NET can be a struggle in some situations, so be careful which language to pick for some of your classes.

Published Wednesday, November 12, 2003 11:15 PM by FransBouma

Comments

# re: Here's a (big, bad) difference between VB.NET and C#@ Wednesday, November 12, 2003 5:30 PM

You don't have to look THAT far to find crippling differences - lack of C variable types (such as unsigned bytes, words etc) makes VB.NET totally unusable for many low level scenarios such as encyption, hashing, CRC algorithms, etc.

Addy Santo

# re: Here's a (big, bad) difference between VB.NET and C#@ Wednesday, November 12, 2003 6:53 PM

This might sound stupid, but how would you go about doing private implementation of an interface? Did you mean not declaring the interface name in the class declaration and just writing out the methods of the interface as regular methods?

Roy Osherove

# re: Here's a (big, bad) difference between VB.NET and C#@ Wednesday, November 12, 2003 9:03 PM

Well, my guess is that sort of thing would just make Mort's head hurt, so it has no place in VB.

As far ass private implementations:

interface IFoo { void Bar(); }

class X: IFoo
{
void IFoo.Bar() { }
}

elsewhere, you can't do this:
X x = new X();
x.Bar(); // not allowed

but you can do this:
IFoo f = x;
f.Bar();

Mickey Williams

# re: Here's a (big, bad) difference between VB.NET and C#@ Wednesday, November 12, 2003 9:05 PM

ROFL: make that as, not ass

Mickey Williams again

# re: Here's a (big, bad) difference between VB.NET and C#@ Wednesday, November 12, 2003 10:15 PM

Micky, Thanks. BTW, I'm a Mort :) My head isn't hurting one bit, but my pride is a little.

Roy Osherove

# re: Here's a (big, bad) difference between VB.NET and C#@ Thursday, November 13, 2003 2:57 AM

Can't you use shadowing to resolve this issue?
Use the Shadows keyword on the GetObjectData() method. From the Visual Basic Language Reference: "If the shadowing element is not accessible from the code referring to it, for example if it is Private, the reference is resolved to the shadowed element."

Sander

# re: Here's a (big, bad) difference between VB.NET and C#@ Thursday, November 13, 2003 3:03 AM

Sander: No, because you have to specify Implements ISerializable with the class, which is not allowed. :)

Mickey: indeed, that's they way you can do it in C#, and that's the way MS did implement ISerializable on DataTable. Of course that's a bad way to design a class, nevertheless, VB.NET can't 'fix' that, only C# can.

Frans Bouma

# Interface reimplementation@ Friday, November 14, 2003 6:57 AM

Will be supported soon.

TrackBack

# re: Here's a (big, bad) difference between VB.NET and C#@ Thursday, December 11, 2003 11:01 AM

C# lets you define a new GetObjectData method, but you still can't call the original method. So you still need to recode the base class implementation. e.g.:

public class MyTable : DataTable, ISerializable
{
void ISerializable.GetObjectData(SerializationInfo info, StreamingContext context)
{
((ISerializable)this).GetObjectData(info, context); // calls this method, not the base class
((ISerializable)base).GetObjectData(info, context); // compiler error
base.GetObjectData(info, context); // compiler error
}
}

Carlos

# re: Here's a (big, bad) difference between VB.NET and C#@ Tuesday, December 23, 2003 1:15 PM

I don't know if this will work for DataTable, but take a look at the ISerialization details of extending ApplicationException in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncscol/html/csharp08162001.asp.

Chuck Eaker

# re: Here's a (big, bad) difference between VB.NET and C#@ Friday, May 28, 2004 5:55 AM

This should work, right?

public interface Base
{
void foo();
}

public class Derived1 : Base
{
void Base.foo()
{
Console.WriteLine("Derived1");
}
}

public class Derived2: Derived1
{
public void foo()
{
Base b = (Base)base.MemberwiseClone();
b.foo();
Console.WriteLine("Derived2");
}

}

So, wouldn't this be easier?(Kindly correct me if I've misunderstood s'thing)

Krishnan

# re: Here's a (big, bad) difference between VB.NET and C#@ Friday, May 28, 2004 6:23 AM

Geez. I forgot its VB.Net counterpart! Here it is:

Interface Base
Sub Foo()
End Interface

Class Derived1
Implements Base

Private Sub Foo() Implements Base.Foo
Console.WriteLine("Derived1")
End Sub
End Class

Class Derived2
Inherits Derived1


Public Sub Foo()
Dim x As Base
x = Me
x.Foo()
Console.WriteLine("Derived2")
End Sub
End Class


And you can test the code with a Module:

Module Module1

Sub Main()
Dim x As New Derived2
Dim i As Base
i = x
i.Foo()
x.Foo()
Console.ReadLine()
End Sub

End Module

Krishnan

# re: Here's a (big, bad) difference between VB.NET and C#@ Friday, May 28, 2004 6:27 AM

And well...there's so many good things about C# here that am compelled to ask if there's any equivalent of the MyClass keyword of VB .Net in C#.

Thanks
Krishnan

Krishnan

# re: Here's a (big, bad) difference between VB.NET and C#@ Tuesday, June 08, 2004 10:34 AM

There is another way (there is always another way!) Krishnan's example is OK but has the caveat that the base class implement the Foo method as private, which may not suit. My way is not really perfect as it requires a base class to declare the implemented interface method as overridable - which may be a bad thing and something you want to avoid. A base class shouldn't really have to know how a sub class is going to do things.

But if you must redefine the code for an implemented method this will work.

It would be nicer if you didn't have to. Why, Microsoft, are we still having to kludge these things! Shades of VB6 collection all over again...

Interface IBase
Sub Foo()
End Interface

Class BaseClass
Implements IBase

Public Overrideable Sub Foo() Implements IBase.Foo
console.Writeline "BaseClass.Foo"
End Sub

End Class

Class SubClass
Inherits BaseClass

Public Overrides Sub Foo()
Mybase.Foo() '<-- optional
console.WriteLine "SubClass.Foo"
End Class

Bruce Chapman

# re: More interesting stuff on Interfaces..@ Wednesday, December 29, 2004 9:06 AM

TrackBack