序列化 - Pesky VB的事件实现。 [英] Serialization - Pesky VB's Event implementation.

问题描述

Heya All，


对不起，我觉得现在是时候换一只猴子了。


我''我只是试图用VB来序列化甚至简单的对象。你可能会想到一个简单的任务 - 坚持< Serialized（）>班上的属性

然后就走了。正如荷马所说的那样 - D''哦


问题的根源在于VB实现事件的方式和事实

你可以不适用< NonSerialized>归因于小流氓。

结果是当你序列化ObjectA时有一个事件

EventX由ObjectB中的方法处理，ObjectB被序列化为右

以及ObjectA。


如果你不相信我，请继续尝试。使用事件和一些私有字段创建一个可序列化的类

。创建一个声明一个实例的表单

该类并处理该事件（使用withevents或addhandler - 不是
）。现在尝试序列化该类的实例 - 你会得到一个

序列化异常，因为表单（不是你想要的类b
序列化）不是'可序列化！


公平，你可以说。这不应该是一个大问题 - 在序列化之前只需删除

事件处理程序。我为什么要这样做？我甚至不能确定它是否可靠（因为我无法告诉谁已经附加到我的

事件 - 它可能是一些我无法控制的客户端如果你有一个自定义的对象集合

（比如定期触发事件的触发对象），另一个问题就变得很明显了。

触发器的集合有它自己的事件，当它触发任何触发器时，它会引发火灾。一个简单的（但也可能不是最好的）实现该集合的方法是使用addhandler连接到触发器'

事件时将其添加到采集。现在，猜猜当你尝试

并序列化集合时会发生什么 - 它有效！哇噢！现在尝试反序列化

吧。再次D''哦。这次你得到一个例外，因为你不能为了安全原因而将一个委托反序列化为一个私人方法！


在我的旅行中我已经有很多关于如何解决这个问题的建议和

我自己想出了一些解决方案。这里有一些和他们的

利弊：


1）实施ISerializable并且不要序列化事件。

优点：工作原理

缺点：工作太多 - 每次添加要序列化的字段时，都必须更改GetObjectData方法和

构造函数。

2）实现ISerializationSurrogate去除事件：

优点：Dunno

缺点：因为二进制格式化程序和肥皂而非常复杂br />
格式化程序不允许你指定代理人，所以你最终还是重写了

。


3）在基类中实现ISerializable并使用反射来获取派生类中的所有

私有字段

优点：它的工作原理

缺点：它'' sa hack


4）在C＃Base类中实现事件

优点：您可以为事件指定[NonSerialized]属性

缺点：你的逻辑分布在两个项目中和两种语言。

正如你所看到的。我非常厌倦了事件。我意识到

< NonSerialized>属性不能应用于事件可能是一个

疏忽，可能会在下一个版本中修复。这么说，可以

任何人都会想到为什么你想要序列化一个事件

（以及处理其事件的所有对象）的正当理由呢？

感谢你忍受这个猴子漫步。我要去学习C＃;）


干杯，


Trev。

Heya All,

Sorry, but I think it''s about time for a monkey-ramble.

I''ve just had enough of trying to serialize even simple objects with VB. A
simple task you may think - stick the <Serialized()> attribute on the class
and away you go. As Homer would say - "D''Oh"

The root of my problem lies in the way VB implements Events and the fact
that you can''t apply the <NonSerialized> attribute to the little rascals.
The result of this is that when you serialize ObjectA that has an event
EventX being handled by a method in ObjectB, ObjectB gets serialized right
along with ObjectA.

If you don''t believe me, go ahead and try it. Create a serializable class
with an event and some private fields. Create a form an declare an instance
of the class and handle the event (with withevents or addhandler - doesn''t
matter). Now try and serialize the instance of the class - you''ll get a
serialization exception because the form (not the class you''re trying to
serialize) isn''t serializable!

Fair enough, you may say. This shouldn''t be a big problem - just remove
event handlers before serializing. Why should I have to do this? I can''t
even do it reliably (because I have no way of telling who has attached to my
events - it could be some client that I have no control over).

Another problem becomes apparent if you have a custom collection of objects
(say Trigger objects that fire an event periodically). The Collection of
triggers has it''s own event which is raised when any of the triggers it
contains fires. A simple (but admittedly probably not the best) way to
implement the collection would be to use addhandler to attach to a trigger''s
event when adding it to the collection. Now, guess what happens when you try
and serialize the collection - it works! WooHoo!. Now try and deserialize
it. Again "D''Oh". This time you get an exception because you can''t
deserialize a delegate to a private method for security reasons!

In my travels I''ve had many suggestions about how to get around this and
have come up with some solutions on my own. Here are a few of them and their
pros and cons:

1) Implement ISerializable and don''t serialize the events.
Pros: It Works
Cons: Too much work - have to change the GetObjectData method and
Constructor every time I add a field that is to be serialized.
2) Implement an ISerializationSurrogate to strip out the events:
Pros: Dunno
Cons: Pretty complicated to do because the Binary Formatter and Soap
Formatter don''t allow you to specify surrogates, so you end up re-writing
them too.

3) Implement ISerializable in a base class and use reflection to get all
private fields in derived classes
Pros: It works
Cons: It''s a hack

4) Implement the events in a C# Base class
Pros: You can specify the [NonSerialized] attribute to the event
Cons: Your logic is spread across two projects and two languages.
As you can see. I''m mighty fed up with events. I realize that the fact that
the <NonSerialized> attribute can''t be applied to events is probably an
oversight and will probably be fixed in the next version. Saying that, can
anybody think of a valid reason why you would want to serialize an event
(and all objects that handle its events) anyway?
Thanks for putting up with this monkey-ramble. I''m off to learn C# ;)

Cheers,

Trev.

推荐答案

Codemonkey，

Codemonkey,

正如您所见。我非常厌倦了事件。我意识到
的事实< NonSerialized>属性不能应用于事件可能是一种疏忽，可能会在下一版本中修复。这么说，无论如何，任何人都可以想到为什么你想要序列化事件
（以及处理其事件的所有对象）的正当理由？
一旦他们说你不能，就会有人提出正当理由;-)

1）实施ISerializable并且不要序列化事件。
这是我一直在使用的那个，因为我需要ISerializable用于其他目的

并在活动部分幸运;-)

2 ）实现一个ISerializationSurrogate去除事件：
我认为这是＃1的变体，仅在第二个类中。

3）在基类中实现ISerializable并使用反射来获取派生类中的所有
私有字段
Reflection或SerializationServices？我的印象是你可以使用当前类中的
SerializationServices。当然，您可能需要修剪SerializationServices.GetSerializableMembers返回的数组，然后我会认为实现所有逻辑会更容易

你自己...


希望这会有所帮助，

Jay


Codemonkey <胡********* @ hotmail.com>在消息中写道

新闻：大江************** @ TK2MSFTNGP12.phx.gbl ... Heya All，

对不起，但是我认为这是一个漫步的时间。

我已经有足够的尝试用VB来序列化甚至简单的对象。你可能会想到一个简单的任务 - 坚持< Serialized（）>
级别的属性，你离开。正如荷马所说的那样 - D''哦

问题的根源在于VB实现事件的方式以及你不能应用< NonSerialized>的事实
;属性为小流氓。
这样做的结果是当你序列化ObjectA时，ObjectB会有一个事件由ObjectB中的方法处理，而ObjectB会与ObjectA一起被序列化。

如果你不相信我，请继续尝试。使用事件和一些私有字段创建一个可序列化的类
。创建一个表单，声明该类的
实例并处理该事件（使用withevents或addhandler - 不重要）。现在尝试序列化该类的实例 - 你会得到一个序列化异常，因为表单（不是你想要序列化的类）是不可序列化的！

你可能会说，够公平。这不应该是一个大问题 - 只需在序列化之前删除
事件处理程序。我为什么要这样做？我甚至不能可靠地做到这一点（因为我无法告诉谁已经附加了
我的事件 - 它可能是一些我无法控制的客户）。
<如果您有
对象的自定义集合（比如定期触发事件的Trigger对象），则另一个问题变得明显。
触发器的集合具有它自己的事件，当它触发任何触发器时会引发它。实现集合的一种简单（但可能不是最好的）方法是在将其添加到集合时使用addhandler附加到
触发器的事件。现在，猜猜当你
尝试序列化集合时会发生什么 - 它有效！哇噢！现在尝试反序列化它。再次D''哦。这次你得到一个例外，因为出于安全原因你不能将代表反序列化为私有方法！

在我的旅行中我有很多关于如何到处走动的建议这个和我自己想出了一些解决方案。以下是他们中的一些和
他们的利弊：

1）实施ISerializable并且不要将事件序列化。
优点：它的工作原理
：太多工作 - 每次添加要序列化的字段时都必须更改GetObjectData方法和
构造函数。

2）实现ISerializationSurrogate去除事件：缺点：因为二进制格式化程序和肥皂格式化程序不允许你指定代理人，所以很复杂，所以你最终也会重写它们。

3）在基类中实现ISerializable并使用反射来获取派生类中的所有
私有字段
优点：它的工作原理
缺点：它是一个黑客

4）在C＃Base类中实现事件
优点：您可以为事件指定[NonSerialized]属性
缺点：您的逻辑分布在两个项目和两个项目中语言。

正如你所看到的。我非常厌倦了事件。我意识到
的事实< NonSerialized>属性不能应用于事件可能是一种疏忽，可能会在下一版本中修复。这么说，无论如何，任何人都可以想出你为什么要序列化事件
（以及处理其事件的所有对象）的有效理由？

感谢您忍受这个猴子漫步。我要去学习C＃;）

干杯，

Trev。

As you can see. I''m mighty fed up with events. I realize that the fact that the <NonSerialized> attribute can''t be applied to events is probably an
oversight and will probably be fixed in the next version. Saying that, can
anybody think of a valid reason why you would want to serialize an event
(and all objects that handle its events) anyway? As soon as they say you cannot, someone will come up with a valid reason ;-)
1) Implement ISerializable and don''t serialize the events. This is the one I''ve been using as I needed ISerializable for other purposes
and lucked out on the event part of it ;-)
2) Implement an ISerializationSurrogate to strip out the events: I consider this a variation of #1, only in a second class.
3) Implement ISerializable in a base class and use reflection to get all
private fields in derived classes Reflection or SerializationServices? I was under the impression you can use
SerializationServices from the current class. Granted you may need to trim
the array that SerializationServices.GetSerializableMembers returned,
however I would think that would be easier then implementing all the logic
yourself...

Hope this helps,
Jay

"Codemonkey" <hu*********@hotmail.com> wrote in message
news:Oe**************@TK2MSFTNGP12.phx.gbl... Heya All,

Sorry, but I think it''s about time for a monkey-ramble.

I''ve just had enough of trying to serialize even simple objects with VB. A
simple task you may think - stick the <Serialized()> attribute on the class and away you go. As Homer would say - "D''Oh"

The root of my problem lies in the way VB implements Events and the fact
that you can''t apply the <NonSerialized> attribute to the little rascals.
The result of this is that when you serialize ObjectA that has an event
EventX being handled by a method in ObjectB, ObjectB gets serialized right
along with ObjectA.

If you don''t believe me, go ahead and try it. Create a serializable class
with an event and some private fields. Create a form an declare an instance of the class and handle the event (with withevents or addhandler - doesn''t
matter). Now try and serialize the instance of the class - you''ll get a
serialization exception because the form (not the class you''re trying to
serialize) isn''t serializable!

Fair enough, you may say. This shouldn''t be a big problem - just remove
event handlers before serializing. Why should I have to do this? I can''t
even do it reliably (because I have no way of telling who has attached to my events - it could be some client that I have no control over).

Another problem becomes apparent if you have a custom collection of objects (say Trigger objects that fire an event periodically). The Collection of
triggers has it''s own event which is raised when any of the triggers it
contains fires. A simple (but admittedly probably not the best) way to
implement the collection would be to use addhandler to attach to a trigger''s event when adding it to the collection. Now, guess what happens when you try and serialize the collection - it works! WooHoo!. Now try and deserialize
it. Again "D''Oh". This time you get an exception because you can''t
deserialize a delegate to a private method for security reasons!

In my travels I''ve had many suggestions about how to get around this and
have come up with some solutions on my own. Here are a few of them and their pros and cons:

1) Implement ISerializable and don''t serialize the events.
Pros: It Works
Cons: Too much work - have to change the GetObjectData method and
Constructor every time I add a field that is to be serialized.
2) Implement an ISerializationSurrogate to strip out the events:
Pros: Dunno
Cons: Pretty complicated to do because the Binary Formatter and Soap
Formatter don''t allow you to specify surrogates, so you end up re-writing
them too.

3) Implement ISerializable in a base class and use reflection to get all
private fields in derived classes
Pros: It works
Cons: It''s a hack

4) Implement the events in a C# Base class
Pros: You can specify the [NonSerialized] attribute to the event
Cons: Your logic is spread across two projects and two languages.
As you can see. I''m mighty fed up with events. I realize that the fact that the <NonSerialized> attribute can''t be applied to events is probably an
oversight and will probably be fixed in the next version. Saying that, can
anybody think of a valid reason why you would want to serialize an event
(and all objects that handle its events) anyway?
Thanks for putting up with this monkey-ramble. I''m off to learn C# ;)

Cheers,

Trev.

是的，我也注意到了......

我有一个需要序列化的类，另一个有事件的类

不能序列化

我有一个类的参考，在头等舱的事件，我必须

在序列化之前分离任何事件处理程序...与你的相反

问题....丑陋的事情

-

干杯，

Crirus


- ----------------------------

如果工作是好事，那么老板就会把它全部拿走你好


------------------------------

" Codemonkey" <胡********* @ hotmail.com>在消息中写道

新闻：大江************** @ TK2MSFTNGP12.phx.gbl ...

Yeah, I noticed that too...
I have a class that need to be serialised, and another class with events
not to be serialised
I have a reference of the class with events in first class and I have to
detach any event handler before serialisation ... the opposite to your
issue.... ugly thing
--
Cheers,
Crirus

------------------------------
If work were a good thing, the boss would take it all from you

------------------------------

"Codemonkey" <hu*********@hotmail.com> wrote in message
news:Oe**************@TK2MSFTNGP12.phx.gbl...

Heya All，

很抱歉，但我认为这是一个漫步的时间。

我已经有足够的尝试使用VB序列化甚至简单的对象。你可能会想到一个简单的任务 - 坚持< Serialized（）>
级别的属性，你离开。正如荷马所说的那样 - D''哦

问题的根源在于VB实现事件的方式以及你不能应用< NonSerialized>的事实
;属性为小流氓。
这样做的结果是当你序列化ObjectA时，ObjectB会有一个事件由ObjectB中的方法处理，而ObjectB会与ObjectA一起被序列化。

如果你不相信我，请继续尝试。使用事件和一些私有字段创建一个可序列化的类
。创建一个表单，声明该类的
实例并处理该事件（使用withevents或addhandler - 不重要）。现在尝试序列化该类的实例 - 你会得到一个序列化异常，因为表单（不是你想要序列化的类）是不可序列化的！

你可能会说，够公平。这不应该是一个大问题 - 只需在序列化之前删除
事件处理程序。我为什么要这样做？我甚至不能可靠地做到这一点（因为我无法告诉谁已经附加了
我的事件 - 它可能是一些我无法控制的客户）。
<如果您有
对象的自定义集合（比如定期触发事件的Trigger对象），则另一个问题变得明显。
触发器的集合具有它自己的事件，当它触发任何触发器时会引发它。实现集合的一种简单（但可能不是最好的）方法是在将其添加到集合时使用addhandler附加到
触发器的事件。现在，猜猜当你
尝试序列化集合时会发生什么 - 它有效！哇噢！现在尝试反序列化它。再次D''哦。这次你得到一个例外，因为出于安全原因你不能将代表反序列化为私有方法！

在我的旅行中我有很多关于如何到处走动的建议这个和我自己想出了一些解决方案。以下是他们中的一些和
他们的利弊：

1）实施ISerializable并且不要将事件序列化。
优点：它的工作原理
：太多工作 - 每次添加要序列化的字段时都必须更改GetObjectData方法和
构造函数。

2）实现ISerializationSurrogate去除事件：缺点：因为二进制格式化程序和肥皂格式化程序不允许你指定代理人，所以很复杂，所以你最终也会重写它们。

3）在基类中实现ISerializable并使用反射来获取派生类中的所有
私有字段
优点：它的工作原理
缺点：它是一个黑客

4）在C＃Base类中实现事件
优点：您可以为事件指定[NonSerialized]属性
缺点：您的逻辑分布在两个项目和两个项目中语言。

正如你所看到的。我非常厌倦了事件。我意识到
的事实< NonSerialized>属性不能应用于事件可能是一种疏忽，可能会在下一版本中修复。这么说，无论如何，任何人都可以想出你为什么要序列化事件
（以及处理其事件的所有对象）的有效理由？

感谢您忍受这个猴子漫步。我要去学习C＃;）

干杯，

Trev。

Heya All,

Sorry, but I think it''s about time for a monkey-ramble.

I''ve just had enough of trying to serialize even simple objects with VB. A
simple task you may think - stick the <Serialized()> attribute on the class and away you go. As Homer would say - "D''Oh"

The root of my problem lies in the way VB implements Events and the fact
that you can''t apply the <NonSerialized> attribute to the little rascals.
The result of this is that when you serialize ObjectA that has an event
EventX being handled by a method in ObjectB, ObjectB gets serialized right
along with ObjectA.

If you don''t believe me, go ahead and try it. Create a serializable class
with an event and some private fields. Create a form an declare an instance of the class and handle the event (with withevents or addhandler - doesn''t
matter). Now try and serialize the instance of the class - you''ll get a
serialization exception because the form (not the class you''re trying to
serialize) isn''t serializable!

Fair enough, you may say. This shouldn''t be a big problem - just remove
event handlers before serializing. Why should I have to do this? I can''t
even do it reliably (because I have no way of telling who has attached to my events - it could be some client that I have no control over).

Another problem becomes apparent if you have a custom collection of objects (say Trigger objects that fire an event periodically). The Collection of
triggers has it''s own event which is raised when any of the triggers it
contains fires. A simple (but admittedly probably not the best) way to
implement the collection would be to use addhandler to attach to a trigger''s event when adding it to the collection. Now, guess what happens when you try and serialize the collection - it works! WooHoo!. Now try and deserialize
it. Again "D''Oh". This time you get an exception because you can''t
deserialize a delegate to a private method for security reasons!

In my travels I''ve had many suggestions about how to get around this and
have come up with some solutions on my own. Here are a few of them and their pros and cons:

1) Implement ISerializable and don''t serialize the events.
Pros: It Works
Cons: Too much work - have to change the GetObjectData method and
Constructor every time I add a field that is to be serialized.
2) Implement an ISerializationSurrogate to strip out the events:
Pros: Dunno
Cons: Pretty complicated to do because the Binary Formatter and Soap
Formatter don''t allow you to specify surrogates, so you end up re-writing
them too.

3) Implement ISerializable in a base class and use reflection to get all
private fields in derived classes
Pros: It works
Cons: It''s a hack

4) Implement the events in a C# Base class
Pros: You can specify the [NonSerialized] attribute to the event
Cons: Your logic is spread across two projects and two languages.
As you can see. I''m mighty fed up with events. I realize that the fact that the <NonSerialized> attribute can''t be applied to events is probably an
oversight and will probably be fixed in the next version. Saying that, can
anybody think of a valid reason why you would want to serialize an event
(and all objects that handle its events) anyway?
Thanks for putting up with this monkey-ramble. I''m off to learn C# ;)

Cheers,

Trev.

您好CodeMonkey，


这是未来产品增强的好主意。我建议您将建议转发给Microsoft Wish Program：


Microsoft提供了几种方式来发送有关
Microsoft产品。如果您希望在未来版本的Microsoft产品中看到产品增强功能，请

使用本文后面列出的方法之一与我们联系。


告诉我们如何改进产品。


产品增强建议包括：


对现有产品的改进。

"有关其他功能的建议。

"如何使产品更易于使用。


万维网 - 要通过网络发送评论或建议，请使用以下方法之一

：


"在Internet Explorer 6中，单击帮助菜单上的发送反馈，然后单击

单击出现的页面的产品建议部分中的链接。

"在Windows XP中，单击开始菜单上的帮助和支持。单击发送您的

反馈给Microsoft，然后填写产品建议页面

出现。

"访问以下Microsoft网站： http://www.microsoft.com/ms.htm

"单击页面右上角的Microsoft.com指南，然后单击联系我们。
单击联系我们。单击出现的

页面的Product Suggestion部分中的链接。

"访问以下Microsoft产品反馈网站：

" http://register.microsoft.com/mswish/suggestion.asp"然后填写并提交表格

。


电子邮件 - 要通过电子邮件发送评论或建议，请使用以下

Microsoft Wish Program电子邮件地址， ms****@microsoft.com 。

传真 - 要通过传真发送评论或建议，请使用以下Microsoft

传真号码，[phone]。


阅读每个产品建议由我们的产品反馈团队成员，分类为
以便于访问，并路由到产品或服务团队以获得微软产品和/或服务改进。因为我们收到了大量的建议（每年超过69,000条建议！）我们不能保证每个请求都成为最终产品或服务。但是

我们可以告诉你，每个建议都已经收到，并且是由最有能力解决它的团队审核的。


收到的所有产品或服务建议都是微软的唯一财产。如果有任何建议，微软没有义务提供赔偿。

问候，

Peter Huang

Microsoft在线合作伙伴支持

安全！ www.microsoft.com/security

此帖子是提供按原样没有保证，也没有赋予任何权利。

Hi CodeMonkey,

This is a great idea for a future product enhancement. I''d recommend that
you forward the recommendation to the Microsoft Wish Program:

Microsoft offers several ways for you to send comments or suggestions about
Microsoft products. If you have suggestions for product enhancements that
you would like to see in future versions of Microsoft products, please
contact us using one of the methods listed later in this article.

Let us know how we can improve our products.

Product Enhancement suggestions can include:

" Improvements on existing products.
" Suggestions for additional features.
" Ways to make products easier to use.

World Wide Web - To send a comment or suggestion via the Web, use one of
the following methods:

" In Internet Explorer 6, click Send Feedback on the Help menu and then
click the link in the Product Suggestion section of the page that appears.
" In Windows XP, click Help and Support on the Start menu. Click Send your
feedback to Microsoft, and then fill out the Product Suggestion page that
appears.
" Visit the following Microsoft Web site: http://www.microsoft.com/ms.htm
" Click Microsoft.com Guide in the upper-right corner of the page and then
click Contact Us . Click the link in the Product Suggestion section of the
page that appears.
" Visit the following Microsoft Product Feedback Web site:
"http://register.microsoft.com/mswish/suggestion.asp" and then complete and
submit the form.

E-mail - To send comments or suggestions via e-mail, use the following
Microsoft Wish Program e-mail address, ms****@microsoft.com.
FAX - To send comments or suggestions via FAX, use the following Microsoft
FAX number, [phone].

Each product suggestion is read by a member of our product feedback team,
classified for easy access, and routed to the product or service team to
drive Microsoft product and/or service improvements. Because we receive an
abundance of suggestions (over 69,000 suggestions a year!) we can''t
guarantee that each request makes it into a final product or service. But
we can tell you that each suggestion has been received and is being
reviewed by the team that is most capable of addressing it.

All product or service suggestions received become the sole property of
Microsoft. Should a suggestion be implemented, Microsoft is under no
obligation to provide compensation.
Regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

这篇关于序列化 - Pesky VB的事件实现。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！