I don't understand how the ISerializable interface helps, since by the time the special constructor is called the decision on which type to load has already been determined. Here's the scenario...I have an interface IProfile, and two implementations SimpleProfile and AdvancedProfile. They are all in the same strongly-named assembly with version number 1.0.0.0. I persist instances of SimpleProfile and AdvancedProfile to a database. My application occasionally deserializes the object from the database and casts it to an IProfile reference. My understanding is that the version number, public key token, culture, assembly name, etc are included in the serialization stream and that the formatters use that information to load the appropriate type and then call the special constructor and GetObjectData method. If I release version 2.0.0.0 of my assembly and want to upgrade my application, assuming that both versions of the assembly are on the machine, I can still deserialize the object, but it will be a version 1.0.0.0 object and when I try to cast to the version 2.0.0.0 IProfile interface it will throw an exception. If I upgrade to version 2.0.0.0 and uninstall version 1.0.0.0 then I don't think I can even deserialize the object, since the version number is embedded in the serialized stream.
Does the ISerializable interface somehow let you change the object that results from the serialization process? Thanks, Paul On Sat, 6 Jul 2002 10:29:03 -0400, Craig Andera <[EMAIL PROTECTED]> wrote: >Serialization has no way of inherently dealing with version issues. And >interfaces don't come in to it - serialization looks at your object's >internal state via reflection (or a similar mechanism - I don't know >that it uses reflection per se). > >The best way to deal with this problem is to implement ISerializable and >implement the two methods (ISerializable::GetObjectData and a private >constructor) that are required for serialization. > >It's really pretty easy - they give you a property bag, and you write >stuff to it as a series of name-value pairs. The tough part comes in >when you try to rectify the delta between the old object that was saved, >and the new one that you're trying to create. But since only you could >possibly know how to do this, the runtime leaves it up to you. > >> -----Original Message----- >> From: Moderated discussion of advanced .NET topics. [mailto:ADVANCED- >> [EMAIL PROTECTED]] On Behalf Of Paul Currit >> Sent: Friday, July 05, 2002 2:31 PM >> To: [EMAIL PROTECTED] >> Subject: [ADVANCED-DOTNET] Serialization and assembly version >redirection >> >> I am persisting objects to a database using the BinaryFormatter. When >> inserting new objects, I call BinaryFormatter.Serialize and store the >> object as a byte array in a database table. When getting an object out >of >> the table I use BinaryFormatter.Deserialize to convert the byte array >back >> into the object. If the version of the assembly containing the >> serializable type changes, can the serialized object in the database >be >> deserialized with the newer version. In other words, is there any way >to >> deserialize objects that were originally serialized under a different >> version number, as long as the type's interface hasn't changed? Is >this >> even an appropriate use of the BinaryFormatter, since it is typically >used >> for ephemeral objects and not persistence? >> >> I've tried using the <assemblyBinding> config section, but in my >tests, >> deserialization is ignoring the assembly version redirection. >> >> You can read messages from the Advanced DOTNET archive, unsubscribe >from >> Advanced DOTNET, or >> subscribe to other DevelopMentor lists at http://discuss.develop.com. > >You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or >subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
