Problem with Persistance of object type between apps 
Author Message
 Problem with Persistance of object type between apps

I've got an interesting little problem.....
I have two apps, which trade data using UDP sockets to send objects as
byte arrays between themselves. The actual sending/receiving of the data
is fine, but when I try to translate the data at the receiving end back
into an object, the second app (which has no way of knowing anything
about the first) cannot convert the bytearray back into an object.
Here's some pseudo-code....

App1:
MyObject_Class is defined as a simple class file.
MyObject as new MyObject_Class
Convert MyObject into a byte().
Send MyObject() to App2.

App2:
MyObject_Class is defined (this class file is a copy of the class
definition from app1 (above).
MyObject() is detected when it arrived at the socket.
MyObject() is attempted to convert into a generic object--This fails,
citing that "File or assembly name App1, or one of its dependencies, is
not found".

I'm guessing that what is happening here is that the byte() containing
the object *also* contains some indication of what the object
was--referring to the application it was created in (app1). However,
when I attempt to reconstruct the object in app2, it doesn't realize
that it should use the class definition in app2--and fails.

Is there a way for me to "force" the app2 to realize that it can use
it's local class definition to do this, or is there a simpler way.
Please note that the UDP (non-remoting) of this project is not
changeable for a reason.

--
==================================================
Sam J. Marrocco



Thu, 24 Mar 2005 02:21:28 GMT  
 Problem with Persistance of object type between apps
Hi, how are you serializing the object before you send it? Have you tried
using the default serialization methods? That might fix the problem.

The steps are:
* If you have custom way to serialize your object, you can look at the
documentation. If you just want to quickly convert you object to a byte
array using Serialization, in MyObject_Class, mark the class with
<Serializable()> attribute.
* Dim up a System.Runtime.Serialization.Formatters.Binary.BinaryFormatter a
MemoryStream and use BinaryFormatter.Serialize(MemoryStream, MyObject).
* Call MemoryStream.ToArray() to get back the Byte array that you're going
to send out.
* On the other machine, receive the stream, and call
BinaryFormatter.Deserialize(Stream) to get back your object.

Hope it help.
--

This posting is provided "AS IS" with no warranties, and confers no rights.

Quote:
> I've got an interesting little problem.....
> I have two apps, which trade data using UDP sockets to send objects as
> byte arrays between themselves. The actual sending/receiving of the data
> is fine, but when I try to translate the data at the receiving end back
> into an object, the second app (which has no way of knowing anything
> about the first) cannot convert the bytearray back into an object.
> Here's some pseudo-code....

> App1:
> MyObject_Class is defined as a simple class file.
> MyObject as new MyObject_Class
> Convert MyObject into a byte().
> Send MyObject() to App2.

> App2:
> MyObject_Class is defined (this class file is a copy of the class
> definition from app1 (above).
> MyObject() is detected when it arrived at the socket.
> MyObject() is attempted to convert into a generic object--This fails,
> citing that "File or assembly name App1, or one of its dependencies, is
> not found".

> I'm guessing that what is happening here is that the byte() containing
> the object *also* contains some indication of what the object
> was--referring to the application it was created in (app1). However,
> when I attempt to reconstruct the object in app2, it doesn't realize
> that it should use the class definition in app2--and fails.

> Is there a way for me to "force" the app2 to realize that it can use
> it's local class definition to do this, or is there a simpler way.
> Please note that the UDP (non-remoting) of this project is not
> changeable for a reason.

> --
> ==================================================
> Sam J. Marrocco



Sat, 26 Mar 2005 04:22:51 GMT  
 Problem with Persistance of object type between apps
I am assuming that the .NET Runtime is having problems re-serializing your
object because the assembly and class identity from within App1 and App2 are
different--even though your class name and class code files are the same. If
you put the MyObject_Class into a shared assembly and then reference a copy
of the same DLL from both sides, you won't run into object/class identity
issues when deserializing.

To do this, create a new Class Library project, put your class in it and
make sure that the class is declared Public. Name the Assembly whatever you
wish and then go reference it from App1 and App2.

Alternatively, you can perform custom serialization and deserialization, but
that is beyond the scope of what I could describe here. If the above doesn't
work, check back and we can talk about how to perform custom serialization
of objects.

Hope this helps.
John & John
The VB Team

--
This posting is provided "AS IS" with no warranties, and confers no rights.

Quote:
> I've got an interesting little problem.....
> I have two apps, which trade data using UDP sockets to send objects as
> byte arrays between themselves. The actual sending/receiving of the data
> is fine, but when I try to translate the data at the receiving end back
> into an object, the second app (which has no way of knowing anything
> about the first) cannot convert the bytearray back into an object.
> Here's some pseudo-code....

> App1:
> MyObject_Class is defined as a simple class file.
> MyObject as new MyObject_Class
> Convert MyObject into a byte().
> Send MyObject() to App2.

> App2:
> MyObject_Class is defined (this class file is a copy of the class
> definition from app1 (above).
> MyObject() is detected when it arrived at the socket.
> MyObject() is attempted to convert into a generic object--This fails,
> citing that "File or assembly name App1, or one of its dependencies, is
> not found".

> I'm guessing that what is happening here is that the byte() containing
> the object *also* contains some indication of what the object
> was--referring to the application it was created in (app1). However,
> when I attempt to reconstruct the object in app2, it doesn't realize
> that it should use the class definition in app2--and fails.

> Is there a way for me to "force" the app2 to realize that it can use
> it's local class definition to do this, or is there a simpler way.
> Please note that the UDP (non-remoting) of this project is not
> changeable for a reason.

> --
> ==================================================
> Sam J. Marrocco



Sat, 26 Mar 2005 05:02:42 GMT  
 Problem with Persistance of object type between apps

Quote:

> Hi, how are you serializing the object before you send it? Have you tried
> using the default serialization methods? That might fix the problem.

I'm using the default serialization methods.

Quote:
> The steps are:
> * If you have custom way to serialize your object, you can look at the
> documentation. If you just want to quickly convert you object to a byte
> array using Serialization, in MyObject_Class, mark the class with
> <Serializable()> attribute.
> * Dim up a System.Runtime.Serialization.Formatters.Binary.BinaryFormatter a
> MemoryStream and use BinaryFormatter.Serialize(MemoryStream, MyObject).
> * Call MemoryStream.ToArray() to get back the Byte array that you're going
> to send out.
> * On the other machine, receive the stream, and call
> BinaryFormatter.Deserialize(Stream) to get back your object.

You've just described *exactly* how I'm serializing my object (and
deserializing it).

THis definitely has to do with one app "stamping" a signature onto the
object type itself--which the second app can't decipher. Another
response to my posting seems to describe what I was suspicious of, but I
was hoping to keep *source code* shared between apps--instead of having
to resort to a "third" assembly that is used by the other two apps. That
may be my only option for this.....

--
==================================================
Sam J. Marrocco
Sr. Visual Effects Artist/R&D
Inferno, Flame, Houdini, All that cool stuff!
Travelling Pictures/GTN
"Always remember to pillage BEFORE you burn"
==================================================



Sat, 26 Mar 2005 05:53:02 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Object Type in Object dialog box problem

2. Persistance of objects

3. Object Persistance/Serialization

4. Object persistance

5. Object Persistance and Focus

6. PublicNotCreatable object collection persistance

7. Object property persistance

8. Object persistance without the PropBag?

9. Object Persistance to DB

10. someone please explain object persistance

11. Object persistance

12. ActiveX Exe Persistance problem

 

 
Powered by phpBB® Forum Software