 J# interop design flaw? -
10-31-2003
, 09:03 AM
Being in the process of migrating to J# a rather big J++
distributed application with J++ code both on clients and
as COM+ components I have run into the following problem:
In J++ a JActiveX generated interface with a
com.ms.com.Variant argument would be COM-marshalled as the
COM type VARIANT. In J# using the same interface the
argument will be marshalled to COM directly as
com.ms.com.Variant. When using J# on both sides, this
seems to be funtionally equivalent as long as methods are
called In Process. However, when calling Out of Process
the remoting framework tries to serialize
com.ms.com.Variant and throws
System.Runtime.Serialization.SerializationExceptio n:
The type com.ms.com.Variant in Assembly vjslib,
Version=1.0.5000.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a is not marked as
serializable.
This makes it impossible to call a J# assembly with a
method with Variant arguments installed as a Server
component in COM+. At least as long as you call from a
client J# assembly with the same JActiveX generated
interface.
Is this a design flaw or is there some way to get around
this? A simple solution would have been to let the
com.ms.com.Variant class be serializable. The same
reasoning goes for com.ms.com.SafeArray.
The only way I see around this (except for rewriting large
amounts of legacy code which J# was intended to save me
from!) is to use RealProxy and intercept all method calls
to the server. Variant and SafeArray arguments could be
wrapped in a serializable class and all arguments could be
marshalled over to a Dispatcher class on the server which
could unwrap Variants and SafeArrays and then invoke the
method In Process. But should this really be neccessary?
Any advice is welcome.
/Ulf Werner
 |
Linear Mode
