Add <NonSerialized()> attribute to implicitly created xxxEvent private fields??

  • Thread starter Thread starter Samuel R. Neff
  • Start date Start date
S

Samuel R. Neff

Is there a way to add the NonSerialized attribute to the "Event"
fields that the VB.NET compiler creates when you declare an event?

I have a class that we use with binary serialization and we just added
two events so now old files won't deserialize to the new class. It
says it was expecting 2 more fields, obviously corresponding to the
two private fields created for the events.

I tried adding the fields explicitly with the NonSerialized attribute
but then I get a compiler error about the names conflicting.

Thanks,

Sam
 
Hi

Based on my understanding, you wants to mark a event in VB.NET as
NonSerialized.
In C# 1.1 we have an attribute [field:NonSerialized].
Unfortunately this is not supported in VB.NET on .net framework 1.1 and it
will be added in vb.net 2005.
Here is a link for your reference.

..NET 2.0 solution to serialization of objects that raise events
http://www.lhotka.net/WeBlog/PermaLink.aspx?guid=776f44e8-aaec-4845-b649-e0d
840e6de2c

Best regards,

Perter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
That's a lot of code to fix a simple problem--the C# solution is fine
for most cases and certainly would be good as an option in VB.NET.
The proposed solution replaces a single attribute with ~13 lines of
code (assuming the custom functions just marshal the calls to a
declared non-serializable delegate).

Best regards,

Sam
 
Peter,
In C# 1.1 we have an attribute [field:NonSerialized].
... it
will be added in vb.net 2005.
Click to expand...
Are you certain it will be added, Lhotka's sample does not show:

<Field: NonSerialized> _
Public Event NameChanged As EventHander

Which is what most if not all of my serialization code needs, rarely do I
need Custom Events that Rocky shows, where some of the handlers are
serialized & some are not.

I have classes that have multiple events, these classes are serialzed to
files using Binary Serialization. The event handlers do not need to be
serialized with the file, using <Field: NonSerialized> would save 12+ lines
of code per event, which would reduce a significant amount of duplicate
code!

Also the above would solve *all* the questions I've seen on events being
serialized in the newsgroups.

VB.NET 2005 really needs both flavors, just as C# 1.0 supported both flavors
([field:NonSerialized] & custom events).

In other words, as Samuel suggests the custom event is an excessive amount
of code for what is a simply problem in most cases...

Hope this helps
Jay

"Peter Huang" said:
Hi

Based on my understanding, you wants to mark a event in VB.NET as
NonSerialized.
In C# 1.1 we have an attribute [field:NonSerialized].
Unfortunately this is not supported in VB.NET on .net framework 1.1 and it
will be added in vb.net 2005.
Here is a link for your reference.

NET 2.0 solution to serialization of objects that raise events
http://www.lhotka.net/WeBlog/PermaLink.aspx?guid=776f44e8-aaec-4845-b649-e0d
840e6de2c

Best regards,

Perter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no
rights.
Click to expand...
 
Hi Jay,

Thanks for your feedback.
And I am sorry if I have made any mistake, in our internal document, we are
planning to add the feature in vb 2005, since the whidbey is not released
so far, so I can not guarantee if the feature will occur in the release
version.

Hope this helps.

Best regards,

Perter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Sam,

Thanks for your feedback.
We will try to keep improving our product to make VB.NET a more powerful
dev tool.

Best regards,

Perter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top