Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Hashtable compatibility 1

Status
Not open for further replies.

domenu

Programmer
May 31, 2002
30
BE
Hello everybody,

I have a little question about Serialization.

I have written an application that Serializes a Hashtable to a file on disk.

Now I want to open this serialize-file from another application, but I get an error that the assembly from where I serialized the Hashtable in the first place (=the other applic) is missing...

How can I bypass this assymbly-check on the serialized data?


Thanks in advance,


nick;

 
How did you do the serialization? Which serialization method did you use?

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first
 
I did the Serialization as follows:

FileStream fs = new FileStream(GlobalClass.SyncLog, FileMode.OpenOrCreate, FileAccess.Write);

IFormatter formatter = new BinaryFormatter();
try
{
//SyncTable is the Hashtable to serialize
formatter.Serialize(fs, SyncTable); //save entire HashTable
}
catch(SerializationException e)
{
...

I have no Assembly-information of any kind stored in this Serialization-file.

The key of the HashTable is a String, the value is a class of my own: SyncDirClass:

public class SyncDirClass : ISerializable
{
public SyncDirClass() {}

public String Status;
public String DestDir;
public DateTime dtModTime; //date and time of last modification

// The security attribute demands that code that calls
// this method have permission to perform serialization.
[SecurityPermissionAttribute(SecurityAction.Demand,SerializationFormatter=true)]
void ISerializable.GetObjectData(
SerializationInfo info, StreamingContext context)
{
info.AddValue("Status",this.Status);
info.AddValue("DestDir",this.DestDir);
info.AddValue("ModTime", this.dtModTime);
}

// The security attribute demands that code that calls
// this method have permission to perform serialization.
[SecurityPermissionAttribute(SecurityAction.Demand,SerializationFormatter=true)]
public SyncDirClass(SerializationInfo info, StreamingContext context)
{
this.Status = info.GetString("Status");
this.DestDir = info.GetString("DestDir");
this.dtModTime = info.GetDateTime("ModTime");
}

public override String ToString()
{
return "Status=" + this.Status + "// DestDir=" + this.DestDir + "// ModTime=" + this.dtModTime.ToString();
}

}//public class SyncDirClass : ISerializable

What is wrong or missing?

Thanks for the help!!

nick;
 
I believe that the Binary Formatter will store the full name of a class (it's assembly, version, strong-name, etc). So if you still have the version set to "1.0.*" in the assemblyinfo.cs class, every time you build, you get a new version, which means that unless the exact same build is available when you de-serialize from the database, you'll get this error.

Since you'll naturally be making changes to your assembly (which necessitates incrementing the version number), I don't think using the Binary Formatter is right for this use. I would write my own custom serializer so that I can control what goes in there. It would also allow me a chance to handle run-time migrations (data stored in the database is in v2.3 format, but the program reading it knows about v2.3 format, and when it writes the value back out it uses code to update the format to the most recent version .. say v2.4)

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top