Home Library Learn Downloads Support Community
Sign in | United States - English | |
This topic has not yet been rated - Rate this topic

Exception.SerializeObjectState Event

.NET Framework 4

Occurs when an exception is serialized to create an exception state object that contains serialized data about the exception.

Namespace:  System
Assembly:  mscorlib (in mscorlib.dll)
C#
C++
F#
VB
Copy 
protected event EventHandler<SafeSerializationEventArgs> SerializeObjectState

The exception state object implements the ISafeSerializationData interface.

When the SerializeObjectState event is subscribed to, the exception is deserialized and created as an empty exception. The exception's constructor is not run, and the exception state is also deserialized. The CompleteDeserialization callback method of the exception state object is then notified so that it can push deserialized data into the empty exception.

The SerializeObjectState event enables transparent exception types to serialize and deserialize exception data. Transparent code can execute commands within the bounds of the permission set it is operating within, but cannot execute, call, derive from, or contain critical code.

If the SerializeObjectState event is not subscribed to, deserialization occurs as usual using the Exception constructor.

Notes to Implementers

If this event is subscribed to and used, all derived types that follow in the inheritance hierarchy must implement the same serialization mechanism.

.NET Framework

Supported in: 4

.NET Framework Client Profile

Supported in: 4

Windows 7, Windows Vista SP1 or later, Windows XP SP3, Windows Server 2008 (Server Core not supported), Windows Server 2008 R2 (Server Core supported with SP1 or later), Windows Server 2003 SP2

The .NET Framework does not support all versions of every platform. For a list of the supported versions, see .NET Framework System Requirements.
Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
Needed for Security-Transparent Code
You do need this event when your assembly is marked with [assembly: SecurityTransparent]. This will prevent your [SecurityCritical] attributes from working at all: everything is set to transparent instead, and that means you cannot override GetObjectData() anymore.

The advantage of so marking your assembly is that this will prevent it from asserting permissions; it has to live with the permission set it is given. Just the thing for partially-trusted code. The event lets you have all this, but still serialize exception state in a custom way.
History
GetObjectData() does still work
The new code-access-security model in .NET 4 is a little more explicit; you must mark GetObjectData() with the [SecurityCritical] attribute, every time you override it. This prevents the method from being called from partial trust. .NET's serialization code seems to be trusted, however: partially trusted code can use a BinaryFormatter to serialize your exception, and it will call GetObjectData() in spite of the SecurityCriticalAttribute, provided that it has the permissions to use to formatter in the first place.

I think the idea here is that if you don't have permission to use the formatter, you can't use GetObjectData() to access private fields. As long as your code is not trying to do this, it should be safe to just mark the GetObjectData() methods with [SecurityCritical] and leave it at that.
History