VB.NET object "bloating" and WCF

  • Thread starter Thread starter sloan
  • Start date Start date
S

sloan

VB.NET object "bloating" and WCF.


//quote from web page
This can result in the following undesirable situations:
a.. You end up serializing objects that you didn't expect, resulting in a
larger stream.
b.. If the object handling the events is not Serializable, then the
serialization process will throw an exception.
The root of the problem is the fact that you cannot apply the
<NonSerialized> attribute to events in VB (you can in C# by using the Field:
modifier).
//end quote
from
http://www.codeproject.com/vb/net/serializevbclasses.asp




Does anyone know if this VB.NET object "bloating" (where it serializes more
than it has to) is addressed in 2.0?



The reason I am asking is that I want to go to a WCF architecture, but some
of my back end business objects are already written in vb.net.

I need to know if I need to pay the piper now and translate them to C# to
avoid this issue.

My assumptions are that because WCF relies so heavily on serialization, I
feel this is a big gotcha which could happen.

Anybody have an idea that in VB.net 2.0 if this can be a big WCF gotcha? Or
am I barking up the wrong tree?

Thanks
 
If you use [DataContract] then this is "opt-in" (unlike [Serializable]
which is "opt-out"), so it shouldn't be included.

Otherwise; it is more code, but I'm wondering if custom event
implementation (e.g. http://www.simple-talk.com/content/print.aspx?article=224)
might be the answer? Then you can presumably control access at the
field level.

But I'm a C# person, so this is only a "perhaps"...

Marc
 
Yeah, I'm a C# person as well.
(http://sholliday.spaces.live.com/)

And these VB.NET nuances irk the crap out of me.
99.9% of the time VB.NET is the same as C# (before I get a bunch of posts
telling me how smug I am).
But those 0.1% really bite when you hit them.

Anyway. Like I said, it may be the reason to convert existing code to C#
and be done with it.



...
 
Back
Top