Deserializing in a different assembly... how to?

[Carl Mercier]

Hi!

I have 2 different applications/assembly. The first one creates an
object and serializes it to a textfile on disk.

The second one has the the exact same class (copied/pasted). It reads
the file that is on disk and attempts to deserialize it and create a new
object.

The process works fine if I serialize/deserialize in the first
application, but it fails when I try to deserialize in the second
application. Here's the exception:

Parse Error, no assembly associated with Xml key
a1:http://schemas.microsoft.com/clr/ns...9.30011, Culture=neutral, PublicKeyToken=null
AdonisConfigDisk

Although it is generally not a good idea to copy/paste code like I did
(I should have 1 dll with the code I need), I am forced to do so for
some reasons I won't go into right now.

Here's my code... Does anyone have an idea of what I'm doing wrong? How
can I strip the assembly information from the serialized object?


public MemoryStream Serialize() {
MemoryStream stream = New MemoryStream();
SoapFormatter sf = New SoapFormatter(null, New
StreamingContext(StreamingContextStates.All));
sf.Serialize(stream, this);
stream.Seek(0, 0);
return stream;
}

public AdonisConfigDisk Deserialize(MemoryStream ms) {
SoapFormatter sf = New SoapFormatter(null, New
StreamingContext(StreamingCOntextStates.All));
return DirectCast(sf.Deserialize(ms), AdonisConfigDisk);
}


Thanks!

Carl

 

[Mickey Williams]

This is an answer I posted a few days ago on a similar issue. Short answer:
factor the common data into an assembly that can be shared. Longer answer
below:

From the runtime's point of view, the true name of a type includes the name
of the assembly that contains it. If you're using C#, and create two classes
that have the same source-level name identity (including the namespaces),
you're going to have issues. The runtime believes that type F.O.G in
assembly A is not the same type as F.O.G in assembly B. Unfortunately, (or
fortunately depending on your POV) there's no way to express that difference
in C#. The custom of my people is to factor the common types into a common
assembly.

 

[Nicholas Paldino [.NET/C# MVP]]

It should be noted that one can get around this using custom
serialization. Basically, if both implement the same custom serialization
scheme, then you would be able to get around this (implement ISerializable,
and have the custom serialization constructor).

However, I agree with Mickey, the common types should be factored out
into another assembly and that assembly referenced from both assemblies
sharing in the serialization/deserialization.

Hope this helps.