As mentioned earlier, a set of well-serialized objects can have many destinations: the same process, different processes on the same machine, different processes on different machines, and so on. In some rare cases, an object may want to know where it is going to deserialize, thus generating its state in different ways. For example, for an object that wraps a Windows semaphore object, it might decide to serialize its kernel handle if it knows to deserialize it into the same process because the kernel handle is valid in a process. However, if it knows to deserialize to a different process in the same machine, it may decide to serialize the string name of the semaphore. Finally, if the object knows that he wants to deserialize a process on a different machine, an exception may be thrown because the semaphore is only valid within one machine.
Many of the methods mentioned in this chapter accept a StreamingContext. The StreamingContext structure is a very simple value type that provides only two public read-only properties.
Member name member type description
State Streamingcontextstates a set of bit flags that specify the source or destination of the object to serialize/deserialize
Context object A reference to an object that contains any context that the user wants
The way to accept a StreamingContext structure is to check the bit flags of the State property and determine the source or destination of the object to serialize/deserialize.
Specifies that the source or destination context is another process on the same computer.
crossprocess = 1,
//
Summary:
Specifies that the source or destination context is another computer.
Crossmachine = 2,
//
Summary:
Specifies that the source or destination context is a file. Users can assume that the duration of a file is longer than the process in which they were created, and that the file serializes the object in a particular way, which does not cause the deserialization process to require access to any data in the current process.
File = 4,
//
Summary:
Specifies that the source or destination context is a persistent store, which can include a database, file, or other backing store. The user can assume that the duration of the data is longer than the process that created the data, and that persistent data serializes the object in a particular way, which does not make the deserialization process require access to any data in the current process.
persistence = 8,
//
Summary:
Specifies that the data is handled remotely in the context of an unknown location. The user cannot assume that it is on the same computer.
Remoting = 16,
//
Summary:
Specifies that the serialization context is unknown.
other = 32,
//
Summary:
Specifies that the object graphic is being cloned. The user can assume that the cloned graphic will continue to exist in the same process and can safely access the handle or other reference to the unmanaged resource.
Clone = 64,
//
Summary:
Specifies that the source or destination context is another AppDomain. (For a description of the AppDomain, see Application Domains).
Crossappdomain = 128,
//
Summary:
Specifies that serialized data can be transmitted (or received from any other context) to any other context.
all = 255,
After knowing how to get this information, let's discuss how to set them up. The IFormatter interface (also BinaryFormatter and SoapFormatter type implementations) defines a property of the StreamingContext type, called context. When constructing a formatter, the formatter initializes its context property, sets Streamingcontextstates to all, and sets a reference to the extra state object to null.
Once the formatter is constructed, you can use any streamingcontextstates as a flag to construct a StreamingContext structure and optionally pass an object reference (the object contains any additional contextual information you need). Now the only thing you have to do before calling the formatter's serialize or deserialize method is to set the context property of the formatter to this new StreamingContext object.
Section Sixth: Stream context